On 08/21/2013 05:42 PM, Canek Peláez Valdés wrote: > On Wed, Aug 21, 2013 at 10:54 AM, thegeezer <[email protected]> wrote: >> On 08/21/2013 04:10 PM, Neil Bothwick wrote: >>> On Wed, 21 Aug 2013 10:40:32 -0400, Tanstaafl wrote: >>> >>>>>> update LVM2 >>>>>> kernel remains the same >>>>>> reboot >>>>>> initramfs finds all PVS and activates VG >>>>>> main system init >>>>>> /etc/init.d/lvm2 start >>>>>> error can't read from USB PVS >>>>>> login to system with missing PVS >>>>>> /etc/init.d/lvm2 restart >>>>>> all PVS listed >>>>>> reboot several times to verify it wasn't just a stuck service, >>>>>> exactly the same >>>>>> now ok but restarting a boot service manually required (!) >>>>> I updated the initramfs and rebooted and all problems went away >>> This sounds like a bug in LVM. If it was down to a version clash, why did >>> a restart find the PVs? >> well you can probably understand my confusion replugging usb devices and >> trying to pvscan // vgchange -ay --partial etc >> the errors i was getting are below. i genuinely thought with the >> missing device it was a hardware failure of the usb disk, and a restart >> of lvm was a last gasp chance; when it worked i realised the initram >> might need updating. > As Neil said, this sounds like a bug in LVM and/or the initramfs you either way i'm not too fussed to find out - i found a temp solution (restart lvm) and a complete resolution (update initramfs). it is odd though huh, and is an important headsup to me (and maybe others) to make sure to update the initramfs in future when i notice lvm updates. as it only happened last week it was i thought pertinent to the discussion, thanks for the thoughts on finding a resolution but it is resolved for me now. i only post it as a potential warning to others. > were using (did you use genkernel, dracut, you roll your own?) If a > restart worked, the initramfs could do that, right?
genkernel initramfs --lvm > > So, it was not a problem with the initramfs, per se. > > >> Aug 17 17:56:30 [kernel] Buffer I/O error on device dm-26, logical block >> 5242864 >> - Last output repeated twice - >> Aug 17 17:56:30 [kernel] Buffer I/O error on device dm-26, logical block >> 5242878 >> - Last output repeated twice - >> Aug 17 17:56:30 [kernel] Buffer I/O error on device dm-26, logical block 0 >> - Last output repeated twice - >> Aug 17 17:56:30 [kernel] Buffer I/O error on device dm-26, logical block 1 >> Aug 17 17:56:30 [kernel] Buffer I/O error on device dm-26, logical block >> 5242879 >> - Last output repeated 2 times - >> >> >>>> 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. >>> This is irrelevant to separate /usr. an initramfs is required if / is on >>> a VM, whether or not /usr is on the same LV. >>> >>> >> >> Perhaps though it highlights a need for a utility to identify if items >> on an initramfs have been updated ? >> in this case the problem was definitely between the keyboard and the >> chair, but it is easily overlooked (yeah just trying to make myself feel >> better) > I'm under the impression that, with a properly generated initramfs, > this kind of things would be avoided when changing minor versions of > stuff like LVM or NFS. For major versions, a message from the ebuild > shoul be enough, and I'm not even sure about that. > > We should also expect some responsibility from the user towards her > system; if she updates anything related to mounting /usr (and perhaps > /), then she should use her common sense and rebuild her initramfs. +1 for the user responsibility, as i said definitely pebkac. however, a friendly notice wouldn't go amiss. as i mentioned in a previous post where that notice comes from is to be debated as i do not want an ubuntu style everything happens for you automagically because then when you try to do anything different it all falls down. ya, i want full control and none of the responsibility for when it goes wrong ;) > >> either way i'm already using initramfs anyway -- i pesonally roll out >> lvm on root on everything i can because of it's flexibility: so the >> whole argument of whether or not split /usr is not my argument. i'm >> just bringing things to light to make the overall process easier for >> everyone by highlighting potential issues folks may have. > If we had just one initramfs generator, this could be easily > automatized. The problem is that we have genkernel, dracut, busybox > with the sep-usr USE flag, and roll-your-own-initramfs (and whichever > one I don't know about). The cost of all this choice is that is > responsibility of the user to take care of her system. > > I highly recommend to use dracut; it just works, it can be called at > any time, and it takes between 10 to 30 seconds (depends on the speed > of the machine) to build an initramfs. If you are really, *really* > paranoid, you can make an script for your "emerge -whatever world" > command, and add "dracut -f -H" afterwards, and then only upgrade your > world with that script. > > That way, *every* time you upgrade your world, you update your > initramfs. It adds 10-30 seconds to your upgrade time, but the > initramfs is always in sync. i'll have to try dracut, genkernel is considerably longer as it seems to want to recompile everything each time i.e. busybox > > I only update my initramfs after a kernel update, but I follow > vanilla-sources, so that is every other week or something like that. I > have an script that compiles the new kernel, installs it, generates > the initramfs, and updates the GRUB (or GRUB2) config file, so > everything is automatized. > > Regards. anyone have any good pointers to an initramfs interrogator, maybe that takes as argument kernel command line ?
