Tomáš Čech <sleep_wal...@gnu.org> skribis:
> as project for my Hackweek in SUSE I decided to spend my time on LVM
> support in GuixSD - something I miss greatly. This also means that
> I'll have much less time for that after this week :(
Well this is nice already!
> So far I spent time on reviving my GuixSD installation and preparing
> staticly linked binaries for initrd. I have now lvm2 package with
> extra output "static".
Don’t worry about static linking or anything: you can use any package,
including dynamically-linked, and it will be magically added to the
initrd if needed.
Then as a second step, since that’ll probably be very big, you can work
on statically-linked variants of the relevant packages (as done for
‘e2fsck/static’.)
> Now the simplest way would be to simply call
>
> vgchange --activate y
>
> Matching configuration could be one configuration option:
> (use-lvm?)
>
>
> That would scan all block devices and look for LVM signature.
>
> Pros:
> - it's super simple!
> Cons:
> - if LVM with filesystem required at boot-time is not found, error
> is not detected or returned by LVM itself
>
>
>
> Slightly bit more complicated way could be
>
> vgchange --activate y <volume_group_name>
>
> for every volume group defined in system configuration. Matching
> configuration could be
> (logical-volume-groups '("system" "data"))
>
> e.g. specify list of volume group names used by system.
>
> Pros:
> - still simple
> - if group activation fails, I can detect it and report it to user
>
> Cons:
> - some block devices with LVM may not be available at boot-time (like
> iSCSI devices accessible through network only or Luks devices
> available after entering password)
>
> That is my current approach.
>
>
>
> I could also specify whether it should be made available at boot time or not
> (logical-volume-groups '('("system" #t)
> '("data" #f)))
>
> (sorry for my poor Scheme taste here :)
>
> Pros:
> - with this I could say that volume group "system" should be activated
> at boot time, but "data" should be activated later.
>
> Cons:
> - starting to be more complicated - I need both initrd stage LVM
> activation and root filesystem stage LVM activation (implemented as
> service? which dependencies it has?)
Sorry I’m not really familiar with LVM.
Technically, if LVM volumes are mapped devices, the best would be to
define a <mapped-device-kind> structure for them, as discussed on IRC
(like ‘luks-device-mapping’ in (gnu system).)
Then users would need to adjust their ‘mapped-devices’ accordingly (info
"(guix) Mapped Devices").
How does that sound?
Thanks,
Ludo’.
