What you are saying does not exactly match what I have previously seen, but there is a known feature with using a journaling filesystem (ext4-journal, or xfs) for /boot, if only the journal is updated and if it is not yet replayed into the non-journal then grub will not be able to find the new files/updated files (grub filesystem code is simple and does not process the journal so if critical updates are still in the journal then those updates(changed file, new files) cannot be seen). To get this one generally has to do the update and almost immediately reboot (within a few minutes though in some cases, note syncing the does not replay the journal). The fix is to boot up with a kernel that it can still find and/or livecd and mount /boot so that the journal gets replayed, or fsck boot so that the journal gets replayed. Long term the solution is to move boot to a non-journaled fs (ext without a journal) or after each update umount/mount /boot(before reboot).. If /boot is not separated then you cannot umount/mount it to get the journal to replay. There is a second method to force a journal replay, but reports say that one often "hangs" when /boot is not separate so is not a reliable solution. There were some detailed posts on this several years ago with reliable commenters confirming the behavior. I have also personally seen the issue a number of times and mount /boot and/or fscking corrects it (replays journal). On Fri, May 8, 2020 at 8:52 AM John Mellor <john.mellor@xxxxxxxxx> wrote: > > I have one completely stock workstation F32 machine where kernel updates > almost always cause a multiple-reboot panic problem. This problem also > occurred on F31, but not on releases before that. I'm stumped and need > some help in figuring it out. > > The symptoms vary in the number of reboots and the type of tertiary > error, but are otherwise pretty similar. It does not matter whether I > use the Gnome update app or the CLI dnf method. After a number of > reboots, the upgrade succeeds and Fedora behaves nortmally again. I > think that this only happens whenever the kernel is upgraded. > > What I observe is that the machine is rebooted and on reboot, grub (I > think) gets a halt for a 32-bit relocation error. This sequence may > happen twice. Its an i7 with plenty of memory and an SSD boot disk, so > the 32-bit thing is confusing. To get around this error, I powercycle > the box and get into the next stage of the problem. One the 2nd or 3rd > reboot, I usually see a halt with an access outside of the kernel space, > although with the update this morning, I had a kernel panic instead. > Cold-booting again, and the update is installed, and the last reboot and > I'm up on the new updates. > > After that, the machine behaves normally until the next kernel updates. > I assume that there is some incorrectly-asynchronous operation in grub > related to the update entry, but I can find no grub logs to dig into > this problem. I have several other machines that do not see this > problem. I dug around in the fedora bugs, but not knowing what to look > for, I'm basically blind. Its a pretty serious bug, especially if the > machine is remote. Does anyone have a way out of this? > > -- > > John Mellor > _______________________________________________ > users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx _______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx
