[qubes-users] HELP! after update dom0 "no bootable device found"

Mailing Lists qubes-users
1

The main line is in the title. I did a dom0 upgrade that installed kernel-latest. After reboot I got the freaky message
“No bootable device found, press F1… F2 … F5…” – it does not really say where it comes from, but it sounds like a BIOS message.

I have no idea where to start, so I give all I have here and ask for help. Please read quickly over it, any hint is appreciated.
(1) I did boot my computer with a live linux.
(2) The boot partition does exist. The qubes folder reads like this

-rwxr-xr-x 1 root root 24M Jan 29 17:57 initramfs-5.10.11-1.fc25.qubes.x86_64.img
-rwxr-xr-x 1 root root 24M Jan 12 15:27 initramfs-5.10.5-1.qubes.x86_64.img
-rwxr-xr-x 1 root root 23M Jan 24 09:41 initramfs-5.10.8-1.qubes.x86_64.img
-rwxr-xr-x 1 root root 24M Jan 24 09:39 initramfs-5.4.91-1.fc25.qubes.x86_64.img
-rwxr-xr-x 1 root root 7.9M Jan 29 17:57 vmlinuz-5.10.11-1.fc25.qubes.x86_64
-rwxr-xr-x 1 root root 7.9M Jan 12 15:27 vmlinuz-5.10.5-1.qubes.x86_64
-rwxr-xr-x 1 root root 7.9M Jan 24 09:41 vmlinuz-5.10.8-1.qubes.x86_64
-rwxr-xr-x 1 root root 6.9M Jan 24 09:39 vmlinuz-5.4.91-1.fc25.qubes.x86_64
-rwxr-xr-x 1 root root 2.0M Jan 4 00:43 xen-4.8.5-29.fc25.efi
-rwxr-xr-x 1 root root 1.4K Jan 29 20:57 xen.cfg
-rwxr-xr-x 1 root root 2.0M Jan 4 00:43 xen.efi

I am surprised by the sizes – files seem small. Do the seem correct?? Are there files missing?? Could maybe someone check these md5sums, please?

1ff66a646f443da650caca5a71d14dc9 initramfs-5.10.11-1.fc25.qubes.x86_64.img
0ed0b625599395686c950b11ca626659 initramfs-5.10.5-1.qubes.x86_64.img
66ad105adc1bcf8543fde0be5e1cffa9 initramfs-5.10.8-1.qubes.x86_64.img
aa03e2e037aa2a173c4f9a2db6dd9096 initramfs-5.4.91-1.fc25.qubes.x86_64.img
36993c5ea1f93a37c548f8ac32b18baf vmlinuz-5.10.11-1.fc25.qubes.x86_64
9669c095819240d8117f208748707b4c vmlinuz-5.10.5-1.qubes.x86_64
3db1a8bdd97a608a5459ac5521052ab8 vmlinuz-5.10.8-1.qubes.x86_64
0834cc9a9bfbacb9cfc420f3b879bca7 vmlinuz-5.4.91-1.fc25.qubes.x86_64

If these files were corrupt, other error messages should appear, so it is, probably, somthing else. But still!
Next, my actual xen.cfg reads like this

[global]
default=5.4.91-1.fc25.qubes.x86_64
[5.10.5-1.qubes.x86_64]
options=loglvl=all dom0_mem=min:1024M dom0_mem=max:4096M iommu=no-igfx ucode=scan smt=off
kernel=vmlinuz-5.10.5-1.qubes.x86_64 root=/dev/mapper/qubes_dom0-root rd.luks.uuid=luks-5efeb9ad-e2a2-47ae-b8e2-d12180464e33 rd.lvm.lv=qubes_dom0/root rd.lvm.lv=qubes_dom0/swap i915.alpha_support=1 rhgb quiet rd.qubes.hide_all_usb plymouth.ignore-serial-consoles
ramdisk=initramfs-5.10.5-1.qubes.x86_64.img
[5.4.91-1.fc25.qubes.x86_64]
options=loglvl=all dom0_mem=min:1024M dom0_mem=max:4096M iommu=no-igfx ucode=scan smt=off
kernel=vmlinuz-5.4.91-1.fc25.qubes.x86_64 root=/dev/mapper/qubes_dom0-root rd.luks.uuid=luks-5efeb9ad-e2a2-47ae-b8e2-d12180464e33 rd.lvm.lv=qubes_dom0/root rd.lvm.lv=qubes_dom0/swap i915.alpha_support=1 rhgb quiet rd.qubes.hide_all_usb plymouth.ignore-serial-consoles
ramdisk=initramfs-5.4.91-1.fc25.qubes.x86_64.img
[5.10.11-1.fc25.qubes.x86_64]
options=loglvl=all dom0_mem=min:1024M dom0_mem=max:4096M iommu=no-igfx ucode=scan smt=off
kernel=vmlinuz-5.10.11-1.fc25.qubes.x86_64 root=/dev/mapper/qubes_dom0-root rd.luks.uuid=luks-5efeb9ad-e2a2-47ae-b8e2-d12180464e33 rd.lvm.lv=qubes_dom0/root rd.lvm.lv=qubes_dom0/swap i915.alpha_support=1 rhgb quiet rd.qubes.hide_all_usb plymouth.ignore-serial-consoles
ramdisk=initramfs-5.10.11-1.fc25.qubes.x86_64.img

these all look OK, a part from 5.10.8. being present as files, but not in the boot menu, which is strange.

(3) I could try the " efibootmgr " commands mentioned in UEFI troubleshooting, but I do not understand them, and I am afraid to f*ck it up even worse. If my harddrive-boot partition is mounted on /BOOT instead of /boot , how would the command read, please??

Thank you very much, Bernhard

2

Hi,

I am surprised by the sizes -- files seem small. Do the seem correct??
Are there files missing?? Could maybe someone check these md5sums, please?

1ff66a646f443da650caca5a71d14dc9 initramfs-5.10.11-1.fc25.qubes.x86_64.img
0ed0b625599395686c950b11ca626659 initramfs-5.10.5-1.qubes.x86_64.img
66ad105adc1bcf8543fde0be5e1cffa9 initramfs-5.10.8-1.qubes.x86_64.img
aa03e2e037aa2a173c4f9a2db6dd9096 initramfs-5.4.91-1.fc25.qubes.x86_64.img
36993c5ea1f93a37c548f8ac32b18baf vmlinuz-5.10.11-1.fc25.qubes.x86_64
9669c095819240d8117f208748707b4c vmlinuz-5.10.5-1.qubes.x86_64
3db1a8bdd97a608a5459ac5521052ab8 vmlinuz-5.10.8-1.qubes.x86_64
0834cc9a9bfbacb9cfc420f3b879bca7 vmlinuz-5.4.91-1.fc25.qubes.x86_64

[user@dom0 boot]$ sudo md5sum initramfs-5.*
9026c8b1f9d4ba3da856197e6a864f87 initramfs-5.10.11-1.fc25.qubes.x86_64.img
7b37ca7152c6a13d43c8786b309781af initramfs-5.10.7-1.qubes.x86_64.img
037caef7ad5ffae014c02174f9d32ec8 initramfs-5.10.8-1.qubes.x86_64.img
4ab81d0bd949b982bc1d4c8624e6ed97 initramfs-5.4.83-1.qubes.x86_64.img
0167631c01c4a8e48f231e93adbc30dc initramfs-5.4.88-1.qubes.x86_64.img
ad56a62721d0953e9b7547b6e0f34c8e initramfs-5.4.91-1.fc25.qubes.x86_64.img

[user@dom0 boot]$ md5sum vmlinuz-5.*
36993c5ea1f93a37c548f8ac32b18baf vmlinuz-5.10.11-1.fc25.qubes.x86_64
55e0df9ec8fa8e5b812a2e0bf9794094 vmlinuz-5.10.7-1.qubes.x86_64
3db1a8bdd97a608a5459ac5521052ab8 vmlinuz-5.10.8-1.qubes.x86_64
0834cc9a9bfbacb9cfc420f3b879bca7 vmlinuz-5.4.91-1.fc25.qubes.x86_64

Probably the initramfs differ due different hardware or configuration.
vmlinuz image seems fine.

(3) I could try the " efibootmgr " commands mentioned in UEFI

troubleshooting, but I do not understand them, and I am afraid to f*ck
it up even worse. If my harddrive-boot partition is mounted on /BOOT
instead of /boot , how would the command read, please??

It seems it ignores your mountpoint, you pass directly the hard disk and
EFI partition number (which should be the first) so in:
efibootmgr -v -c -u -L Qubes -l /EFI/qubes/xen.efi -d /dev/sda -p 1
"placeholder /mapbs /noexitboot"

You only have to worry about /dev/sda

You only need to worry about /dev/sda, if you are afraid about breaking
it more try using a different label like "-L TryingQubesRescue".

3

Hi,

I am surprised by the sizes – files seem small. Do the seem correct??
Are there files missing?? Could maybe someone check these md5sums, please?

Probably the initramfs differ due different hardware or configuration.
vmlinuz image seems fine.

(3) I could try the " efibootmgr " commands mentioned in UEFI
troubleshooting, but I do not understand them, and I am afraid to f*ck
it up even worse. If my harddrive-boot partition is mounted on /BOOT
instead of /boot , how would the command read, please??

It seems it ignores your mountpoint, you pass directly the hard disk and
EFI partition number (which should be the first) so in:
efibootmgr -v -c -u -L Qubes -l /EFI/qubes/xen.efi -d /dev/sda -p 1
“placeholder /mapbs /noexitboot”

You only have to worry about /dev/sda

4

If it not helps, have you tried switching to different kernel in xen.cfg?

5

It seems it ignores your mountpoint, you pass directly the hard disk and
EFI partition number (which should be the first) so in:
efibootmgr -v -c -u -L Qubes -l /EFI/qubes/xen.efi -d /dev/sda -p 1
"placeholder /mapbs /noexitboot"

You only have to worry about /dev/sda
-----------------------------
Thank you very much Donoban. I tried:
root@debian:~# efibootmgr -v -c -u -L Qubes -l /EFI/qubes/xen.efi -d
/dev/nvme0n1 -p 1 "placeholder /mapbs /noexitboot"
efibootmgr: ** Warning ** : Boot0002 has same label Qubes
BootCurrent: 0001
Timeout: 0 seconds
BootOrder: 0000,0001
Boot0001* UEFI: KingstonDataTraveler 2.0PMAP, Partition 1
PciRoot(0x0)/Pci(0x14,0x0)/USB(8,0)/HD(1,MBR,0x51f9fa69,0x630,0x1700)
Boot0002* Qubes
HD(1,GPT,13cfa870-22a0-4035-8a48-d3cb09dcfb92,0x800,0x64000)/File(\EFI\qubes\xen.efi)placeholder /mapbs /noexitboot
Boot0006* CD/DVD/CD-RW Drive BBS(CDROM,CD/DVD/CD-RW Drive,0x0)
Boot0007* Onboard NIC BBS(Network,IBA CL Slot 00FE v0112,0x0)
Boot0000* Qubes
HD(1,GPT,13cfa870-22a0-4035-8a48-d3cb09dcfb92,0x800,0x64000)/File(\EFI\qubes\xen.efi)placeholder /mapbs /noexitboot
what you see is that Qubes was still in the UEFI "line" now at position
0002. I will have to try a reboot - don't like it, because it is a pain
in the neck to re-install wireless on debian; I hope that I downloaded
all packages I need on /boot of my life system ... otherwise I will
become silent for a while! Cheers

I tried a reboot after an extra-emergeny backup (luks-by-hand training:)
and your efibootmgr command worked. qubes is back! Thank you so much.

Bernhard

6

You could try to boot the kernel installed using: Super Grub2 Disk