[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.
S
More information about the Pkg-sysvinit-devel
mailing list