All of lore.kernel.org
 help / color / mirror / Atom feed
* Future of installing GRUB to LVM volumes (and loop devices)
@ 2015-05-05 16:54 Sebastian Pipping
  2015-05-05 17:38 ` Andrei Borzenkov
  0 siblings, 1 reply; 21+ messages in thread
From: Sebastian Pipping @ 2015-05-05 16:54 UTC (permalink / raw)
  To: grub-devel

[-- Attachment #1: Type: text/plain, Size: 3222 bytes --]

Hello!


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.

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.

To reproduce it:

  # touch /var/tmp/disk2
  # truncate --size=$((100*1024**2)) /var/tmp/disk2
  # loop_device_2="$(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=/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.

When I add a device map containing that drive ..

  # 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

.. grub-install replaces the "lvmid/*" drive to
"hostdisk//dev/mapper/vg-lv" saying

  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').

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

  (fd0) ...
  (hd0) ...
  (cd) ...

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/<file>)".  So it does not allow me
helping GRUB in finding the disk.


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.


Now that you know about the scenario and problem I would like to ask:

 * How you would like to see this addressed in GRUB code?

 * What replacements to "grub-install --boot-directory=<X> <Y>" 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?


Many thanks in advance,



Sebastian


[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

[-- Attachment #2: 0001-Allow-for-lvmid-device-map-entries.patch --]
[-- Type: text/x-patch, Size: 1113 bytes --]

From 810f62351dbb181843fdfdff7add4893e4e17710 Mon Sep 17 00:00:00 2001
From: Sebastian Pipping <sebastian@pipping.org>
Date: Tue, 5 May 2015 17:58:45 +0200
Subject: [PATCH] Allow for "lvmid/*" device map entries

---
 grub-core/kern/emu/hostdisk.c | 10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/grub-core/kern/emu/hostdisk.c b/grub-core/kern/emu/hostdisk.c
index a3b00c8..81b9840 100644
--- a/grub-core/kern/emu/hostdisk.c
+++ b/grub-core/kern/emu/hostdisk.c
@@ -538,8 +538,14 @@ read_device_map (const char *dev_map)
       map[drive].device = grub_canonicalize_file_name (p);
       if (! map[drive].device)
 	map[drive].device = xstrdup (p);
-      
-      if (!map[drive].drive)
+
+      if (strncmp(drive_e, "lvmid/", sizeof("lvmid/") - 1) == 0)
+	{
+	  map[drive].drive = xmalloc (drive_p - drive_e + sizeof ('\0'));
+	  strncpy (map[drive].drive, drive_e, drive_p - drive_e + sizeof ('\0'));
+	  map[drive].drive[drive_p - drive_e] = '\0';
+	}
+      else if (!map[drive].drive)
 	{
 	  char c;
 	  map[drive].drive = xmalloc (sizeof ("hostdisk/") + strlen (p));
-- 
2.1.4


^ permalink raw reply related	[flat|nested] 21+ messages in thread

* Re: Future of installing GRUB to LVM volumes (and loop devices)
  2015-05-05 16:54 Future of installing GRUB to LVM volumes (and loop devices) Sebastian Pipping
@ 2015-05-05 17:38 ` Andrei Borzenkov
  2015-05-06 12:30   ` Sebastian Pipping
  0 siblings, 1 reply; 21+ messages in thread
From: Andrei Borzenkov @ 2015-05-05 17:38 UTC (permalink / raw)
  To: Sebastian Pipping; +Cc: grub-devel

В Tue, 05 May 2015 18:54:03 +0200
Sebastian Pipping <sebastian@pipping.org> пишет:

> Hello!
> 
> 
> 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.
> 
> 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.
> 
> To reproduce it:
> 
>   # touch /var/tmp/disk2
>   # truncate --size=$((100*1024**2)) /var/tmp/disk2
>   # loop_device_2="$(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=/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.
> 
> When I add a device map containing that drive ..
> 
>   # 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
> 
> .. grub-install replaces the "lvmid/*" drive to
> "hostdisk//dev/mapper/vg-lv" saying
> 
>   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').
> 
> 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
> 
>   (fd0) ...
>   (hd0) ...
>   (cd) ...
> 
> 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/<file>)".  So it does not allow me
> helping GRUB in finding the disk.
> 

bor@opensuse:~/build/grub> cat boot/grub/device.map 
(hd0) /dev/system/docker
bor@opensuse:~/build/grub> sudo pkgdatadir=$PWD ./grub-install -d grub-core --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 :)

> 
> 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.
> 
> 
> Now that you know about the scenario and problem I would like to ask:
> 
>  * How you would like to see this addressed in GRUB code?
> 
>  * What replacements to "grub-install --boot-directory=<X> <Y>" 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?
> 
> 
> Many thanks in advance,
> 
> 
> 
> Sebastian
> 
> 
> [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



^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: Future of installing GRUB to LVM volumes (and loop devices)
  2015-05-05 17:38 ` Andrei Borzenkov
@ 2015-05-06 12:30   ` Sebastian Pipping
  2015-05-06 17:16     ` Andrei Borzenkov
  2015-05-07  9:35     ` Vladimir 'φ-coder/phcoder' Serbinenko
  0 siblings, 2 replies; 21+ messages in thread
From: Sebastian Pipping @ 2015-05-06 12:30 UTC (permalink / raw)
  To: grub-devel

Hello Andrei,


On 05/05/2015 07:38 PM, Andrei Borzenkov wrote:
> bor@opensuse:~/build/grub> cat boot/grub/device.map 
> (hd0) /dev/system/docker
> bor@opensuse:~/build/grub> sudo pkgdatadir=$PWD ./grub-install -d grub-core --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 :)

many thanks for your quick reply and this valuable workaround!


I have tested the

  echo -e "(hd0)\tY" > X/grub/device.map
  grub-install --boot-directory=X '(hd0)'

approach with all combinations of

 * Git HEAD, Debian wheezy (1.99), Debian jessie (2.02~beta2)

 * a loop device, an LVM volume

by now.  Of those

 * the only one that fails is loop device on Debian wheezy [1]
   (I welcome a workaround for that, too!) and

 * the only one requiring manual symlink resolution
   (e.g. passing /dev/dm-9 rather than /dev/mapper/vg-lv)
   is again Debian wheezy.


So that approach should allow me to patch future releases
grml-debootstrap for jessie, stretch and sid.


Nevertheless, let's get good old

  grub-install --boot-directory=... /dev/...

fixed, please.  It did work previously.  How do we proceed?

Best,



Sebastian


PS: I have not tested any from-within-chroot cases yet.  Those have
given different results to some extent in the past, at least.


[1] In the the shell:

# grub-install --boot-directory=/mnt/loop-root/boot '(hd0)' ; echo $?
/usr/sbin/grub-probe: error: cannot find a GRUB drive for
/dev/mapper/loop0p1.  Check your device.map.
Auto-detection of a filesystem of /dev/mapper/loop0p1 failed.
Try with --recheck.
If the problem persists please report this together with the output of
"/usr/sbin/grub-probe --device-map="/mnt/loop-root/boot/grub/device.map"
--target=fs -v /mnt/loop-root/boot/grub" to <bug-grub@gnu.org>
1
# mount | fgrep /mnt/loop-root
/dev/mapper/loop0p1 on /mnt/loop-root type ext4
(rw,relatime,user_xattr,barrier=1,data=ordered)
# cat /mnt/loop-root/boot/grub/device.map
(hd0)	/dev/loop0



^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: Future of installing GRUB to LVM volumes (and loop devices)
  2015-05-06 12:30   ` Sebastian Pipping
@ 2015-05-06 17:16     ` Andrei Borzenkov
  2015-05-12 10:41       ` Sebastian Pipping
  2015-05-07  9:35     ` Vladimir 'φ-coder/phcoder' Serbinenko
  1 sibling, 1 reply; 21+ messages in thread
From: Andrei Borzenkov @ 2015-05-06 17:16 UTC (permalink / raw)
  To: Sebastian Pipping; +Cc: grub-devel

В Wed, 06 May 2015 14:30:00 +0200
Sebastian Pipping <sebastian@pipping.org> пишет:

> 
> 
> Nevertheless, let's get good old
> 
>   grub-install --boot-directory=... /dev/...
> 
> fixed, please.  It did work previously.  How do we proceed?
> 
> Best,
> 
> 
> 
> Sebastian
> 
> 
> PS: I have not tested any from-within-chroot cases yet.  Those have
> given different results to some extent in the past, at least.
> 
> 
> [1] In the the shell:
> 
> # grub-install --boot-directory=/mnt/loop-root/boot '(hd0)' ; echo $?
> /usr/sbin/grub-probe: error: cannot find a GRUB drive for
> /dev/mapper/loop0p1.  Check your device.map.

bor@opensuse:~/build/grub> findmnt /mnt
TARGET SOURCE       FSTYPE OPTIONS
/mnt   /dev/loop0p1 ext2   rw,relatime
bor@opensuse:~/build/grub> sudo ./grub-probe -t fs /mnt
ext2
bor@opensuse:~/build/grub> sudo ./grub-probe -t partmap /mnt
msdos
bor@opensuse:~/build/grub> 

bor@opensuse:~/build/grub> /usr/sbin/losetup --help
...
 -P, --partscan                create a partitioned loop device
...

> Auto-detection of a filesystem of /dev/mapper/loop0p1 failed.
> Try with --recheck.
> If the problem persists please report this together with the output of
> "/usr/sbin/grub-probe --device-map="/mnt/loop-root/boot/grub/device.map"
> --target=fs -v /mnt/loop-root/boot/grub" to <bug-grub@gnu.org>
> 1
> # mount | fgrep /mnt/loop-root
> /dev/mapper/loop0p1 on /mnt/loop-root type ext4

There is no feasible way to map this device back to contained device,
short of scanning all maps, finding all partition labels on them and
matching maps against labels.

Half working solution would be to assume that it is always child map.

Or you can take shortcut and assume that /dev/mapper/XXXXpY is
partition of /dev/mapper/XXX but you still will need to verify it.

Patches are welcome.

> (rw,relatime,user_xattr,barrier=1,data=ordered)
> # cat /mnt/loop-root/boot/grub/device.map
> (hd0)	/dev/loop0
> 
> 
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel



^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: Future of installing GRUB to LVM volumes (and loop devices)
  2015-05-06 12:30   ` Sebastian Pipping
  2015-05-06 17:16     ` Andrei Borzenkov
@ 2015-05-07  9:35     ` Vladimir 'φ-coder/phcoder' Serbinenko
  2015-05-12  9:16       ` Sebastian Pipping
  1 sibling, 1 reply; 21+ messages in thread
From: Vladimir 'φ-coder/phcoder' Serbinenko @ 2015-05-07  9:35 UTC (permalink / raw)
  To: The development of GNU GRUB

[-- Attachment #1: Type: text/plain, Size: 675 bytes --]


> Nevertheless, let's get good old
> 
>   grub-install --boot-directory=... /dev/...
> 
> fixed, please.  It did work previously.  How do we proceed?
> 
grub tools assume that notion of what's "physical" remains unchanged
between install and boot unless specified otherwise in device.map. This
assumption is important to find out how to access disks. Obviously it's
not true when using
> 
> # grub-install --boot-directory=/mnt/loop-root/boot '(hd0)' ; echo $?
> /usr/sbin/grub-probe: error: cannot find a GRUB drive for
> /dev/mapper/loop0p1.  Check your device.map.
Does this wotk with HEAD? It should as long as GRUB is compiled with
devmapper support


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 213 bytes --]

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: Future of installing GRUB to LVM volumes (and loop devices)
  2015-05-07  9:35     ` Vladimir 'φ-coder/phcoder' Serbinenko
@ 2015-05-12  9:16       ` Sebastian Pipping
  0 siblings, 0 replies; 21+ messages in thread
From: Sebastian Pipping @ 2015-05-12  9:16 UTC (permalink / raw)
  To: grub-devel

On 05/07/2015 11:35 AM, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
>> # grub-install --boot-directory=/mnt/loop-root/boot '(hd0)' ; echo $?
>> /usr/sbin/grub-probe: error: cannot find a GRUB drive for
>> /dev/mapper/loop0p1.  Check your device.map.
> Does this wotk with HEAD?

With HEAD: Yes.

Best,



Sebastian



^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: Future of installing GRUB to LVM volumes (and loop devices)
  2015-05-06 17:16     ` Andrei Borzenkov
@ 2015-05-12 10:41       ` Sebastian Pipping
  2015-05-12 11:41         ` Andrei Borzenkov
  0 siblings, 1 reply; 21+ messages in thread
From: Sebastian Pipping @ 2015-05-12 10:41 UTC (permalink / raw)
  To: The development of GNU GRUB

On 05/06/2015 07:16 PM, Andrei Borzenkov wrote:
> bor@opensuse:~/build/grub> findmnt /mnt
> TARGET SOURCE       FSTYPE OPTIONS
> /mnt   /dev/loop0p1 ext2   rw,relatime
> bor@opensuse:~/build/grub> sudo ./grub-probe -t fs /mnt
> ext2
> bor@opensuse:~/build/grub> sudo ./grub-probe -t partmap /mnt
> msdos
> bor@opensuse:~/build/grub> 
> 
> bor@opensuse:~/build/grub> /usr/sbin/losetup --help
> ...
>  -P, --partscan                create a partitioned loop device
> ...

Thanks for introducing me to --partscan.  It's too young for Debian
wheezy, though.


>> Auto-detection of a filesystem of /dev/mapper/loop0p1 failed.
>> Try with --recheck.
>> If the problem persists please report this together with the output of
>> "/usr/sbin/grub-probe --device-map="/mnt/loop-root/boot/grub/device.map"
>> --target=fs -v /mnt/loop-root/boot/grub" to <bug-grub@gnu.org>
>> 1
>> # mount | fgrep /mnt/loop-root
>> /dev/mapper/loop0p1 on /mnt/loop-root type ext4
> 
> There is no feasible way to map this device back to contained device,
> short of scanning all maps, finding all partition labels on them and
> matching maps against labels.

Why not?

lsblk manages to detect that /dev/mapper/loop0p1 is a child of /dev/loop0:

# lsblk | fgrep loop | sed 's| \{23\}||'
loop0                 7:0    0   100M  0 loop
└─loop0p1 (dm-9)    254:9    0    96M  0 part  /mnt/loop-root


> Half working solution would be to assume that it is always child map.
> 
> Or you can take shortcut and assume that /dev/mapper/XXXXpY is
> partition of /dev/mapper/XXX but you still will need to verify it.
> 
> Patches are welcome.

I am still wondering: how come it was working in GRUB 2.00 but now
longer is?

Best,



Sebastian



^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: Future of installing GRUB to LVM volumes (and loop devices)
  2015-05-12 10:41       ` Sebastian Pipping
@ 2015-05-12 11:41         ` Andrei Borzenkov
  2015-05-15  9:28           ` Sebastian Pipping
  0 siblings, 1 reply; 21+ messages in thread
From: Andrei Borzenkov @ 2015-05-12 11:41 UTC (permalink / raw)
  To: Sebastian Pipping; +Cc: The development of GNU GRUB

В Tue, 12 May 2015 12:41:19 +0200
Sebastian Pipping <sebastian@pipping.org> пишет:

> 
> >> Auto-detection of a filesystem of /dev/mapper/loop0p1 failed.
> >> Try with --recheck.
> >> If the problem persists please report this together with the output of
> >> "/usr/sbin/grub-probe --device-map="/mnt/loop-root/boot/grub/device.map"
> >> --target=fs -v /mnt/loop-root/boot/grub" to <bug-grub@gnu.org>
> >> 1
> >> # mount | fgrep /mnt/loop-root
> >> /dev/mapper/loop0p1 on /mnt/loop-root type ext4
> > 
> > There is no feasible way to map this device back to contained device,
> > short of scanning all maps, finding all partition labels on them and
> > matching maps against labels.
> 
> Why not?
> 
> lsblk manages to detect that /dev/mapper/loop0p1 is a child of /dev/loop0:
> 
> # lsblk | fgrep loop | sed 's| \{23\}||'
> loop0                 7:0    0   100M  0 loop
> └─loop0p1 (dm-9)    254:9    0    96M  0 part  /mnt/loop-root
>

That's what mean - this is direct parent-child. But consider

bor@opensuse:~/build/grub> echo 0 2048 linear /dev/loop0 0 | sudo dmsetup create whole
bor@opensuse:~/build/grub> echo 0 59392 linear /dev/loop0 2048 | sudo dmsetup create part

At this point /dev/mapper/part refers to partition of /dev/mapper/whole
but there is not direct relationships between two that you can
easily discover

bor@opensuse:~/build/grub> sudo dmsetup ls --tree
whole (254:5)
 └─ (7:0)
part (254:6)
 └─ (7:0)

and

bor@opensuse:~/build/grub> sudo ./grub-probe  -t hints_string -m device.map /mnt 
./grub-probe: warning: unknown device type loop0
.

bor@opensuse:~/build/grub> cat device.map 
(hd0) /dev/mapper/whole

but

bor@opensuse:~/build/grub> sudo ./grub-probe  -t hints_string -m device.map /mnt 
./grub-probe: warning: unknown device type loop0
.
--hint='hd0,msdos1' 
bor@opensuse:~/build/grub> cat device.map
(hd0) /dev/loop0

So in common cases it will work and is better as nothing, but there will be corner cases that may fail.

> 
> > Half working solution would be to assume that it is always child map.
> > 
> > Or you can take shortcut and assume that /dev/mapper/XXXXpY is
> > partition of /dev/mapper/XXX but you still will need to verify it.
> > 
> > Patches are welcome.
> 
> I am still wondering: how come it was working in GRUB 2.00 but now
> longer is?
> 

But by you said in previous message that HEAD works? Not sure how
though :)


^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: Future of installing GRUB to LVM volumes (and loop devices)
  2015-05-12 11:41         ` Andrei Borzenkov
@ 2015-05-15  9:28           ` Sebastian Pipping
  2015-05-15  9:34             ` Andrei Borzenkov
  0 siblings, 1 reply; 21+ messages in thread
From: Sebastian Pipping @ 2015-05-15  9:28 UTC (permalink / raw)
  To: grub-devel

On 05/12/2015 01:41 PM, Andrei Borzenkov wrote:
> That's what mean - this is direct parent-child. But consider
> 
> bor@opensuse:~/build/grub> echo 0 2048 linear /dev/loop0 0 | sudo dmsetup create whole
> bor@opensuse:~/build/grub> echo 0 59392 linear /dev/loop0 2048 | sudo dmsetup create part
> 
> At this point /dev/mapper/part refers to partition of /dev/mapper/whole
> but there is not direct relationships between two that you can
> easily discover
> 
> bor@opensuse:~/build/grub> sudo dmsetup ls --tree
> whole (254:5)
>  └─ (7:0)
> part (254:6)
>  └─ (7:0)
> 
> and
> 
> bor@opensuse:~/build/grub> sudo ./grub-probe  -t hints_string -m device.map /mnt 
> ./grub-probe: warning: unknown device type loop0
> .
> 
> bor@opensuse:~/build/grub> cat device.map 
> (hd0) /dev/mapper/whole
> 
> but
> 
> bor@opensuse:~/build/grub> sudo ./grub-probe  -t hints_string -m device.map /mnt 
> ./grub-probe: warning: unknown device type loop0
> .
> --hint='hd0,msdos1' 
> bor@opensuse:~/build/grub> cat device.map
> (hd0) /dev/loop0
> 
> So in common cases it will work and is better as nothing, but there will be corner cases that may fail.

Thanks for that explanation.

I understand that some relations may be hard to impossible to detect.
The cases that I have are plain parent-child relations, though.
It would rock the house to get these cases covered again.

(On a side note, text "unknown device type loop0" looks like a bug to me
since "loop0" is not a type.)


>>> Half working solution would be to assume that it is always child map.
>>>
>>> Or you can take shortcut and assume that /dev/mapper/XXXXpY is
>>> partition of /dev/mapper/XXX but you still will need to verify it.
>>>
>>> Patches are welcome.
>>
>> I am still wondering: how come it was working in GRUB 2.00 but now
>> longer is?
>>
> 
> But by you said in previous message that HEAD works? Not sure how
> though :)

That referred to the '(hd0)'-parameter-with-device-map case, only.

This patch to grml-debootstrap says best what has stopped working:
https://github.com/hartwork/grml-debootstrap/commit/a705ff45c2d053b0d90ec51700e2d25a760106f3

Best,



Sebastian



^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: Future of installing GRUB to LVM volumes (and loop devices)
  2015-05-15  9:28           ` Sebastian Pipping
@ 2015-05-15  9:34             ` Andrei Borzenkov
  2015-05-15 10:42               ` Sebastian Pipping
  0 siblings, 1 reply; 21+ messages in thread
From: Andrei Borzenkov @ 2015-05-15  9:34 UTC (permalink / raw)
  To: The development of GNU GRUB

On Fri, May 15, 2015 at 12:28 PM, Sebastian Pipping
<sebastian@pipping.org> wrote:
>
> I understand that some relations may be hard to impossible to detect.
> The cases that I have are plain parent-child relations, though.
> It would rock the house to get these cases covered again.
>
> (On a side note, text "unknown device type loop0" looks like a bug to me
> since "loop0" is not a type.)
>

It comes from Open Firmware part. May be it should be downgraded to
Info. But as long as it happens in grub-probe only it is OK.

>
>>>> Half working solution would be to assume that it is always child map.
>>>>
>>>> Or you can take shortcut and assume that /dev/mapper/XXXXpY is
>>>> partition of /dev/mapper/XXX but you still will need to verify it.
>>>>
>>>> Patches are welcome.
>>>
>>> I am still wondering: how come it was working in GRUB 2.00 but now
>>> longer is?
>>>
>>
>> But by you said in previous message that HEAD works? Not sure how
>> though :)
>
> That referred to the '(hd0)'-parameter-with-device-map case, only.
>
> This patch to grml-debootstrap says best what has stopped working:
> https://github.com/hartwork/grml-debootstrap/commit/a705ff45c2d053b0d90ec51700e2d25a760106f3
>

Could you please describe your exact configuration that does not work
(including all devices and their relationships) and what does not
work? Sorry if you did it already but I somehow lost track here.


^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: Future of installing GRUB to LVM volumes (and loop devices)
  2015-05-15  9:34             ` Andrei Borzenkov
@ 2015-05-15 10:42               ` Sebastian Pipping
  2015-05-16  3:47                 ` Jordan Uggla
  2015-05-17  8:14                 ` Andrei Borzenkov
  0 siblings, 2 replies; 21+ messages in thread
From: Sebastian Pipping @ 2015-05-15 10:42 UTC (permalink / raw)
  To: The development of GNU GRUB

Hello Andrei,


On 05/15/2015 11:34 AM, Andrei Borzenkov wrote:
> On Fri, May 15, 2015 at 12:28 PM, Sebastian Pipping
> <sebastian@pipping.org> wrote:
>>
>> I understand that some relations may be hard to impossible to detect.
>> The cases that I have are plain parent-child relations, though.
>> It would rock the house to get these cases covered again.
>>
>> (On a side note, text "unknown device type loop0" looks like a bug to me
>> since "loop0" is not a type.)
> 
> It comes from Open Firmware part. May be it should be downgraded to
> Info. But as long as it happens in grub-probe only it is OK.

my point was more about the text of the error message.


>>>>> Half working solution would be to assume that it is always child map.
>>>>>
>>>>> Or you can take shortcut and assume that /dev/mapper/XXXXpY is
>>>>> partition of /dev/mapper/XXX but you still will need to verify it.
>>>>>
>>>>> Patches are welcome.
>>>>
>>>> I am still wondering: how come it was working in GRUB 2.00 but now
>>>> longer is?
>>>>
>>>
>>> But by you said in previous message that HEAD works? Not sure how
>>> though :)
>>
>> That referred to the '(hd0)'-parameter-with-device-map case, only.
>>
>> This patch to grml-debootstrap says best what has stopped working:
>> https://github.com/hartwork/grml-debootstrap/commit/a705ff45c2d053b0d90ec51700e2d25a760106f3
>>
> 
> Could you please describe your exact configuration that does not work
> (including all devices and their relationships) and what does not
> work? Sorry if you did it already but I somehow lost track here.

Sure.

The setup is a single plain partition in an LVM volume.

The following commands reproduce the setup (in RAM if /tmp is tmpfs).
With a plain LVM volume, the error is the same tough.

  # tmpfile="$(mktemp)"
  # echo "${tmpfile}"
  # truncate --size=$((100*1024**2)) "${tmpfile}"
  # loop_device_2="$(losetup --show -f "${tmpfile}")"
  # echo "${loop_device_2}"
  # vgcreate vg "${loop_device_2}"
  # lvcreate --name lv -l 100%free vg
  # sleep 1

  # parted /dev/vg/lv --script mklabel msdos
  # parted /dev/vg/lv --script mkpart primary ext4 4m 100%
  # sleep 1
  # mkfs.ext4 /dev/mapper/vg-lv1
  # mkdir /mnt/lv-root
  # mount /dev/mapper/vg-lv1 /mnt/lv-root
  # mkdir /mnt/lv-root/boot
  # grub-install --boot-directory=/mnt/lv-root/boot /dev/mapper/vg-lv ;
echo $?
  Installing for i386-pc platform.
  grub-install: error: disk
`lvmid/KO9MVd-KNgN-Nbo0-RJb0-pGdK-K7lO-apdskW/rrvxSA-SFY6-P6gy-1jYv-0ims-RmyL-m1KZMB'
not found.
  1

Best,



Sebastian



^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: Future of installing GRUB to LVM volumes (and loop devices)
  2015-05-15 10:42               ` Sebastian Pipping
@ 2015-05-16  3:47                 ` Jordan Uggla
  2015-05-16 14:10                   ` Sebastian Pipping
  2015-05-17  8:14                 ` Andrei Borzenkov
  1 sibling, 1 reply; 21+ messages in thread
From: Jordan Uggla @ 2015-05-16  3:47 UTC (permalink / raw)
  To: The development of GNU GRUB

On Fri, May 15, 2015 at 3:42 AM, Sebastian Pipping
<sebastian@pipping.org> wrote:
> Hello Andrei,
>
>
> On 05/15/2015 11:34 AM, Andrei Borzenkov wrote:
>> On Fri, May 15, 2015 at 12:28 PM, Sebastian Pipping
>> <sebastian@pipping.org> wrote:
>>>
>>> I understand that some relations may be hard to impossible to detect.
>>> The cases that I have are plain parent-child relations, though.
>>> It would rock the house to get these cases covered again.
>>>
>>> (On a side note, text "unknown device type loop0" looks like a bug to me
>>> since "loop0" is not a type.)
>>
>> It comes from Open Firmware part. May be it should be downgraded to
>> Info. But as long as it happens in grub-probe only it is OK.
>
> my point was more about the text of the error message.
>
>
>>>>>> Half working solution would be to assume that it is always child map.
>>>>>>
>>>>>> Or you can take shortcut and assume that /dev/mapper/XXXXpY is
>>>>>> partition of /dev/mapper/XXX but you still will need to verify it.
>>>>>>
>>>>>> Patches are welcome.
>>>>>
>>>>> I am still wondering: how come it was working in GRUB 2.00 but now
>>>>> longer is?
>>>>>
>>>>
>>>> But by you said in previous message that HEAD works? Not sure how
>>>> though :)
>>>
>>> That referred to the '(hd0)'-parameter-with-device-map case, only.
>>>
>>> This patch to grml-debootstrap says best what has stopped working:
>>> https://github.com/hartwork/grml-debootstrap/commit/a705ff45c2d053b0d90ec51700e2d25a760106f3
>>>
>>
>> Could you please describe your exact configuration that does not work
>> (including all devices and their relationships) and what does not
>> work? Sorry if you did it already but I somehow lost track here.
>
> Sure.
>
> The setup is a single plain partition in an LVM volume.
>
> The following commands reproduce the setup (in RAM if /tmp is tmpfs).
> With a plain LVM volume, the error is the same tough.
>
>   # tmpfile="$(mktemp)"
>   # echo "${tmpfile}"
>   # truncate --size=$((100*1024**2)) "${tmpfile}"
>   # loop_device_2="$(losetup --show -f "${tmpfile}")"
>   # echo "${loop_device_2}"
>   # vgcreate vg "${loop_device_2}"
>   # lvcreate --name lv -l 100%free vg
>   # sleep 1
>
>   # parted /dev/vg/lv --script mklabel msdos
>   # parted /dev/vg/lv --script mkpart primary ext4 4m 100%
>   # sleep 1
>   # mkfs.ext4 /dev/mapper/vg-lv1
>   # mkdir /mnt/lv-root
>   # mount /dev/mapper/vg-lv1 /mnt/lv-root
>   # mkdir /mnt/lv-root/boot
>   # grub-install --boot-directory=/mnt/lv-root/boot /dev/mapper/vg-lv ;

That is a nonsensical grub-install command.

You're telling grub-install that you want grub's boot sector and
core.img to be installed to a device that cannot possibly be accessed
by your BIOS (unless you have a BIOS that understands LVM). It may be
that it should be failing with a better error message, or that there
is a better example of what should be working that isn't, but I would
never expect this command to work. I'm not even sure what semantics
you would expect from this command, and if it happened to do what you
wanted it to do in the past I can only imagine that that was a "lucky"
quirk of the implementation.

-- 
Jordan Uggla (Jordan_U on irc.freenode.net)


^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: Future of installing GRUB to LVM volumes (and loop devices)
  2015-05-16  3:47                 ` Jordan Uggla
@ 2015-05-16 14:10                   ` Sebastian Pipping
  2015-05-16 23:33                     ` Jordan Uggla
  0 siblings, 1 reply; 21+ messages in thread
From: Sebastian Pipping @ 2015-05-16 14:10 UTC (permalink / raw)
  To: The development of GNU GRUB

On 16.05.2015 05:47, Jordan Uggla wrote:
>> The setup is a single plain partition in an LVM volume.
>>
>> The following commands reproduce the setup (in RAM if /tmp is tmpfs).
>> With a plain LVM volume, the error is the same tough.
>>
>>   # tmpfile="$(mktemp)"
>>   # echo "${tmpfile}"
>>   # truncate --size=$((100*1024**2)) "${tmpfile}"
>>   # loop_device_2="$(losetup --show -f "${tmpfile}")"
>>   # echo "${loop_device_2}"
>>   # vgcreate vg "${loop_device_2}"
>>   # lvcreate --name lv -l 100%free vg
>>   # sleep 1
>>
>>   # parted /dev/vg/lv --script mklabel msdos
>>   # parted /dev/vg/lv --script mkpart primary ext4 4m 100%
>>   # sleep 1
>>   # mkfs.ext4 /dev/mapper/vg-lv1
>>   # mkdir /mnt/lv-root
>>   # mount /dev/mapper/vg-lv1 /mnt/lv-root
>>   # mkdir /mnt/lv-root/boot
>>   # grub-install --boot-directory=/mnt/lv-root/boot /dev/mapper/vg-lv ;
> 
> That is a nonsensical grub-install command.

I do not approve of calling nonsense on me.  Don't do that.  Thanks.


> You're telling grub-install that you want grub's boot sector and
> core.img to be installed to a device that cannot possibly be accessed
> by your BIOS (unless you have a BIOS that understands LVM). It may be
> that it should be failing with a better error message, or that there
> is a better example of what should be working that isn't, but I would
> never expect this command to work. I'm not even sure what semantics
> you would expect from this command, and if it happened to do what you
> wanted it to do in the past I can only imagine that that was a "lucky"
> quirk of the implementation.

The tempfile and loop device are for (1) not messing with any
producution LVM volume group of the host system and (2) for being able
to write to work with RAM rather than wasting disk cycles.
If that looks wierd to you: it's for reproduction purposes.
As I wrote above "With a plain LVM volume, the error is the same".

For the second half, the host BIOS does not have to be able to boot from
that GRUB since I'm creating a virtual machine image here.  In the mail
starting this thread I explained:

  "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.

  [1] from inside a tool called grmldeboostrap [2], a wrapper around
      deboostrap installing Debian to a given block device"

Best,



Sebastian



^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: Future of installing GRUB to LVM volumes (and loop devices)
  2015-05-16 14:10                   ` Sebastian Pipping
@ 2015-05-16 23:33                     ` Jordan Uggla
  0 siblings, 0 replies; 21+ messages in thread
From: Jordan Uggla @ 2015-05-16 23:33 UTC (permalink / raw)
  To: The development of GNU GRUB

On Sat, May 16, 2015 at 7:10 AM, Sebastian Pipping
<sebastian@pipping.org> wrote:
> On 16.05.2015 05:47, Jordan Uggla wrote:
>>> The setup is a single plain partition in an LVM volume.
>>>
>>> The following commands reproduce the setup (in RAM if /tmp is tmpfs).
>>> With a plain LVM volume, the error is the same tough.
>>>
>>>   # tmpfile="$(mktemp)"
>>>   # echo "${tmpfile}"
>>>   # truncate --size=$((100*1024**2)) "${tmpfile}"
>>>   # loop_device_2="$(losetup --show -f "${tmpfile}")"
>>>   # echo "${loop_device_2}"
>>>   # vgcreate vg "${loop_device_2}"
>>>   # lvcreate --name lv -l 100%free vg
>>>   # sleep 1
>>>
>>>   # parted /dev/vg/lv --script mklabel msdos
>>>   # parted /dev/vg/lv --script mkpart primary ext4 4m 100%
>>>   # sleep 1
>>>   # mkfs.ext4 /dev/mapper/vg-lv1
>>>   # mkdir /mnt/lv-root
>>>   # mount /dev/mapper/vg-lv1 /mnt/lv-root
>>>   # mkdir /mnt/lv-root/boot
>>>   # grub-install --boot-directory=/mnt/lv-root/boot /dev/mapper/vg-lv ;
>>
>> That is a nonsensical grub-install command.
>
> I do not approve of calling nonsense on me.  Don't do that.  Thanks.

I did not intend to insult you, and I'm sorry that my message did.
That said, without a device.map specifying that /dev/mapper/vg-lv will
be seen as a drive from the booting environment, that grub-install
command literally does not make sense. You are telling grub to prepare
an environment that cannot possibly work.

>
>
>> You're telling grub-install that you want grub's boot sector and
>> core.img to be installed to a device that cannot possibly be accessed
>> by your BIOS (unless you have a BIOS that understands LVM). It may be
>> that it should be failing with a better error message, or that there
>> is a better example of what should be working that isn't, but I would
>> never expect this command to work. I'm not even sure what semantics
>> you would expect from this command, and if it happened to do what you
>> wanted it to do in the past I can only imagine that that was a "lucky"
>> quirk of the implementation.
>
> The tempfile and loop device are for (1) not messing with any
> producution LVM volume group of the host system and (2) for being able
> to write to work with RAM rather than wasting disk cycles.
> If that looks wierd to you: it's for reproduction purposes.
> As I wrote above "With a plain LVM volume, the error is the same".

Note that I made no mention of the tempfile or the loop device. The
command makes just as little sense with a plain LVM volume. The part
that makes no sense is installing grub's boot sector to something that
is clearly an LVM volume (without a device.map clarifying that it will
look like a drive at boot).

>
> For the second half, the host BIOS does not have to be able to boot from
> that GRUB since I'm creating a virtual machine image here.  In the mail
> starting this thread I explained:

Using grub-install from a host to install grub for use in a VM (where
the devices involved will be exposed differently to the the VM than
they are to the host) is exactly what the device.map is for. For grub
to properly prepare such a setup (without getting lucky due to a quirk
of the implementation) grub-install needs to know how the devices will
be exposed to the VM.

>
>   "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.
>
>   [1] from inside a tool called grmldeboostrap [2], a wrapper around
>       deboostrap installing Debian to a given block device"

Please correct me if I am wrong, but it seemed like in earlier mails
it was said that this does work if you add a device.map entry like
"(hd0) /dev/mapper/vg-lv". If that is the case, then I don't see
anything wrong (except lack of documentation and poor error messages).

I think that "grub-install --boot-directory=/mnt/lv-root/boot
/dev/mapper/vg-lv" without a device.map should not be expected to
work.

I think that "grub-install --boot-directory=/mnt/lv-root/boot
/dev/mapper/vg-lv" with a device.map clarifying the usage of
/dev/mapper/vg-lv as a virtual drive should work.

If you disagree still, and think that the case without a device.map
should work, I ask how you think that grub should detect that this
device is intended to be used with a VM, and how that VM will expose
the device to the guest?

It's much more common in my experience that users pass non-drive
devices to grub-install (usually /dev/md0) because they are confused,
not because they are preparing a VM where that device will show up as
a drive. I do not think that it is good to always assume that a device
passed to grub-install will be exposed as drive at boot. I think to
make such an assumption, and have grub-install not error out, would
lead to users thinking that "grub-install /dev/mapper/vg-lv" or
"grub-install /dev/md0" on their non virtual machine setups had
succeeded, where it had actually silently broken their ability to
boot.

All of that said, we don't currently protect users from this in all
cases, and we certainly could to a much better job of reporting
helpful error messages, and providing further documentation in the
manual, to help users understand and correct the problem.

-- 
Jordan Uggla (Jordan_U on irc.freenode.net)


^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: Future of installing GRUB to LVM volumes (and loop devices)
  2015-05-15 10:42               ` Sebastian Pipping
  2015-05-16  3:47                 ` Jordan Uggla
@ 2015-05-17  8:14                 ` Andrei Borzenkov
  2015-05-21 21:41                   ` Sebastian Pipping
  1 sibling, 1 reply; 21+ messages in thread
From: Andrei Borzenkov @ 2015-05-17  8:14 UTC (permalink / raw)
  To: Sebastian Pipping; +Cc: The development of GNU GRUB

В Fri, 15 May 2015 12:42:13 +0200
Sebastian Pipping <sebastian@pipping.org> пишет:

> Hello Andrei,
> 
> 
> On 05/15/2015 11:34 AM, Andrei Borzenkov wrote:
> > On Fri, May 15, 2015 at 12:28 PM, Sebastian Pipping
> > <sebastian@pipping.org> wrote:
> >>
> >> I understand that some relations may be hard to impossible to detect.
> >> The cases that I have are plain parent-child relations, though.
> >> It would rock the house to get these cases covered again.
> >>
> >> (On a side note, text "unknown device type loop0" looks like a bug to me
> >> since "loop0" is not a type.)
> > 
> > It comes from Open Firmware part. May be it should be downgraded to
> > Info. But as long as it happens in grub-probe only it is OK.
> 
> my point was more about the text of the error message.
> 
> 
> >>>>> Half working solution would be to assume that it is always child map.
> >>>>>
> >>>>> Or you can take shortcut and assume that /dev/mapper/XXXXpY is
> >>>>> partition of /dev/mapper/XXX but you still will need to verify it.
> >>>>>
> >>>>> Patches are welcome.
> >>>>
> >>>> I am still wondering: how come it was working in GRUB 2.00 but now
> >>>> longer is?
> >>>>
> >>>
> >>> But by you said in previous message that HEAD works? Not sure how
> >>> though :)
> >>
> >> That referred to the '(hd0)'-parameter-with-device-map case, only.
> >>
> >> This patch to grml-debootstrap says best what has stopped working:
> >> https://github.com/hartwork/grml-debootstrap/commit/a705ff45c2d053b0d90ec51700e2d25a760106f3
> >>
> > 
> > Could you please describe your exact configuration that does not work
> > (including all devices and their relationships) and what does not
> > work? Sorry if you did it already but I somehow lost track here.
> 
> Sure.
> 
> The setup is a single plain partition in an LVM volume.
> 
> The following commands reproduce the setup (in RAM if /tmp is tmpfs).
> With a plain LVM volume, the error is the same tough.
> 
>   # tmpfile="$(mktemp)"
>   # echo "${tmpfile}"
>   # truncate --size=$((100*1024**2)) "${tmpfile}"
>   # loop_device_2="$(losetup --show -f "${tmpfile}")"
>   # echo "${loop_device_2}"
>   # vgcreate vg "${loop_device_2}"
>   # lvcreate --name lv -l 100%free vg
>   # sleep 1
> 
>   # parted /dev/vg/lv --script mklabel msdos
>   # parted /dev/vg/lv --script mkpart primary ext4 4m 100%
>   # sleep 1
>   # mkfs.ext4 /dev/mapper/vg-lv1
>   # mkdir /mnt/lv-root
>   # mount /dev/mapper/vg-lv1 /mnt/lv-root
>   # mkdir /mnt/lv-root/boot
>   # grub-install --boot-directory=/mnt/lv-root/boot /dev/mapper/vg-lv ;
> echo $?
>   Installing for i386-pc platform.
>   grub-install: error: disk
> `lvmid/KO9MVd-KNgN-Nbo0-RJb0-pGdK-K7lO-apdskW/rrvxSA-SFY6-P6gy-1jYv-0ims-RmyL-m1KZMB'
> not found.
>   1
> 

Yes, it got broken during code rearrange. grub effectively ignores
device.map at this point:

opensuse:/home/bor/build/grub # ./grub-probe --verbose -t drive -m /tmp/device.map -d /dev/mapper/vg-lv
./grub-probe: info: adding `hd0' -> `/dev/dm-5' from device.map.
./grub-probe: info: /dev/mapper/vg-lv is present in device map.
./grub-probe: info: Looking for /dev/mapper/vg-lv.
./grub-probe: info: /dev/mapper/vg-lv (0) is a parent of /dev/mapper/vg-lv.
./grub-probe: info: /dev/mapper/vg-lv is present in device map.
./grub-probe: info: Looking for /dev/mapper/vg-lv.
./grub-probe: info: /dev/mapper/vg-lv (0) is a parent of /dev/mapper/vg-lv.
(lvmid/Q7vbHZ-MAzV-RtmN-lWJh-I2z3-2Jz2-CJRBgf/NyMQtV-4NgS-uXZ0-3klS-VQ7c-zMVz-butVbK)


Comparing 2.00 and current head:

2.00:

char *
grub_util_get_grub_dev (const char *os_dev)
{
  char *grub_dev = NULL;

  grub_util_pull_device (os_dev);

  switch (grub_util_get_dev_abstraction (os_dev))
    {
#if defined(__linux__) || defined(__FreeBSD__) || defined(__FreeBSD_kernel__)
    case GRUB_DEV_ABSTRACTION_LVM:

      {

and current head:

char *
grub_util_get_grub_dev (const char *os_dev)
{
  char *ret;

  grub_util_pull_device (os_dev);

  ret = grub_util_get_devmapper_grub_dev (os_dev);

So device.map effectively got ignored at this point. I'm not sure
whether it was intentional; Vladimir?

Hmm ... grub_util_get_devmapper_grub_dev() actually always returns
either LVM or LUKS device. At which point we probably have to check
whether device abstraction is really one of them.

Anyway, Sebastian, thanks for report; could you open bug report so it is
not lost?


^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: Future of installing GRUB to LVM volumes (and loop devices)
  2015-05-17  8:14                 ` Andrei Borzenkov
@ 2015-05-21 21:41                   ` Sebastian Pipping
  2015-05-21 21:44                     ` Vladimir 'phcoder' Serbinenko
  0 siblings, 1 reply; 21+ messages in thread
From: Sebastian Pipping @ 2015-05-21 21:41 UTC (permalink / raw)
  To: The development of GNU GRUB

On 17.05.2015 10:14, Andrei Borzenkov wrote:
> Anyway, Sebastian, thanks for report; could you open bug report so it is
> not lost?

I opened a ticket at https://savannah.gnu.org/bugs/?45163 now.

Best,



Sebastian



^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: Future of installing GRUB to LVM volumes (and loop devices)
  2015-05-21 21:41                   ` Sebastian Pipping
@ 2015-05-21 21:44                     ` Vladimir 'phcoder' Serbinenko
  2015-05-21 21:48                       ` Sebastian Pipping
  0 siblings, 1 reply; 21+ messages in thread
From: Vladimir 'phcoder' Serbinenko @ 2015-05-21 21:44 UTC (permalink / raw)
  To: The development of GRUB 2

[-- Attachment #1: Type: text/plain, Size: 560 bytes --]

The bug as filed is invalid. This is WAI as you didn't supply device.map
Le 21 mai 2015 23:42, "Sebastian Pipping" <sebastian@pipping.org> a écrit :

> On 17.05.2015 10:14, Andrei Borzenkov wrote:
> > Anyway, Sebastian, thanks for report; could you open bug report so it is
> > not lost?
>
> I opened a ticket at https://savannah.gnu.org/bugs/?45163 now.
>
> Best,
>
>
>
> Sebastian
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
>

[-- Attachment #2: Type: text/html, Size: 1040 bytes --]

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: Future of installing GRUB to LVM volumes (and loop devices)
  2015-05-21 21:44                     ` Vladimir 'phcoder' Serbinenko
@ 2015-05-21 21:48                       ` Sebastian Pipping
  2015-05-21 22:17                         ` Vladimir 'phcoder' Serbinenko
  0 siblings, 1 reply; 21+ messages in thread
From: Sebastian Pipping @ 2015-05-21 21:48 UTC (permalink / raw)
  To: grub-devel

There is not device map and there was no need for one previously.
I'm happy to add that to the ticket, give me a second.


On 21.05.2015 23:44, Vladimir 'phcoder' Serbinenko wrote:
> The bug as filed is invalid. This is WAI as you didn't supply device.map
> 
> Le 21 mai 2015 23:42, "Sebastian Pipping" <sebastian@pipping.org
> <mailto:sebastian@pipping.org>> a écrit :
> 
>     On 17.05.2015 10:14, Andrei Borzenkov wrote:
>     > Anyway, Sebastian, thanks for report; could you open bug report so
>     it is
>     > not lost?
> 
>     I opened a ticket at https://savannah.gnu.org/bugs/?45163 now.
> 
>     Best,
> 
> 
> 
>     Sebastian
> 
> 
>     _______________________________________________
>     Grub-devel mailing list
>     Grub-devel@gnu.org <mailto:Grub-devel@gnu.org>
>     https://lists.gnu.org/mailman/listinfo/grub-devel
> 
> 
> 
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
> 



^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: Future of installing GRUB to LVM volumes (and loop devices)
  2015-05-21 21:48                       ` Sebastian Pipping
@ 2015-05-21 22:17                         ` Vladimir 'phcoder' Serbinenko
  2015-05-21 22:20                           ` Sebastian Pipping
  2015-05-22  2:25                           ` Andrei Borzenkov
  0 siblings, 2 replies; 21+ messages in thread
From: Vladimir 'phcoder' Serbinenko @ 2015-05-21 22:17 UTC (permalink / raw)
  To: The development of GRUB 2

[-- Attachment #1: Type: text/plain, Size: 1504 bytes --]

Le 21 mai 2015 23:48, "Sebastian Pipping" <sebastian@pipping.org> a écrit :
>
> There is not device map and there was no need for one previously.
> I'm happy to add that to the ticket, give me a second.
>
It worked only by lack of support for devmapper, not because it was
designed so or because it's reasonable to. It was just a bug which happened
to do what you wanted
>
> On 21.05.2015 23:44, Vladimir 'phcoder' Serbinenko wrote:
> > The bug as filed is invalid. This is WAI as you didn't supply device.map
> >
> > Le 21 mai 2015 23:42, "Sebastian Pipping" <sebastian@pipping.org
> > <mailto:sebastian@pipping.org>> a écrit :
> >
> >     On 17.05.2015 10:14, Andrei Borzenkov wrote:
> >     > Anyway, Sebastian, thanks for report; could you open bug report so
> >     it is
> >     > not lost?
> >
> >     I opened a ticket at https://savannah.gnu.org/bugs/?45163 now.
> >
> >     Best,
> >
> >
> >
> >     Sebastian
> >
> >
> >     _______________________________________________
> >     Grub-devel mailing list
> >     Grub-devel@gnu.org <mailto:Grub-devel@gnu.org>
> >     https://lists.gnu.org/mailman/listinfo/grub-devel
> >
> >
> >
> > _______________________________________________
> > Grub-devel mailing list
> > Grub-devel@gnu.org
> > https://lists.gnu.org/mailman/listinfo/grub-devel
> >
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel

[-- Attachment #2: Type: text/html, Size: 2566 bytes --]

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: Future of installing GRUB to LVM volumes (and loop devices)
  2015-05-21 22:17                         ` Vladimir 'phcoder' Serbinenko
@ 2015-05-21 22:20                           ` Sebastian Pipping
  2015-05-22  2:25                           ` Andrei Borzenkov
  1 sibling, 0 replies; 21+ messages in thread
From: Sebastian Pipping @ 2015-05-21 22:20 UTC (permalink / raw)
  To: The development of GNU GRUB

On 22.05.2015 00:17, Vladimir 'phcoder' Serbinenko wrote:
> It worked only by lack of support for devmapper, not because it was
> designed so or because it's reasonable to. It was just a bug which
> happened to do what you wanted

Maybe, but it's a regression now that causes need for patching software
relying on GRUB that worked fine before.



Sebastian



^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: Future of installing GRUB to LVM volumes (and loop devices)
  2015-05-21 22:17                         ` Vladimir 'phcoder' Serbinenko
  2015-05-21 22:20                           ` Sebastian Pipping
@ 2015-05-22  2:25                           ` Andrei Borzenkov
  1 sibling, 0 replies; 21+ messages in thread
From: Andrei Borzenkov @ 2015-05-22  2:25 UTC (permalink / raw)
  To: The development of GRUB 2

В Fri, 22 May 2015 00:17:50 +0200
"Vladimir 'phcoder' Serbinenko" <phcoder@gmail.com> пишет:

> Le 21 mai 2015 23:48, "Sebastian Pipping" <sebastian@pipping.org> a écrit :
> >
> > There is not device map and there was no need for one previously.
> > I'm happy to add that to the ticket, give me a second.
> >
> It worked only by lack of support for devmapper, not because it was
> designed so or because it's reasonable to. It was just a bug which happened
> to do what you wanted

The actual bug is that device.map does not work anymore for
device-mapper devices that LVM happens to be:

opensuse:/home/bor # grub2-install --boot-directory /tmp/x/boot /dev/mapper/vg-lv
Выполняется установка для платформы i386-pc.
grub2-install: ошибка: диск «lvmid/AxK0hm-Xmee-kRPP-dqU3-ycoo-EfcX-Vs3mk2/aot5OT-H8ZH-FXKe-Kz8e-gw6r-PI6v-9IdcGb» не найден.
opensuse:/home/bor # grub2-install --boot-directory /tmp/x/boot '(hd0)'
Выполняется установка для платформы i386-pc.
grub2-install: ошибка: диск «hd0» не найден.
opensuse:/home/bor # cat /tmp/x/boot/grub/device.map 
(hd0) /dev/mapper/vg-lv


This is fixed with patch below. And yes, with this patch it does not
require device.map which itself is a bug and should be fixed but it is
much more intrusive.

From: Andrei Borzenkov <arvidjaar@gmail.com>
Subject: [PATCH] check for abstraction in grub_util_get_devmapper_grub_dev

If user added device to device.map we should respect it.

---
 grub-core/osdep/devmapper/getroot.c | 33 ++++++++++++++++++++-------------
 grub-core/osdep/linux/getroot.c     |  2 +-
 2 files changed, 21 insertions(+), 14 deletions(-)

diff --git a/grub-core/osdep/devmapper/getroot.c b/grub-core/osdep/devmapper/getroot.c
index 0a77a04..f830f9c 100644
--- a/grub-core/osdep/devmapper/getroot.c
+++ b/grub-core/osdep/devmapper/getroot.c
@@ -224,11 +224,14 @@ grub_util_get_devmapper_grub_dev (const char *os_dev)
   uuid = get_dm_uuid (os_dev);
   if (!uuid)
     return NULL;
-  
-  if (strncmp (uuid, "LVM-", sizeof ("LVM-") - 1) == 0)
+
+  switch (grub_util_get_dev_abstraction (os_dev))
     {
+    case GRUB_DEV_ABSTRACTION_LVM:
+      {
 	unsigned i;
 	int dashes[] = { 0, 6, 10, 14, 18, 22, 26, 32, 38, 42, 46, 50, 54, 58};
+
 	grub_dev = xmalloc (grub_strlen (uuid) + 40);
 	optr = grub_stpcpy (grub_dev, "lvmid/");
 	for (i = 0; i < ARRAY_SIZE (dashes) - 1; i++)
@@ -246,19 +249,23 @@ grub_util_get_devmapper_grub_dev (const char *os_dev)
 	return grub_dev;
       }
 
-  if (strncmp (uuid, "CRYPT-LUKS1-", sizeof ("CRYPT-LUKS1-") - 1) == 0)
-    {
-      char *dash;
-      dash = grub_strchr (uuid + sizeof ("CRYPT-LUKS1-") - 1, '-');
-      if (dash)
-	*dash = 0;
-      grub_dev = grub_xasprintf ("cryptouuid/%s",
-				 uuid + sizeof ("CRYPT-LUKS1-") - 1);
+    case GRUB_DEV_ABSTRACTION_LUKS:
+      {
+	char *dash;
+
+	dash = grub_strchr (uuid + sizeof ("CRYPT-LUKS1-") - 1, '-');
+	if (dash)
+	  *dash = 0;
+	grub_dev = grub_xasprintf ("cryptouuid/%s",
+				   uuid + sizeof ("CRYPT-LUKS1-") - 1);
+	grub_free (uuid);
+	return grub_dev;
+      }
+
+    default:
       grub_free (uuid);
-      return grub_dev;
+      return NULL;
     }
-  grub_free (uuid);
-  return NULL;
 }
 
 char *
diff --git a/grub-core/osdep/linux/getroot.c b/grub-core/osdep/linux/getroot.c
index a2e360f..bc79eaa 100644
--- a/grub-core/osdep/linux/getroot.c
+++ b/grub-core/osdep/linux/getroot.c
@@ -1075,7 +1075,7 @@ grub_util_get_grub_dev_os (const char *os_dev)
   switch (grub_util_get_dev_abstraction (os_dev))
     {
       /* Fallback for non-devmapper build. In devmapper-builds LVM is handled
-	 in rub_util_get_devmapper_grub_dev and this point isn't reached.
+	 in grub_util_get_devmapper_grub_dev and this point isn't reached.
        */
     case GRUB_DEV_ABSTRACTION_LVM:
       {
-- 
tg: (f4e62af..) u/devmapper-check-abstraction (depends on: master)


^ permalink raw reply related	[flat|nested] 21+ messages in thread

end of thread, other threads:[~2015-05-22  2:26 UTC | newest]

Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-05-05 16:54 Future of installing GRUB to LVM volumes (and loop devices) Sebastian Pipping
2015-05-05 17:38 ` Andrei Borzenkov
2015-05-06 12:30   ` Sebastian Pipping
2015-05-06 17:16     ` Andrei Borzenkov
2015-05-12 10:41       ` Sebastian Pipping
2015-05-12 11:41         ` Andrei Borzenkov
2015-05-15  9:28           ` Sebastian Pipping
2015-05-15  9:34             ` Andrei Borzenkov
2015-05-15 10:42               ` Sebastian Pipping
2015-05-16  3:47                 ` Jordan Uggla
2015-05-16 14:10                   ` Sebastian Pipping
2015-05-16 23:33                     ` Jordan Uggla
2015-05-17  8:14                 ` Andrei Borzenkov
2015-05-21 21:41                   ` Sebastian Pipping
2015-05-21 21:44                     ` Vladimir 'phcoder' Serbinenko
2015-05-21 21:48                       ` Sebastian Pipping
2015-05-21 22:17                         ` Vladimir 'phcoder' Serbinenko
2015-05-21 22:20                           ` Sebastian Pipping
2015-05-22  2:25                           ` Andrei Borzenkov
2015-05-07  9:35     ` Vladimir 'φ-coder/phcoder' Serbinenko
2015-05-12  9:16       ` Sebastian Pipping

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.