On Mon, May 22, 2017 at 11:04:54PM -0500, Eric Sandeen wrote: > 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. Actually, IIUC what Stewart told me at LCA earlier this year, what petitboot does now is far more convoluted and whacky than mount -o norecovery. It overlays a write-capturing ram disk on top of the block device, mounts the filesystem and performs log recovery. All writes from log recovery go into the ram disk so it never modifies the underlying block device. It then traverses the recovered filesystem to find the kernel images, and once they are found it boots from them, throwing away the ramdisk that contained the recovered changes from the log. > Hacks upon hacks. It's hacks all the way down.... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx -- 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
