[PATCH] Handle partition devices without corresponding disk devices

[PATCH] Handle partition devices without corresponding disk devices

[Colin Watson]

On Xen (I'm told), it's possible to assign disk images in the host to
things that are named rather like partitions in the guest (e.g.
/dev/sda1), but that don't have an associated disk (e.g. /dev/sda);
indeed, the latter device is nonexistent.  This confuses
grub_util_biosdisk_get_grub_dev.

There's really no other situation in which I think it's terribly
plausible that you might have /dev/sda1 but not /dev/sda, so it seems to
me that in this case we can reasonably treat the apparent "partition" as
a disk in its own right.

2010-09-10  Colin Watson  <cjwatson@ubuntu.com>

	* grub-core/kern/emu/hostdisk.c (find_system_device): Only try
	to convert partition names to disk names if the new `convert'
	parameter is set.
	(grub_util_biosdisk_get_grub_dev): If opening the disk device
	returns GRUB_ERR_UNKNOWN_DEVICE, treat the partition device as a
	disk in its own right.  This can happen with Xen disk images.

=== modified file 'grub-core/kern/emu/hostdisk.c'
--- grub-core/kern/emu/hostdisk.c	2010-07-12 19:13:28 +0000
+++ grub-core/kern/emu/hostdisk.c	2010-09-10 17:24:11 +0000
@@ -1334,12 +1334,15 @@ device_is_wholedisk (const char *os_dev)
 #endif /* defined(__NetBSD__) */
 
 static int
-find_system_device (const char *os_dev, struct stat *st)
+find_system_device (const char *os_dev, struct stat *st, int convert)
 {
   unsigned int i;
   char *os_disk;
 
-  os_disk = convert_system_partition_to_system_disk (os_dev, st);
+  if (convert)
+    os_disk = convert_system_partition_to_system_disk (os_dev, st);
+  else
+    os_disk = xstrdup (os_dev);
   if (! os_disk)
     return -1;
 
@@ -1373,7 +1376,7 @@ grub_util_biosdisk_get_grub_dev (const c
       return 0;
     }
 
-  drive = find_system_device (os_dev, &st);
+  drive = find_system_device (os_dev, &st, 1);
   if (drive < 0)
     {
       grub_error (GRUB_ERR_UNKNOWN_DEVICE,
@@ -1456,7 +1459,32 @@ grub_util_biosdisk_get_grub_dev (const c
     free (name);
 
     if (! disk)
-      return 0;
+      {
+	/* We already know that the partition exists.  Given that we already
+	   checked the device map above, we can only get
+	   GRUB_ERR_UNKNOWN_DEVICE at this point if the disk does not exist.
+	   This can happen on Xen, where disk images in the host can be
+	   assigned to devices that have partition-like names in the guest
+	   but are really more like disks.  */
+	if (grub_errno == GRUB_ERR_UNKNOWN_DEVICE)
+	  {
+	    grub_util_info
+	      ("disk does not exist, so falling back to partition device %s",
+	       os_dev);
+
+	    drive = find_system_device (os_dev, &st, 0);
+	    if (drive < 0)
+	      {
+		grub_error (GRUB_ERR_UNKNOWN_DEVICE,
+			    "no mapping exists for `%s'", os_dev);
+		return 0;
+	      }
+
+	    return make_device_name (drive, -1, -1);
+	  }
+	else
+	  return 0;
+      }
 
     partname = NULL;
     grub_partition_iterate (disk, find_partition);

-- 
Colin Watson                                       [cjwatson@ubuntu.com]

grub-setup inflexibility

[Joey Korkames]

Colin Watson writes:

> On Xen (I'm told), it's possible to assign disk images in the host to
> things that are named rather like partitions in the guest (e.g.
> /dev/sda1), but that don't have an associated disk (e.g. /dev/sda);
> indeed, the latter device is nonexistent.  This confuses
> grub_util_biosdisk_get_grub_dev.
> 
> There's really no other situation in which I think it's terribly
> plausible that you might have /dev/sda1 but not /dev/sda, so it seems to
> me that in this case we can reasonably treat the apparent "partition" as
> a disk in its own right.
> 

Can we make some of these 'decisions' switchable on the command line?
I perform a lot of block device redirections (Xen, iSCSI, 
nbd, etc) or work from live cd's (where / is merely rootfs+unionfs with 
no disk, but /boot is a mounted disk), and grub-setup raises fatal 
objections that I would like to override when _I_ know what devnodes 
the bootblocks and the filesystems belong on.

Some of this probe logic is starting to delve into sysadmin logic, which can 
be terribly obtuse and site-specific. I really don't think the install code 
should be _solely_ implemented in compiled languages - it should be 
possible to install grub2 boot blocks in alternative/scriptable ways like 
it was with grub1 (dd if=/boot/grub/stage1 of=/dev/foo bs=446 count=1 conv=notrunc).
That also lets you install pre-assembled grub cores from 
non-grub2-supported platforms, which is useful for no-physical-access OS 
conversion.

This is somewhat like the "where is stage1" complaints the list has been 
getting, but I'd like to see this minor inflexibility resolved in the 
awesome grub2 framework vs. just asking to keep bugfixing ancient grub1.

thanks for reading
-joey

Re: grub-setup inflexibility

[Vladimir 'φ-coder/phcoder' Serbinenko]

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

On 09/15/2010 08:55 PM, Joey Korkames wrote:
> Colin Watson writes:
>
>> On Xen (I'm told), it's possible to assign disk images in the host to
>> things that are named rather like partitions in the guest (e.g.
>> /dev/sda1), but that don't have an associated disk (e.g. /dev/sda);
>> indeed, the latter device is nonexistent.  This confuses
>> grub_util_biosdisk_get_grub_dev.
>>
>> There's really no other situation in which I think it's terribly
>> plausible that you might have /dev/sda1 but not /dev/sda, so it seems to
>> me that in this case we can reasonably treat the apparent "partition" as
>> a disk in its own right.
>>
>
> Can we make some of these 'decisions' switchable on the command line?
> I perform a lot of block device redirections (Xen, iSCSI, nbd, etc) or
> work from live cd's (where / is merely rootfs+unionfs with no disk,
> but /boot is a mounted disk), and grub-setup raises fatal objections
> that I would like to override when _I_ know what devnodes the
> bootblocks and the filesystems belong on.
>
It looks like you confused grub-setup (called from grub-install) with
grub-mkconfig (called from update-grub). Former accesses only to
/boot/grub and it needs to know about /boot/grub in order to configure
image correctly.
grub-mkconfig on the other hand probes for root but you don't have to
use it. If you prefer the old way of doing things you can simply remove
grub-mkconfig and write grub.cfg yourself.
> Some of this probe logic is starting to delve into sysadmin logic,
> which can be terribly obtuse and site-specific. I really don't think
> the install code should be _solely_ implemented in compiled languages
> - it should be possible to install grub2 boot blocks in
> alternative/scriptable ways like it was with grub1 (dd
> if=/boot/grub/stage1 of=/dev/foo bs=446 count=1 conv=notrunc).
> That also lets you install pre-assembled grub cores from
> non-grub2-supported platforms, which is useful for no-physical-access
> OS conversion.
>
> This is somewhat like the "where is stage1" complaints the list has
> been getting, but I'd like to see this minor inflexibility resolved in
> the awesome grub2 framework vs. just asking to keep bugfixing ancient
> grub1.
>
> thanks for reading
> -joey
>
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>


-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko



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

Re: grub-setup inflexibility

[Joey Korkames]

 [UTF-8]Vladimir 'Æ-coder/phcoder' Serbinenko writes:

> On 09/15/2010 08:55 PM, Joey Korkames wrote:
>> Colin Watson writes:
>>
>>> On Xen (I'm told), it's possible to assign disk images in the host to
>>> things that are named rather like partitions in the guest (e.g.
>>> /dev/sda1), but that don't have an associated disk (e.g. /dev/sda);
>>> indeed, the latter device is nonexistent.  This confuses
>>> grub_util_biosdisk_get_grub_dev.
>>>
>>> There's really no other situation in which I think it's terribly
>>> plausible that you might have /dev/sda1 but not /dev/sda, so it seems to
>>> me that in this case we can reasonably treat the apparent "partition" as
>>> a disk in its own right.
>>>
>>
>> Can we make some of these 'decisions' switchable on the command line?
>> I perform a lot of block device redirections (Xen, iSCSI, nbd, etc) or
>> work from live cd's (where / is merely rootfs+unionfs with no disk,
>> but /boot is a mounted disk), and grub-setup raises fatal objections
>> that I would like to override when _I_ know what devnodes the
>> bootblocks and the filesystems belong on.
>>
> It looks like you confused grub-setup (called from grub-install) with
> grub-mkconfig (called from update-grub). Former accesses only to
> /boot/grub and it needs to know about /boot/grub in order to configure
> image correctly.

Nope, I really do mean grub-setup. The situations I described also confuses
grub-install and grub-mkconfig's sh functions, but I generate my own configs 
so I don't use those. 

I was looking at the grub-setup code and just saw a new option, 
--skip-fs-probe . I'll try that for the livecd edge case and if that 
doesn't fix my problems, then I'll try to get a detailed breakpoint where 
grub-setup gets confused.

Re: grub-setup inflexibility

[Vladimir 'φ-coder/phcoder' Serbinenko]

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

On 09/16/2010 04:02 AM, Joey Korkames wrote:
> [UTF-8]Vladimir 'Æ-coder/phcoder' Serbinenko writes:
>
>> On 09/15/2010 08:55 PM, Joey Korkames wrote:
>>> Colin Watson writes:
>>>
>>>> On Xen (I'm told), it's possible to assign disk images in the host to
>>>> things that are named rather like partitions in the guest (e.g.
>>>> /dev/sda1), but that don't have an associated disk (e.g. /dev/sda);
>>>> indeed, the latter device is nonexistent.  This confuses
>>>> grub_util_biosdisk_get_grub_dev.
>>>>
>>>> There's really no other situation in which I think it's terribly
>>>> plausible that you might have /dev/sda1 but not /dev/sda, so it
>>>> seems to
>>>> me that in this case we can reasonably treat the apparent
>>>> "partition" as
>>>> a disk in its own right.
>>>>
>>>
>>> Can we make some of these 'decisions' switchable on the command line?
>>> I perform a lot of block device redirections (Xen, iSCSI, nbd, etc) or
>>> work from live cd's (where / is merely rootfs+unionfs with no disk,
>>> but /boot is a mounted disk), and grub-setup raises fatal objections
>>> that I would like to override when _I_ know what devnodes the
>>> bootblocks and the filesystems belong on.
>>>
>> It looks like you confused grub-setup (called from grub-install) with
>> grub-mkconfig (called from update-grub). Former accesses only to
>> /boot/grub and it needs to know about /boot/grub in order to configure
>> image correctly.
>
> Nope, I really do mean grub-setup. The situations I described also
> confuses
> grub-install and grub-mkconfig's sh functions, but I generate my own
> configs so I don't use those.
> I was looking at the grub-setup code and just saw a new option,
> --skip-fs-probe . I'll try that for the livecd edge case and if that
> doesn't fix my problems, then I'll try to get a detailed breakpoint
> where grub-setup gets confused.
Then it's a bug. Can you attach the logs of your attempts? Be sure to
use sh -x, --debug and -v when appropriate
>
>
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>


-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko



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

Re: grub-setup inflexibility

[Vladimir 'φ-coder/phcoder' Serbinenko]

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

On 09/16/2010 04:02 AM, Joey Korkames wrote:
> [UTF-8]Vladimir 'Æ-coder/phcoder' Serbinenko writes:
>
>> On 09/15/2010 08:55 PM, Joey Korkames wrote:
>>> Colin Watson writes:
>>>
>>>> On Xen (I'm told), it's possible to assign disk images in the host to
>>>> things that are named rather like partitions in the guest (e.g.
>>>> /dev/sda1), but that don't have an associated disk (e.g. /dev/sda);
>>>> indeed, the latter device is nonexistent.  This confuses
>>>> grub_util_biosdisk_get_grub_dev.
>>>>
>>>> There's really no other situation in which I think it's terribly
>>>> plausible that you might have /dev/sda1 but not /dev/sda, so it
>>>> seems to
>>>> me that in this case we can reasonably treat the apparent
>>>> "partition" as
>>>> a disk in its own right.
>>>>
>>>
>>> Can we make some of these 'decisions' switchable on the command line?
>>> I perform a lot of block device redirections (Xen, iSCSI, nbd, etc) or
>>> work from live cd's (where / is merely rootfs+unionfs with no disk,
>>> but /boot is a mounted disk), and grub-setup raises fatal objections
>>> that I would like to override when _I_ know what devnodes the
>>> bootblocks and the filesystems belong on.
>>>
>> It looks like you confused grub-setup (called from grub-install) with
>> grub-mkconfig (called from update-grub). Former accesses only to
>> /boot/grub and it needs to know about /boot/grub in order to configure
>> image correctly.
>
> Nope, I really do mean grub-setup. The situations I described also
> confuses
> grub-install and grub-mkconfig's sh functions, but I generate my own
> configs so I don't use those.
> I was looking at the grub-setup code and just saw a new option,
> --skip-fs-probe . I'll try that for the livecd edge case and if that
> doesn't fix my problems, then I'll try to get a detailed breakpoint
> where grub-setup gets confused.
>
I've successfully installed GRUB from Ubuntu live CD both using Ubuntu
version and trunk version with root on aufs and /boot being a mounted
/dev/sda1 device. It doesn't seem to be any problem. IF problem persists
for you please supply additional data including the output of
sh -x grub-install --root-directory=.. /dev/sdXY
>
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>


-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko



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