Alpha no longer recognises certain partition tables (v2.6.38)

Alpha no longer recognises certain partition tables (v2.6.38)

[Michael Cree]

v2.6.38 boot reports it can't recognise the partition table on the 
system disk on my Alpha and panics when it can't find the root device.

It worked at v2.6.38-rc7.

While I haven't done a bisect to fully verify I nevertheless suggest the 
following patch as the likely cause:

1eafbfe Fix corrupted OSF partition table parsing

Cheers
Michael.

Re: Alpha no longer recognises certain partition tables (v2.6.38)

[Linus Torvalds]

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

On Tue, Mar 15, 2011 at 2:06 AM, Michael Cree <mcree@orcon.net.nz> wrote:
> v2.6.38 boot reports it can't recognise the partition table on the system
> disk on my Alpha and panics when it can't find the root device.
>
> It worked at v2.6.38-rc7.
>
> While I haven't done a bisect to fully verify I nevertheless suggest the
> following patch as the likely cause:
>
> 1eafbfe Fix corrupted OSF partition table parsing

That sounds likely. What does something like the attached do? In
particular, what's the printed-out value of the OSF npartitions thing?

Also, it's quite possible that we should raise the value of
MAX_OSF_PARTITIONS. If I checked it right, the d_partitions[] array
starts at byte offset 148 in the sector, and it's 16 bytes in size, so
there _could_ be up to 22 partitions there. The fact that we had
defined the 'struct disklabel' to only contain 8 partitions is I think
from documentation, not a technical "there can be only eight".

                                  Linus

[-- Attachment #2: patch.diff --]
[-- Type: text/x-patch, Size: 595 bytes --]

 fs/partitions/osf.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/partitions/osf.c b/fs/partitions/osf.c
index be03a0b..fcab201 100644
--- a/fs/partitions/osf.c
+++ b/fs/partitions/osf.c
@@ -68,8 +68,8 @@ int osf_partition(struct parsed_partitions *state)
 	}
 	npartitions = le16_to_cpu(label->d_npartitions);
 	if (npartitions > MAX_OSF_PARTITIONS) {
-		put_dev_sector(sect);
-		return 0;
+		printk("OSF: %u partitions\n", npartitions);
+		npartitions = MAX_OSF_PARTITIONS;
 	}
 	for (i = 0 ; i < npartitions; i++, partition++) {
 		if (slot == state->limit)

Re: Alpha no longer recognises certain partition tables (v2.6.38)

[Linus Torvalds]

On Tue, Mar 15, 2011 at 8:10 AM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> Also, it's quite possible that we should raise the value of
> MAX_OSF_PARTITIONS. If I checked it right, the d_partitions[] array
> starts at byte offset 148 in the sector, and it's 16 bytes in size, so
> there _could_ be up to 22 partitions there.

Actually, I think it's byte offset 148 in the structure, but the
structure is at offset 64 in the partition sector, so I think that
leaves room for just 18 partitions in one 512-byte sector.

Of course, we do end up reading a whole page, so historically we've
been able to see even more when the sector is aligned right (and it
is, it's the first sector). So by mistake we could have accepted many
more partitions and it just "worked" because we never actually checked
any limits.

                        Linus

Re: Alpha no longer recognises certain partition tables (v2.6.38)

[Michael Cree]

On 16/03/2011, at 4:10 AM, Linus Torvalds wrote:
> On Tue, Mar 15, 2011 at 2:06 AM, Michael Cree <mcree@orcon.net.nz>  
> wrote:
>> v2.6.38 boot reports it can't recognise the partition table on the  
>> system
>> disk on my Alpha and panics when it can't find the root device.
>>
>> It worked at v2.6.38-rc7.
>>
>> While I haven't done a bisect to fully verify I nevertheless  
>> suggest the
>> following patch as the likely cause:
>>
>> 1eafbfe Fix corrupted OSF partition table parsing
>
> That sounds likely. What does something like the attached do? In
> particular, what's the printed-out value of the OSF npartitions thing?
>
> Also, it's quite possible that we should raise the value of
> MAX_OSF_PARTITIONS. If I checked it right, the d_partitions[] array
> starts at byte offset 148 in the sector, and it's 16 bytes in size, so
> there _could_ be up to 22 partitions there. The fact that we had
> defined the 'struct disklabel' to only contain 8 partitions is I think
> from documentation, not a technical "there can be only eight".

I am not able to run the patch until much later today but I think the  
number of partitions is the issue.  I have three disks, all with bsd  
type partition tables, and the kernel sees the partition tables of two  
of them (they both have fewer than five partitions) but the system  
disk has about nine (or it might be ten) partitions.  I didn't know  
the limit when creating them some time ago and assumed fdisk would  
flag an error if the number of permitted partitions was exceeded!   
What's more it worked with recent kernels until now.

I'll give the patch a whirl later (my) today.

Cheers
Michael.

Re: Alpha no longer recognises certain partition tables (v2.6.38)

[Dialup Jon Norstog]

To the lists:

Pardon me for a userland-type question, but is this going to be a problem if I
want to mount advfs disks? Or even some old OSF1 disks (that have some quite
valuable GIS covers on them)?  Just curious.

jn


On Wed, 16 Mar 2011 14:23:43 +1300, Michael Cree wrote
> On 16/03/2011, at 4:10 AM, Linus Torvalds wrote:
> > On Tue, Mar 15, 2011 at 2:06 AM, Michael Cree <mcree@orcon.net.nz>  
> > wrote:
> >> v2.6.38 boot reports it can't recognise the partition table on the  
> >> system
> >> disk on my Alpha and panics when it can't find the root device.
> >>
> >> It worked at v2.6.38-rc7.
> >>
> >> While I haven't done a bisect to fully verify I nevertheless  
> >> suggest the
> >> following patch as the likely cause:
> >>
> >> 1eafbfe Fix corrupted OSF partition table parsing
> >
> > That sounds likely. What does something like the attached do? In
> > particular, what's the printed-out value of the OSF npartitions thing?
> >
> > Also, it's quite possible that we should raise the value of
> > MAX_OSF_PARTITIONS. If I checked it right, the d_partitions[] array
> > starts at byte offset 148 in the sector, and it's 16 bytes in size, so
> > there _could_ be up to 22 partitions there. The fact that we had
> > defined the 'struct disklabel' to only contain 8 partitions is I think
> > from documentation, not a technical "there can be only eight".
> 
> I am not able to run the patch until much later today but I think 
> the  number of partitions is the issue.  I have three disks, all 
> with bsd  type partition tables, and the kernel sees the partition 
> tables of two  of them (they both have fewer than five partitions) 
> but the system  disk has about nine (or it might be ten) partitions. 
>  I didn't know  the limit when creating them some time ago and 
> assumed fdisk would  flag an error if the number of permitted 
> partitions was exceeded!   What's more it worked with recent kernels 
> until now.
> 
> I'll give the patch a whirl later (my) today.
> 
> Cheers
> Michael.
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-
> alpha" in the body of a message to majordomo@vger.kernel.org More 
> majordomo info at  http://vger.kernel.org/majordomo-info.html


--
Open WebMail Project (http://openwebmail.org)

Re: Alpha no longer recognises certain partition tables (v2.6.38)

[Michael Cree]

On 16/03/11 05:17, Linus Torvalds wrote:
> On Tue, Mar 15, 2011 at 8:10 AM, Linus Torvalds <torvalds@linux-foundation.org>  wrote:
>>
>> Also, it's quite possible that we should raise the value of
>> MAX_OSF_PARTITIONS. If I checked it right, the d_partitions[] array
>> starts at byte offset 148 in the sector, and it's 16 bytes in size, so
>> there _could_ be up to 22 partitions there.
>
> Actually, I think it's byte offset 148 in the structure, but the
> structure is at offset 64 in the partition sector, so I think that
> leaves room for just 18 partitions in one 512-byte sector.
>
> Of course, we do end up reading a whole page, so historically we've
> been able to see even more when the sector is aligned right (and it
> is, it's the first sector). So by mistake we could have accepted many
> more partitions and it just "worked" because we never actually checked
> any limits.

OK, I've fallen for that and created too many partitions on my system 
disk.  When using your patch dmesg reports:

[    7.511714] sd 1:0:0:0: [sdb] 2930277168 512-byte logical blocks: 
(1.50 TB/1.36 TiB)
[    7.551753] sd 1:0:0:0: [sdb] Write Protect is off
[    7.572261] sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00
[    7.591792] sd 1:0:0:0: [sdb] Write cache: enabled, read cache: 
enabled, doesn't support DPO or FUA
[    7.633785] OSF: 10 partitions
[    7.654292]  sdb: sdb1 sdb2 sdb3 sdb4 sdb5 sdb6 sdb7 sdb8
[    7.675777] sd 1:0:0:0: [sdb] Attached SCSI disk

I could get it back to eight partitions but it will require copying the 
largest partition to another disk and back again as that partition does 
not meet the conditions for resizing.  Part of the reason for so many 
partitions was a brilliant scheme (or so it seemed at the time) when I 
repartitioned the disk in a manner that enabled me to do an efficient 
"in-place" repartitioning of an already well used disk.

Cheers
Michael.

Re: Alpha no longer recognises certain partition tables (v2.6.38)

[Linus Torvalds]

On Wed, Mar 16, 2011 at 12:40 AM, Michael Cree <mcree@orcon.net.nz> wrote:
>
> OK, I've fallen for that and created too many partitions on my system disk.
>  When using your patch dmesg reports:
>
> [    7.511714] sd 1:0:0:0: [sdb] 2930277168 512-byte logical blocks: (1.50
> TB/1.36 TiB)
> [    7.551753] sd 1:0:0:0: [sdb] Write Protect is off
> [    7.572261] sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00
> [    7.591792] sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled,
> doesn't support DPO or FUA
> [    7.633785] OSF: 10 partitions
> [    7.654292]  sdb: sdb1 sdb2 sdb3 sdb4 sdb5 sdb6 sdb7 sdb8
> [    7.675777] sd 1:0:0:0: [sdb] Attached SCSI disk

Ok, no problem.

I'll increase the value of OSF_MAX_PARTITIONS to 18 (which is what
fits in a 512 byte sector), and mark it for back-porting into stable
too.

Thanks for testing.

> I could get it back to eight partitions but it will require copying the
> largest partition to another disk and back again as that partition does not
> meet the conditions for resizing.

Oh, no need for that. There really isn't any real technical limit for
the "limit to 8 partitions", and we don't cause regressions.

                              Linus

Re: Alpha no longer recognises certain partition tables (v2.6.38)

[Linus Torvalds]

On Wed, Mar 16, 2011 at 12:40 AM, Michael Cree <mcree@orcon.net.nz> wrote:
>
> OK, I've fallen for that and created too many partitions on my system disk.
>  When using your patch dmesg reports:
>
> [    7.511714] sd 1:0:0:0: [sdb] 2930277168 512-byte logical blocks: (1.50
> TB/1.36 TiB)
> [    7.551753] sd 1:0:0:0: [sdb] Write Protect is off
> [    7.572261] sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00
> [    7.591792] sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled,
> doesn't support DPO or FUA
> [    7.633785] OSF: 10 partitions
> [    7.654292]  sdb: sdb1 sdb2 sdb3 sdb4 sdb5 sdb6 sdb7 sdb8
> [    7.675777] sd 1:0:0:0: [sdb] Attached SCSI disk

Ok, no problem.

I'll increase the value of OSF_MAX_PARTITIONS to 18 (which is what
fits in a 512 byte sector), and mark it for back-porting into stable
too.

Thanks for testing.

> I could get it back to eight partitions but it will require copying the
> largest partition to another disk and back again as that partition does not
> meet the conditions for resizing.

Oh, no need for that. There really isn't any real technical limit for
the "limit to 8 partitions", and we don't cause regressions.

                              Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-alpha" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Jakestevens hitel cégkorlátozódik a jegyzett tőke.

[Jakestevens]

Jakestevens hitel cég korlátozódik a jegyzett tőke. Kínálunk hitelek és a
pénzügyi
szolgáltatások mindenféle. A hitel változó üzleti személyes hosszú vagy
rövid távon. Feltételek kedvező kamatozású (2%). A hitel folyamat
nagyon gyors és megbízható garanciákkal. További információ a
szolgáltatások, az üzenet számunkra a hitelösszeg kell a következő e-mail címét.

jakestevensloanfirm@gmail.com

--
To unsubscribe from this list: send the line "unsubscribe linux-alpha" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html