[Pkg-sysvinit-devel] Bug#757083: Bug#757083: initscripts: please treat /usr (if separate) the same as /

Simon McVittie smcv at debian.org
Fri Aug 8 17:02:34 UTC 2014

On 08/08/14 15:33, Henrique de Moraes Holschuh wrote:
> As for using -M in the checkfs initscript, it looks like it can be done as
> long as the initramfs will make sure to fsck anything it will mount.  With
> that in mind, I will second this change in checkfs.

Good. The currently-proposed initramfs-tools patchset already fscks
everything it mounts, and I hope nobody is going to propose a patchset
that does otherwise.

> Note that someone else will have to do the work and testing, and come up
> with a tested patch, and attach it to #757083.

I'll try to do that at some point, but I will be delighted if someone
else comes up with a patch sooner.

> Also, redundant fsck is not supposed to be a problem: it should skip the
> clean filesystem.  It is a non-problem when compared with mounting a dirty
> filesystem (even if it would happen only on rare use cases), which causes
> data loss.  If this adds some boot latency, so be it. REALLY.

Great. Then switching to fsck -M does not block the other bugs, and
initscripts/systemd redundantly fsck'ing a root filesystem that is
already (intentionally) mounted ro shouldn't be a problem.

> Anyway, if we switch checkfs to fsck -M, there would be no need to change
> the fsck wrapper -R behaviour, would there be?  So maybe #697002 can be
> dismissed?

Or turned into "use fsck -M instead of fsck -R" and reassigned to
initscripts, yes.

> BTW: whether the kernel uses modules or not is orthogonal to whether it has
> an initramfs or not.  It took me some time to notice you meant "no
> initramfs" when you wrote about monolithic (module-less) kernels in #757083
> and #697002.

Sorry, yes, "monolithic" was a poor choice of shorthand there.


More information about the Pkg-sysvinit-devel mailing list