'No Bootable Device' error after clean Qubes 4 install

[Guy Frank]

I did a fully automatic disk partition on my last attempt to install Qubes 4. When I try to boot my new Qubes install, I get a 'no bootable device' error. I looked at the partitioning scheme using a live usb drive and it shows a /boot partition, with EFI and GRUB information and a large encrypted partition, which presumably holds / and swap. It may be relevant that the installation was on a 500GB SSD drive and that there is also a 2TB hard disk in the system. I used gparted to delete all partitions from both devices before installing Qubes. The 2TB device is entirely unallocated and using BIOS to turn off recognition of everything but the SSD drive has no effect. Also the system indicates it has UEFI firmware.

I'm not very familiar w/ how the boot process works, but had thought there would need to be a GPT table or MBR on the disk, but automatic boot doesn't put one there. In previous attempts to install, I tried to create an ESP (GPT) partition, but the Qubes installer would not permit this (and doesn't have it as an option). In another attempt, I added a BIOSBOOT partition (for MBR table, I presume) of 1MB. Installation halts at post-installation (about half way through) and never completes.

Any suggestions?

Guy

[Marcus Linsner]

I'm one, but it may not be any good.

Try to enter BIOS and somehow select UEFI boot which should list "Qubes" as the boot device. I don't think this needs any MBR(code) as long as the partitions exist, like:

$ sudo fdisk -l /dev/sda
Disk /dev/sda: 223.6 GiB, 240057409536 bytes, 468862128 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: D72B9D42-215E-483B-82A3-28CA53959280

Device Start End Sectors Size Type
/dev/sda1 2048 1640447 1638400 800M EFI System
/dev/sda2 1640448 468860927 467220480 222.8G Linux filesystem

See none is marked as bootable (would be an "*")
the EFI System is a vfat partition:
$ lsblk|grep sda
sda 8:0 0 223.6G 0 disk
├─sda2 8:2 0 222.8G 0 part
└─sda1 8:1 0 800M 0 part /boot/efi

The point is, BIOS should be capable itself of reading your /dev/sda1 FAT partition and boot from it(in UEFI mode) without needing to run any MBR code(aka Legacy). Actually I just looked, my MBR starts with lots of zeroes until the partitions are defined, but the very next sector starts with "EFI PART" so maybe there's some kind of stamp that's required? I don't know, I'm new to all this EFI thing.

In BIOS you may have two settings something like "Legacy" (needs MBR code and a partition set active in order to succeed booting - but maybe Qubes Installer didn't prepare for this if it detected you system supports UEFI? I'm guessing here) and something like "UEFI". See if you can try to boot in UEFI mode. That's my suggestion basically.


See also: https://www.qubes-os.org/doc/uefi-troubleshooting/

[Marcus Linsner]

On Friday, September 7, 2018 at 12:27:04 PM UTC+2, Marcus Linsner wrote:
> Actually I just looked, my MBR starts with lots of zeroes until the partitions are defined

In fact the MBR contains the definition of only one (dummy)partition, since it's GPT, like:

[ctor@dom0 ~]$ sudo dd if=/dev/sda of=here.mbr bs=512 count=1
1+0 records in
1+0 records out
512 bytes copied, 8.5102e-05 s, 6.0 MB/s
[ctor@dom0 ~]$ fdisk -l here.mbr
GPT PMBR size mismatch (468862127 != 0) will be corrected by w(rite).
Disk here.mbr: 512 B, 512 bytes, 1 sectors

Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

Disklabel type: dos
Disk identifier: 0x00000000

Device Boot Start End Sectors Size Id Type
here.mbr1 1 468862127 468862127 223.6G ee GPT

but this doesn't matter.

I see the 'Boot' field is present only here (when type is dos, but not when type is gpt)

[Guy Frank]

Hi Marcus: Thanks so much for your input on this! You're on the right track to think this is a UEFI issue. I've learned more about my problem, so let me explain.

I have new hardware and the BIOS that comes w/ it *absolutely refuses* to run MBRs for internal storage (HDD, SSD). Problem is that when I transfer the Qubes ISO over to a USB drive, it sets up the drive with a MBR (fdisk -l shows 'msdos' or 'dos'). Apparently the Qubes installer takes a cue from the install medium and installs with a MBR, not with UEFI / GPT (again, checked with fdisk -l). When I try to run the installation, even though it's all there, the BIOS refuses to treat the installation as a bootable disk--so it boots nothing and throws an error.

If I understand your suggestion, it's to set the BIOS to UEFI and try to install. Problem is it will not read my usb drive with the Qubes install on it--because the drive has a MBR and UEFI mode will not read a thumb drive that isn't UEFI / GPT.

I therefore looked for instructions on how to convert the Qubes installation USB drive to UEFI / GPT (and then install w/ BIOS set to UEFI). I followed the instructions here:

https://www.qubes-os.org/doc/thinkpad-troubleshooting/

Ran into two problems. One is that I get an error at the end of creating the GPT thumb drive saying that there is no grub.cfg file to write out to the USB. [specifically: sed: can't read /run/tgttmp.xI67OE/EFI/BOOT/grub.cfg: No such file or directory] Have no idea what causes that, but perhaps a grub.cfg is not essential. The second problem I run into is that, contrary to the instructions, I see no xen.cfg under .../EFI/BOOT, just a BOOT.cfg. I change the label to BOOT in this cfg file, the only one in that directory.

When I try to install, I get a 'Panic on CPU 0' and installation halts before I get to the Qubes GUI install. The error seems to be that Xen can't read the cmos time to set its time. One of the calls is to efi_get_time.

When I installed from a MBR USB stick, I got to the Qubes QUI install w/o any fatal errors. So am guessing there's something about efi_get_time that isn't cooperating w/ my computer's hardware.

At this point, I don't know whether I should give up because Qubes is not yet compatible with my hardware (Dell Precision 3630), or whether I should continue my efforts, perhaps by finding alternative instructions for creating UEFI USB sticks for installation.

Best, Guy

[Guy Frank]

OK, then, I read somewhere that DVD-ROM installations will install either UEFI or Legacy, depending on the setting of the BIOS. So, I tried burning a DVD w/ Qubes and running that. I get the same error as above, including the efi time problem (which I suspect also shows the install is going to UEFI), so it looks like when I do succeed in installing from a UEFI media, I simply run headlong into a software bug related to my newer hardware. I can't find any info on the bug online and have no idea how I might fix it. Qubes, then, looks like it's out for me. This is the 2nd time I've tried to use Qubes and run into severe problems. Oh well, would be a great OS to be using, but if I can't, I can't.

[awokd]

If you do want to give this another go at some point, try this one:
https://www.qubes-os.org/doc/uefi-troubleshooting/#installation-freezes-before-getting-to-anaconda--disable-efi-runtime-services
. It's an ugly solution but let me get Qubes installed on a troublesome
computer.

[Guy Frank]

Hi awokd: Thanks for the astute reply. I've been meaning to mention on this board that I tried exactly what you are suggesting. And, yup, Qubes installed. However, there have been some problems. I'll open a new post with my problems on that.

Thanks again!
Guy

[Guy Frank]

Apparently a new post will not be necessary. I did some digging on this users group and learned that the following command would enable my ethernet controller (so it wasn't a driver issue at all):

qvm-pci attach --persistent --option permissive=true --option no-strict-reset=true sys-net dom0:00_1f.6

So, it took me only about 55 hours of tearing my hair out to get Qubes running on my computer. Admittedly, I'm not an IT professional, but I know a fair amount about linux systems, which I've been using for 12 years.

If the goal is that more people adopt Qubes, it really should be a lot easier to install (and hopefully won't run into difficult bugs while running--have already had two boot ups where I couldn't get the qubes manager or any qube other than dom0 running. error was something like 'unable to open line 9 in qubes.qubes.manager'). Ok, so there are bugs in the UEFI firmware, but shouldn't it be possible to do a bit of testing in the code to see if the bug is there and then automatically implement some of the fixes on the UEFI troubleshooting page? And shouldn't an OS be able to recognize and run an Ethernet card w/o the user issuing root commands?

Well, easy for me to say--I don't have the programming skills to actually contribute to Qubes and I realize the development team for Qubes isn't large and has limited resources. I persisted w/ Qubes because it seems to have some marvelous capabilities. So, kudos to the development team, albeit some frustration as well.

Best wishes,
Guy

[awokd]

On Tue, September 11, 2018 3:56 pm, Guy Frank wrote:

> Apparently a new post will not be necessary. I did some digging on this
> users group and learned that the following command would enable my
> ethernet controller (so it wasn't a driver issue at all):
>
> qvm-pci attach --persistent --option permissive=true --option
> no-strict-reset=true sys-net dom0:00_1f.6
>
> So, it took me only about 55 hours of tearing my hair out to get Qubes
> running on my computer. Admittedly, I'm not an IT professional, but I
> know a fair amount about linux systems, which I've been using for 12
> years.

It took me days as well to figure out that no-rs hack and get Qubes
installed the first time.

> If the goal is that more people adopt Qubes, it really should be a lot
> easier to install (and hopefully won't run into difficult bugs while
> running--have already had two boot ups where I couldn't get the qubes
> manager or any qube other than dom0 running. error was something like
> 'unable to open line 9 in qubes.qubes.manager'). Ok, so there are bugs
> in the UEFI firmware, but shouldn't it be possible to do a bit of testing
> in the code to see if the bug is there and then automatically implement
> some of the fixes on the UEFI troubleshooting page? And shouldn't an OS
> be able to recognize and run an Ethernet card w/o the user issuing root
> commands?
>
> Well, easy for me to say--I don't have the programming skills to actually
> contribute to Qubes and I realize the development team for Qubes isn't
> large and has limited resources. I persisted w/ Qubes because it seems
> to have some marvelous capabilities. So, kudos to the development team,
> albeit some frustration as well.

Agree this is a good goal, but afraid to say I'm not a good enough coder
either to tackle it...

Glad you got it working finally!

[Guy Frank]

Whew, it's not just me :-} . Thanks awokd.