On 04/23/2015 10:57 AM, Michael Biebl wrote:
> On Fri, 02 Jan 2015 12:13:06 +0100 Peter Rajnoha <prajn...@redhat.com>
> wrote:
>> So this just seems that the initramfs scripts and systemd units
>> are not set up properly - this needs to be inspected:
>>
>> 1) is lvm2-lvmetad.socket systemd unit enabled?
>
> By default this is the case.
OK.
>
>> 2) is lvmetad supposed to be used in initramfs at all?
>
> Debian uses initramfs-tools by default.
> The lvm2 hooks for initramfs-tools do not use lvmetad.
Then we need to make sure that use_lvmetad=0 is set in
the lvm.conf that used in initramfs so LVM does not try
to contact lvmetad if it's not there (this will remove
the warning which says there's a fallback to direct
scanning once the contact with lvmetad fails - if lvmetad
is not there, it's useless to even try that then - so
use_lvmetad=0 in initramfs' lvm.conf).
>
>> 2a) if yes, is systemd used in initramfs
>
> initramfs-tools does not use systemd.
>
>> 2aa) if yes, is lvm2-lvmetad.socket unit present and enabled there?
>> (as well as lvm2-lvmetad.service unit and lvmetad binary present
>> in initramfs)
>> 2ab) if no, is lvmetad started directly within initramfs script?
>> 2b) if no, is there a direct vgchange/lvchange -aay call in initramfs
>> script?
>> (also, is lvm.conf modified for initramfs script so that
>> use_lvmetad=0 is used
>> for the "fallback to direct LVM scan" warning messages to disappear)
So we need to make sure there's vgchange or lvchange -aay direct call
in initramfs to activate the LV with root FS.
> Vincent, looks like you weren't CCed, so you didn't get the message.
>
> Peter, if the initramfs does *not* use lvmetad (as is the case with the
> default initramfs-tools setup), does it actually work if the root file
> system uses lvm in lvmetad = 1 mode?
>
Yes, after switching to root FS, there should be "udevadm trigger" call
within bootup scripts to rerun all the udev rules - this will include
all the "pvscan --cache -aay" calls from lvmetad udev rule (it's
69-dm-lvm-metad.rules in upstream, not sure how it is now in Debian,
but probably the same file I suppose).
The very first "pvscan --cache -aay" call will use lvmetad socket
and that will also instantiate lvm2-lvmetad.service via lvm2-lvmetad.socket
unit. Then all the pvscan --cache calls based on the events coming from
the udevadm trigger on bootup will update lvmetad and its cache about
all PVs present in the system, including the device on which LV with
root FS resides and other filesystems.
This way, lvmetad will have all the information cached about PVs present
in the system and then all LVM tools will use this cache to get the list
of PVs and VGs/LVs present in the system.
Also, the pvscan --cache -aay activates the VG as soon as it is
complete, meaning all PVs are present in the system (all udev
events for PVs making up a VG were issued).
If there's a mount point on a device, systemd can wait for such
device to appear. If that device is an LV, that LV gets activated
automatically once all PVs are present in the system for that VG
Once activated, the device that systemd is waiting on appears and
systemd immediately does a mount of the FS that resides on that
device (...if it's supposed to be mounted, of course - so either
fstab entry or systemd's .mount unit is defined for that device/FS).
So that's basically how all the LVM activation works:
- manually in initramfs (where systemd and lvmetad is not used)
- fully automatically once we switch to root FS and lvmetad and
systemd is used
--
Peter
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
