From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1R1i0D-0005cD-HS for garchives@archives.gentoo.org; Thu, 08 Sep 2011 17:03:01 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 261FC21C140; Thu, 8 Sep 2011 17:02:51 +0000 (UTC) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by pigeon.gentoo.org (Postfix) with SMTP id 5DBD821C064 for ; Thu, 8 Sep 2011 17:01:38 +0000 (UTC) Received: (qmail invoked by alias); 08 Sep 2011 17:01:37 -0000 Received: from p5B082D1C.dip.t-dialin.net (EHLO pc.localnet) [91.8.45.28] by mail.gmx.net (mp066) with SMTP; 08 Sep 2011 19:01:37 +0200 X-Authenticated: #13997268 X-Provags-ID: V01U2FsdGVkX1/HDHsLRFLHRMxPYHxDiJwMg7YRpwkcR/3S6znZ/y b/wlHApgjxgFZE From: Michael Schreckenbauer To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] /dev/sda* missing at boot Date: Thu, 08 Sep 2011 19:01:34 +0200 Message-ID: <2110889.rUh24Q481G@pc> User-Agent: KMail/4.7.0 (Linux/2.6.38-gentoo; KDE/4.7.0; x86_64; ; ) In-Reply-To: References: <201108191109.34984.michaelkintzios@gmail.com> <2799076.QhjHdal4hI@pc> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" X-Y-GMX-Trusted: 0 X-Archives-Salt: X-Archives-Hash: 63e85f87bc2291f6567987bb7af35e5b Am Donnerstag, 8. September 2011, 12:34:50 schrieb Canek Pel=E1ez Vald=E9= s: > On Thu, Sep 8, 2011 at 12:06 PM, Michael Schreckenbauer =20 wrote: > > Am Donnerstag, 8. September 2011, 11:13:58 schrieb Canek Pel=E1ez V= ald=E9s: > >> On Thu, Sep 8, 2011 at 4:09 AM, Michael Schreckenbauer > >> > >=20 > > wrote: > >> > Am Mittwoch, 7. September 2011, 23:33:35 schrieb Canek Pel=E1ez = Vald=E9s: > >> >> 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 you= r > >> >> /boot partition, then don't upgrade to new kernels. > >> >=20 > >> > 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. > >>=20 > >> 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 yo= u > >> guys reasons. > >>=20 > >> 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. > >=20 > > That's the point. You *need* an initramfs. You know KISS? >=20 > 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.=20 Mission accomplished. It's the upcoming change, that violates KISS. If udev cannot work prope= rly=20 with separate /usr, fix udev not the FS-hierarchy. What next? Put /home= into=20 initramfs, because udev decides it cannot work without /home mounted? > >> > 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 > >>=20 > >> No, I haven't thought about them, because I don't use them. What i= t > >> has to do with anything? > >=20 > > Well, I linked a mail. MIPS is mentioned. As I read it, there are c= ases > > with MIPS, where the initramfs *has* to be built into the kernel *a= nd* > > the kernel- image is size restricted. That's the problem with an > > initramfs bigger than the kernel itself. >=20 > That's a MIPS restriction. Then with MIPS you will need to put /usr i= n > /, and problem solved. Solved? You call "no separate /usr on MIPS" a solution? How about existing installations? Ah, yes, don't upgrade. > But no, everyone wants everything, and exactly > the way they want. It works now. > 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. >=20 > >> >> Change happens. > >> >=20 > >> > That's right. And sometimes these changes are simply bad ideas. > >>=20 > >> If so you think, then write the code to support the *really good* > >> ideas. > >=20 > > Ah. Criticism is only allowed, if you are writing the code. Not in = my > > world, sorry. >=20 > 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. > 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". I'd say, we discuss things, as do= the=20 gentoo-devs on their list. > 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 i= t > 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=20 and valid options. > But such is life: i didn't write the code. If I wanted to keep up wit= h > 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 199= 6 > (damn, I'm old), and sometimes it bite you in the ass in the long run= > (hello HAL!) >=20 > 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? > Of course, sometimes it doesn't (hello devfs!), but what are you goin= g > to do? Look a gift horse in the mouth? >=20 > 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. > Regards. Regards, Michael