From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1MlJzm-000508-AO for mharc-grub-devel@gnu.org; Wed, 09 Sep 2009 06:01:46 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MlJzj-0004zT-Lc for grub-devel@gnu.org; Wed, 09 Sep 2009 06:01:43 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MlJze-0004uj-OS for grub-devel@gnu.org; Wed, 09 Sep 2009 06:01:43 -0400 Received: from [199.232.76.173] (port=58068 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MlJze-0004uY-GF for grub-devel@gnu.org; Wed, 09 Sep 2009 06:01:38 -0400 Received: from mx1.redhat.com ([209.132.183.28]:40572) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MlJzd-0005HL-Q1 for grub-devel@gnu.org; Wed, 09 Sep 2009 06:01:38 -0400 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id n89A1ZuX021430 for ; Wed, 9 Sep 2009 06:01:35 -0400 Received: from alatyr.englab.brq.redhat.com (alatyr.englab.brq.redhat.com [10.34.33.30]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id n89A1Yxf015311; Wed, 9 Sep 2009 06:01:34 -0400 Message-ID: <4AA77CFD.3000806@redhat.com> Date: Wed, 09 Sep 2009 12:01:33 +0200 From: Peter Rajnoha User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.1) Gecko/20090814 Fedora/3.0-2.6.b3.fc11 Lightning/1.0pre Thunderbird/3.0b3 MIME-Version: 1.0 To: grub-devel@gnu.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12 X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. Cc: Alasdair G Kergon , Milan Broz Subject: Changes in device-mapper and LVM2 that can affect grub's functionality X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2009 10:01:44 -0000 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. Thanks, Peter