Re: Stuff from /bin, /sbin, /lib depending on /usr/lib libraries
2012/8/30 Michael Biebl wrote:
>> All PAM modules are installed under /lib, because that's the path
>> used by libpam to load them. However, I don't think the vast
>> majority of PAM modules could be considered critical for early boot
>> or need to be usable without /usr mounted
> Imho moving pam modules around is just wasted (maintainer) time.
Are they needed to mount other filesystems? Are they needed for `root`
user to log in? If not, why bother? ;) (see a long explanation below)
> A much more sensible approach is to just lift the /-vs-/usr restriction.
> The obvious way is to not use a separate /usr anymore or simply mount
> /usr via the initramfs.
It doesn't really solve a problem, it just turns one problem into
another one. I'll try to put some details in.
It was long time ago, there may be some mistakes in my explanation,
please correct me if they are.
Many (most?) major successes in IT history were about inventing a good
standard communication interface to do things. IBM PC was successful
because it could be assembled from standard easily accessible components,
and was easy to upgrade by just replacing those components with newer
ones. That worked so good because there were standard interfaces for
devices (ISA, PCI, AGP, etc).
Similar things happened to the systems, installed on IBM PC. For many years
typical OS booting looked very simple: BIOS just executes first 512 bytes
of HDD (MBR, aka Master Boor Record) and it did not care what those bytes
do. That simple idea allowed to install any OS, one just had to wrote its
OS loader into MBR. And that made it possible to write many different OSes,
which brought more success to BIOS approach and IBM PC.
Then the dual(multi)-boot idea arose. To make it possible to install several
systems there came boot loaders (I've seen some ancient DOS-time boot
managers but don't remember their names any more). They also worked for
UNIXes (and linux). Boot loader just started OS kernel and did not care what
it's going to do next.
POSIX was so great that it allowed a great idea of network file systems.
Each machine did not have to contain everything locally any more, it could
just have a bare minimum, and mount everything else from a local server.
For linux it meant that kernel mounts a small root partition, which in turn
mounts everything else.
Kernel, obviously had to reach its root partition. Thus all the disk
controllers drivers and filesystem modules had to be built into the kernel.
When one wanted to change disk controller he had to rebuild the kernel,
otherwise kernel could not get to root filesystem. That was not good, so
initrd came to the rescue. It was basically a small root-like image, it's
only goal was to help kernel reach the root partition (which could mount
everything else anyway).
All this turns into a standard boot sequence:
1. BIOS runs boot loader
2. Boot loader boots kernel (optionally with initrd/initramfs)
3. Kernel mounts root partition (/)
4. Root partition mounts everything else (/usr, /var, /home, /srv, /opt...)
5. Then all the programs are started
And each of these steps appeared for a reason.
This standard boot sequence brought a great flexibility and allowed people
to turn their systems into whatever they need. Separation between steps was
very clear:
* Things that might be needed to mount other filesystems belong to /.
* Things needed to reach / belong to initrd.
* If something does not mount, admin must be able to log in and check/fix
things (that's why /root is not /home/root).
That allowed a small (even read-only) root partition that should probably
never break because of power outage, which is good for servers.
Everything was good. The problem came from the Internet and network-mounted
filesystems. Modern networks allow to mount filesystems using nfs/samba,
and an Internet connection to do that could be brought up with help of such
things as network manager, wpa_supplicant, usb_modeswitch, and so on. So
the problem is that if we continue to literally follow that separation
("things that might be needed to mount other filesystems belong to /")
we should put more and more software to /, thus defeating the purpose of
good small root partition.
And here comes the question: where to put new programs, to / or somewhere
else (/usr, or maybe /opt)? Things were even worse because almost nobody
remembers anymore what this separation was used for.
Then a radical suggestion appeared: since nobody remembers why it was done
that way, change the historical sequence and merge #4 into #3, by having
initramfs mount not just root partition but also mount /usr (and then even
move /s?bin to /usr). But it does not really solves the problem. It just
turns the question "what should be a part of the root partition" into
question "what should be a part of initramfs".
This approach has an advantage: initramfs can be generated dynamically, so
one can dynamically rebuild it including required network stuff there. But
it also have major disadvantage — it's limited by the initramfs size (which
is much smaller then root partition and can support fewer boot options),
thus it reduces flexibility, breaking use cases, that were working before.
And, which is more important, it still does not solve the initial problem.
For example if filesystem is supposed to be network-mounted, and network is
brought by the user, which logs into GNOME session and manually selects wifi
connection in nm-applet, initramfs still does not help there, since you
can't put entire gnome session into initramfs anyway.
Either historical or new radical approach is chosen — they both are limited.
None of them can support all possible cases of network mounting.
But at least one of these approaches should be supported.
Having none of them working is kind of pointless. :)
I suggest:
1. Define (implicitly or explicitly) where we would allow to mount subroot
filesystems from (that decision mainly affects /usr and partially /var,
/home and others) and what tools are needed to do that.
2. Make sure that all the tools from #1 are on / partition.
3. Make sure that everything required for `root` user to login (and do basic
stuff, i.e. move files, read logs and edit scripts) is on / partition.
4. Don't move anything else around — unless it fixes something,
it will just add more bugs and more problems for users.
These steps are rather easy, and make sure that at least historical
approach is fully supported.
--
Serge
Reply to: