Mageia forum

My new installation of mga5 on a software raid (Intel) cannot be booted. Immediately after the installation the first few reboots were just fine but from then on I have problems to boot the system. Adding the kernel parameter rootdelay=20 (or any bigger number) does not help. What else could I try? I am using an UEFI system.

Problems to boot - can you please be a little more verbose?
Bootloader loads or does not load, or does not load always? (Huge) delays before/after bootloader?
If you select something in bootloader, what happens?


From the log it seems the pivot_root cannot be performed from initrd to actual system hence it fails to continue booting, otherwise looks OK:

Code: Select all

[    5.148956] dracut Warning: Failed to mount -t ext4 -o ro,ro /dev/disk/by-uuid/b3df7655-a5a1-4a4b-bc9a-3c5dff81c24d /sysroot
[    5.149025] dracut Warning: *** An error occurred during the file system check.
[    5.149070] dracut Warning: *** Dropping you to a shell; the system will try
[    5.149113] dracut Warning: *** to mount the filesystem(s), when you leave the shell.
[    5.149251] dracut Warning: filesystem)

What's with that partition at that time? Is that a RAID device?

You are right. Sorry.

If the system fails to boot then it always fails to mount partition /dev/sda5. This partition is part of the raid /dev/dm-5 (/dev/sda5 + /dev/sdb5) which contains the root partition of the system ("/"). Partition /dev/dm-1 (/dev/sda1 + /dev/sdb1) contains /boot/EFI. Why does mga5 try to mount /dev/sda5 separately when it already discovered /dev/dm-5?

From previous rdsosreport.txt:

Code: Select all

/dev/disk/by-id:
total 0
lrwxrwxrwx 1 root 0  9 Jul 28 12:31 ata-SAMSUNG_MZ7TE512HMHP-00004_S1RJNSAFC01559 -> ../../sdb
lrwxrwxrwx 1 root 0 10 Jul 28 12:31 ata-SAMSUNG_MZ7TE512HMHP-00004_S1RJNSAFC01559-part1 -> ../../sdb1
lrwxrwxrwx 1 root 0 10 Jul 28 12:31 ata-SAMSUNG_MZ7TE512HMHP-00004_S1RJNSAFC01559-part2 -> ../../sdb2
lrwxrwxrwx 1 root 0 10 Jul 28 12:31 ata-SAMSUNG_MZ7TE512HMHP-00004_S1RJNSAFC01559-part3 -> ../../sdb3
lrwxrwxrwx 1 root 0 10 Jul 28 12:31 ata-SAMSUNG_MZ7TE512HMHP-00004_S1RJNSAFC01559-part4 -> ../../sdb4
lrwxrwxrwx 1 root 0 10 Jul 28 12:31 ata-SAMSUNG_MZ7TE512HMHP-00004_S1RJNSAFC01559-part5 -> ../../sdb5
lrwxrwxrwx 1 root 0  9 Jul 28 12:31 ata-SAMSUNG_MZ7TE512HMHP-00004_S1RJNSAFC02785 -> ../../sda
lrwxrwxrwx 1 root 0 10 Jul 28 12:31 ata-SAMSUNG_MZ7TE512HMHP-00004_S1RJNSAFC02785-part1 -> ../../sda1
lrwxrwxrwx 1 root 0 10 Jul 28 12:31 ata-SAMSUNG_MZ7TE512HMHP-00004_S1RJNSAFC02785-part2 -> ../../sda2
lrwxrwxrwx 1 root 0 10 Jul 28 12:31 ata-SAMSUNG_MZ7TE512HMHP-00004_S1RJNSAFC02785-part3 -> ../../sda3
lrwxrwxrwx 1 root 0 10 Jul 28 12:31 ata-SAMSUNG_MZ7TE512HMHP-00004_S1RJNSAFC02785-part4 -> ../../sda4
lrwxrwxrwx 1 root 0 10 Jul 28 12:31 ata-SAMSUNG_MZ7TE512HMHP-00004_S1RJNSAFC02785-part5 -> ../../sda5
lrwxrwxrwx 1 root 0  9 Jul 28 12:31 ata-TSSTcorp_BDDVDW_SN-506BB_R9266YLFA0002K -> ../../sr0
lrwxrwxrwx 1 root 0 10 Jul 28 12:31 dm-name-isw_iabiigfig_Volume0 -> ../../dm-0
lrwxrwxrwx 1 root 0 10 Jul 28 12:31 dm-name-isw_iabiigfig_Volume0p1 -> ../../dm-1
lrwxrwxrwx 1 root 0 10 Jul 28 12:31 dm-name-isw_iabiigfig_Volume0p2 -> ../../dm-2
lrwxrwxrwx 1 root 0 10 Jul 28 12:31 dm-name-isw_iabiigfig_Volume0p3 -> ../../dm-3
lrwxrwxrwx 1 root 0 10 Jul 28 12:31 dm-name-isw_iabiigfig_Volume0p4 -> ../../dm-4
lrwxrwxrwx 1 root 0 10 Jul 28 12:31 dm-name-isw_iabiigfig_Volume0p5 -> ../../dm-5
lrwxrwxrwx 1 root 0 10 Jul 28 12:31 dm-uuid-DMRAID-isw_iabiigfig_Volume0 -> ../../dm-0
lrwxrwxrwx 1 root 0 10 Jul 28 12:31 dm-uuid-part1-DMRAID-isw_iabiigfig_Volume0 -> ../../dm-1
lrwxrwxrwx 1 root 0 10 Jul 28 12:31 dm-uuid-part2-DMRAID-isw_iabiigfig_Volume0 -> ../../dm-2
lrwxrwxrwx 1 root 0 10 Jul 28 12:31 dm-uuid-part3-DMRAID-isw_iabiigfig_Volume0 -> ../../dm-3
lrwxrwxrwx 1 root 0 10 Jul 28 12:31 dm-uuid-part4-DMRAID-isw_iabiigfig_Volume0 -> ../../dm-4
lrwxrwxrwx 1 root 0 10 Jul 28 12:31 dm-uuid-part5-DMRAID-isw_iabiigfig_Volume0 -> ../../dm-5
...


Today I generated a new rdsosreport after adding the kernel option rd.debug. Maybe it is helpful.

To be honest, can't really help you that much with the RAID stuff at all. I've very little practical experience with linux and softraid.
Can only provide a few pointers by going through the logs and information you provided.

In the previous post, the error was about failing to mount partition with the UUID b3df7655-a5a1-4a4b-bc9a-3c5dff81c24d as / (or /sysroot during initrd).
According to the by-uuid mapping, this is sda5.

/dev/disk/by-uuid:
total 0
lrwxrwxrwx 1 root 0 10 Jul 29 06:22 2844fbb9-df92-4d77-afde-efe101d42166 -> ../../sdc1
lrwxrwxrwx 1 root 0 10 Jul 29 06:22 37e7d55d-fbbe-42be-8f96-7e867e32b479 -> ../../sda4
lrwxrwxrwx 1 root 0 10 Jul 29 06:22 8500-9080 -> ../../sda1
lrwxrwxrwx 1 root 0 10 Jul 29 06:22 95c143bb-fdef-4cd2-8da8-4b051c0a2275 -> ../../sda3
lrwxrwxrwx 1 root 0 10 Jul 29 06:22 96231aa8-09d9-41e4-a40f-c428d87c9ab6 -> ../../sda2
lrwxrwxrwx 1 root 0 10 Jul 29 06:22 b3df7655-a5a1-4a4b-bc9a-3c5dff81c24d -> ../../sda5
lrwxrwxrwx 1 root 0 10 Jul 29 06:22 b452250a-cdb2-41f5-92ac-0c7c736626f2 -> ../../sdc2

That's also what's contained in your bootloader config and kernel command line, so seems to be consistent at least:

[ 0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-server root=UUID=b3df7655-a5a1-4a4b-bc9a-3c5dff81c24d ro nokmsboot splash quiet resume=UUID=2844fbb9-df92-4d77-afde-efe101d42166 rd.debug

[ 0.000000] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-server root=UUID=b3df7655-a5a1-4a4b-bc9a-3c5dff81c24d ro nokmsboot splash quiet resume=UUID=2844fbb9-df92-4d77-afde-efe101d42166 rd.debug

[ 4.169151] dracut: ///lib/dracut/hooks/cmdline/10-parse-root-opts.sh@5(source): root=UUID=b3df7655-a5a1-4a4b-bc9a-3c5dff81c24d

So your question is actually the answer. Your system fails to mount this as it's being told to by bootloader (and probably fstab, so now also by the initrd)
because it tries to mount a partition that is actually part of the RAID device for /.

Yes, very consistent. After many attempts I am sure that something goes wrong in mcc. If I install mga5 on a fakeRAID (/dev/sda+/dev/sdb) everything is OK. I can even boot it - probably after adjusting the kernelparameter rootdelay a bit. But once I apply those changes to the bootmanager from within mcc the next reboot will fail. As you also realized the system tries to mount one partition which belongs to the fakeRAID and should not be mounted separately. After changing the number of partitions on the fakeRAID I found out that it will always be the last partition of the first hard disk belonging to the fakeRAID (/dev/sda5 if you have 5 partitions, /dev/sda4 if you have 4 partitions, …). But this happens only if you saved the bootmanager from within mcc. Strange.

Another problem is that an EFI-partition cannot be placed on a software RAID. Neither mdadm nor fakeRAID works. Some people got it working somehow but none of their suggestions worked for me. So, there are finally to possibilities:

1. When you create a fakeRAID make sure not to use all the space for it. You have to leave some space for an EFI-partition. Then you can install mga5 on the fakeRAID and put /boot/EFI on /dev/sda1 or /dev/sdb1. Just be careful not to mix partitions because you should never touch the partitions on /dev/sda and /dev/sdb which belong to the fakeRAID! After the installation you can reboot your system. But I did not investigate whether you can safely make changes to the bootmanager with mcc then.

2. My favored possibility. Just like in the good old times when we could use boot-floppy-disks to start a system you can use a small USB-stick which will hold the /boot/EFI partition. In this case you should not create a fakeRAID but a software RAID during the installation of mga5. This is the cleanest installation of a software RAID on an (U)EFI-system I think. Of course, instead of an USB-stick you could take a small partition of any other internal drive as long as it does not belong to another software RAID.

magfan wrote:Yes, very consistent. After many attempts I am sure that something goes wrong in mcc. If I install mga5 on a fakeRAID (/dev/sda+/dev/sdb) everything is OK. I can even boot it - probably after adjusting the kernelparameter rootdelay a bit. But once I apply those changes to the bootmanager from within mcc the next reboot will fail.

Should be pretty easy to reproduce and check what exactly is changed so stuff breaks. Install, and when it boots normally then copy away /boot/ and /etc/grub.d/ and /etc/default/grub
Then run drakboot, and when it's broken run a recursive diff between backup copies and the actual directories/file.

My first impression was wrong. The system does not always try to mount the last partition on the first disk but the root partition on the first disk (see rdsysreport.txt)! This does not depend on the number of partitions on that disk. It only depends on which partition is the root partition.

Code: Select all

/dev/mapper/isw_didbcdcdga_Volume0p3 / ext4 relatime,acl 1 1
/dev/mapper/isw_didbcdcdga_Volume0p1 /boot/EFI vfat umask=0,iocharset=utf8 0 0
/dev/mapper/isw_didbcdcdga_Volume0p4 /home ext4 relatime,acl 1 2
none /proc proc defaults 0 0
/dev/mapper/isw_didbcdcdga_Volume0p2 swap swap defaults 0 0


A recursive diff shows differences in /boot and /etc/default/grub (see attached files).

Sorry, no clue how to get this fixed - you might need the help of upstream on that one.
Check https://www.kernel.org/pub/linux/utils/ ... leshooting and https://fedoraproject.org/wiki/Dracut#Communicate