Re: [gentoo-user] Re: separate / and /usr to require initramfs 2013-11-01

[Walter Dnes]

On Sun, Sep 29, 2013 at 12:36:43AM +0200, Alan McKinnon wrote

> The actual problem is better stated something like this:
>
> In the early stages of user-land setup (around the time when udev is
> getting it's act together), arbitrary code can run and that code can be
> in any arbitrary place, but there is no guarantee that that code is even
> accessible at the point when it is needed. The actual cause of this mess
> is the lack of standards on where to put stuff on Linux systems, and it
> forms a classic bootstrap problem.
>
> There has only ever been one way around that problem - define an exact
> entry point that is guaranteed to be in a specific state. For current
> userland this effectively means that everything that has traditionally
> been in bin, sbin and lib in / and /usr must be available as step 1.
> Technically, you could include /var/lib/ and maybe even /opt in there.
> but we can safely exclude those at this time as only a brain-dead moron
> would ever put init-critical code there.

  Separate /usr worked for many years, even with udev.  The question I
have is why is udev *NOW* monkeying around with a whole bunch of
additional stuff before mounting partitions?  If you have an NFS-mounted
/usr, I can see needing to have network services running first.  Ditto
for /usr being in an LVM or encrypted partition, you need LVM and/or
decryption running first.  There is no excuse for anything else breaking
a separate /usr.

  Then again, separate /usr isn't the first thing Kay Sievers has broken
since he took over udev, and I wouldn't be surprised if he one day "just
happens to break openrc"...

https://lkml.org/lkml/2012/10/2/303

> From	Linus Torvalds <>
> Date	Tue, 2 Oct 2012 09:33:03 -0700
> Subject Re: udev breakages - was: Re: Need of an ".async_probe()"
> type of callback at driver's core - Was: Re: [PATCH] [media] drxk:
> change it to use request_firmware_nowait()
	

> On Tue, Oct 2, 2012 at 6:03 AM, Mauro Carvalho Chehab
> <mchehab@××××××.com> wrote:
>
> > I basically tried a few different approaches, including deferred
> > probe(), as you suggested, and request_firmware_async(), as Kay
> > suggested.
>
> Stop this crazy. FIX UDEV ALREADY, DAMMIT.
>
> Who maintains udev these days? Is it Lennart/Kai, as part of systemd?
>
> Lennart/Kai, fix the udev regression already. Lennart was the one
> who brought up kernel ABI regressions at some conference, and if
> you now you have the *gall* to break udev in an incompatible manner
> that requires basically impossible kernel changes for the kernel to
> "fix" the udev interface, I don't know what to say.
>
> "Two-faced lying weasel" would be the most polite thing I could say.
> But it almost certainly will involve a lot of cursing.
>
> > However, for 3.7 or 3.8, I think that the better is to revert
> > changeset 177bc7dade38b5 and to stop with udev's insanity of
> > requiring asynchronous firmware load during device driver
> > initialization. If udev's developers are not willing to do that,
> > we'll likely need to  add something at the drivers core to trick
> > udev for it to think that the modules got probed before the probe
> > actually happens.
>
> The fact is, udev made new - and insane - rules that are simply
> *invalid*. Modern udev is broken, and needs to be fixed.
>
> I don't know where the problem started in udev, but the report I
> saw was that udev175 was fine, and udev182 was broken, and would
> deadlock if module_init() did a request_firmware(). That kind of
> nested behavior is absolutely *required* to work, in order to not
> cause idiotic problems for the kernel for no good reason.
>
> What kind of insane udev maintainership do we have? And can we fix it?

-- 
Walter Dnes <waltdnes@××××××××.org>
I don't run "desktop environments"; I run useful applications