On Wed, Mar 15, 2017 at 1:30 PM, Darrick J. Wong <darrick.wong@xxxxxxxxxx> wrote: > 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: >> > 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. The last line after those three is "All filesystems unmounted." So if it isn't really unmounting, then that's a bogus message. Also, on Btrfs I'm getting the same three remounting messages, and the unmounted message. Remounting '/' read-only with options 'seclabel,space_cache,subvolid=5,subvol=/'. Remounting '/' read-only with options 'seclabel,space_cache,subvolid=5,subvol=/'. Remounting '/' read-only with options 'seclabel,space_cache,subvolid=5,subvol=/'. All filesystems unmounted. > 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.... Yuck. I'll ask on systemd list if there's a way to get more verbose information about this without that. It really ought to be in systemd.log_level=debug anyway. -- 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
