From: Felix Zielcke <fzielcke@z-51.de>
To: The development of GRUB 2 <grub-devel@gnu.org>
Subject: Re: Changes in device-mapper and LVM2 that can affect grub's functionality
Date: Wed, 09 Sep 2009 12:26:32 +0200 [thread overview]
Message-ID: <1252491992.2998.11.camel@fz.local> (raw)
In-Reply-To: <4AA77CFD.3000806@redhat.com>
Am Mittwoch, den 09.09.2009, 12:01 +0200 schrieb Peter Rajnoha:
> Hi,
>
> (I'm speaking for the LVM/DM team)
>
> we have integrated official udev support for device-mapper/LVM
> devices lately which is now part of upstream LVM release (however
> it's still turned off in default configuration). This includes
> our own udev rules responsible for creating /dev nodes and
> associated symlinks.
>
> After discussing this with the udev team, we decided to create
> DM nodes directly in /dev (with the kernel name of that particular
> DM device, which is "dm-X", X being a number for now). The /dev/mapper
> contains symlinks to these nodes then. This seems to be a standard
> solution from udev point of view which is considered to be correct.
> We would like to comply with this standard.
>
> As for the LVM subsystem, the symlinks stay like in the old non-udev
> approach -- /dev/VG_NAME subdir containing symlinks with LV names that
> point to appropriate DM devices. The change here is only in their
> target -- they point to /dev/dm-X devices now, not /dev/mapper ones.
>
> However, we have to consider that not all configurations will have
> this udev support turned on, therefore we still keep the old code
> responsible for direct creation of the nodes/symlinks (this feature
> can be turned on/off by particular configuration option).
>
> Also, if we detect that udev daemon is not running or node/symlink
> creation has failed for any reason, we fallback to the old way
> of node/symlink creation.
>
> To sum it up briefly, this means we have two layouts that should
> be supported:
>
> 1. old layout -- nodes /dev/mapper/DM_NAME,
> symlinks /dev/VG_NAME/LV_NAME
>
> 2. new (udev) layout -- nodes /dev/dm-X,
> symlinks /dev/mapper/DM_NAME
> symlinks /dev/VG_NAME/LV_NAME
>
>
>
> Such layout breaks grub-probe because of the symlinks used afaik
> (particularly "find_root_device" function that is used in this
> situation).
>
> My question is if supporting this would be a problem from grub's
> point of view and if appropriate corrections could be made.
>
> Also, I've spotted that you use some hardcodings in your code,
> particularly when filtering out /dev/dm-[0-9] devices
> (e.g. in "find_root_device" fn). The thing is that this number
> part of the DM name could be changed in the future, so such
> assumptions should not be made as well.
>
> I'd like to open a discussion here and any comments are welcome
> so finally we could end up with a working solution.
>
What's the point in having the /dev/dm-X devices at all?
Does anything use them?
Currently all symlinks are ignored.
If we use the target of the /dev/mapper/* symlinks, i.e. a /dev/dm-X
device this would at least with the default Debian initrd not work and I
doubt the responding persons for this will change this ever. Even
root=UUID= isn't working for LVM devices, because only the root LV is
activated and not all inside the initrd.
If we would use the symlink itself for root= it could break if there
were symlinks which aren't inside the initrd too.
I personally don't like this change at all.
Why not just remove the dm-X devices and make the /dev/mapper/ ones the
only and real ones?
Maybe the udev maintainers just prefer cryptic numbers for every real
device and only accept symlinks for descriptive ones.
--
Felix Zielcke
Proud Debian Maintainer
next prev parent reply other threads:[~2009-09-09 10:26 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-09 10:01 Changes in device-mapper and LVM2 that can affect grub's functionality Peter Rajnoha
2009-09-09 10:26 ` Felix Zielcke [this message]
2009-09-09 12:01 ` Peter Rajnoha
2009-10-12 12:19 ` Felix Zielcke
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1252491992.2998.11.camel@fz.local \
--to=fzielcke@z-51.de \
--cc=grub-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.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.