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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAOVenEpAOYEKRgJ=xpch59q4bqnsf+9jwx9vsoms6-zw5fy...@mail.gmail.com