http://bugzilla.opensuse.org/show_bug.cgi?id=1205261 http://bugzilla.opensuse.org/show_bug.cgi?id=1205261#c1 --- Comment #1 from Felix Miata <mrmazda@earthlink.net> --- Same comment #0 host gb250 normally has a HDD RAID, which I disconnected to perform the NVME migration. Since the migration appeared to be complete, I removed the original NVME, and reconnected the RAID, which has its own TW installation that had been bootable either from the native /boot directory on the RAID, or an extra EXT2 filesystem on the NVME that contains an rsync of the RAID's native /boot directory. I copied the RAID's initrd-5.19.13-default over the freshly built and working NVME TW's 5.19.13 and tried booting the NVME TW using it. The result is similar to comment #0: halted in the dracut emergency shell, not because the ESP FAT serial number is missing, but because what's missing is the initrd's dracut/hooks/emergency UUID for the old NVME's EXT2 /boot rsync'd filesystem, which is represented in the RAID TW's /etc/fstab mounted noatime,noacl to /boot. Trying to boot the RAID TW using the NVME EXT2 or it native /boot also fails because what's missing is the initrd's dracut/hooks/emergency UUID for the old NVME's EXT2 /boot rsync'd filesystem. The fresh 5.19.13 initrd from NVME TW copied to the EXT2 and to the RAID /boot also produces failure for same reason attempted from EXT2, or failure to find RAID / attempted from RAID /boot (/etc/mdadm.conf absent from initrd). ToDo: rebuild the RAID TW's initrds and retest. -- You are receiving this mail because: You are on the CC list for the bug.