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

["Canek Peláez Valdés" <caneko@gmail.com>]

On Thu, Sep 8, 2011 at 1:01 PM, Michael Schreckenbauer <grimlog@gmx.de> wrote:
> Am Donnerstag, 8. September 2011, 12:34:50 schrieb Canek Peláez Valdés:
>> On Thu, Sep 8, 2011 at 12:06 PM, Michael Schreckenbauer <grimlog@gmx.de>
> wrote:
>> > Am Donnerstag, 8. September 2011, 11:13:58 schrieb Canek Peláez Valdés:
>> >> On Thu, Sep 8, 2011 at 4:09 AM, Michael Schreckenbauer
>> >> <grimlog@gmx.de>
>> >
>> > wrote:
>> >> > Am Mittwoch, 7. September 2011, 23:33:35 schrieb Canek Peláez Valdés:
>> >> >> I don't see any problem with an initramfs larger than the
>> >> >> kernel. It
>> >> >> will handle a lot of stuff. But if you don't want to change your
>> >> >> /boot partition, then don't upgrade to new kernels.
>> >> >
>> >> > How about accepting the fact, that there are a lot of things out
>> >> > there
>> >> > "you don't see"? Get over it. People have told a lot of valid
>> >> > reasons.
>> >> > They might not seem valid to you, but that's not their problem.
>> >>
>> >> Relax man, I keep saying that is *I* who don't see a valid reason.
>> >> That doesn't mean there is no valid reason; I thought that went
>> >> without saying. Sorry if it sounded like I was invalidating all you
>> >> guys reasons.
>> >>
>> >> My primary point was that, I *you* have your reasons to keep a
>> >> separated /usr, then by all means do it. You will only need an
>> >> initramfs.
>> >
>> > That's the point. You *need* an initramfs. You know KISS?
>>
>> If it's so "simple", write the code for support the option of not
>> having an initramfs. If it's not that simple, then what KISS are we
>> talking about?
>
> We already *have* the situation of not requiring initramfs for separate /usr.
> Mission accomplished.
> It's the upcoming change, that violates KISS. If udev cannot work properly
> with separate /usr, fix udev not the FS-hierarchy. What next? Put /home into
> initramfs, because udev decides it cannot work without /home mounted?

Then don't upgrade. Keep doing only security updates.

Want the new cool stuff? Roll with the change.

>> >> > Have you *ever* thought about machines, that are not x86 or
>> >> > x86_64?
>> >> > Here's an intersting read:
>> >> > http://permalink.gmane.org/gmane.linux.gentoo.devel/72769
>> >>
>> >> No, I haven't thought about them, because I don't use them. What it
>> >> has to do with anything?
>> >
>> > Well, I linked a mail. MIPS is mentioned. As I read it, there are cases
>> > with MIPS, where the initramfs *has* to be built into the kernel *and*
>> > the kernel- image is size restricted. That's the problem with an
>> > initramfs bigger than the kernel itself.
>>
>> That's a MIPS restriction. Then with MIPS you will need to put /usr in
>> /, and problem solved.
>
> Solved? You call "no separate /usr on MIPS" a solution?
> How about existing installations? Ah, yes, don't upgrade.

There you go.

>> But no, everyone wants everything, and exactly
>> the way they want.
>
> It works now.

Exactly, and if you don't upgrade, it will work as long as you want.

>> Well, then they will need to write the code to support it, because no
>> developer is forced to support every single architecture in the whole
>> damn world, in every possible configuration available.
>>
>> >> >> Change happens.
>> >> >
>> >> > That's right. And sometimes these changes are simply bad ideas.
>> >>
>> >> If so you think, then write the code to support the *really good*
>> >> ideas.
>> >
>> > Ah. Criticism is only allowed, if you are writing the code. Not in my
>> > world, sorry.
>>
>> By all means, criticize as much as you want. What I meant by "If so
>> you think, then write the code to support the *really good* ideas" is
>> that you have the *option* to do that. You can of course complain
>> forever: that will not mean that anybody (and in particular the
>> developers) will listen.
>
> Not listening to users is a very bad idea.

No, they listen to users. They just don't listen too every user,
because that's impossible. Maybe I'm wrong, but I think your setup is
in the minority of use-cases. Who they should listen to?

>> Of course not. But, as with anything Open Source related, the ones
>> that write the support code will prevail. The complainers (if they
>> only complain) will not change anything.
>
> You keep talking about "complainers".

If someone complains and doesn't code, it's a complainer. By
definition. If someone complains and code, it's creating alternative
technologies.

> I'd say, we discuss things, as do the
> gentoo-devs on their list.

I agree. I'm subscribed to both.

>> My point is: if everything would be the other way around, and the
>> Gentoo (or kernel, or udev) developers decided that the True One Way
>> (TM) to do things were to separate / and /usr, I would do it. I did it
>> when me moved from ipchains to iptables, and that was particularly
>> painful because every single damn script just stopped working.
>
> Ah yes. What option was lost, when this switch happend?
> Nobody (I think) complains about some config changes. It's the removal of sane
> and valid options.

You cannot keep *EVERY* option supported. It's impossible. They grow a
lot really fast. You have to mark some things as "not supported".
Don't like it? Try alternative technologies.

>> But such is life: i didn't write the code. If I wanted to keep up with
>> development, I needed to change my way of doing things. I have rolled
>> with the change every single time since I started to use Linux in 1996
>> (damn, I'm old), and sometimes it bite you in the ass in the long run
>> (hello HAL!)
>>
>> But most of the times is for a good reason, and everything kinda
>> improves. And since I'm not writing code, just taking advantage of
>> getting it for free (as in beer and as in speech), I usually trust
>> developers. It usually pays off.
>
> How's needing an initramsfs for separate /usr an improvement?

With the initramfs you can do a lot of really cool stuff. I know it's
shallow, but I really like my plymouth-based splash screen.

>> Of course, sometimes it doesn't (hello devfs!), but what are you going
>> to do? Look a gift horse in the mouth?
>>
>> In the long term, trusting the developers usually it's the way to go.
>> Been here a long time, I stick to my guns. Don't like it? Well,
>> complain if you want, but if you don't writing some code it would
>> probably be for nothing.
>
> Yeah, "probably", that's why we discuss things.

Again, we can discuss (or complain) until the sun is red. As long as
we don't give code back, it's basically academic.

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México