ERROR | ugrd | [/dev/md126p8] Unable to find device mapper device with maj: 259 min: 27

[linuxandos2]

using sys-kernel/ugrd-9999
/dev/md126p8 is a partition on fakeraid raid1
ran ugrd -d see output.log

output.log

[desultory]

51cc996

this may fix that, do you know how to use a branch with 9999 ebuilds?

You should be able to do something like EGIT_OVERRIDE_BRANCH_DESULTORY_UGRD=dev emerge ugrd -1 to test this.

[linuxandos2]

still fails but later.

ugrd.log
ugrddebug.log

[desultory]

what are devices sde and sdd?

I think this must have something to do with the fakeraid. ugrd uses blkid for a lot of device info enumeration, but it seems there is no info for those devices in there.

can you share the output of blkid?

[linuxandos2]

Informational:

blkid.log
lsblk.log
mdstat.log

As you can observe there are extra /dev entries for the devices numbered higher than sdd16 are present, they belong to the raid1 md126.

what are devices sde and sdd? yes yey belong to the fake raid1 md126 (containing all root,boot partitions)

[desultory]

can this setup be initialized with mdadm --assemble --scan? that is all ugrd does at runtime.

I'm assuming the lack of blkid info can be ignored here, what actual physical devices are backing this raid array? It's somewhat important ugrd can "Trace" that info for validation, etc.

[linuxandos2]

can this setup be initialized with mdadm --assemble --scan? the initialisation is done with the Firmware (bios) the assembly occurs during boot, Because they are the boot drives it is difficult to do a mdadm: I will boot an ubuntu system on a partition of a non-raid drive, and post result.

what actual physical devices are backing this raid array they are 2 ssds of one TB.
search for "product: Samsung SSD 870" in:

lshw.log

will be back in a couple of minutes for result of mdadm

[desultory]

thanks, im wondering how ugrd can go from "mountpint /" to that nvme, the main reason being that ugrd uses that info to determine which kmods are needed.

I guess in this case, linux doesn't actually need the kmods for the nvme, since it's handled by firmware?

I've only tested using a raid controller on an older dell server, but in that case, it simply presents the device as a "normal" sata or scsi device (/sdb), which apears in blkid: /dev/sdb1: LABEL="storage" UUID="45057260-03ef-472b-ac22-7f3e94b513f3" UUID_SUB="a933cec6-c7d7-45fd-b774-ca7aea89ad9f" BLOCK_SIZE="4096" TYPE="btrfs" PARTUUID="5c391bd1-eba1-4934-a4fb-510ba8136ad1"

I think this is using this kmod tho: megaraid_sas

[linuxandos2]

Samsung SSD 870 is not a nvme
There is a nvme also: Samsung SSD 960 PRO 1TB this one is not a raidmember. (ubuntu where I did the tests is on a partition on that drive.)

Under that ubuntu I was able to stop the raid1 array with "mdadm --stop /dev/md126"
Then I was able to start again the array with "mdadm --assemble --scan"

But when I stop /dev/md126 AND /dev/md127 then
"mdadm --assemble --scan" crashes.
/dev/md127 is the ddf part of the array (external metadata)

Tests were done with and without a mdadm.conf

I also rebooted the ubuntu after renaming madam.conf, the array was present??
I don't have an idea how the assembly is done during boot.

[desultory]

I'm not entirely sure how it works either, for my tests I have some simple vms where mdraid builds a single simple group from 2 virtio devices.

ugrd doesn't copy the mdadm config into the image, but I've considered making it an option, it just didn't seem necessary in my tests. I think that config could possibly be used to define what groups to init, and how? mdadm scanning seems to work reasonably.

if you can figure out how the backing devices could be determined in your setup, and if kmods for those even matter, I'd appreciate that. In the mean time, I think I can make a patch to let it continue it it can't get device info like it needs. That detection is not fatal if it doesn't actually need to worry about the underlying devices.

[linuxandos2]

if you can figure out how the backing devices could be determined in your setup

are what you call the "backing devices" the raidmembers?.
like for the raid device "/dev/md126" the members: /dev/sdd and /dev/sde.

In that case the output of "cat /proc/mdstat" can be used:

cat /proc/mdstat 
Personalities : [raid1] [raid6] [raid5] [raid4] 
md125 : active raid5 sdh1[4] sdi1[6] sdc1[2] sdb1[1] sdf1[3] sda1[0]
      87890972160 blocks super 1.2 level 5, 512k chunk, algorithm 2 [6/6] [UUUUUU]
      bitmap: 3/131 pages [12KB], 65536KB chunk

md126 : active raid1 sdd[1] sde[0]                    <----------------this line
      975585280 blocks super external:/md127/0 [2/2] [UU]
      
md127 : inactive sdd[1](S) sde[0](S)
      2354608 blocks super external:ddf
       
unused devices: <none>

[desultory]

if you can figure out how the backing devices could be determined in your setup

are what you call the "backing devices" the raidmembers?. like for the raid device "/dev/md126" the members: /dev/sdd and /dev/sde.

In that case the output of "cat /proc/mdstat" can be used:

cat /proc/mdstat 
Personalities : [raid1] [raid6] [raid5] [raid4] 
md125 : active raid5 sdh1[4] sdi1[6] sdc1[2] sdb1[1] sdf1[3] sda1[0]
      87890972160 blocks super 1.2 level 5, 512k chunk, algorithm 2 [6/6] [UUUUUU]
      bitmap: 3/131 pages [12KB], 65536KB chunk

md126 : active raid1 sdd[1] sde[0]                    <----------------this line
      975585280 blocks super external:/md127/0 [2/2] [UU]
      
md127 : inactive sdd[1](S) sde[0](S)
      2354608 blocks super external:ddf
       
unused devices: <none>

What confuses me is that /dev/sde and /dev/sdd don't appear in blkid? or did I miss that. I normally expect that info to be in there. It may not be necessary in this case, but that's where ugrd sources info like uuids which are (often) relevant.

[linuxandos2]

I can confirm that /dev/sde and /dev/sdd don't appear in blkid, in fact if there are less than 16 partitions on the array none of the /dev/sdex and /dev/sddx partitions appear in blkid.

[desultory]

I can confirm that /dev/sde and /dev/sdd don't appear in blkid, in fact if there are less than 16 partitions on the array none of the /dev/sdex and /dev/sddx partitions appear in blkid.

yeah it's this gap in info that i'd like to address, or figure out how to be certain it's a case where it can be ignored (safely). while not used everywhere, a lot of the mount related stuff in ugrd operates under the assumption that any valid/verifiable device has blkid info, basically except for ZFS where you need to use its tools to ask it, when relevant.

[linuxandos2]

But when I stop /dev/md126 AND /dev/md127 then
"mdadm --assemble --scan" crashes.
/dev/md127 is the ddf part of the array (external metadata)

Found out how a boot recreates the /dev/ entries:
Kernels uses udev.
One can manualy recreate all /dev entries with following cmd:
udevadm trigger --action=add
The assemble of the array also occurs as a result.

udevadm info --query=all --name=/dev/sdxy (or =/dev/sdx)
also gives a lot info.
For a normal partition among a lot of info the uuid of the container raid is shown:
E: ID_FS_UUID_ENC=a6f4693e-1554-697b-5c93-edf466ac4f07
for example for /dev/sdd from the fakeraid:
E: ID_FS_UUID_ENC=LSI\x20\x20\x20\x20\x20\x80\x86\x27\xc3
for a partition < 16 on it:
Unknown device "/dev/sdd8": No such device
for a partition > 15:
no 'E: ID_FS_UUID_ENC'
but E: ID_PART_ENTRY_UUID=5643e2c3-e229-b449-8453-e0e82c615c45 among a lot of other info is present.

[desultory]

ugrd avoids using udev during boot time. does udev provide information about what "real" device is used for the RAID array? Do you know if that matters in this case?

In /sys, the RAID array is saying it's based on /dev/sdd and /dev/sde. I'd like to figure out the most straightforward way to enumerate these devices. I don't think I have any hardware to test on here.