On 2/24/20 7:17 PM, ncmy...@gmail.com wrote:
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. On Monday, February 24, 2020 at 1:58:48 PM UTC-5, Andrey Arapov wrote: 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
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. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/33130140-dc8f-9523-646f-25896193ef36%40keehan.net.
