A sync will flush the writes to the journal were the data is safe. It will not force a replay of the journal. Nothing except removing the journal from the ext4 filesystem will fix it. This is not a fedora bug, this is a long standing kernel/grub/filesystem interaction bug (all who use a journaled filesystem have this bug). See tune2fs and something like -O ^has_journal will turn off the journal. It has to be done unmounted and verify that your fstab entry will remounted it. Check /proc/mounts having data=XXX (probably ordered) says you have a journal, after the umount+above tune2fs+remount the data=ordered will be gone. On Fri, May 8, 2020 at 10:53 AM John Mellor <john.mellor@xxxxxxxxx> wrote: > > Interesting! This machine does reboot in about 5secs and the other > machines take longer, so it makes sense. My /boot is mounted just like > /home and / as follows: > > /dev/sda1 on /boot type ext4 (rw,relatime,seclabel) > > I assume that a symple sync would flush the journal. Its pretty easy to > do a sync;sync if updating using the CLI, but not possible when using > the GUI. Is this a Fedora bug where the journal is not correctly > flushed on the reboot? Should I modify that mount entry or do achattr > change to workaround the bug? > > > On 2020-05-08 11:11 a.m., Roger Heflin wrote: > > 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 > _______________________________________________ > 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
