Re: [gentoo-user] /dev/sda* missing at boot

[Michael Mol <mikemol@gmail.com>]

On Thu, Sep 8, 2011 at 4:03 PM, Canek Peláez Valdés <caneko@gmail.com> wrote:
> On Thu, Sep 8, 2011 at 3:37 PM, Michael Mol <mikemol@gmail.com> wrote:
>> On Thu, Sep 8, 2011 at 3:00 PM, Canek Peláez Valdés <caneko@gmail.com> wrote:
>>> Sorry you read that way; I keep trying to explain why I don't find a
>>> separated /usr a necessity and why I don't think an initramfs is such
>>> a big problem.
>>
>> The rhythmic baseline of your explanation is "and you can use an
>> initramfs for that." I haven't seen much in argument for why initramfs
>> isn't a problem apart from your expectation that the *kernel* will
>> eventually require it, and dracut theoretically solve the problem of
>> updating initrd. (Which sounds nice, but it's yet another moving part
>> in the system, and another point of failure.)
>
> No, I think you haven't been reading carefully enough. Again:
>
> 1. In 2011, we need a dynamic /dev tree. I'm not going to argue why.

I'll go ahead and conflate "dynamic /dev tree" with things like
alternate names for network interfaces, and then I can agree with you
there. (I don't put up with this ethN, sitN, tunN BS. Give me an
interface name that says what it's for. I need udev for that, though.)

> 2. udev, successor of devfs, which was successor of the classical /dev
> tree, after years of design and development iterations, solves the
> problem. It's not perfect, but I think that is as close as it could
> be, for the problem it tries to solve, and with the feature set it
> has.

I'll give a pass on this one; I don't know enough about how it
operates to be very informed.

> 3. udev needs either an initramfs, because it needs an early user
> space, or a /usr inside /.

First, it sounds like we're conflating /usr with "user space". User
space is any executing space in the system, but outside the kernel.
/usr is just one of several traditional mountpoints in UNIX-like
systems.

Second, why can't we say, "anything that needs to be operated by udev
needs its binaries in /bin or /sbin"? As I said, I thought that was
the whole *point* of having those distinct from paths under /usr;
anything you needed in order to perform online system recovery would
be in one of those two folders. Anything needed to perform online
system recovery ought to be nearly sufficient to bootstrap the system.
(The only mountpoint exception I can think of is /etc)

Yes, this may mean modifying many more packages, but that's what
having a clean system architecture is about. Unless I'm
misunderstanding sysadmin history, that would seem to be the Correct
solution, and would be the strongest broad solution.

> From this 3 points, I make my conclusion: keep up with the changes, or
> code an alternative (that includes using something like mdev).
>> I thought the primary reason we had
>> /{,s}bin and /usr/{,s}bin was to differentiate between system-vital
>> programs and other programs.
>
> That enters perflectly in my other solution: code an alternative. That
> includes changing (or trying to) udev.

"Changing udev" wasn't on the table earlier.

>
>>> That people don't like the answer doesn't mean is not true.
>>
>> There's also no solid evidence that it's true, either.
>
> Prove me wrong, or find the code that proves me wrong. If it's that
> important to you, do it. My whole point is that it's easier (and in
> the long term more beneficial) to roll with the changes.

What's important to me is clarity of the situation and understanding
the Whys and trying to understand the logic (and illogical aspects) of
the scenario. I'm just trying to be clear on everything here. As I
said, I can deal, it's just a pain. As has been mentioned, there are
other architectures which will have a harder time of it. That's their
problem.

Still, if the Kernel is deciding that udev is the be-all hotplug
manager, though, and udev is hanging edge architectures like MIPS out
to dry, then we'll be lucky if a common, familiar and compatible
environment will continue to be available on MIPS. Maybe they'll fall
back to a static /dev. Maybe they'll come up with something good to
replace udev. Or maybe manufacturers using MIPS will use something
other than Linux, such as QNX, and MIPS will be a much less hackable
platform than it once was.

>> I remember when
>> sysfs came about. Linux Journal's diff -u column described it as a
>> herculean effort accomplishing something the majority of kernel devs
>> thought impossible or not worth the time. I rather like sysfs, but at
>> one time, it was the thing very few people thought was in the possible
>> set of solutions.
>
> I don't see the connection. If someone actually goes and writes the
> code for an alternative to udev (or /usr inside /, or an initramfs),
> then it enters my second alternative.

See my note above about modifying udev not being clearly on the table
earlier. In an environment where a single dev is responsible for
something, foreign patches aren't often welcome.

>> People are beginning to consider alternatives, but you've shot them
>> down without offering improvements, suggesting adjustments or even
>> pointing out specific flaws. As a result, you come across as something
>> akin to a fanboy with your mind already made up, which just seems
>> *bizarre*.
>
> I don't really care if people mind me a fanboi: I know I'm not. I'm
> old enoguh to be a fanold, though.

Heh. Fair enough.

>
> Seriously, maybe I'm not communicating my point clearly. The only
> alternative mentioned (I think: please correct me if I'm wrong) is
> mdev... which I didn't shoot down, I just mentioned that I don't think
> will solve the problem. And if you have followed the development of
> Linux as I have, then you know it is a *really* hard problem, and that
> udev is the result of many man-hours of thinking, designing and
> implementing. That's why I don't give to much hope to a project I have
> never heard about.

I'd be _very_ careful about that mentality. If you've been following
Linux as long as I have (and I honestly think you've been following it
longer; I only started in 1998), you'll remember that Linux was once
an upstart nobody'd heard of. I'm not trying to draw a direct analogy
between Linux and mdev, I'm just trying to illustrate that it's
problematic to ignore small projects because it's assume the big ones
have already thought something through. I've personally tended to find
that big projects and organizations tend to evolve a set of
assumptions (we'll call it groupthink) and don't challenge it often
enough.

> That doesn't mean I'm not mistaken, of course.

Sure. And I'm not trying to say you're necessarily *wrong*, I'm just
trying to break down and poke the assumptions and arguments I'm
hearing.

>>> Sometimes the devs do stupid things; but most of the times they really
>>> think and come to a solution. And the affected users usually just see
>>> how that solution affects them in the short term, instead of trying to
>>> see the big picture and how affects the whole distribution, the
>>> community, and the technological path that Linux is following.
>>
>> For being irritated that people aren't seeing it, you haven't been
>> clarifying it much.
>
> When did I say I was being irritated? I'm only trying to express my POV.

Hm. I may have read too much emotion into the text. My bad.

>> That much is appreciated, but you didn't say *why* you doubt that'll
>> be the solution. Downvotes aren't debate, nor are they discussion.
>> They're expressions of dissatisfaction.
>
> Why should I be dissatisfied? The development of Linux goes exactly in
> the direction *I* want, I don't complain about any of the required
> changes discussed.
>
> Why I doubt it I answered some paragraphs above.

Understood, points taken, some addressed.

>
>>>> As for me, this will be a royal inconvenience, and may require the
>>>> rebuilding of my primary machine. Still, I can deal. It'll mean
>>>> learning how to build initramfs*, how to make sure it contains the
>>>> needed tools, and probably a half-dozen other things I didn't even see
>>>> coming when I set up this box last fall.
>>>
>>> I compile my own kernels (no genkernel for me). I don't use modules
>>> (except for the stupid scsi_wait_scan), and I didn't used an initramfs
>>> until I started using systemd. The arguments for using it convinced
>>> me, and I made the switch in all my machines.
>>>
>>> I don't see why it would require to "rebuild" your primary machine,
>>> but I don't know your configuration. I know that any sane
>>> configuration would only require to install dracut and modify a line
>>> in grub. Maybe a kernel rebuild.
>>
>> My / isn't large enough to hold /usr.
>
> I don't understand. You said you were to try building an initramfs,
> and if that's the case, then you can keep /usr separated.
>
> If you will put /usr in / (and hence rebuild your system), then why
> you said you would learn how to built an initramfs?

I fully expected building an initramfs with a bunch of userland
binaries to be a PITA. If drago is as simple as you describe it, then
perhaps not. At the original point when I indicated I'd need to
rebuild my machine, that was under the assumption I wouldn't be able
to figure out the initramfs.

>>> Apparently. But is not "grossly" unnecessary: udev need it, and udev
>>> solves a kinda complicated problem. Maybe mdev can solve it in a
>>> simpler way.
>>>
>>> But again, I doubt it.
>>
>> One question: Why? Are there specific technical reasons to your
>> doubts, or is it simply confidence that the devs are more likely to
>> have made a good choice than a bad choice?
>
> I answered that already (actually, in that paragraph). But again: udev
> is not trivial, and it solves a (far from) trivial problem. If some
> developers think they can outsmart the kernel devs, please, lets try
> it. Maybe they will.

I was largely looking for an elucidation, which you provided farther up.


Anyway, the discussion has been interesting and, in places,
enlightening. I need to stop getting sucked back into it. :)
-- 
:wq