See also:
Bug 15791 	mageiatools@ml.mageia.org 	REOP 	--- 	RAID 0 can't add 5th partition 

To the best of my knowledge this bug is still active.  If I recall correctly, I was unable to partition the RAID0 in this computer from scratch using Mageia, but did manage somehow to subvert a big windows partition (Drive D) and break it up into the partitions listed above, not touching the boundaries of existing windows stuff otherwise.  Don't recall what partitioning utility I used for this.  M6 then installed as listed above.  M7 install is in partition 7 - I can mount it in M6.  Directory structure looks normal seen from an M6 mount of it.

I just have to figure out how I save the /run/initramfs/rdsosreport.txt and post it here.  Obviously have to save it from dracut promptin failed M7 boot: it no longer exists when looking for it (in M7 partition) from M6 boot later.
Tony

Which ISO did you use to install from?

Please mount the root partition you used for your newest install and

* in case of a traditional install, fetch:
      /root/drakx/report.bug.xz from that install

* in case of a Live install:
There's a directory with a very long hexadecimal name in
 /that/root_partition's/var/log/journal/

please run, as root,

  journalctl -D /path/into/that/hexadecimal/directory/ > journal.txt

and then attach journal.txt to this bug report.
(Compress the journal with "xz journal.txt" if it's too large to attach.)

CC: (none) => isobuild, mageiatools, marja11
Keywords: (none) => NEEDINFO

The rdosreport.txt will also be useful. Use the mount command to see what, if any, partitions have been mounted or to manually mount one, and copy it there. If you manually mount a partition, unmount it before you reboot.

CC: (none) => mageia

Created attachment 11141 [details]
report.bug.xz from new M7 which fails to boot, extracted as per comment above

I haven't yet managed to get rdsosreport.txt out of the system.  Putting in a usb stick, this appears to be recognised as sdc as per stuff at dracut prompt.  I've mounted sdc on /mnt, cp the file there, see it from dracut prompt, but memstick is empty when removed.  Puzzled.  What am I doing wrong...

Created attachment 11144 [details]
generated by dracut on failed boot

attached rdsosreport.txt

Created attachment 11145 [details]
/etc/fstab

Hmm, fstab has the M7 partition (partition 7) named as I would expect in this RAID0 config.  I don't understand why dracut is complaining that a /dev/disk/by_uuid/de54b(long-string) does not exist.  I have the vague idea that by-uuid naming is an alternative in this context???

OK, /boot/grub2/grub2.cfg includes
--set=root de54b480-cb5a-4e08-87c4-1e5477e42fa4

grub2-mkconfig doesn't get this from /etc/default/grub
Must be generated by something in /etc/grub.d, possibly 10_linux?

*** Bug 25039 has been marked as a duplicate of this bug. ***

CC: (none) => mail

I've compared /etc/grub.d/10-linux and code down to uuid stuff seems identical between M6 and M7.

Attempting to compare /dev/disk/by-uuid between M6 and M7 partitions, I was surprised to find that the M7 /dev is utterly empty (looking as root from M6 with M7 partition mounted).  That can't be right - not a single device listed.

At this point I'm stuck - needs wiser folk than me!

(In reply to Tony Blackwell from comment #11)
> I've compared /etc/grub.d/10-linux and code down to uuid stuff seems
> identical between M6 and M7.

grub is finding and booting your kernel and initrd, so I doubt the problem is there.

> Attempting to compare /dev/disk/by-uuid between M6 and M7 partitions, I was
> surprised to find that the M7 /dev is utterly empty (looking as root from M6
> with M7 partition mounted).  That can't be right - not a single device
> listed.

That's normal. /dev is the mount point for the devtmpfs filesystem, which is created and populated at runtime by the kernel and udevd.

Your rdosreport.txt contains:

  + command -v dmsetup
  + dmsetup ls --tree
  No devices found

which suggests a problem. I've never used dmraid, so am on unfamiliar ground. If you remove "splash quiet" and add "rd.break" when booting Mageia 6, that would provide a rdosreport.txt to compare against.

If you mount your Mageia 7 root filesystem on, say, /mnt and as root

  chroot /mnt

then the log files produced by

  dracut -f |& tee dracut.log
  lsinitrd |& tee lsinitrd.log

might be useful.

(In reply to Martin Whitaker from comment #12)

 
>   chroot /mnt
> 
> then the log files produced by
> 
>   dracut -f |& tee dracut.log

This wont work, dracut needs /dev /proc /sys populated, and only calling with "-f" will try to match the running mga6 kernel and complain about missing modules... 

So you would need to do pass initrd file and kernel version, so something like:

dracut -f /boot/initrd-5.1.14-desktop-1.mga7.img 5.1.14-desktop-1.mga7


And you should not try to recreate the initrd you want to debug before making a backup copy so you can then compare non-working / working ...


>   lsinitrd |& tee lsinitrd.log
> 

And this wont work either as it will try to find initrd for the running mga6 kernel...

you need lsinitrd /boot/initrd-5.1.14-desktop-1.mga7.img

CC: (none) => tmb

Created attachment 11157 [details]
journal.txt (from bug 25039)

I reported an identical bug (25039) to which I already uploaded the rdsosreport.txt to:
 https://bugs.mageia.org/attachment.cgi?id=11146

After starting Mageia (and some minutes) I get the following message:
 dracut Warning: Could not boot.
 dracut Warning: /dev/mapper/isw_bhfgfajagj_Volume1p1 does not exist
 Generating "/run/initramfs/rdsosreport.txt"

Loading up journal.txt with this Comment.
Hardware specs are to follow.

Created attachment 11158 [details]
hardware (from bug 25039)

Martin: just for comparison, 

M6 booted just to # prompt, 
dmsetup ls:
isw_ggceccijf_vol0p8
isw_ggceccijf_vol0p7
isw_ggceccijf_vol0p6  etc,for the 8 partitions
 plus the parent  isw_ggceccijf_vol0

mounted M7 at /mnt/disk
chroot /mnt/disk:
unicode_start skipped on not a tty

dracut -f /boot/initrd-5.1.14-desktop-1.mga7.img 5.1.14-desktop-1.mga7
Got 2/3 screen of dracut progress stuff, 13 lines of skipping various udev rules but overall looked as a novice might expect, ending with

dracut: Stored kernel command line:
dracut: No dracut internal kernel commandline stored in the initramfs
dracut: *** Creating image file '/boot/initrd-5.1.14-desktop-1.mga7.img***
dracut: *** Creating initramfs image file '/boot/initrd-5.1.14-desktop-1.mga7.img' done ***

Thought I should maybe copy this off onto usb (sdc) but my attempts to mount /dev/disk/sdc or similar failed as /dev is empty in this chrooted environment.  Is there some more correct syntax which would mount sdc? (and would this be useful?)

lsinitrd /boot/initrd-5.1.14-desktop-1.mga7.img
got many screens of output.  Ran it again, redirected into /output.txt.
Will try rebooting M6 and see if any of this is still there in the mounted-again M7

Yes, the image file and my output.txt are both there.  
Tried booting M7 into recovery mode again, but stopped at same point as before.

Created attachment 11161 [details]
output of lsinitrd when M6 chrooted to M7 partition

after running dracut as above

Sorry, I started comment 16  with a bit in response to Martin, but didn't go on to acknowledge (obvious I hope) that the rest of it was Thomas's refinements.  Thank-you both.
Tony

from Martin's comment 12
"grub is finding and booting your kernel and initrd, so I doubt the problem is there."

Then is there a mismatch somewhere between it starting off OK, but later complains that /dev/disk/by_uuid/de54b480-cb5a-4e08-87c4-1e5477e42fa4 does not exist.  What other modality has looked for and not found it?

Might it have anything all all, or not, to do with your comment 4 years ago Thomas in bug 15791?
 Thomas Backlund 2015-05-27 16:13:09 CEST
"
Partitioning on dmraid managed raid devices should work... It atleast used to back when I used them...

Since it seems a specific <=4 is ok, but the 5th fails, I wonder if we are actually doing the partitioning (or checking) in mbr format with only primary ones, meaning we hit mbr max 4 primary...

And as it works on pre-partitioned disc where Win does switch to extended partitioning when it hits >3 partitions, we can easily add partitions in the extended section"

Something's different.
Tried booting M7 to text prompt:  Still failed with the could-not-boot message, but did get a myriad lines:
'dracut: Scanning for all btrfs devices' before it crashed,
which didn't appear before.  Probably not helpful...

Poking around from the dracut prompt, I see that /dev is now well-populated, but note that /dev/disk has by-id and by-path directories, but that by-uuid is not present.

from dracut prompt, ran blkid:
/dev/sda: TYPE="isw_raid_member"
/dev/sdb: TYPE="isw_raid_member"

Ah well, that is just seeing the 2 physical SSD's in RAID0 config.

other poking around from dracut prompt:
I ran dmraid -ay:
got:
RAID set "isw_ggceccijf_vol0" was activated
device "isw_ggceccijf_vol0" is now registered with dneventd for monitoring

Promising??  but "dmsetup ls" just gives the single line for isw_ggceccijf_vol0, but none of the partitions within this - contrast with how M6 sees it (start of comment 16).

I'm unsure how dmraid partitions in this format relate to the message as boot fails:
dracut warning: /dev/disk/by-uuid/de54b480-cb5a-4e08-87c4-1e5477e42fa4 does not exist

except that no uuid's seem to have been created at all, and by-uuid directory is not there.

I also note that /etc/fstab does not exist on the M7 partition (there is just fstab.empty).

As I see it so far, the central issue might be that dmraid -ay is supposed to activate all the sub-partitions is well as "isw_ggceccijf_vol0", but it isn't.
This fails in M7, where it must have succeeded in M6 as shown by the start of comment 16 above.

M7 dmraid version 1.0.0.rc16 (2009.09.16) shared
device-mapper version 4.40.0

M6: dmraid version same as above
device-mapper version 4.37.0

Can I alter the M7 classical x86_64 iso to substitute and try the older device-mapper from M6?  If so, how, or am I barking up the wrong tree? (or is there an easier way?)  

Tried just mounting the iso, but root mounts it read-only, so perhaps the iso format doesn't allow me just to swap packages in and out?

The M7 version of device-mapper worked in the installer, so is unlikely to be the problem. My suspicion was that something was missing from the installed system initrd, hence my questions. However, I can't spot anything obviously missing in the output from lsinitrd.

I've tried to reproduce this on an old system with a NVIDIA nforce chipset, but that booted into the installed system without any problem.

Removing the NEEDINFO keyword, because IIUC the needed information was supplied.

I'm still not sure what/whom to assign to, but will assign to the isobuilders because both Martin and Thomas have already helped.

Changing version to cauldron, because we can't fix already released ISOs

Assignee: bugsquad => isobuild
Version: 7 => Cauldron
Whiteboard: (none) => (MGA7)
Keywords: NEEDINFO => (none)

I was able to reproduce this on a system with an Intel Ivy Bridge chipset.

/dev/mapper should get populated when this rule

RUN+="/sbin/initqueue --onetime --unique --settled /sbin/dmraid_scan $env{DEVNAME}"

from /etc/udev/rules.d/61-dmraid-imsm.rules is run. Running that command manually had no effect (maybe because the dracut initqueue is no longer active). But running just

  /sbin/dmraid_scan /dev/sda

did populate /dev/mapper with the full set of partitions.

Tony and Werner,
When the boot reaches the emergency shell, enter the command

  dmraid_scan

If that adds the partitions in /dev/mapper, exit the shell (^D). For me, that was enough to boot to a working desktop.

does it change anything if you boot with:

noiswmd 

on kernel command line ?

(In reply to Thomas Backlund from comment #30)
> does it change anything if you boot with:
> 
> noiswmd 
> 
> on kernel command line ?

No.

Commenting out this line

  ENV{ID_FS_TYPE}=="isw_raid_member", ENV{rd_NO_MDIMSM}!="?*", GOTO="dm_end"

in 61-dmraid-imsm.rules fixes the problem. Tests suggest that ENV{rd_NO_MDIMSM} is not set, yet

  rd.md.imsm=0: no MD RAID for imsm/isw raids

(which comes from /lib/dracut/modules.d/90dmraid/parse-dm.sh) appears in the journal.

(In reply to Martin Whitaker from comment #29)
> Tony and Werner,
> When the boot reaches the emergency shell, enter the command
> 
>   dmraid_scan
> 
> If that adds the partitions in /dev/mapper, exit the shell (^D). For me,
> that was enough to boot to a working desktop.

That indeed gets me to a working desktop.
Have to use that command again at next start. 
Is there a way to fix the system so it does not run into this trap on each start?

(In reply to Werner Brinkmann from comment #32)
> Is there a way to fix the system so it does not run into this trap on each
> start?

Once you've booted into the Mageia 7 system, edit the file

  /lib/dracut/modules.d/90dmraid/61-dmraid-imsm.rules

and insert a # character at the start of the line

  ENV{ID_FS_TYPE}=="isw_raid_member", ENV{rd_NO_MDIMSM}!="?*", GOTO="dm_end"

Then, as root, run

  dracut -f

And it's a systemd bug. Fixed here:

  https://github.com/systemd/systemd/pull/12872

Source RPM: (none) => systemd-241-8.mga7.src.rpm

Ah, nice find...

Will roll a new systemd with that and some other fixes added..

(In reply to Martin Whitaker from comment #33)
> (In reply to Werner Brinkmann from comment #32)
> > Is there a way to fix the system so it does not run into this trap on each
> > start?
> 
> Once you've booted into the Mageia 7 system, edit the file
> 
>   /lib/dracut/modules.d/90dmraid/61-dmraid-imsm.rules
> 
> and insert a # character at the start of the line
> 
>   ENV{ID_FS_TYPE}=="isw_raid_member", ENV{rd_NO_MDIMSM}!="?*", GOTO="dm_end"
> 
> Then, as root, run
> 
>   dracut -f

That did it. Works perfectly now.
Thank you very much!

(In reply to Thomas Backlund from comment #35)
> Ah, nice find...
> 
> Will roll a new systemd with that and some other fixes added..

I've just submitted a  systemd-241-8.1.mga7 to testing.

I wont assign it to QA  yet as I need to check a few more fixes, but so you can test atleast this one for now

Hmm, dmraid_scan didn't work at all for me.  (Sorry Martin!  

(and while one should never look a gift horse in the mouth, should we be doing stuff with dmraid these days?  I recall Thomas telling me (4 years ago in linked RAID bug above) that dmraid was on the way out, and above discussion indirectly references it being excluded from Intel chipsets?  Not being critical at all and I truly don't know when to use one or the other.   It _was_ a good find for some, just wondering if we should be trying to do it with mdadm if tooling up for the future.

That aside, in the spirit of dmraid_scan, I tried on my system at the dracut emergency prompt:
mdadm --assemble --scan.

Response:
md: md126 stopped.
md126: detected capacity change from 0 to 512114832640
mdadm: Started /dev/md/vol0_0 with 2 devices
md126: p1 p2 p3 p4 p5 p6 p7 p8

However, at the continuing dracut prompt, 'ls /dev/mapper' still just shows the 'control' file, without the expected isw(some string)_vol0p1, isw*vol0p2 files etc.  Ctrl-D falls back to 'could not boot' again.

Must be close - how do I get there from here?  (how to get the relevant files generated in /dev/mapper?)

Tony

but I do have:

# ls /dev/md
imsm0 vol0_0 vol0_0p1 vol0_0p2 vol0_0p3 vol0_0p4 etc to p8

(In reply to Tony Blackwell from comment #38)
> Hmm, dmraid_scan didn't work at all for me.  (Sorry Martin!  
> 
> (and while one should never look a gift horse in the mouth, should we be
> doing stuff with dmraid these days?  I recall Thomas telling me (4 years ago
> in linked RAID bug above) that dmraid was on the way out, and above
> discussion indirectly references it being excluded from Intel chipsets?  Not
> being critical at all and I truly don't know when to use one or the other.  
> It _was_ a good find for some, just wondering if we should be trying to do
> it with mdadm if tooling up for the future.


thats the idea, but someone have to do the work...

I've now gotten as far as I have built an extra Intel system that have 2 nvme and 2 ssds added in it so I can build and play with intel raid to allow to rely on mdadm for all new raid setups...

Hopefully for mga8 ...

> 
> That aside, in the spirit of dmraid_scan, I tried on my system at the dracut
> emergency prompt:
> mdadm --assemble --scan.
> 
> Response:
> md: md126 stopped.
> md126: detected capacity change from 0 to 512114832640
> mdadm: Started /dev/md/vol0_0 with 2 devices
> md126: p1 p2 p3 p4 p5 p6 p7 p8
> 
> However, at the continuing dracut prompt, 'ls /dev/mapper' still just shows
> the 'control' file, without the expected isw(some string)_vol0p1, isw*vol0p2
> files etc.  Ctrl-D falls back to 'could not boot' again.
> 
> Must be close - how do I get there from here?  (how to get the relevant
> files generated in /dev/mapper?)


/dev/mapper/* is for dmraid

/dev/md/ is where mdadm will add its containers and partitions...

Ha, being tired and brain-dead, I tried: 
ln /dev/md /dev/mapper.  Got error message that hard links to directory were not allowed, and ls /dev/mapper still showed only the control file, but Ctrl-D after this has got me booted to an emergency root prompt.

Did martin's stuff in comment33 above, inc dracut -f, and re-booted.

Various error messages:
Couldn't parse stripe destination
rw,noatime,stripe=64

timed out waiting for device /dev/mapper/isw_ggceccijf_vol0p4
Dependency failed for /media/win_d
same for vol0p1, Dependency failed for /media/win_c
same for vol0p2, Dependency failed for /boot/EFI      :-(
Dependency failed for local file systems

... and shortly at the emergency root prompt.

Thanks Thomas.
And yes, I utterly appreciate, even without being skilled enough to know all the details, that re-tooling from dmraid to mdadm is real work and time out of people's lives...

Wonder why my system didn't boot after initial; 
mdadm --assemble --scan

...and my desk and wife's study are littered with bits as I partly-dismantle another system and its 9 disks, to set up intel RAID0 on a couple to cross-check all this.  Currently at a mismatch between what intel UEFI says is now RAID0 of 10.9Tb and how it is seen from M7 at 2.9 Tb.  Time out...

(In reply to Tony Blackwell from comment #42)
> Thanks Thomas.
> And yes, I utterly appreciate, even without being skilled enough to know all
> the details, that re-tooling from dmraid to mdadm is real work and time out
> of people's lives...
> 
> Wonder why my system didn't boot after initial; 
> mdadm --assemble --scan
> 

Because every config tells your system that you are using /dev/mapper/*, so regardless of what mdadm finds / activates, the system does not know you want to use mdadm.

@martinw, as you can reproduce the issue, can you test that systemd-241-8.1.mga7 fixes it for you ?

SRPMS:
systemd-241-8.1.mga7.src.rpm

i586:
libsystemd0-241-8.1.mga7.i586.rpm
libudev1-241-8.1.mga7.i586.rpm
libudev-devel-241-8.1.mga7.i586.rpm
nss-myhostname-241-8.1.mga7.i586.rpm
systemd-241-8.1.mga7.i586.rpm
systemd-devel-241-8.1.mga7.i586.rpm
systemd-tests-241-8.1.mga7.i586.rpm
systemd-units-241-8.1.mga7.i586.rpm

x86_64:
lib64systemd0-241-8.1.mga7.x86_64.rpm
lib64udev1-241-8.1.mga7.x86_64.rpm
lib64udev-devel-241-8.1.mga7.x86_64.rpm
nss-myhostname-241-8.1.mga7.x86_64.rpm
systemd-241-8.1.mga7.x86_64.rpm
systemd-devel-241-8.1.mga7.x86_64.rpm
systemd-tests-241-8.1.mga7.x86_64.rpm
systemd-units-241-8.1.mga7.x86_64.rpm

(In reply to Thomas Backlund from comment #44)
> @martinw, as you can reproduce the issue, can you test that
> systemd-241-8.1.mga7 fixes it for you ?

Yes, that fixes it, once you remember to regenerate the initrd...

@Tony, I think my asking you to regenerate the initrd may be responsible for your problems. Sorry! If you saved a copy of the original initrd, restore it. If not, boot into your Mageia 6 system and do:

mount /dev/mapper/isw_ggceccijf_vol0p7 /mnt/disk
mount -t proc none /mnt/disk/proc
mount -t devtmpfs none /mnt/disk/dev
chroot /mnt/disk
DRACUT_SKIP_FORCED_NON_HOSTONLY=1 dracut -f initrd-5.1.14-desktop-1.mga7.img 5.1.14-desktop-1.mga7

and that ought to generate a new initrd with the right contents.

And watch out for an unwanted line break in that last command - view in Bugzilla to get it right.

Actually, wondering if I could do any of comment33 _during_ the install, I'm at a first failed boot of a re-installation.

(and I discovered that at end of first install run, using Ctrl-Alt-F2 # prompt, the directory /etc/udev/rules.d contains only the 3 files
10-console.rules
59-persistent-storage.rules
61-persistent-storage.rules

61-dmraid-imsm.rules does not exist yet.  Immediately after this, at start of the graphical config setting of timezone, country etc the Ctrl-Alt-F2 # prompt changed to bash 4.4 # and remained unresponsive to any keyboard input for the remainder of the install, so that idea didn't work.)

Ha, I see that running dmraid-scan at this point has indeed populated /dev/mapper with all the appropriate files.
Just did Ctrl-D without the dracut -f command.
Got a whole lot of [OK] messages, rescue mode prompt, typed 'exit' there, and lo and behold, now logged in to this new M7.  Thankyou!  Will do the Comment33 edit

See I confused /etc/udev/rules.d with 
 /lib/dracut/modules.d/90dmraid/61-dmraid-imsm.rules
in the above comment.

and after dracut -f, is all fixed.  Bots normally
Tony

An update for this issue has been pushed to the Mageia Updates repository.

https://advisories.mageia.org/MGAA-2019-0062.html

Status: NEW => RESOLVED
Resolution: (none) => FIXED