[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: packages being essential but having stuff in /usr/?!

On Fri, 16 Jul 2010, Christoph Anton Mitterer wrote:
> Having $remote_fs is a really nice way to secure that /usr/-stuff is
> there (and also other stuff like /var...)

It is the *only* supported way, AFAIK...

> As far as I understand - please correct me if I'm wrong - the root-fs is
> just guaranteed, to have /bin/, /sbin and /lib, right? Neither /var
> nor /opt.
> What about /etc?

> Also, right after the init system starts, neither /proc, nor /dev,
> nor /sys are there, right?

You can assume /etc is available along with the root filesystem (/etc must
be part of /).  However, it will be *read-only*.  Read-write scrach space
goes into /lib/init/rw during early userspace, and it does not even exist
during very early userspace.

/proc, /dev and /sys get mounted VERY early, before / is available in
read-write mode.  This does NOT mean everything you might want in /dev is
already functional, or that every module has already been loaded (and
therefore it is possible that something you might want in /proc or /sys
might not be there yet, if ever).

So, it is "You Must Really Know What You're Doing" land.  Look at the code.
We risk much breakage should docs and reality go out of sync.

And it depends on whether an initramfs did some setup or not.  And if you're
doing *anything* that early, you are to subscribe to the relevant
mailinglists for the initscript subsystems to keep in the loop.

> Would it be a good idea, to add new virtual facilities like $dev, $proc
> or so?

Well, this is stuff that is too fragile.  And stuff will only be on /proc or
/dev AFTER the kernel support is active, which can happen rather later than
you would expect (or much earlier!).

It is best to come up with specific scenarios, and bring these up on the
initscripts subsystem ML.

> That way init-scripts could try to even restrict their dependencies
> more, and don't need to find out the current init script (e.g.
> mountdevsubfs.sh)

Only if it doesn't make things even more uncertain.

  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Reply to: