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

[Canek Peláez Valdés]

On Thu, Sep 8, 2011 at 3:59 AM, Neil Bothwick <neil@××××××××××.uk> wrote:
> On Wed, 7 Sep 2011 23:30:16 -0400, Canek Peláez Valdés wrote:
>
>> > Because you can't boot from an LV, so you'd than need a separate /boot
>> > and an initramfs. Without LVM, you are unlikely to be able to resize /
>> > or /usr as it is not usually the last partition on the drive.
>>
>> So, you guys want a separated /usr, but don't want a separate /boot.
>> Awesome.
>
> I want as much as possible on LVM, and no initramfs. A small / and
> everything else on LVM fulfils that need.

If you really want it, go ahead and code the support for it. The code
for every single piece on the stack is available, and you have the
right to modify it if you don't like upstream decisions.

Upstream(s) don't need or have to care about what I (or you, or
anybody) wants. They (for reasons that we may or may not agree) will
decide what set of configurations will be supported. Don't like the
decision? Use the source, Luke.

>> >> Again, I don't see the reason for a separated /usr.
>> >
>> > That doesn't mean there aren't several valid reasons to do so.
>>
>> I didn't say they were invalid, I say that *I* don't see the reason to
>> separate /usr. The arguments exposed just don't convice me. But
>> anyway, you will be able to do it with an initramfs.
>
> No one is saying YOU should change your preferred setup. Please do us the
> same courtesy.

I do: I don't want you to change your setup. Absolutely nobody is
saying that. I'm truly sorry if thats the way I sounded (my first
language is not English).

However, if you don't want to change your setup, you will have two
options: either you don't upgrade (which is feasible, if you limit
yourself to security upgrades), or you write the code necessary for
your particular configuration. We (neither you nor I) can force the
developers (being udev, kernel, Gentoo or whatever) to write the code
supporting configuration X or Y, no matter how "rational" it seems to
you (or me).

When upstream wants to changes stuff, I change my setup and relearn
how to do it with the new technology/options. It happens all the time:
we moved from devfs to udev, from OSS to ALSA (and then PulseAudio),
from ipchains to iptables... I could go on and on.

> want, what we need and how best to achieve it. How would you feel if you
> were told that you had to separate /usr, install extra packages, go
> through extra configuration steps and introduce more points of failure,
> just to do what you are already doing?

I will do it. I have done it. And the reason is that the kernel churns
out a new version every 2 or 3 months, GNOME gets a new version every
six months, and everything gets (usually) better so fast thatt you
want to keep ip. And the only way to keep up with development, is
sometimes you need to change your setup.

Of course there are different setups. My laptop I keep it updated
every week. Sometimes shit gets wrong: I fix it, no problem. A
production server only gets security updates, and I keep a twin setup
ready if something goes wrong updating. If an update is intrusive
(say, I need to change /usr to the same partition as /), then I do it
first on the twin, and when it's ready I change them and do the same
in the primary.

And life goes on.

>> Then don't update.
>
> I can't decide whether this comment is arrogant or ingenuous.

It's called "being in production". You don't upgrade your kernel in
production, unless there is a security flaw that affects you. If there
is a security flaw in NFS, and you don't use NFS, you don't upgrade.
You don't upgrade Apache unless there is a security flaw. You don't
upgrade *anything* if it's working.

Want the new features? Guess what? You need to use the supported
setups, or write the code for your particular setup.

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