Improperly nested partitions, help needed!

Improperly nested partitions, help needed!

[Svante Signell]

Yes,

I should have posted to help-grub, but I am not subscribed to that list,
only grub-devel.

Can somebody please help me with the following problem:
(I have asked on Debian lists, and also filed a bug #594158 but no
response so far).

When installing a new kernel or a new version of grub I get a warning
that /dev/sda1 (windows rescue) and /dev/sda3 (linux root /) are 
improperly nested: /usr/sbin/grub-probe: warn: Discarding improperly nested partition
(hd1,msdos3,msdos1).

What does improperly nested mean: overlapping, or something else?

How to resolve this problem? According to fdisk the sda1 and sda3 partitions are _not_ overlapping:
Additionally, does the same warning have to be repeated so many times for every kernel entry???

#> fdisk -l /dev/sda

Disk /dev/sda: 160.0 GB, 160041885696 bytes
240 heads, 63 sectors/track, 20673 cylinders
Units = cylinders of 15120 * 512 = 7741440 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0xd568d568

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1               1         501     3787528+  1b  Hidden W95 FAT32
/dev/sda2   *         502       15254   111532680    7  HPFS/NTFS
/dev/sda3           15255       15512     1950480   83  Linux
/dev/sda4           15513       20673    39017160    f  W95 Ext'd (LBA)
/dev/sda5           15513       15930     3160048+  83  Linux
/dev/sda6           15931       17320    10508368+  83  Linux
/dev/sda7           17321       20530    24267568+  83  Linux
/dev/sda8           20531       20673     1081048+  82  Linux swap/Solaris


Output when upgrading the kernel:
Setting up linux-image-2.6.32-5-686 (2.6.32-22) ...
Running depmod.
Running update-initramfs.
update-initramfs: Generating /boot/initrd.img-2.6.32-5-686
Examining /etc/kernel/postinst.d.
run-parts: executing /etc/kernel/postinst.d/initramfs-tools
2.6.32-5-686 /boot/vmlinuz-2.6.32-5-686
run-parts: executing /etc/kernel/postinst.d/pm-utils
2.6.32-5-686 /boot/vmlinuz-2.6.32-5-686
run-parts: executing /etc/kernel/postinst.d/zz-update-grub
2.6.32-5-686 /boot/vmlinuz-2.6.32-5-686
/usr/sbin/grub-probe: warn: Discarding improperly nested partition
(hd1,msdos3,msdos1).
(repeated 17 times)

Found background image: moreblue-orbit-grub.png
/usr/sbin/grub-probe: warn: Discarding improperly nested partition
(hd1,msdos3,msdos1).
(repeated 12 times)

Found linux image: /boot/vmlinuz-2.6.32-5-686
Found initrd image: /boot/initrd.img-2.6.32-5-686
/usr/sbin/grub-probe: warn: Discarding improperly nested partition
(hd1,msdos3,msdos1).
(repeated 8 times)

Found linux image: /boot/vmlinuz-2.6.32-3-686
Found initrd image: /boot/initrd.img-2.6.32-3-686
Found linux image: /boot/vmlinuz-2.6.31-1-686
Found initrd image: /boot/initrd.img-2.6.31-1-686
/usr/sbin/grub-probe: warn: Discarding improperly nested partition
(hd1,msdos3,msdos1).
(repeated twice)

Found Windows NT/2000/XP on /dev/sda1
/usr/sbin/grub-probe: warn: Discarding improperly nested partition
(hd1,msdos3,msdos1).
(repeated 8 times)

Found Microsoft Windows XP Home Edition on /dev/sda2
/usr/sbin/grub-probe: warn: Discarding improperly nested partition
(hd1,msdos3,msdos1).
(repeated 8 times)

done

Re: Improperly nested partitions, help needed!

[Isaac Dupree]

On 09/21/10 03:31, Svante Signell wrote:
> I should have posted to help-grub, but I am not subscribed to that list,
> only grub-devel.

Then subscribe to help-grub!  It's not hard to do, and that list gets 
less email than grub-devel these days so you shouldn't be overwhelmed 
with email...

Re: Improperly nested partitions, help needed!

[Grégoire Sutre]

On 09/21/2010 09:31, Svante Signell wrote:

> When installing a new kernel or a new version of grub I get a
> warning that /dev/sda1 (windows rescue) and /dev/sda3 (linux root /)
> are improperly nested: /usr/sbin/grub-probe: warn: Discarding
> improperly nested partition (hd1,msdos3,msdos1).

Assuming that hd1 is sda, this means that (1) grub-probe detects an
MSDOS partition table T in the first sector of sda3, and (2) the first
partition descriptor in T describes a partition that ends after sda3.

It does not say anything about sda1, which is (hd1,msdos1).

Correct detection of MSDOS partition tables is not obvious.  If I read
the code correctly, grub-probe detects an MSDOS partition table (at the
beggining of a disk/partition) if (a) the sector ends with the correct
signature and (b) the first byte of each partition descriptor contains
a valid boot flag.

Actually, for (b), the check that it's a valid boot flag is:

       for (i = 0; i < 4; i++)
	if (mbr.entries[i].flag & 0x7f)
	  return grub_error (GRUB_ERR_BAD_PART_TABLE, "bad boot flag");

Couldn't this be made stronger, with:

       for (i = 0; i < 4; i++)
	if (mbr.entries[i].flag != 0x00 && mbr.entries[i].flag != 0x80)
	  return grub_error (GRUB_ERR_BAD_PART_TABLE, "bad boot flag");

?

> How to resolve this problem?

It's likely that the first sector of sda3 contains useless, leftover
data.  If that's the case (I mean if you are absolutely sure that it's
the case) then you could simply fill this sector with zeroes.

> Additionally, does the same warning have to be repeated so many times
> for every kernel entry???

Well, I guess so, since grub-probe is run independently for each kernel
entry (several times actually).

Grégoire

Re: Improperly nested partitions, help needed!

[Lennart Sorensen]

On Tue, Sep 21, 2010 at 09:31:16AM +0200, Svante Signell wrote:
> I should have posted to help-grub, but I am not subscribed to that list,
> only grub-devel.
> 
> Can somebody please help me with the following problem:
> (I have asked on Debian lists, and also filed a bug #594158 but no
> response so far).
> 
> When installing a new kernel or a new version of grub I get a warning
> that /dev/sda1 (windows rescue) and /dev/sda3 (linux root /) are 
> improperly nested: /usr/sbin/grub-probe: warn: Discarding improperly nested partition
> (hd1,msdos3,msdos1).
> 
> What does improperly nested mean: overlapping, or something else?
> 
> How to resolve this problem? According to fdisk the sda1 and sda3 partitions are _not_ overlapping:
> Additionally, does the same warning have to be repeated so many times for every kernel entry???

It did not say they overlapped.  It said it found a partition table
inside sda3 which is improper given it is not an extended partition
(sda4 is).

> #> fdisk -l /dev/sda
> 
> Disk /dev/sda: 160.0 GB, 160041885696 bytes
> 240 heads, 63 sectors/track, 20673 cylinders
> Units = cylinders of 15120 * 512 = 7741440 bytes
> Sector size (logical/physical): 512 bytes / 512 bytes
> I/O size (minimum/optimal): 512 bytes / 512 bytes
> Disk identifier: 0xd568d568
> 
>    Device Boot      Start         End      Blocks   Id  System
> /dev/sda1               1         501     3787528+  1b  Hidden W95 FAT32
> /dev/sda2   *         502       15254   111532680    7  HPFS/NTFS
> /dev/sda3           15255       15512     1950480   83  Linux
> /dev/sda4           15513       20673    39017160    f  W95 Ext'd (LBA)
> /dev/sda5           15513       15930     3160048+  83  Linux
> /dev/sda6           15931       17320    10508368+  83  Linux
> /dev/sda7           17321       20530    24267568+  83  Linux
> /dev/sda8           20531       20673     1081048+  82  Linux swap/Solaris

Is there any chance you used to have an extended partition as sda3 and
then made a linux partition which is now sda3 and your new extended
partition is sda4?

If so, then there is a chance that the first sector of sda3 contains
the old extended partition table, and grub probe might be detecting that.

One way to check would be to do:

dd if=/dev/sda3 of=/tmp/sda3.mbr bs=512 count=1

Then run 'file /tmp/sda3.mbr'.  If it says partition table, then I think
you have found your problem.

If that is what is happening, then it is a question of whether grub-probe
made a mistake when it scanned for partitions in something not marked
as a valid place to look for partitions.  Of course the quick workaround
in that case is to clear that sector (assuming the filesystem doesn't
use the first sector of the partition, which many filesystems avoid
since it is a handy place for boot loaders and such).

If the filesystem does avoid that part of the partition, that would be a
good reason an old extended partition table would have survived creating
a filesystem.

-- 
Len Sorensen

Re: Improperly nested partitions, help needed!

[Grégoire Sutre]

On 09/21/2010 16:54, Lennart Sorensen wrote:

>> What does improperly nested mean: overlapping, or something else?
>>
>> How to resolve this problem? According to fdisk the sda1 and sda3 partitions are _not_ overlapping:
>> Additionally, does the same warning have to be repeated so many times for every kernel entry???
>
> It did not say they overlapped.  It said it found a partition table
> inside sda3 which is improper given it is not an extended partition
> (sda4 is).

I'm pretty sure that the warning message ``improperly nested'' really
is about partition nesting as discussed e.g. in [1].  It's not about
extended partitions.


But I agree that the problem at hand may come from this:

> If so, then there is a chance that the first sector of sda3 contains
> the old extended partition table, and grub probe might be detecting that.


Grégoire

[1] http://lists.gnu.org/archive/html/grub-devel/2010-01/msg00320.html

Re: Improperly nested partitions, help needed!

[Svante Signell]

On Tue, 2010-09-21 at 10:54 -0400, Lennart Sorensen wrote:
> On Tue, Sep 21, 2010 at 09:31:16AM +0200, Svante Signell wrote:
[...]

> Is there any chance you used to have an extended partition as sda3 and
> then made a linux partition which is now sda3 and your new extended
> partition is sda4?

Yes, if I remember correctly, that's what I did some time ago, when
installing a new disk for /home.

> If so, then there is a chance that the first sector of sda3 contains
> the old extended partition table, and grub probe might be detecting that.
> 
> One way to check would be to do:
> 
> dd if=/dev/sda3 of=/tmp/sda3.mbr bs=512 count=1
> 
> Then run 'file /tmp/sda3.mbr'.  If it says partition table, then I think
> you have found your problem.

Yes, you are right:
# file /tmp/sda3.mbr 
/tmp/sda3.mbr: x86 boot sector; GRand Unified Bootloader, stage1 version
0x3, 1st sector stage2 0xdd29b38; partition 1: ID=0x83, starthead 239,
startsector 63, 35153937 sectors, extended partition table (last)\011,
code offset 0x48

# fdisk -lu /dev/sda

Disk /dev/sda: 160.0 GB, 160041885696 bytes
240 heads, 63 sectors/track, 20673 cylinders, total 312581808 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0xd568d568

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1              63     7575119     3787528+  1b  Hidden W95 FAT32
/dev/sda2   *     7575120   230640479   111532680    7  HPFS/NTFS
/dev/sda3       230640480   234541439     1950480   83  Linux
/dev/sda4       234541440   312575759    39017160    f  W95 Ext'd (LBA)
/dev/sda5       234541503   240861599     3160048+  83  Linux
/dev/sda6       240861663   261878399    10508368+  83  Linux
/dev/sda7       261878463   310413599    24267568+  83  Linux
/dev/sda8       310413663   312575759     1081048+ 82 Linux swap/Solaris

> If that is what is happening, then it is a question of whether grub-probe
> made a mistake when it scanned for partitions in something not marked
> as a valid place to look for partitions.  Of course the quick workaround
> in that case is to clear that sector (assuming the filesystem doesn't
> use the first sector of the partition, which many filesystems avoid
> since it is a handy place for boot loaders and such).

You are the Grub developers, you can tell if Grub does the right thing.

> If the filesystem does avoid that part of the partition, that would be a
> good reason an old extended partition table would have survived creating
> a filesystem.

So the solution is to blank out the first sector of /dev/sda3,

dd if=/dev/null of=/tmp/sda3 bs=512 count=1

to get rid of the warnings? Please confirm the command above is correct.

Thanks Grégoire and Lennart for your help!

Re: Improperly nested partitions, help needed!

[Lennart Sorensen]

On Tue, Sep 21, 2010 at 09:42:14PM +0200, Svante Signell wrote:
> Yes, if I remember correctly, that's what I did some time ago, when
> installing a new disk for /home.
> 
> > If so, then there is a chance that the first sector of sda3 contains
> > the old extended partition table, and grub probe might be detecting that.
> > 
> > One way to check would be to do:
> > 
> > dd if=/dev/sda3 of=/tmp/sda3.mbr bs=512 count=1
> > 
> > Then run 'file /tmp/sda3.mbr'.  If it says partition table, then I think
> > you have found your problem.
> 
> Yes, you are right:
> # file /tmp/sda3.mbr 
> /tmp/sda3.mbr: x86 boot sector; GRand Unified Bootloader, stage1 version
> 0x3, 1st sector stage2 0xdd29b38; partition 1: ID=0x83, starthead 239,
> startsector 63, 35153937 sectors, extended partition table (last)\011,
> code offset 0x48
> 
> # fdisk -lu /dev/sda
> 
> Disk /dev/sda: 160.0 GB, 160041885696 bytes
> 240 heads, 63 sectors/track, 20673 cylinders, total 312581808 sectors
> Units = sectors of 1 * 512 = 512 bytes
> Sector size (logical/physical): 512 bytes / 512 bytes
> I/O size (minimum/optimal): 512 bytes / 512 bytes
> Disk identifier: 0xd568d568
> 
>    Device Boot      Start         End      Blocks   Id  System
> /dev/sda1              63     7575119     3787528+  1b  Hidden W95 FAT32
> /dev/sda2   *     7575120   230640479   111532680    7  HPFS/NTFS
> /dev/sda3       230640480   234541439     1950480   83  Linux
> /dev/sda4       234541440   312575759    39017160    f  W95 Ext'd (LBA)
> /dev/sda5       234541503   240861599     3160048+  83  Linux
> /dev/sda6       240861663   261878399    10508368+  83  Linux
> /dev/sda7       261878463   310413599    24267568+  83  Linux
> /dev/sda8       310413663   312575759     1081048+ 82 Linux swap/Solaris
> 
> > If that is what is happening, then it is a question of whether grub-probe
> > made a mistake when it scanned for partitions in something not marked
> > as a valid place to look for partitions.  Of course the quick workaround
> > in that case is to clear that sector (assuming the filesystem doesn't
> > use the first sector of the partition, which many filesystems avoid
> > since it is a handy place for boot loaders and such).
> 
> You are the Grub developers, you can tell if Grub does the right thing.

I am just a user.

> > If the filesystem does avoid that part of the partition, that would be a
> > good reason an old extended partition table would have survived creating
> > a filesystem.
> 
> So the solution is to blank out the first sector of /dev/sda3,
> 
> dd if=/dev/null of=/tmp/sda3 bs=512 count=1
> 
> to get rid of the warnings? Please confirm the command above is correct.

Not quite.

dd if=/dev/zero of=/tmp/sda3 bs=512 count=1

That should work.  /dev/null is for output.  You need input and a source
of all zeros.

Probably want to save the original you dumped before on some other media
just in case you need to restore it (although I highly doubt it).

-- 
Len Sorensen

Re: Improperly nested partitions, help needed!

[Isaac Dupree]

On 09/21/10 09:13, Isaac Dupree wrote:
> On 09/21/10 03:31, Svante Signell wrote:
>> I should have posted to help-grub, but I am not subscribed to that list,
>> only grub-devel.
>
> Then subscribe to help-grub! It's not hard to do, and that list gets
> less email than grub-devel these days so you shouldn't be overwhelmed
> with email...

hang on, I meant to send this message privately (so as not to spam all 
of you more).  Why does grub-devel set Reply-to:, unlike every other 
technical e-mail-list I'm on?

-Isaac

Re: Improperly nested partitions, help needed!

[Svante Signell]

On Tue, 2010-09-21 at 16:18 -0400, Lennart Sorensen wrote:
[...]
> > So the solution is to blank out the first sector of /dev/sda3,
> > 
> > dd if=/dev/null of=/tmp/sda3 bs=512 count=1
> > 
> > to get rid of the warnings? Please confirm the command above is correct.
> 
> Not quite.
> 
> dd if=/dev/zero of=/tmp/sda3 bs=512 count=1

I see my mistake of output file in my previous mail, it should read /dev/sda3 instead
 of /tmp/sda3, right?

dd if=/dev/zero of=/dev/sda3 bs=512 count=1

> That should work.  /dev/null is for output.  You need input and a source
> of all zeros.
> 
> Probably want to save the original you dumped before on some other media
> just in case you need to restore it (although I highly doubt it).

Thanks!

Re: Improperly nested partitions, help needed!

[Lennart Sorensen]

On Tue, Sep 21, 2010 at 10:29:35PM +0200, Svante Signell wrote:
> I see my mistake of output file in my previous mail, it should read /dev/sda3 instead
>  of /tmp/sda3, right?
> 
> dd if=/dev/zero of=/dev/sda3 bs=512 count=1

Right.

-- 
Len Sorensen

Re: Improperly nested partitions, help needed!

[Grégoire Sutre]

On 09/21/2010 09:42 PM, Svante Signell wrote:

> # file /tmp/sda3.mbr /tmp/sda3.mbr: x86 boot sector; GRand Unified
> Bootloader, stage1 version 0x3, 1st sector stage2 0xdd29b38;
> partition 1: ID=0x83, starthead 239, startsector 63, 35153937
> sectors, extended partition table (last)\011, code offset 0x48

I'm surprised that file is able to tell that this is an extended
partition table.  If we could reliably distinguish MBR partition tables
from EBR ones, then we could prevent GRUB from considering such EBR
partition tables.  But I don't see how a such a distinction could be
made: as far as I know, any EBR partition table could appear in an MBR.

So out of curiosity, I looked a bit deeper at the behavior of the file
command, and I'm afraid that the result of file is not 100% reliable in
this respect: for a partition table with only one used entry, file
detects it as an EBR partition table if the entry is not active, as
shown by this example (one sector in /tmp/sect.bin):

    Device      Boot    Start       End   #sectors  Id  System
/tmp/sect.bin1   *        63  41945714   41945652  83  Linux
/tmp/sect.bin2             0         -          0   0  Empty
/tmp/sect.bin3             0         -          0   0  Empty
/tmp/sect.bin4             0         -          0   0  Empty

$ od -Ax -t x1 /tmp/sect.bin
000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
*
0001b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80 01
0001c0 01 00 83 fe ff ff 3f 00 00 00 34 0a 80 02 00 00
0001d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
*
0001f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa
000200

$ file /tmp/sect.bin
/tmp/sect.bin: x86 boot sector; partition 1: ID=0x83, active, starthead
1, startsector 63, 41945652 sectors, code offset 0x0


Everything looks good.  But after making the partition inactive,
we get:

$ od -Ax -t x1 /tmp/sect.bin
000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
*
0001b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01
0001c0 01 00 83 fe ff ff 3f 00 00 00 34 0a 80 02 00 00
0001d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
*
0001f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa
000200

$ file /tmp/sect.bin
/tmp/sect.bin: x86 boot sector; partition 1: ID=0x83, starthead 1,
startsector 63, 41945652 sectors, extended partition table (last)\011,
code offset 0x0

Still, this partition table may well be contained in an MBR.

Grégoire

Re: Improperly nested partitions, help needed!

[Phillip Susi]

On 9/21/2010 10:54 AM, Lennart Sorensen wrote:
>> How to resolve this problem? According to fdisk the sda1 and sda3 partitions are _not_ overlapping:
>> Additionally, does the same warning have to be repeated so many times for every kernel entry???
> 
> It did not say they overlapped.  It said it found a partition table
> inside sda3 which is improper given it is not an extended partition
> (sda4 is).

This sounds like a bug in grub.  It should not be looking for an EBR
inside a non extended partition, so if there happens to be some old data
there that looks like one, it should not matter.

Re: Improperly nested partitions, help needed!

[Lennart Sorensen]

On Wed, Sep 22, 2010 at 12:19:22PM -0400, Phillip Susi wrote:
> This sounds like a bug in grub.  It should not be looking for an EBR
> inside a non extended partition, so if there happens to be some old data
> there that looks like one, it should not matter.

Well it would appear that it does currently scan for partitions inside
all partition types.  After all msdos partitions tables may only exist
in MBR and extended partitions, but BSD and Solaris slices can exist in
other partitions, and those should be detected.  Perhaps the msdos
partition scanner needs to be tought the special rules that apply to
msdos partition tables as an exception.

-- 
Len Sorensen

Re: Improperly nested partitions, help needed!

[Grégoire Sutre]

On 09/22/2010 18:44, Lennart Sorensen wrote:

> After all msdos partitions tables may only exist in MBR and extended
> partitions

According to which standard?

Grégoire

Re: Improperly nested partitions, help needed!

[Lennart Sorensen]

On Wed, Sep 22, 2010 at 07:08:49PM +0200, Grégoire Sutre wrote:
> On 09/22/2010 18:44, Lennart Sorensen wrote:
>
>> After all msdos partitions tables may only exist in MBR and extended
>> partitions
>
> According to which standard?

Well, I think DOS and common practice.

Can you think of any OS that supports any other cases?

-- 
Len Sorensen

Re: Improperly nested partitions, help needed!

[Vladimir 'φ-coder/phcoder' Serbinenko]

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

On 09/22/2010 07:44 PM, Lennart Sorensen wrote:
> On Wed, Sep 22, 2010 at 07:08:49PM +0200, Grégoire Sutre wrote:
>   
>> On 09/22/2010 18:44, Lennart Sorensen wrote:
>>
>>     
>>> After all msdos partitions tables may only exist in MBR and extended
>>> partitions
>>>       
>> According to which standard?
>>     
> Well, I think DOS and common practice.
>
> Can you think of any OS that supports any other cases?
>
>   
Minix.
Before ranting about anything please (a) check list archives (b) use the
latest version.


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



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

Re: Improperly nested partitions, help needed!

[Brendan Trotter]

Hi,

2010/9/23 Vladimir 'φ-coder/phcoder' Serbinenko <phcoder@gmail.com>:
> On 09/22/2010 07:44 PM, Lennart Sorensen wrote:
>> On Wed, Sep 22, 2010 at 07:08:49PM +0200, Grégoire Sutre wrote:
>>> On 09/22/2010 18:44, Lennart Sorensen wrote:
>>>
>>>> After all msdos partitions tables may only exist in MBR and extended
>>>> partitions
>>>>
>>> According to which standard?
>>>
>> Well, I think DOS and common practice.
>>
>> Can you think of any OS that supports any other cases?
>>
>>
> Minix.

Lennart Sorensen is entirely correct. If both Minix and GRUB are
broken, then both Minix and GRUB should be fixed...


Cheers,

Brendan

Re: Improperly nested partitions, help needed!

[Vladimir 'φ-coder/phcoder' Serbinenko]

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

On 09/22/2010 10:57 PM, Brendan Trotter wrote:
> Hi,
>
> 2010/9/23 Vladimir 'φ-coder/phcoder' Serbinenko <phcoder@gmail.com>:
>   
>> On 09/22/2010 07:44 PM, Lennart Sorensen wrote:
>>     
>>> On Wed, Sep 22, 2010 at 07:08:49PM +0200, Grégoire Sutre wrote:
>>>       
>>>> On 09/22/2010 18:44, Lennart Sorensen wrote:
>>>>
>>>>         
>>>>> After all msdos partitions tables may only exist in MBR and extended
>>>>> partitions
>>>>>
>>>>>           
>>>> According to which standard?
>>>>
>>>>         
>>> Well, I think DOS and common practice.
>>>
>>> Can you think of any OS that supports any other cases?
>>>
>>>
>>>       
>> Minix.
>>     
> Lennart Sorensen is entirely correct. If both Minix and GRUB are
> broken, then both Minix and GRUB should be fixed...
>
>   
subpartition layouts are broken in many different ways, you have a whole
exhibition of it, basically only FreeBSD (not NetBSD) and Solaris are
sane. However since minix subdivides its partition using msdos label
(the worst possible choice if you ask me) we need to cope with it.
Trouble begins when you try to identify the minix partition. Previously
I had the opinion "important is to find all real partitions, and who
cares about ghosts", but since users seem to have phantonophobia bzr
trunk was restricted to check minix subpartition only in partition
having minix type.
> Cheers,
>
> Brendan
>
> _______________________________________________
> 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 --]