On 28/09/2013 00:57, Dale wrote: > Bruce Hill wrote: >> On Fri, Sep 27, 2013 at 05:33:02PM -0500, Dale wrote: >>> I'm hoping that since I use eudev, I don't have to worry about this. >>> If I do, this could get interesting, again. Dale >> Do you have /usr separate from / ? > > Yep. From my understanding tho, eudev is not supposed to be affected by > this problem tho. > > One reason for this being seperate, I have / and /boot on a regular > partition and everything else on LVM. Sometimes that /usr gets a bit > full. It's not so bad after I moved all the portage stuff out and put > it in /var. Now I have to watch /var too. lol
Ask yourself this question: Why do you have /usr separate? No really, *why exactly*? One of the very first things you do with /usr at boot time is mount it, and from then on you use it exactly as if it were always on / anyway. I'll bet that since you moved all of portage out, your mount options and fs configs are the same between the two anyway. So what exactly does a separate /usr get you on a stabd-alone workstation buy you? I've been looking at this for ages and conclude it buys me nothing but pain. They don't even change much if /home and /var are elsewhere, so guage your size right (easy to do) and never need look at it again. Separate /usr for the most part is an ancient artifact from decades ago. It's useful in edge cases but not in the general case with modern hardware. So why do people do it? I reckon it's inertia and nothign more. Which is kinda silly as inertia ignores everythign else in the environment that is changing around you (and *that* is a given). So unless you have something exotic like /usr mounted off a central server, or want / on LVM (and your grub doesn't support lvm), you are going to need an initramfs anyway to get around the circular bootstrap problem. I say people should make their lives easier and just stick /usr on the same volume as / and be done with it. It removes a whole lot of painful scenarios that are going to keep on biting you as the rest of the world moves on and progresses -- Alan McKinnon [email protected]
