diff options
| author | Colin Walters <walters@verbum.org> | 2017-08-02 22:07:26 -0400 |
|---|---|---|
| committer | Atomic Bot <atomic-devel@projectatomic.io> | 2017-08-08 16:09:04 +0000 |
| commit | 8642ef5ab3fec3ac8eb8f193054852f83a8bc4d0 (patch) | |
| tree | 4105371c58a3e719836e0d19a70b72508a22919d /tests/test-admin-deploy-uboot.sh | |
| parent | 9f8f351cd45e5dd0219c3177558b497ab10c58e9 (diff) | |
| download | ostree-8642ef5ab3fec3ac8eb8f193054852f83a8bc4d0.tar.gz | |
lib/deploy: Use a FIFREEZE/FITHAW cycle for /boot
See: http://marc.info/?l=linux-fsdevel&m=149520244919284&w=2
XFS doesn't flush the journal on `syncfs()`. GRUB doesn't know how to follow the
XFS journal, so if the filesystem is in a dirty state (possible with xfs
`/boot`, extremely likely with `/`, if the journaled data includes content for
`/boot`, the system may be unbootable if a system crash occurs.
Fix this by doing a `FIFREEZE`+`FITHAW` cycle. Now, most people
probably would have replaced the `syncfs()` invocation with those two
ioctls. But this would have become (I believe) the *only* place in
libostree where we weren't safe against interruption. The failure
mode would be ugly; nothing else would be able to write to the filesystem
until manual intervention.
The real fix here I think is to land an atomic `FIFREEZETHAW` ioctl
in the kernel. I might try a patch.
In the meantime though, let's jump through some hoops and set up
a "watchdog" child process that acts as a fallback unfreezer.
Closes: https://github.com/ostreedev/ostree/issues/876
Closes: #1049
Approved by: jlebon
Diffstat (limited to 'tests/test-admin-deploy-uboot.sh')
| -rwxr-xr-x | tests/test-admin-deploy-uboot.sh | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/tests/test-admin-deploy-uboot.sh b/tests/test-admin-deploy-uboot.sh index d9104f8c..5262b48a 100755 --- a/tests/test-admin-deploy-uboot.sh +++ b/tests/test-admin-deploy-uboot.sh @@ -20,7 +20,7 @@ set -euo pipefail -echo "1..19" +echo "1..20" . $(dirname $0)/libtest.sh |