On Wed, Mar 15, 2017 at 12:13:55PM -0700, Darrick J. Wong wrote: > On Wed, Mar 15, 2017 at 12:11:22PM -0600, Chris Murphy wrote: > > On Wed, Mar 15, 2017 at 1:23 AM, Darrick J. Wong > > <darrick.wong@xxxxxxxxxx> wrote: > > > > > > > > So... you fire up gnome-software, click "Update", it downloads rpms to > > > the hard disk, reboots, (presumably) installs the rpms, reboots again, > > > and after the /second/ reboot grub just barfs up a grub> prompt? > > > > Correct. > > > > > > > Now I'm curious how systemd actually triggers the reboot. Unmounting > > > would seem to force the log and push the AIL, which (you'd think) would > > > be enough. But maybe systemd is doing something weird? Or maybe > > > post-update we fail to unmount / ? > > > > If I boot with the following parameters, and use virsh console to > > track what's going on right after the updating, > > > > systemd.log_level=debug systemd.log_target=console console=ttyS0,38400 > > > > > > > > Sending SIGTERM to remaining processes... > > Sending SIGKILL to remaining processes... > > Process 304 (plymouthd) has been marked to be excluded from killing. > > It is running from the root file system, and thus likely to block > > re-mounting of the root file system to read-only. Please consider > > moving it into an initrd file system instead. > > Heh. So the splash screen is still running and we can't unmount /. > Consequently systemd remounts the fs readonly... > > > Unmounting file systems. > > Remounting '/tmp' read-only with options 'seclabel'. > > Unmounting /tmp. > > Remounting '/' read-only with options 'seclabel,attr2,inode64,noquota'. > > Remounting '/' read-only with options 'seclabel,attr2,inode64,noquota'. > > Remounting '/' read-only with options 'seclabel,attr2,inode64,noquota'. > > (I wonder why it does this three times?) Because systemd (v229, anyway) doesn't ever unmount /; it merely tries to remount it readonly. Regrettably it /also/ throws away the return code from the mount call so there's no way to positively confirm my current theory, which is that we don't actually succeed at the remount-ro request and that's why the log needs recovery after the reboot. So maybe plymouthd, or journald, or systemd, or something else entirely still holds a writable file descriptor to somewhere on the rootfs. I guess you could build a custom systemd that actually logs the return value.... > > All filesystems unmounted. > > Deactivating swaps. > > All swaps deactivated. > > Detaching loop devices. > > device-enumerator: scan all dirs > > device-enumerator: scanning /sys/bus > > device-enumerator: scanning /sys/class > > All loop devices detached. > > Detaching DM devices. > > device-enumerator: scan all dirs > > device-enumerator: scanning /sys/bus > > device-enumerator: scanning /sys/class > > All DM devices detached. > > Spawned /usr/lib/systemd/system-shutdown/mdadm.shutdown as 8408. > > /usr/lib/systemd/system-shutdown/mdadm.shutdown succeeded. > > system-shutdown succeeded. > > Failed to read reboot parameter file: No such file or directory > > Rebooting. > > [ 52.963598] Unregister pv shared memory for cpu 0 > > [ 52.965736] Unregister pv shared memory for cpu 1 > > [ 52.966795] sd 1:0:0:0: [sda] Synchronizing SCSI cache > > [ 52.991220] reboot: Restarting system > > [ 52.993119] reboot: machine restart > > ...and reboots, having not unmounted, and (I guess?) without forcing the > log to write all of the logged changes back to the metadata. They > changes are safely recorded /in/ the log.... > > > <no further entries, VM shuts down> > > > > However, I get a different result. This time I get a stale grub menu > > with a single kernel option (same as if the update hadn't happened). > > If I boot, kernel messages reports log replay. When I reboot again, > > ...because mounting replays them and after that the metadata is up to > date. > > Strange, though, because afaict we xfs_attr_quiesce seems to do the > right things when we remount rw->ro, so you wouldn't think that there > would be a need to recover. Maybe there's something funny going on > w.r.t. the three messages about remounting readonly? Or maybe we're simply /not/ remounting readonly despite the log messages, as mentioned above. --D > > now I have a two kernel grub menu. I'm guessing the slowness of > > systemd debug is resulting in the difference; more time to commit the > > changes? > > > > Anyway, it looks / is remounted read-only before reboot. Note, this is > > a single partition/volume setup, so /boot/grub2/grub.cfg being > > modified by grubby is on the fs being remounted read-only and reboot > > time. > > --D > > > > > > > > > -- > > Chris Murphy > > -- > > 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 > -- > 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 -- 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
