Re: LVM support

[Ludovic Courtès]

Tomáš Čech <address@hidden> 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’.