First thought: Even without the exit code or anything, it's going to be -EBUSY like 99.999% of the time. Not much else can fail during umount.
And ”Filesystem is busy" would perfectly fit the earlier error message which you overlooked: "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." So you have a process holding / open (Plymouth is the boot splash screen app) and the kernel doesn't allow it to be umounted due to that. On Tue, Mar 21, 2017, 05:25 Chris Murphy <li...@colorremedies.com> wrote: > Any thoughts on this? > > I've followed these instructions: > https://freedesktop.org/wiki/Software/systemd/Debugging/ > Shutdown Completes Eventually > > However, no additional information is being logged that gives any > answer to why there are three remount ro attempts, and why they aren't > succeeding. > > https://github.com/systemd/systemd/blob/master/src/core/umount.c > line 409 > > This suggests three ro attempts shouldn't happen. And then 413 says > that / won't actually get umounted, reboot happens leaving it ro > mounted. So the "All filesystems unmounted." doesn't tell us anything; > but it does seem like there should be a way to expose exit code for > umount. I'm just not sure how to do it, and if that means compiling > systemd myself. > > -- > Chris Murphy > _______________________________________________ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/systemd-devel > -- Mantas Mikulėnas <graw...@gmail.com> Sent from my phone
_______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
