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 1RF0Mk-0007Ke-UC for garchives@archives.gentoo.org; Sat, 15 Oct 2011 09:17:15 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id A33A721C111; Sat, 15 Oct 2011 09:17:01 +0000 (UTC) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by pigeon.gentoo.org (Postfix) with SMTP id DC1C321C13D for ; Sat, 15 Oct 2011 09:15:33 +0000 (UTC) Received: (qmail invoked by alias); 15 Oct 2011 09:15:32 -0000 Received: from p5B085C58.dip.t-dialin.net (EHLO pc.localnet) [91.8.92.88] by mail.gmx.net (mp070) with SMTP; 15 Oct 2011 11:15:32 +0200 X-Authenticated: #13997268 X-Provags-ID: V01U2FsdGVkX1/3KwU6o1f3ezbHfzJEOKseofpm9eZq1I/oXafjT7 T8fflSsHpwWkJS From: Michael Schreckenbauer To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] Apologize to everyone for my nonprofessional Date: Sat, 15 Oct 2011 11:15:32 +0200 Message-ID: <2412220.Ql7LvlMYvj@pc> User-Agent: KMail/4.7.2 (Linux/2.6.38-gentoo; KDE/4.7.2; x86_64; ; ) In-Reply-To: References: <4E994657.2030200@gmail.com> 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: 2e82737fffa8028c5852e9b427d01125 Hi Canek, On Saturday, 15. October 2011 02:02:13 Canek Pel=E1ez Vald=E9s wrote: > On Sat, Oct 15, 2011 at 1:37 AM, Dale wrote: > > Canek Pel=E1ez Vald=E9s wrote: > >> On Fri, Oct 14, 2011 at 11:56 PM, Dale wrot= e: > >>> Pandu Poluan wrote: > >>>=20 > >>> On Oct 15, 2011 5:49 AM, "Dale" wrote: > >>>> Neil Bothwick wrote: > >>>>> On Fri, 14 Oct 2011 11:15:24 -0500, Dale wrote: > >>>>>> A'right now. I'm going to start on hal and /usr being on / > >>>>>> again. > >>>>>> :-P > >>>>>=20 > >>>>> Jeez, 43 years on and you're still going on about it... > >>>>=20 > >>>> Dang, I was only a year old when hal came out? That just double= d > >>>> my > >>>> age. > >>>> It's closer to what I feel like tho. > >>>>=20 > >>>> I'm still not happy with /usr being required tho. That is still= > >>>> standing > >>>> on a bad nerve. Don't worry tho, I got plenty of those bad > >>>> nerves. :-P>>>=20 > >>> Do you know that there's a plan to move /var/run to / also? ;-) > >>>=20 > >>> Rgds, > >>>=20 > >>>=20 > >>> Now someone on here swears up and down that /var isn't going to b= e > >>> required > >>> on /. > >>=20 > >> /var !=3D /var/run > >> /var !=3D /var/lock > >>=20 > >> /var/run is going in /run, but /var/run (by definition) only conta= ins > >> things like PID files and runtime sockets. In the same vein, /var/= lock > >> also is going into /run/lock. I have acknowledged this from the ve= ry > >> beginning, and I have been pointing out that implying that because= > >> those two (really small and bounded) directories of /var are going= > >> into /run and /run/lock, it doesn't mean that the whole /var will = go > >> into /. That is disinformation. > >>=20 > >> Nobody has even proposed that /var should go into the same partiti= on > >> as /. *Nobody*, and the simplest proof of that is that nobody has > >> produced a single proof to the contrary. Not a single email, blog > >> post, or wiki entry from any system developer even mentions the > >> possibility of requiring /var to be in the same partition as /. > >>=20 > >> Whoever says that /var will be required to be on the same partitio= n as > >> / is either wildly speculating, or spreading FUD. > >=20 > > So /var/run and /var/lock isn't on /var? Even if they will be link= ing > > to > > another location, the link has to be there for whatever program to > > follow. If /var isn't mounted yet, there is nothing for the program= to > > find. > The link goes the other way around. /run and /lock are the real > directories, /var/run is a link to /run, /var/lock is a link to > /run/lock. When the initramfs (or the init system) mount /var, they > make the link. >=20 > > When I saw the messages about LVM and /var, that caused LVM to fail= to > > start. I wouldn't put / on LVM and wouldn't expect it to work with= out a > > init thingy either. Thing is, based on it failing, you can't have = /var > > on a separate partition and expect LVM to start. So, if you use LV= M > > for /usr and/or /var, you have to have a init thingy even if / is o= n a > > regular file system. >=20 > Yes, as I said in my last mail, if you need LVM, you need an > initramfs. Remove the LVM, and you can have /var (and /usr for that > matter) withouth an initramfs. Where/when did I say something > different? >=20 > >>> I'm telling ya'll, /home is coming. > >>=20 > >> That is just ridiculous. > >=20 > > I would have said the same thing about /usr a year ago. I'm not sa= ying > > it is coming next week but . . . >=20 > You can speculate all you want. Fact is, nobody has proposed that, an= d > there is not even a single email suggesting that it will be necessary= . > On the contrary, the requirement for an initramfs or a /usr inside th= e > same partition as / has been being discussed years ago; if you had > followed the developers lists, you wil had hear about it months befor= e > it happened. >=20 > Nothing similar has happened with /var, least of it /home. >=20 > >>> We are going to end up where we > >>> can only have one drive in our Linux boxes for the OS and its > >>> relatives.>>=20 > >> And so is this: more FUD. > >>=20 > >>> That or we will ALL have to start using the pesky init* thingy. > >>=20 > >> More FUD: the current proposal (from Zac, the principal coder of > >> portage, and someone who actually wrotes code and know what he is > >> talking about) is this: > >>=20 > >>=20 > >> http://archives.gentoo.org/gentoo-dev/msg_20749880f5bc5feda1414884= 9872 > >> 9fe8.xml > >>=20 > >> It basically removes the need for a "pesky init* thingy", although= for > >> the life of me I cannot understand why someone will not see the > >> technical advantages of actually using an initramfs. > >=20 > > I'll have to read his link later. >=20 > Please do. >=20 > >>> I got 7 acres of land here, complete with trees. If someone can > >>> find the dev that started this mess, I can find some rope. Just > >>> saying. ;-) Oh, I > >>> live half a mile from the river too. Makes for a good dump site.= > >>> lol > >>>=20 > >>> I noticed the other day that when LVM tries to start, it fails. = I > >>> have > >>> /var > >>> on a separate partition here. It was complaining about something= on > >>> /var missing. So, you may be late in reporting this. I think it= > >>> is already needed for LVM if /usr or /var is on a separate > >>> partition. > >>=20 > >> Again, get the facts right. If you use LVM you will need to use an= > >> initramfs. If you only use a separated /usr you will be able to us= e > >> Zac's proposal. > >>=20 > >> In no case whatsoever you will be required to have /var on the sam= e > >> partition as /. Nobody has ever proposed that. /run and /run/lock = are > >> not /var. > >>=20 > >> Regards. > >=20 > > No one proposed that /usr was required until just recently. >=20 > http://article.gmane.org/gmane.comp.sysutils.systemd.devel/1337 >=20 > That was on February 25, this year. *Eight* months ago. And the stabl= e > udev in Gentoo still "supports" (it really doesn't, but whatever) a > separated /usr. >=20 > > Saying it won't > > happen really puts you in a bad spot when or if it does. If you kn= ow > > this for sure and certain, I want your crystal ball. >=20 > It's called an "educated guess". Of course I could be wrong; but I am= > more than willing to bet a nice expensive dinner with anyone that it > is not going to happen in the next ten years. Any takers? I would. But given the way udev people "solve" those issues, I don't. If something on /var is needed during boot in the next ten years, they = will=20 propose to move it to /. They do it with /run, they do it with /lock, t= hey=20 will do it the same way the next time such an issue arises. > Regards. Best, Michael