Re: [gentoo-user] systemd and initramfs

[thegeezer]

On 08/21/2013 05:42 PM, Canek Peláez Valdés wrote:
> On Wed, Aug 21, 2013 at 10:54 AM, thegeezer <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
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 ?