On Wed, Aug 21, 2013 at 10:54 AM, thegeezer <thegee...@thegeezer.net> 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 were using (did you use genkernel, dracut, you roll your own?) If a restart worked, the initramfs could do that, right? 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. > 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 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. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
