On Wed, May 24, 2017 at 12:25:10AM -0600, Chris Murphy wrote: > On Wed, May 24, 2017 at 12:22 AM, Chris Murphy <lists@xxxxxxxxxxxxxxxxx> wrote: > > Here's an example from an updated system that > > fails to boot due to zero length grub.cfg; > > > > -rw-------. 1 root root 59650987 May 23 18:16 > > initramfs-0-rescue-a0269ef67a5f4c1ca97e0817ac1c4a6d.img > > -rw-------. 1 root root 19764807 May 23 18:16 initramfs-4.11.0-2.fc26.x86_64.img > > -rw-r--r--. 1 root root 182704 Feb 10 22:58 memtest86+-5.01 > > -rw-------. 1 root root 3548950 May 9 09:42 System.map-4.11.0-2.fc26.x86_64 > > -rw-------. 1 root root 0 May 15 13:46 System.map-4.11.1-300.fc26.x86_64 > > -rwxr-xr-x. 1 root root 7282776 May 23 18:16 > > vmlinuz-0-rescue-a0269ef67a5f4c1ca97e0817ac1c4a6d > > -rwxr-xr-x. 1 root root 7282776 May 9 09:43 vmlinuz-4.11.0-2.fc26.x86_64 > > -rwxr-xr-x. 1 root root 0 May 15 13:46 vmlinuz-4.11.1-300.fc26.x86_64 > > > > -rw-rw-r--. 1 root root 0 May 23 18:44 grub.cfg > > FWIW this was mounted with -o ro,norecovery following an update that > resulted in the problem of hitting the grub prompt instead of a boot > menu. Yup, if the files were sync()d then the file size updates are still in the journal which has not been replayed. This is what we've been saying is the problem all along and that a post-update freeze will work around. If won't fix the fact that the updates are not fail-safe (crash before freeze will still leave the config file update in this state), but it will avoid the failure in the "update successful, reboot without unmounting" scenario being used here. 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
