On Wed, August 21, 2013 22:02, Neil Bothwick wrote: > On Wed, 21 Aug 2013 11:50:57 -0400, Tanstaafl wrote: > >> > This sounds like a bug in LVM. If it was down to a version clash, why >> > did a restart find the PVs? >> >> Sorry, ianap, but I do know that this kind of thing has never happened >> to me in my 8+ years of running this old system with a separate /usr >> *without* an initramfs... > > Which proves absolutely nothing. For all we know you don't use LVM either.
True, except that I have been using LVM for that long with a seperate LVM. My partition scheme used to look like: 1) /boot (100M) 2) / (500M) 3) swap (whatever seemed logical) 4) LVM (rest) And then the larger parts in seperate LVs. This always worked for me and I never had any issues with any programs running on my machines. As it looks like we are being forced to use an initramfs if /usr is seperate, I decided to use the following partitioning: 1) /boot (300M) 2) LVM (rest) And simply put everything into LVM. >> So, the bottom line is, obviously (to me at least), there are a lot >> more things that can go wrong when an initramfs is involved, that >> simply don't or can't happen otherwise. > > I'd take issue with "a lot" but there are things that can go wrong with > an initramfs (but this wasn't one of them, it was PEBKAC) just as there > are things that can go wrong when you use a separate /usr without an > initramfs. I agree with the PEBKAC, but a simple method to identify when the initramfs is out-of-sync with userland tools would help. Preferably something integrated into portage that puts out a warning when a package that has parts in the initramfs is updated mentions that the initramfs is out-of-sync. >> >> And this is *precisely* what scares me about this. >> >> >> >> This simply should not be, period. Support for separate /usr without >> >> initramfs simply SHOULD NOT be dropped unless/until things like this >> >> (updating lvm) can *never* cause a system to fail to boot like >> >> this. > > No one has demonstrated that it can. An initramfs isn't magic, it > caries out a couple of trivial tasks before switching to the real root > partition. The issue mentioned was an example. It was also: 1) The only one I can remember from the last 4 or 5 years 2) Easily avoided with a "rebuild initramfs" notice during upgrade > Yes, an initramfs adds an extra step to the boot process, but so does > having a separate /usr in the first place. I think that if you took the > time to understand what an initramfs is and does instead of making an > emotional reaction to it, you would see that this is no big deal. I think part of the "problem" with it is that the documentation about it isn't clear. There are tools (genkernel / dracut /..? ) that can automate the generation of it. But it isn't clear what exactly it is doing. If there would be a clear guide on how to do it manually, or a tool that would assist in building the file(s) needed to have it build into the kernel, then it might be more acceptable to some. I currently use genkernel, simply because it works-for-me and I haven't had the time to investigate how to get my setup supported with an in-kernel version. >> > This is irrelevant to separate /usr. an initramfs is required if / is >> > on a VM, whether or not /usr is on the same LV. >> >> Sorry, I don't see where he said that this system was running on a >> VM... or did you mean where he had / on an *LVM* partition - which, >> again, he did not say he had. > > Sorry, I meant LV. The person with the issue did not mention having / on LVM. I also never had any issues with /usr on LVM while / was not. -- Joost
