From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1Ypgnz-0002Kb-7c for mharc-grub-devel@gnu.org; Tue, 05 May 2015 13:38:51 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41414) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ypgnx-0002K0-4I for grub-devel@gnu.org; Tue, 05 May 2015 13:38:50 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ypgnp-0000TT-5e for grub-devel@gnu.org; Tue, 05 May 2015 13:38:49 -0400 Received: from mail-lb0-x22b.google.com ([2a00:1450:4010:c04::22b]:33853) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ypgno-0000SR-QH for grub-devel@gnu.org; Tue, 05 May 2015 13:38:41 -0400 Received: by lbcga7 with SMTP id ga7so134607747lbc.1 for ; Tue, 05 May 2015 10:38:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; bh=MjEhqZevEgi8XQumua9tXNAFCrS8Ghg7YPquKu3zSPo=; b=YEVYVy9mwWyPrBJvsHwlq7U11ab3Z38mdshBhoCv9JwCUU5Grp06JyMnYI1fZELGJd ydPCUMaDyFEkg5XG5V/8sp5h0G6ziuqtenWMRIrmrt+L+6lphUoHRSNgKkupXKXbUhKd lbpUSNjhE4uGhDi306SIeMdJ/kIaGOoT5H6wbdETq6qyznK8livbHotgal3py2Ia4Y0a 20TkzuWqbY5hlPZIGAb4QZjeRF6Ri0D890p/F7VD1ORTiwHDUSeU9qaDmDzEZefdVIjg JUBs02yb6d7i9vbBC9hyWmhcMbUpqhNgYvKc8xUaNYwdGPVyN7/ayvB+WTsWMe4xFWay zIKA== X-Received: by 10.152.234.139 with SMTP id ue11mr25114301lac.28.1430847519694; Tue, 05 May 2015 10:38:39 -0700 (PDT) Received: from opensuse.site (ppp91-76-14-38.pppoe.mtu-net.ru. [91.76.14.38]) by mx.google.com with ESMTPSA id ky7sm4203096lab.37.2015.05.05.10.38.37 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 05 May 2015 10:38:38 -0700 (PDT) Date: Tue, 5 May 2015 20:38:36 +0300 From: Andrei Borzenkov To: Sebastian Pipping Subject: Re: Future of installing GRUB to LVM volumes (and loop devices) Message-ID: <20150505203836.30e66cbc@opensuse.site> In-Reply-To: <5548F5AB.4080305@pipping.org> References: <5548F5AB.4080305@pipping.org> X-Mailer: Claws Mail 3.11.0 (GTK+ 2.24.27; x86_64-suse-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:4010:c04::22b Cc: grub-devel@gnu.org X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: The development of GNU GRUB List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2015 17:38:50 -0000 =D0=92 Tue, 05 May 2015 18:54:03 +0200 Sebastian Pipping =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > Hello! >=20 >=20 > I noticed that GRUB stopped supporting installation to LVM volumes and > that installing to loop devices also started failing unless --force is > given. The Release of Debian jessie made me realize that GRUB > 2.02~beta2 stopped doing what 1.99 did without complaining. So I did > some debugging. >=20 > A word on what this is needed for: > I have a case where grub-install is asked to install to an LVM volume > [1] that is later passed to Xen to boot a Xen guest. Inside the Xen > guest the LVM volume is seen as a regular hard disk. So I can no longer > use grml-debootstrap/grub-install to install to LVM volumes without > patching at least one of those. >=20 > To reproduce it: >=20 > # touch /var/tmp/disk2 > # truncate --size=3D$((100*1024**2)) /var/tmp/disk2 > # loop_device_2=3D"$(losetup --show -f /var/tmp/disk2)" > # vgcreate vg "${loop_device_2}" > # lvcreate --name lv -l 100%free vg > # parted /dev/vg/lv mklabel msdos > # parted /dev/vg/lv mkpart primary ext4 4m 100% > # mkfs.ext4 /dev/mapper/vg-lvp1 > # mkdir /mnt/lv-root > # mount /dev/mapper/vg-lvp1 /mnt/lv-root > # mkdir /mnt/lv-root/boot > # grub-install --boot-directory=3D/mnt/lv-root/boot /dev/mapper/vg-lv > Installing for i386-pc platform. > grub-install: error: disk > `lvmid/GrSIBA-3EPT-TxGE-cnSa-glgA-pXpy-Kw8cOg/PD3WT8-956c-CEJ8-yPJE-ttGy-= yACP-ffwTac' > not found. >=20 > When I add a device map containing that drive .. >=20 > # echo -e > '(lvmid/GrSIBA-3EPT-TxGE-cnSa-glgA-pXpy-Kw8cOg/PD3WT8-956c-CEJ8-yPJE-ttGy= -yACP-ffwTac)\t/dev/mapper/vg-lv' > > /mnt/lv-root/boot/grub/device.map >=20 > .. grub-install replaces the "lvmid/*" drive to > "hostdisk//dev/mapper/vg-lv" saying >=20 > grub-install: warning: the drive name > `lvmid/GrSIBA-3EPT-TxGE-cnSa-glgA-pXpy-Kw8cOg/PD3WT8-956c-CEJ8-yPJE-ttGy-= yACP-ffwTac' > in device.map is incorrect. Using hostdisk//dev/mapper/vg-lv instead. > Please use the form [hfc]d[0-9]* (E.g. `hd0' or `cd'). >=20 > and remains complaining "disk `lvmid/...' not found. > Since the docs at "13.1 How to specify devices" (docs/grub.info) > advertise "lvmid/" in Git for valid drive syntax, that came unexpected > to me. > Inspecting the code of read_device_map shows that only >=20 > (fd0) ... > (hd0) ... > (cd) ... >=20 > of the documented syntax are actually registering the drive as-is (which > does match the warning), everything else (including "(lvmid/*)") ends up > being re-written to "(hostdisk/)". So it does not allow me > helping GRUB in finding the disk. >=20 bor@opensuse:~/build/grub> cat boot/grub/device.map=20 (hd0) /dev/system/docker bor@opensuse:~/build/grub> sudo pkgdatadir=3D$PWD ./grub-install -d grub-co= re --boot-directory $PWD/boot --grub-mkdevicemap /tmp/device.map '(hd0)' Installing for i386-pc platform. Installation finished. No error reported. Yes, device.map is *still* useful :) >=20 > I did manage convincing grub-install to accept lvmid device map entries > using the patch attached but I would also like to see something that > works out of the box again (including loop devices), of course. >=20 >=20 > Now that you know about the scenario and problem I would like to ask: >=20 > * How you would like to see this addressed in GRUB code? >=20 > * What replacements to "grub-install --boot-directory=3D " can > you think of for a temporary workaround? > How would use existing GRUB commands to dump future MBR bytes needed > to some regular file to apply that to any device using dd after or > something like that? >=20 >=20 > Many thanks in advance, >=20 >=20 >=20 > Sebastian >=20 >=20 > [1] from inside a tool called grmldeboostrap [2], a wrapper around > deboostrap installing Debian to a given block device > [2] https://github.com/grml/grml-debootstrap