No boot after dom0 kernel update

45 views
Skip to first unread message

ncm...@gmail.com

unread,
Feb 24, 2020, 1:43:34 PM2/24/20
to qubes-users
I find that, when I update dom0 with a new kernel, too
often my machine won't boot anymore, after the update.

Then I need to tinker with the boot partition. It seems as if,
this last time, what worked was to run fsck.vfat on the
partition. I am (I hope understandably) reluctant to mess
about with this bit of infrastructure without strong need.

The machine is an ASUS K501UW, UEFI boot only, that
needs "nouveau.modeset=0" to avoid frequent kernel oopses,
so installing was a chore.

Is there a way to get reliable booting after a dom0 kernel
update?

Do I need to unmount my /boot partition and fsck.vfat it
before rebooting?

Andrey Arapov

unread,
Feb 24, 2020, 1:58:48 PM2/24/20
to ncm...@gmail.com, qubes-users
Is there a way to get reliable booting after a dom0 kernel
update?

I am afraid that there is no such way as the new Linux kernel adds new features, changes the current ones, which are unlikely were thoroughly tested (or if tested at all) for the whole range of HW out there or their combinations.

Whenever you are upgrading the SW, be it a Linux kernel or any other software, you should always expect things can go wrong.
The good news is that you can always rollback and contribute to the FOSS by reporting the issue.
Do I need to unmount my /boot partition and fsck.vfat it
before rebooting?


You should always unmount the mount point before fsck'ing any filesystem.

Kind regards,
Andrey Arapov

ncm...@gmail.com

unread,
Feb 24, 2020, 2:17:00 PM2/24/20
to qubes-users
Thank you for your kind attention.

I want to make clear that in each case, the new kernel has worked
fine once I persuaded my BIOS to boot it. The problem is always
that, after each kernel upgrade, the BIOS no longer recognizes any
bootable partition, not even listing the drive among its boot options.

Unmounting before fsck is the standard process, but I wonder why
and how the dom0 kernel upgrade script leaves the boot partition
in a state that the BIOS will not boot. I am far from certain that the
fsck.vfat was what restored bootability, but something did.

Andrey Arapov

unread,
Feb 24, 2020, 2:33:52 PM2/24/20
to ncm...@gmail.com, qubes-users
I want to make clear that in each case, the new kernel has worked
fine once I persuaded my BIOS to boot it. The problem is always
that, after each kernel upgrade, the BIOS no longer recognizes any
bootable partition, not even listing the drive among its boot options.
Unmounting before fsck is the standard process, but I wonder why
and how the dom0 kernel upgrade script leaves the boot partition
in a state that the BIOS will not boot. I am far from certain that the
fsck.vfat was what restored bootability, but something did.

dom0 kernel upgrade should not leave the boot partition in such undesired state,
unless there is some hard to reproduce bug. Otherwise it will get fixed really soon.

I do not have whole lot of details about your configuration.. but if you really believe this
issue is caused by the dom0 kernel upgrade script, then try to reproduce it in a minimal
amount of steps, e.g.:

1. install qubes os of version X.Y.Z with the /boot on FAT FS (+ any other custom settings you have, including if you have a dual boot);
2. run qubes-dom0-update kernel-x.y.z;

Otherwise it's hard to help.

You can also inspect the install scripts by yourself:
$ rpm -q --scripts kernel
$ less /bin/kernel-install


Kind regards,
Andrey Arapov

Mike Keehan

unread,
Feb 25, 2020, 5:46:47 AM2/25/20
to qubes...@googlegroups.com
If your boot partition needs fsck'ing after something writes to it
(like a Qubes update), then it seems that the partition needs to
be fixed. Probably best to rebuild it if you know how.

Mike.

Reply all
Reply to author
Forward
0 new messages