On 2012-12-24, Dale wrote: > Nuno J. Silva wrote: >> On 2012-12-24, Dale wrote: >> >>> Alan McKinnon wrote: >>>> On Sun, 23 Dec 2012 19:03:25 +0200 >>>> nunojsi...@ist.utl.pt (Nuno J. Silva) wrote: >>>> >>>>> On 2012-12-23, Alan McKinnon wrote: >>>>> >>>>>> On Sun, 23 Dec 2012 12:22:24 +0200 >>>>>> nunojsi...@ist.utl.pt (Nuno J. Silva) wrote: >> [...] >>>>>>> What about just mounting /usr as soon as the system boots? >>>>>> Please read the thread next time. The topic under discussion is >>>>>> solutions to the problem of not being able to do exactly that. >>>>> Then I suppose you can surely explain in a nutshell why can't init >>>>> scripts simply do that? >>>>> >>>> It is trivially easy to create a circular loop whereby code required to >>>> mount /usr now resides on /usr. >>>> >>>> Which is the entire thrust of this whole thread. >>>> >>> When I reboot, I get a lot of errors about /var being empty, since it is >>> not mounted yet. It appears it wants /var as well as /usr early on in >>> the boot process. It boots regardless of the errors tho. >>> >>> For the record Nuno, I have / and /boot on regular partitions. I have >>> everything else, /home, /usr, /var and /usr/portage on LVM partitions. >>> Until recently, I NEVER needed a init thingy and had zero errors while >>> booting. Once this 'needing /usr on /' started a few months ago, I was >>> told I would need one to boot. The claim being it was broken all the >>> time but odd that it worked for the last 9 years with no problem, might >>> add, I only been using Linux for the last 9 years but it also would have >>> worked before that. >>> >> In your case, does it actually fail without an initrd now? It's just >> that I see lots of people saying "it doesn't work" or "it will silently >> fail", that's why I asked the question, I was looking for actual >> examples of how can this go wrong (other than just because the init >> scripts don't try to mount /usr before starting udev). >> >> Also, how does an initrd help solving the chicken-and-the-egg problem >> for a missing /usr? >> >> I suppose the LVM drivers create additional device files that are only >> created once udevd is up and running in order to process these events? >> (With the case of a regular partition being no problem just because >> linux apparently offers hardcoded files for some partitions in the first >> ATA controllers.) >> > > Well, so far I have stuck with the udev that works without a init > thingy. I do have a init thingy for when the udev that requires it is > marked stable. The devs are keeping the udev that requires /usr on / > masked and/or keyworded until everyone is ready. That was until eudev > was announced. Now they are also waiting on eudev to get stable so > people can switch to it. I plan to switch too. > > The problem is this from my understanding. For decades, any commands or > config files needed to boot Linux had to be in /bin, /sbin, /etc, and/or > /lib. Those directories were what was needed to boot and anything > needed to boot a system should be installed into one or more of those > directories. Then someone came up with the idea of putting things into > /usr instead. When they did that, it broke things. To me, this change > makes as much sense as putting the mount command is /usr/bin but that is > where some want Linux to go. I have read where some want to basically > move about everything to /usr but not sure how much traction that is > getting.
>From my understanding, the problem with udev was that the rules used to process events may require stuff from /usr. Which is OK, as I think the rules may even end up executing random executables. And the sole problem with this is that udev will not wait, it will simply fail in a silent way when applying rules that require stuff from /usr. Now, also, from my understanding, this was already the case for some time (maybe even years?). And that's why I've asked for more details. So, if the udev you use is OK with no initrd, what is in the new udev that actually requires the initrd? Meanwhile, I found https://bugs.gentoo.org/show_bug.cgi?id=446372, which would explain why, all of a sudden, there is a bigger problem. Now, I wonder how is this solved with an initrd, by copying udevd there? If so, why don't we simply install udevd under (or copy its stuff to) / instead of using /usr as $PREFIX? > Basically, something that has worked for decades is declared to be > broken all that time and if it wasn't broken, we are going to break it. ... yeah... the thing here is that I'm just trying to separate the upstream comments on "separate /usr is broken" from the actual thing that breaks the boot process. So far, even the stuff from freedesktop I've read stating that "separate /usr is broken" do not seem to mention that udevd is moving to /usr. > From my understanding, if I upgrade my system to the later version of > udev and bypass the init system, my system will not boot. I have not > tested the theory but that is what people have been saying. Not only is > my /usr separate but it is on LVM partitons too. Your problem would be LVM (if that's an issue at all, as I said I don't know LVM), you'd not need udevd to mount /usr if it were a regular partition. -- Nuno Silva (aka njsg) http://njsg.sdf-eu.org/
