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.
On Tue, Mar 15, 2011 at 2:06 AM, Michael Cree <[email protected]> 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
On Tue, Mar 15, 2011 at 8:10 AM, Linus Torvalds
<[email protected]> 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
On 16/03/2011, at 4:10 AM, Linus Torvalds wrote:
> On Tue, Mar 15, 2011 at 2:06 AM, Michael Cree <[email protected]>
> 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 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 <[email protected]>
> > 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 [email protected] More
> majordomo info at http://vger.kernel.org/majordomo-info.html
--
Open WebMail Project (http://openwebmail.org)
On 16/03/11 05:17, Linus Torvalds wrote:
> On Tue, Mar 15, 2011 at 8:10 AM, Linus Torvalds <[email protected]> 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.
On Wed, Mar 16, 2011 at 12:40 AM, Michael Cree <[email protected]> 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