On Sat, Oct 15, 2011 at 2:32 AM, Michael Schreckenbauer <grim...@gmx.de> wrote: > On Saturday, 15. October 2011 02:21:18 Canek Peláez Valdés wrote: >> On Sat, Oct 15, 2011 at 2:15 AM, Michael Schreckenbauer <grim...@gmx.de> > wrote: >> > Hi Canek, >> > >> > On Saturday, 15. October 2011 02:02:13 Canek Peláez Valdés wrote: >> >> On Sat, Oct 15, 2011 at 1:37 AM, Dale <rdalek1...@gmail.com> wrote: >> >> > Canek Peláez Valdés wrote: >> >> >> On Fri, Oct 14, 2011 at 11:56 PM, Dale<rdalek1...@gmail.com> wrote: >> >> >>> Pandu Poluan wrote: >> >> >>> >> >> >>> On Oct 15, 2011 5:49 AM, "Dale"<rdalek1...@gmail.com> 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 >> >> >>>>> >> >> >>>>> Jeez, 43 years on and you're still going on about it... >> >> >>>> >> >> >>>> Dang, I was only a year old when hal came out? That just >> >> >>>> doubled >> >> >>>> my >> >> >>>> age. >> >> >>>> It's closer to what I feel like tho. >> >> >>>> >> >> >>>> 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>>> >> >> >>> >> >> >>> Do you know that there's a plan to move /var/run to / also? >> >> >>> ;-) >> >> >>> >> >> >>> Rgds, >> >> >>> >> >> >>> >> >> >>> Now someone on here swears up and down that /var isn't going >> >> >>> to be >> >> >>> required >> >> >>> on /. >> >> >> >> >> >> /var != /var/run >> >> >> /var != /var/lock >> >> >> >> >> >> /var/run is going in /run, but /var/run (by definition) only >> >> >> contains >> >> >> 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 very 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. >> >> >> >> >> >> Nobody has even proposed that /var should go into the same >> >> >> partition >> >> >> 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 /. >> >> >> >> >> >> Whoever says that /var will be required to be on the same >> >> >> partition as / is either wildly speculating, or spreading FUD. >> >> > >> >> > So /var/run and /var/lock isn't on /var? Even if they will be >> >> > linking >> >> > 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. >> >> >> >> > 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 >> >> > without 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 LVM for /usr and/or /var, you have to have a init >> >> > thingy even if / is on a regular file system. >> >> >> >> 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? >> >> >> >> >>> I'm telling ya'll, /home is coming. >> >> >> >> >> >> That is just ridiculous. >> >> > >> >> > I would have said the same thing about /usr a year ago. I'm not >> >> > saying it is coming next week but . . . >> >> >> >> You can speculate all you want. Fact is, nobody has proposed that, and >> >> 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 the >> >> same partition as / has been being discussed years ago; if you had >> >> followed the developers lists, you wil had hear about it months before >> >> it happened. >> >> >> >> Nothing similar has happened with /var, least of it /home. >> >> >> >> >>> We are going to end up where we >> >> >>> can only have one drive in our Linux boxes for the OS and its >> >> >>> relatives.>> >> >> >> >> >> >> And so is this: more FUD. >> >> >> >> >> >>> That or we will ALL have to start using the pesky init* >> >> >>> thingy. >> >> >> >> >> >> 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: >> >> >> >> >> >> >> >> >> http://archives.gentoo.org/gentoo-dev/msg_20749880f5bc5feda14148 >> >> >> 849872 9fe8.xml >> >> >> >> >> >> 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. >> >> > >> >> > I'll have to read his link later. >> >> >> >> Please do. >> >> >> >> >>> 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 >> >> >>> >> >> >>> 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. >> >> >> >> >> >> 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 >> >> >> use >> >> >> Zac's proposal. >> >> >> >> >> >> In no case whatsoever you will be required to have /var on the >> >> >> same >> >> >> partition as /. Nobody has ever proposed that. /run and >> >> >> /run/lock are >> >> >> not /var. >> >> >> >> >> >> Regards. >> >> > >> >> > No one proposed that /usr was required until just recently. >> >> >> >> http://article.gmane.org/gmane.comp.sysutils.systemd.devel/1337 >> >> >> >> That was on February 25, this year. *Eight* months ago. And the stable >> >> udev in Gentoo still "supports" (it really doesn't, but whatever) a >> >> separated /usr. >> >> >> >> > Saying it won't >> >> > happen really puts you in a bad spot when or if it does. If you >> >> > know >> >> > this for sure and certain, I want your crystal ball. >> >> >> >> 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 propose to move it to /. They do it with /run, they do it with >> > /lock, they will do it the same way the next time such an issue arises. >> >> You keep speculating and speculating. When you have some evidence to >> sustain your claims, we talk. > > My evidence is /run and /lock as stated in the mail you quoted.
That is no evidence: as I have been saying from the beginning, /var/run and /var/lock are not /var. I keep mentioning databases because those use a lot of space. Needing them at boot time would be absurd. /run and /lock are tiny dirs, and perfect candidates for tempfs, and then linking them from /var. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
