语境：
我有一个有 2 个分区的 USB 驱动器：第一个是 CentOS 7.6 1810（带 GNOME）的自定义非持久映像，第二个是加密数据分区。目标是拥有一个可启动的实时 CentOS USB 驱动器，用户可以从中加载加密分区来存储他/她的文件。在大多数情况下，一切都按预期进行。生成的 ISO 与 VirtualBox 完美配合，并且 ISO 从未出现过任何问题。当我将 CentOS live USB 分区与 USB 驱动器上的数据分区合并时，就会出现此问题。
问题：
当我启动 USB 时，我有时收到以下错误：
dracut: FATAL: Failed to mount block device of live image
dracut: Refusing to continue
system halted.
请注意，在许多情况下，我可以成功加载实时 CentOS 映像，而不会出现任何错误。所以这是一个概率问题，意味着潜在的竞争条件涉及某处。
我已启用调试选项以dracut在启动时输出日志文件，遇到的问题似乎用以下几行突出显示：
[ 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'
根据上面的输出，dracut似乎正在尝试从 加载实时映像/dev/sda2，该分区是数据分区，而不是 CentOS 分区，因此无法启动。换句话说，dracut有时会使用正确的分区/dev/sda1来启动操作系统，但由于某种原因，有时会尝试使用/dev/sda2.尝试将root参数替换为root=/dev/sda1没有成功。
blkid在shell 中运行dracut会产生：
/dev/sda1: UUID="2019-07-06-19-24-46-00" LABEL="CentOS-7-x86_x64-LiveGNOME-1810" TYPE="iso9660" PTTYPE="dos"
但是，查看 生成的日志dracut，我可以看到以下输出：
+ 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
我不知道为什么标签CentOS-7-x86_64-LiveGNOME-1810将被分配给sda2.
问题：
是否有修复程序可以确保始终选择正确的分区以保证启动 100% 的成功率？现在，我必须关闭笔记本电脑的电源，然后重新打开电源，直到可以启动进入操作系统。
更新：
此问题似乎是由 2 个分区引起的：第一个是 CentOS 映像，第二个是加密分区。虽然我无法完全解释原因，但似乎在启动时，第一个分区的标签（即）CentOS-7-x86_64-LiveGNOME-1810也分配给了第二个分区。因此，当引导序列寻找带有CentOS-7-x86_64-LiveGNOME-1810标签的分区时，它将返回第一个或第二个分区，具体取决于哪个分区先出现。当首先选择第一个分区时，这会导致某些启动的关键，而当返回第二个分区时则失败。
我尝试更改第二个 Veracrypt 加密分区的标签，但无济于事。我通过将 root 命令更改为以下部分解决了该问题：
initrd=initrd0.img root=live:/dev/sdb1 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
但是，这会导致 USB 密钥在其他设备上失败。我尝试过使用，root=live:/dev/disk/by-id/usb-SanDisk_Extreme_Pro_00000000000000000000-0:0-part1但这似乎也不起作用。
如果有人有任何提示可以帮助我将双分区、自定义 CentOS 7.6 映像与可在大多数现代笔记本电脑/台式机上运行的 Veracrypt 分区搭配使用，我将非常感激。最好与 EFI 配合使用。现在，我会对 MBR 感到满意。