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?) > 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? > 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
