HELP! after update dom0 "no bootable device found"

36 views
Skip to first unread message

haa...@web.de

unread,
Jan 30, 2021, 2:43:55 AM1/30/21
to qubes...@googlegroups.com
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

donoban

unread,
Jan 30, 2021, 5:28:24 AM1/30/21
to qubes...@googlegroups.com
Hi,

On 1/30/21 8:43 AM, haa...@web.de wrote:
> 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".

OpenPGP_signature

haa...@web.de

unread,
Jan 30, 2021, 12:14:07 PM1/30/21
to donoban, qubes...@googlegroups.com
 
 
 
Gesendet: Samstag, 30. Januar 2021 um 10:28 Uhr
Von: "donoban" <don...@riseup.net>
An: qubes...@googlegroups.com
Betreff: Re: [qubes-users] HELP! after update dom0 "no bootable device found"
Hi,

On 1/30/21 8:43 AM, haa...@web.de wrote:
> 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
-----------------------------
 
 
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
 

donoban

unread,
Jan 30, 2021, 12:29:07 PM1/30/21
to qubes...@googlegroups.com
On 1/30/21 6:14 PM, haa...@web.de wrote:
> 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

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

OpenPGP_signature

haaber

unread,
Jan 31, 2021, 6:26:43 AM1/31/21
to qubes...@googlegroups.com
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

Ulrich Windl

unread,
Feb 1, 2021, 5:54:05 PM2/1/21
to qubes...@googlegroups.com
You could try to boot the kernel installed using:
https://www.supergrubdisk.org/super-grub2-disk/
Reply all
Reply to author
Forward
0 new messages