[Top][All Lists]

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

Re: LVM support

From: Ludovic Courtès
Subject: Re: LVM support
Date: Wed, 15 Apr 2015 14:32:14 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

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

> 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?


reply via email to

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