Partition check order in fs/partition/check.c?

Partition check order in fs/partition/check.c?

Post by Peter Oberparleite » Wed, 02 Apr 2003 11:40:08



Hi,

I've got a few questions regarding partition checks in fs/partition/*.c of
both Linux 2.4 and 2.5:

I ran into a situation in which an MSDOS partition table was incorrectly
interpreted as an ACORN POWERTEC partition table, resulting in no valid
partition being found. When I looked at fs/partition/acorn.c I noticed that
the powertec partition check is kept fairly generic (adding bytes 1..511 of
the MBR plus an offset and comparing the result with byte 512). In addition
to this, the acorn-specific set of partition checks comes first in the list
in fs/partition/check.c so that statistically, every one in 256 MSDOS
partition tables (they got a fixed pattern at bytes 511 and 512) would be
incorrectly identified as POWERTEC.

Now for the actual questions: what is the reason for the order of partition
checks as it is? Couldn't the acorn tests be moved further down in the list
to solve this particular problem? Also, is there a way to make the acorn test
more specific?

A workaround for this problem would of course be to deselect the
CONFIG_ACORN_PARTITION_POWERTEC option, but that wouldn't work in cases both
acorn and msdos partition tables are used.

Thanks in advance for any kind of insight into this matter.

Regards,
  Peter Oberparleiter
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

Partition check order in fs/partition/check.c?

Post by Russell Kin » Wed, 02 Apr 2003 12:40:10



> Now for the actual questions: what is the reason for the order of partition
> checks as it is?

It's all to do with getting the right detection of the partitioning
scheme.  If the order is wrong, you either can't detect a scheme, or
you mis-detect a scheme every time.

Quote:> Couldn't the acorn tests be moved further down in the list to solve
> this particular problem?

Unfortunately not (on both counts.)

There are several partitioning schemes for Acorn drives (thanks to Acorn
never defining a decent partitioning method, vendors went off and each
did their own thing.)  So, we have the following schemes:

        Scheme                  512-byte sector offset
1.      ICS                     0
2.      PowerTec                0
3.      EESOX                   7
4.      Cumana                  3
5.      ADFS                    3

Schemes 1 through 3 may (or may not) contain valid ADFS information at
sector 3.  Scheme 4 definitely has valid ADFS information at sector 3.
Therefore, to correctly identify all in this list, ADFS must come last
in this list.

However, there are a large percentage of drives which have an old x86
BIOS partition table at sector 0.  To prevent mis-detecting these
drives (which would render the ADFS partition check useless) the x86
BIOS partition check must come after ADFS.

So, there are three dependencies - ICS, PowerTec, EESOX before Cumana,
Cumana before ADFS, ADFS before x86 BIOS.  This means PowerTec must
come before x86 BIOS.

Quote:> Also, is there a way to make the acorn test more specific?

s/acorn/powertec/

We may be able to check that start,start+size lies within the overall
drive size.  Whether this solves the problem will depend upon the contents
of sector 0 for the x86 drives which clash.  However, as drive sizes
increase, this test will become less and less effective (and at 2TiB
it doesn't help at all.)

Another solution would be to pass a kernel parameter like
"partition=hda:msdos,hdb:adfs" to force specific partition interpretation.
However, this could cause issues with hotplug stuff.  Another alternative
is to just turn off the troublesome powertec scheme if you don't have any
drives using that scheme.

--

             http://www.arm.linux.org.uk/personal/aboutme.html

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

Partition check order in fs/partition/check.c?

Post by Peter Oberparleite » Wed, 02 Apr 2003 15:20:26



[info about acorn partitioning schemes]
Ok, thanks for the explanation about the scheme dependencies. I guess adding
a comment like "/* this must come before msdos */" in the respective line of
fs/partition/check.c could cut down in the number of people asking you the
same question over and over again.. :-)

Quote:> > Also, is there a way to make the acorn test more specific?

> s/acorn/powertec/

> We may be able to check that start,start+size lies within the overall
> drive size.  Whether this solves the problem will depend upon the contents
> of sector 0 for the x86 drives which clash.  However, as drive sizes
> increase, this test will become less and less effective (and at 2TiB
> it doesn't help at all.

Hm, what do you think of these additional checks:

1. Check for overlap of partitions
2. Check for number of recognized partitions (i.e. size != 0) > 0
3. Check for struct ptec_partition.unused1, unused2, unused5 == 0 (assuming
they default to zero)

Anyway, thanks again for the info.

Regards,
  Peter Oberparleiter
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

Partition check order in fs/partition/check.c?

Post by Russell Kin » Wed, 02 Apr 2003 15:30:42



> Hm, what do you think of these additional checks:

> 1. Check for overlap of partitions

That's something which should be done for any partitioning method imho.
I have heard of some situations where, on x86 machines, the DOS and
ext2 filesystems overlapped, but somehow managed to keep working for
a considerable period of time.  Then when it all goes wrong, the user
blamed Linux for screwing their DOS/Windows partition.

This might be an acceptable way out of this problem.

Quote:> 2. Check for number of recognized partitions (i.e. size != 0) > 0

If the checksum seems to be correct and you mis-parse an x86 bios
partition table as powertec, chances are that you'll have a non-zero
size word somewhere in that sector.

Quote:> 3. Check for struct ptec_partition.unused1, unused2, unused5 == 0
> (assuming they default to zero)

Unfortunately they don't default to zero.

--

             http://www.arm.linux.org.uk/personal/aboutme.html

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

Partition check order in fs/partition/check.c?

Post by jw schult » Wed, 02 Apr 2003 22:30:19



> Hm, what do you think of these additional checks:

> 1. Check for overlap of partitions

Be very careful here.  While you better not _use_ overlapping
partitions, a partition table with overlapping partitions is
a traditional UNIX default.  It is usually something like

        part    start   length
        a       0       3/8 drive
        b       3/8     1/8 drive
        c       0       whole drive
        d       0       1/3 drive
        e       1/3     1/3 drive
        f       2/3     1/3 drive
        g       1/3     2/3 drive
        h       1/2     1/2 drive

In this way admins wouldn't repartition, just use the default
partitions in suitable combinations.  This actually reduced
the likelihood of overlapping partitions because the
partitioning tools were sometimes confusing causing custom
partition to have 1 cylinder overlaps.  When drives got to be
larger than 2GB these default partition sizes became
increasingly pointless.

--
________________________________________________________________
        J.W. Schultz            Pegasystems Technologies

                Remember Cernan and Schmitt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

1. bad partition table error during Partition Check

I'm finally getting around to updating my Linux system.  I currently have
1.1.59 (I know it's old:).  It was the Slackware distribution.

I'm trying to install 1.2.8 from InfoMagic (August 1995 disks).  
It is also the Slackware distribution.  I've tried the bare and scsi
boot images and they both give me the same error during boot
during the partition check:

Partition Check:
hda: bad partition table
hdb: bad partition table

When I get to the login and login as root and run fdisk, it spews out lots
of stuff, but nothing related to my actual partitions.

I can still boot my 1.1.59 disks fine, so I know it's not really a
problem with my partition tables.  Also, everything checks out fine under DOS.

My system has a Promise DC-4030VL caching IDE controller.  2 512M IDE drives.
Adaptec AHA 2842 VL SCSI controler with a SCSI CD-ROM.

Any clues to what this problem really is and how to fix it would be
appreciated.

Thanks in advance,
Wayne Mock

BTW, the same thing happened with the RedHat distribution with 1.2.11.

2. install problem

3. Partition check at boot time & fdisk partition table don't agree

4. member of too many groups

5. bad partition table error during Partition Check

6. Solaris 8 install behind NAT box

7. Compile warning in fs/partitions/check.c

8. "One thing that looks definite is....Mac OS X Server in January..."

9. Patch for file fs/partitions/check.c

10. Further madness in fs/partitions/check.c?

11. Remove unused variables from fs/partitions/check.c

12. [TRIVIAL] 2.5.30 - Build error in fs/partition/check.c

13. 2.5.38 fs/partitions/check.c