Re: [PATCH 3/3] xfs: freeze rw filesystems just prior to reboot

[Eric Sandeen <sandeen@redhat.com>]

On 5/22/17 10:56 PM, Chris Murphy wrote:
> On Mon, May 22, 2017 at 2:46 PM, Chris Murphy <lists@colorremedies.com> 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.
> 
>