grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v3] diskfilter: use nodes in logical volume's segment as memb


From: Daniel Kiper
Subject: Re: [PATCH v3] diskfilter: use nodes in logical volume's segment as member device
Date: Tue, 28 Sep 2021 15:48:49 +0200
User-agent: NeoMutt/20170113 (1.7.2)

On Mon, Sep 27, 2021 at 05:39:56PM +0800, Michael Chang via Grub-devel wrote:
> Currently the grub_diskfilter_memberlist function returns all physical
> volumes added to a volume group to which a logical volume (LV) belongs.
> However this is suboptimal as it doesn't fit the intended behavior of
> returning underlying devices that make up the LV. To give a clear
> picture, the result should be identical to running commands below to
> display the logical volumes with underlying physical volumes in use.
>
>   localhost:~ # lvs -o lv_name,vg_name,devices /dev/system/root
>     LV   VG     Devices
>     root system /dev/vda2(512)
>
>   localhost:~ # lvdisplay --maps /dev/system/root
>     --- Logical volume ---
>       ...
>     --- Segments ---
>     Logical extents 0 to 4604:
>       Type                linear
>       Physical volume     /dev/vda2
>       Physical extents    512 to 5116
>
> As shown above, we can know system-root lv uses only /dev/vda2 to
> allocate it's extents, or we can say that /dev/vda2 is the member device
> comprising the system-root lv.
>
> It is important to be precise on the member devices, because that helps
> to avoid pulling in excessive dependency. Let's use an example to
> demonstrate why it is needed.
>
>   localhost:~ # findmnt /
>   TARGET SOURCE                  FSTYPE OPTIONS
>   /      /dev/mapper/system-root ext4   rw,relatime
>
>   localhost:~ # pvs
>     PV               VG     Fmt  Attr PSize    PFree
>     /dev/mapper/data system lvm2 a--  1020.00m    0
>     /dev/vda2        system lvm2 a--    19.99g    0
>
>   localhost:~ # cryptsetup status /dev/mapper/data
>   /dev/mapper/data is active and is in use.
>     type:    LUKS1
>     cipher:  aes-xts-plain64
>     keysize: 512 bits
>     key location: dm-crypt
>     device:  /dev/vdb
>     sector size:  512
>     offset:  4096 sectors
>     size:    2093056 sectors
>     mode:    read/write
>
>   localhost:~ # vgs
>     VG     #PV #LV #SN Attr   VSize  VFree
>     system   2   3   0 wz--n- 20.98g    0
>
>   localhost:~ # lvs -o lv_name,vg_name,devices
>     LV   VG     Devices
>     data system /dev/mapper/data(0)
>     root system /dev/vda2(512)
>     swap system /dev/vda2(0)
>
> We can learn from above that /dev/mapper/data is an encrypted volume and
> also gets assigned to volume group 'system' as one of it's physical
> volumes. And also it is not used by root device,
> /dev/mapper/system-root, for allocating extents, so it shouldn't be
> taking part in the process of setting up grub to access root device.
>
> However running grub-install reports error as volume group 'system'
> contains encrypted volume.
>
>   error: attempt to install to encrypted disk without cryptodisk
>   enabled. Set `GRUB_ENABLE_CRYPTODISK=y' in file `/etc/default/grub'.
>
> Certainly we can enable GRUB_ENABLE_CRYPTODISK=y and move on, but that
> is not always acceptable since the server may need to be booted
> unattended. Additionally, typing passphase for every system startup can
> be a big hassle of which most users would like to avoid.
>
> This patch solves the problem by returning exact physical volume,
> /dev/vda2, rightly used by system-root from the example above, thus
> grub-install will not error out because the excessive encrypted device
> to boot the root device is not configured.
>
> Signed-off-by: Michael Chang <mchang@suse.com>
> Tested-by: Olav Reinert <seroton10@gmail.com>

Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>

Daniel



reply via email to

[Prev in Thread] Current Thread [Next in Thread]