On 5/22/17 10:56 PM, Chris Murphy wrote: > On Mon, May 22, 2017 at 2:46 PM, Chris Murphy <lists@xxxxxxxxxxxxxxxxx> wrote: > >> Second, I have only been able to reproduce this problem with grubby + >> XFS. > > OK so this is just on Fedora/RH systems, which is the example case I > have. The kernel RPM is running a script called new-kernel-pkg which > is part of grubby. It's found here: > > https://github.com/rhinstaller/grubby/blob/master/new-kernel-pkg > > # make sure changes make it to the disk. > # if /boot is a mountpoint, force the meta data on disk > # to by-pass writeback delay. > # PPC64LE-only to deal with Petitboot issues > if [ "$ARCH" = "ppc64le" ]; then > sync && mountpoint -q /boot && fsfreeze -f /boot && fsfreeze -u /boot > fi > > > So why only Petitboot on ppc64 is considered to need this? because petitboot essentially a full kernel & userspace, and it is (may be?) a different endianness than the os and the filesystem it's booting... so normally it actually /could/ replay the log, but it can't due to the different endianness. So, freeze / unfreeze to quiesce, and then petitboot does mount -o norecovery to ignore the unmount record we leave lying around on a frozen fs. Hacks upon hacks. -Eric > Also I put zipl in the bootloader category that doesn't need to be totally > reinstalled, which is incorrect it's more like lilo. I guess I was thinking of > yaboot. In any case the main point remains that the common > bootloaders being used these days depend only on modification of a > bootloader configuration file via the file system that file is located > on. > > -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
