Re: / vs. /usr vs. fsck(8)
On Mi, Okt 12, 2011 at 06:09:00 (CEST), Ivan Shmakov wrote:
>>>>>> Marco d'Itri <md@Linux.IT> writes:
>
> […]
>
> > So let's look at the reasons against merging /usr in / listed in my
> > final summary. All of them do not apply to merging / in /usr, and
> > actually become arguments in favour of doing it:
>
> > - NFS: sharing a read only system over NFS becomes much easier (I
> > would say that it actually becomes possible...)
>
> Agreed. Being one who actually have experimented with such a
> setup, I'd say that it makes an NFS boot environment much easier
> to maintain.
>
> […]
>
> However, please note that the current state of affairs (AIUI) is
> that we rely on / to check all the other filesystems before
> these are mounted. If the / filesystem is itself modified in
> the process, we're to reboot the system for safety.
>
> With /usr being mounted by initramfs, either we'd need to allow
> /usr to be checked /after/ it's mounted (by the filesystem
> checkers residing on it, which doesn't seems all that sane),
> /or/ we'd need to put all the filesystem checkers to initramfs.
AFAIUI Harald (the fedora maintainer for their initramfs tool dracut), he
dislikes having a separate set of tools in /usr and the initramfs, i.e.,
he strongly favors putting glibc, bash, iproute and similar utilities
directly in the initramfs. The main motivation (again AFAIUI) seems to be
behavioral consistency of tools between early userspace and the booted
system.
On the other hand, Debian has chosen against that and relies on klibc,
ipconfig, etc. for early userspace and thus, the initramfs. I suspect
the main motivations behind these decisions were portability and size
(please correct me and add references).
I imagine it would be pretty challenging to improve the klibc based
tools to become feature-par and sufficiently behaviorally consistent
with their glibc based equivalents. In any case, I think having this in
mind is relevant for deciding whether the various fsck(8) utilities can
or should go into the initramfs or not.
--
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4
Reply to: