No more boot after update

[Bertrand Lec]

Hello,

I'm fresh installing Qubes R3.2 on my desktop PC, aside from Ubuntu.
The PC is configured with UEFI.

The installation goes well. At that time, I can reboot directly to Qubes.

However, after I update dom0, Qubes refuse to reboot. The boot is done to Ubuntu. Even when I choose to boot Qubes in the BIOS, Ubuntu will boot.

Result of efibootmgr command is:
BootCurrent: 0000
Timeout: 1 seconds
BootOrder: 0002,0000,0005,0001,0007
Boot0000* ubuntu
Boot0001* Hard Drive
Boot0002* Qubes
Boot0005* CD/DVD Drive
Boot0007* Removable Drive

From my understanding, it says that Qubes is the first one to be booted but the currently booted is ubuntu (which is true :) )

Do you have any idea for me?

Thanks
Bertrand

[cooloutac]

you have to add qubes to the ubuntu grub.

[Bertrand Lec]

With the way the BIOS is configured, it should only boot Qubes, and it's what it did with several reboots done before the dom0 upgrade.

By the way, I have just seen that there is no *cfg file in Qubes' /boot. Is it normal...?

However, if a modification of Ubuntu's grub could be the solution, I'll take it, but I don't see what I could put there.

Bertrand

[Bertrand Lec]

Some additional information:
When the system boots, I can see those three lines at the top of the black screen:
-----
Xen 4.6.6 (c/s ) EFI loader
Using configuration file 'xen.cfg'
vmlinuz-4.9.56-21.pvops.qubes.x86_64: 0x0....-0x000...
-----
The hexa numbers at the end of the last line were long and it was not really possible to read them.
Just a few milisecond after this is displayed, either the system gets back to the BIOS or boots Ubuntu, depending on how I was booting.

Hope this will give you some ideas...

Bertrand

[erikmunk...@gmail.com]

I experienced similar issues today, it seems like it's the recent updates from the current-testing repository with the new kernel. From memory, I can tell there were errors of the kind "not enough disk space to create EFI", and I can inform the EFI is 95MB in size, strictly only containing Qubes information and data since Qubes RC-2. Note to self... use Grub and make it bigger next time... urgh...

I'm using Qubes 4 though, but perhaps Qubes 3.2. also got the same kernel update 4.14.13?

I suspected a reboot might go bad after seeing the error mentioned above, but I tried anyway. Sure enough, now the system can't boot. I tried both adding

efibootmgr -v -c -u -L Qubes -l /EFI/qubes/xen.efi -d /dev/sda -p 1 "placeholder /mapbs /noexitboot"

and also added the EFI path directly from the UEFI(BIOS). None of the two methords workek.

I'm suspecting you're having this issue too Bertrand Lec? Did you install kernel 4.14.13? If you're unsure if you did, try boot from your Qubes installer, and pick "Rescue Qubes" option in the Qubes grub boot menu. Then select 1 in the entry, type in your encryption password, and then do as the text will tell you to chroot into your Qubes system. Once there, use 'sudo cat/nano/vi/whatever-prefered' to '/path/to/EFI-file'.
It should be around /boot/efi/EFI/qubes/xen.cfg

The document should say kernel 4.14.13 if you upgraded the same as I did.

If this is indeed triggered by a too small EFI partition size, then we need to make it bigger next time to avoid it happening again. Though, this is not enough to recover now that it already happened. I'm still pondering about a possible solution.

In your case though, if you have nothing you want to save on it, you could try re-install once more, and ensure that the EFI partition is big enough in size by manually creating it yourself during install. Assuming of course, you indeed like me have this issue.

[awokd]

On Sun, January 14, 2018 11:19 am, erikmunk...@gmail.com wrote:
> Den lørdag den 13. januar 2018 kl. 19.37.57 UTC+1 skrev Bertrand Lec:

>> From my understanding, it says that Qubes is the first one to be booted
>> but the currently booted is ubuntu (which is true :) )
>>
>> Do you have any idea for me?

> If this is indeed triggered by a too small EFI partition size, then we
> need to make it bigger next time to avoid it happening again. Though,
> this is not enough to recover now that it already happened. I'm still
> pondering about a possible solution.

Not sure if you two are having the same issue but I've run into what
Erik's describing before. I luckily caught it before rebooting, but it may
also work from rescue mode. I manually deleted older versions of initramfs
etc. in /boot/efi/EFI/qubes to free up space leaving just the single most
recent, and was able to rebuild the new Qubes EFI boot image with:
/usr/bin/dracut -f
/boot/efi/EFI/qubes/initramfs-4.4.31-11.pvops.qubes.x86_64.img
4.4.31-11.pvops.qubes.x86_64
Replace the file names with the correct versions for your updated kernel.

[erikmunk...@gmail.com]

Indeed, I'm not sure either. But gonna assume it is the same until he confirms or disconfirms it.

Your suggestions sounds like a great approach, I will try it once I'm done copying my /var/lib/qubes/appvms folder. I used qubes rescue to reach dom0 terminal, and is currently copying all my data in case I need to re-install.

USB 2 slowness and a lot of data to copy, probably gonna take some hours to run. Once finished then I'll try your method out, as you said hopefully it works in rescue/tty mode.

I'll rapport back the outcome once I get through all the slow copying.

[erikmunk...@gmail.com]

Den søndag den 14. januar 2018 kl. 12.55.00 UTC+1 skrev awokd:

Amazing, your approah worked smoothly!
Also I can confirm it works just fine in recovery mode too.

Although I had to make some small minor modifications due to my slight different situation, since seemingly I did not have the new initramfs-4.14.13-1.pvops.qubes.x86_64 and only my old one initramfs-4.9.56-21.pvops.qubes.x86_64
I'm not too sure why it didn't work for the new kernel, whether or not it was due to the missing initramfs or not, but either way, it was probably just that, lack of diskspace on the partition.

I did not just delete the old initramfs in the reocvery mode, since guessing it might leave worse off not having a single one available. So to be sure not to mess up, I could either make a copy elsewhere for backup before deleting the last initramfs, or try restore my old kernel.

So I resorted to trying re-establish my old kernel using your method, and it worked. I'll explain what I did below in details in case others need it too. I used your post as a guideline to make these modifcations.

I booted my system normally using the old kernel after the above fix, and proceeded to "sudo dnf remove kernel-4.14.13-1.pvops.qubes.x86_64" to get rid of the new broken kernel.

I then made a backup copy of my EFI folder to my home folder (In case I needed it again), and then followed up to delete the old 21MB'ish or so in size initramfs for my old and current running kernel system.

I then proceeded with updating again, installing the new kernel. This time it installed cleanly. I then checked the EFI folder if the new kernel and new initramfs was there, and the xen.cfg file also correctly pointed to the kernel and initramfs without the need for edits.

Then rebooted, and now it works flawlessly with the new kernel update.

Thanks a lot awokd!

@Bertrand Lec, did you get yours working?

[Bertrand Lec]

So, a little summary:
- I have plenty of room in my EFI partition.
- I was not installing from testing, just from normal repository, so my kenerl was 4.9.56
- I tried the dracut command, without success

However, I did a new fresh install of R3.2 but this time, to do the dom0 update, I chose to use testing repository (--enablerepo=qubes-dom0-current-testing), and it works now fine !

What worries me the most is that I don't understand what happened (and that I am afraid of doing a new update of dom0, as it is requesting it).

Thank you all,
Bertrand