From: "Tomáš Čech" <sleep_walker@gnu.org>
To: guix-devel@gnu.org
Subject: LVM support
Date: Wed, 15 Apr 2015 07:07:56 +0200 [thread overview]
Message-ID: <20150415050756.GC6648@venom> (raw)
Hi Guix,
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 :(
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".
What next?
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?)
Or do it in different way. I'd rather not propose here any wild ideas
for configuration but if you can devise something better, please tell
me...
S_W
next reply other threads:[~2015-04-15 5:08 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-15 5:07 Tomáš Čech [this message]
2015-04-15 12:32 ` LVM support Ludovic Courtès
2015-04-16 6:24 ` Tomáš Čech
2015-04-16 12:47 ` Ludovic Courtès
2015-04-17 1:09 ` Tomáš Čech
2015-04-21 15:52 ` Ludovic Courtès
2015-05-01 11:32 ` Tomáš Čech
2015-05-03 19:59 ` Ludovic Courtès
2015-05-07 8:02 ` Tomáš Čech
2015-05-19 10:32 ` Ludovic Courtès
-- strict thread matches above, loose matches on Subject: below --
2018-07-29 15:18 Roadmap for Guix 1.0 Ludovic Courtès
2018-07-30 1:23 ` Pjotr Prins
2018-07-30 9:02 ` Nils Gillmann
2018-07-30 12:47 ` Pierre Neidhardt
2018-08-19 11:06 ` LVM support Ludovic Courtès
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150415050756.GC6648@venom \
--to=sleep_walker@gnu.org \
--cc=guix-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).