1

Context:

I have a USB drive with 2 partitions: the first one is a custom, non-persistent, image of CentOS 7.6 1810 (with GNOME) and the second one is an encrypted data partition. The objective is to have a bootable live CentOS USB drive from which a user can then load the encrypted partition to store his/her files. And for the most part, everything is working as expected. The generated ISO works perfectly with VirtualBox and never had any issue with the ISO. The issue appears when I combine the CentOS live USB partition with the data partition on the USB drive.

Problem:

When I boot the USB, I sometimes gets the following error:

dracut: FATAL: Failed to mount block device of live image
dracut: Refusing to continue
system halted.

Note that in many cases, I can successfully have the live CentOS image loaded without any error. So this is a probabilistic issue, implying a potential race condition involve somewhere.

I've enabled the debugging options for dracut to output a log file on boot, the issue met appears to be highlighted with the following lines:

[    4.015983] localhost dracut-initqueue[773]: + CMDLINE='   initrd=initrd0.img root=live:CDLABEL=CentOS-7-x86_64-LiveGNOME-1810 rootfstype=auto ro rd.live.image rd.shell rd.debug log_buf_len=1M rd.luks=0 rd.md=0 rd.dm=0 BOOT_IMAGE=vmlinuz0'
[    4.016557] localhost dracut-initqueue[773]: + for arg in '$CMDLINE'
[    4.017178] localhost dracut-initqueue[773]: + case $arg in
[    4.017761] localhost dracut-initqueue[773]: + for arg in '$CMDLINE'
[    4.018361] localhost dracut-initqueue[773]: + case $arg in
[    4.018951] localhost dracut-initqueue[773]: + for arg in '$CMDLINE'
[    4.019579] localhost dracut-initqueue[773]: + case $arg in
[    4.020202] localhost dracut-initqueue[773]: + for arg in '$CMDLINE'
[    4.020785] localhost dracut-initqueue[773]: + case $arg in
[    4.021363] localhost dracut-initqueue[773]: + liverw=ro
[    4.021952] localhost dracut-initqueue[773]: + for arg in '$CMDLINE'
[    4.022584] localhost dracut-initqueue[773]: + case $arg in
[    4.023205] localhost dracut-initqueue[773]: + for arg in '$CMDLINE'
[    4.023798] localhost dracut-initqueue[773]: + case $arg in
[    4.024390] localhost dracut-initqueue[773]: + for arg in '$CMDLINE'
[    4.024970] localhost dracut-initqueue[773]: + case $arg in
[    4.025584] localhost dracut-initqueue[773]: + for arg in '$CMDLINE'
[    4.026135] localhost dracut-initqueue[773]: + case $arg in
[    4.026745] localhost dracut-initqueue[773]: + for arg in '$CMDLINE'
[    4.027375] localhost dracut-initqueue[773]: + case $arg in
[    4.027941] localhost dracut-initqueue[773]: + for arg in '$CMDLINE'
[    4.028544] localhost dracut-initqueue[773]: + case $arg in
[    4.029125] localhost dracut-initqueue[773]: + for arg in '$CMDLINE'
[    4.029652] localhost dracut-initqueue[773]: + case $arg in
[    4.030241] localhost dracut-initqueue[773]: + for arg in '$CMDLINE'
[    4.030788] localhost dracut-initqueue[773]: + case $arg in
[    4.031377] localhost dracut-initqueue[773]: + mkdir -m 0755 -p /run/initramfs/live
[    4.031924] localhost dracut-initqueue[773]: + '[' -f /dev/sda2 ']'
[    4.032484] localhost dracut-initqueue[773]: ++ blkid -o value -s TYPE /dev/sda2
[    4.033075] localhost dracut-initqueue[773]: + '[' '' '!=' ntfs ']'
[    4.033564] localhost dracut-initqueue[773]: + mount -n -t auto -o ro /dev/sda2 /run/initramfs/live
[    4.034100] localhost dracut-initqueue[773]: mount: wrong fs type, bad option, bad superblock on /dev/sda2,
[    4.034593] localhost dracut-initqueue[773]: missing codepage or helper program, or other error
[    4.035175] localhost dracut-initqueue[773]: In some cases useful info is found in syslog - try
[    4.035726] localhost dracut-initqueue[773]: dmesg | tail or so.
[    4.036299] localhost dracut-initqueue[773]: + '[' 32 '!=' 0 ']'
[    4.036846] localhost dracut-initqueue[773]: + die 'Failed to mount block device of live image'
[    4.037422] localhost dracut-initqueue[773]: + echo '<24>dracut: FATAL: Failed to mount block device of live image'
[    4.037966] localhost dracut-initqueue[773]: + echo '<24>dracut: Refusing to continue'
[    4.038553] localhost dracut-initqueue[773]: + echo 'warn dracut: FATAL: "Failed to mount block device of live image"'
[    4.039143] localhost dracut-initqueue[773]: + echo 'warn dracut: Refusing to continue'

Based on the output above, dracut appears to be trying to load the live image from /dev/sda2, which is the data partition, not the CentOS one and thus fails to boot. In other words, dracut sometimes uses the proper partition - /dev/sda1 - to boot the OS, but for some reason, sometimes tries to use /dev/sda2. Trying to replace the root parameter with root=/dev/sda1 didn't worked.

Running blkid at the dracut shell yields:

/dev/sda1: UUID="2019-07-06-19-24-46-00" LABEL="CentOS-7-x86_x64-LiveGNOME-1810" TYPE="iso9660" PTTYPE="dos"

However, looking at the log generated by dracut, I can see the following output:

+ blkid
/dev/sda1: UUID="2019-07-06-19-24-46-00" LABEL="CentOS-7-x86_64-LiveGNOME-1810" TYPE="iso9660" PTTYPE="dos" 
+ blkid -o udev
ID_FS_UUID=2019-07-06-19-24-46-00
ID_FS_UUID_ENC=2019-07-06-19-24-46-00
ID_FS_LABEL=CentOS-7-x86_64-LiveGNOME-1810
ID_FS_LABEL_ENC=CentOS-7-x86_64-LiveGNOME-1810
ID_FS_TYPE=iso9660
ID_PART_TABLE_TYPE=dos
+ ls -l /dev/disk/by-id /dev/disk/by-label /dev/disk/by-path /dev/disk/by-uuid
/dev/disk/by-id:
total 0
lrwxrwxrwx 1 root 0  9 Jul  7 11:54 usb-SanDisk_Extreme_Pro_00000000000000000000-0:0 -> ../../sda
lrwxrwxrwx 1 root 0 10 Jul  7 11:54 usb-SanDisk_Extreme_Pro_00000000000000000000-0:0-part1 -> ../../sda1
lrwxrwxrwx 1 root 0 10 Jul  7 11:54 usb-SanDisk_Extreme_Pro_00000000000000000000-0:0-part2 -> ../../sda2

/dev/disk/by-label:
total 0
lrwxrwxrwx 1 root 0 10 Jul  7 11:54 CentOS-7-x86_64-LiveGNOME-1810 -> ../../sda2

/dev/disk/by-path:
total 0
lrwxrwxrwx 1 root 0  9 Jul  7 11:54 pci-0000:00:14.0-usb-0:1:1.0-scsi-0:0:0:0 -> ../../sda
lrwxrwxrwx 1 root 0 10 Jul  7 11:54 pci-0000:00:14.0-usb-0:1:1.0-scsi-0:0:0:0-part1 -> ../../sda1
lrwxrwxrwx 1 root 0 10 Jul  7 11:54 pci-0000:00:14.0-usb-0:1:1.0-scsi-0:0:0:0-part2 -> ../../sda2

/dev/disk/by-uuid:
total 0
lrwxrwxrwx 1 root 0 10 Jul  7 11:54 2019-07-06-19-24-46-00 -> ../../sda2

I have no idea why the label CentOS-7-x86_64-LiveGNOME-1810 would be assigned to sda2.

Question:

Is there a fix to ensure that the proper partition is always selected to guarantee a 100% success rate on boot? Right now, I have to power off the laptop, and repower it on until I can boot into the OS.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.