Re: windows 2000 could not start because the following file is mi ssing or corrupt: <windows 2000 root>/system32/ntoskrnl.exe

[Thierry Laronde]

Hello,

Let's start analyzing the data.

On Wed, Jul 23, 2003 at 02:04:24PM +0100, Graeme Vetterlein wrote:
> 
> Command (m for help): 
> Disk /dev/sda: 255 heads, 63 sectors, 4427 cylinders
> Units = cylinders of 16065 * 512 bytes
> 
>    Device Boot    Start       End    Blocks   Id  System
> /dev/sda4   *         1      2257  18129321    7  HPFS/NTFS
> 
> Command (m for help): 
> Expert command (m for help): 
> Disk /dev/sda: 255 heads, 63 sectors, 4427 cylinders
> 
> Nr AF  Hd Sec  Cyl  Hd Sec  Cyl    Start     Size ID
>  1 00   0   0    0   0   0    0        0        0 00
>  2 00   0   0    0   0   0    0        0        0 00
>  3 00   0   0    0   0   0    0        0        0 00
>  4 80   1   1    0 254  63 1023       63 36258642 07
> 
> Expert command (m for help): 

Here we have the beginning of the explanation. When `fdisk' was
referring to the partition `3' it was indeed referring to the 4th entry
of the partition table, the 3 first being empty.

So what we must suspect here is that no-one trying to be smart with
other systems has ever imagined that someone could have the spiteful
idea to declare the only partition has a fourth entry, leaving all the
others empty. Hence Linux refers to the only one as /dev/sda4, the empty
ones (/dev/sda1 to /dev/sda3) being treated like null.

This is Microsoft which tries and succeeds to create a mess.

But when one installs another operating system the sole mean is to
declare a partition in the legacy partition table, so creating
partitions that will take the place of the empty ones. But the
bootloader will reorder the partitions in sector increasing order that
will not match the random numbering enforces by the first partition
occupying the last slot in the partition. 

The size of the Windows extended partition is more or less 18 gigabytes.
Windows leaves one cylinder at the beginning, and one cylinder at the
end (the one referred by the 255th head).

This is confirmed by the partition table after installing Linux and
fixing the MBR.

> Command (m for help): p
> 
> Disk /dev/sda: 255 heads, 63 sectors, 4427 cylinders
> Units = cylinders of 16065 * 512 bytes
> 
>    Device Boot    Start       End    Blocks   Id  System
> /dev/sda2   *         1      2257  18129321    7  HPFS/NTFS
> /dev/sda3          2258      2662   3253162+   5  Extended
> /dev/sda4          2663      4427  14177362+  83  Linux
> /dev/sda5          2258      2411   1236973+  83  Linux
> /dev/sda6          2412      2662   2016126   82  Linux swap
> 
> 
> Disk /dev/sda: 255 heads, 63 sectors, 4427 cylinders
> 
> Nr AF  Hd Sec  Cyl  Hd Sec  Cyl    Start     Size ID
>  1 00   0   0    0   0   0    0        0        0 00
>  2 80   1   1    0 254  63 1023       63 36258642 07
>  3 00   0   1 1023 254  63 1023 36258705  6506325 05
>  4 00 254  63 1023 254  63 1023 42765030 28354725 83
>  5 00 254  63 1023 254  63 1023       63  2473947 83
>  6 00 254  63 1023 254  63 1023       63  4032252 82
> 

Here we see that an extended partition has been created for Linux, since
it was not possible to create primary ones due to the fact that Windows
has managed to occupy already almost all the place in the legacy
partition table leaving only head 0 plate, and head 255 plate.

But here the view given is slightly different. 
There is still an empty partition (the first one; so /dev/sda1 is
discarded). But there is also a 4th one (tagged Linux that
seems to be outside of the extended partition, that is a primary one!).

If we use sfdisk on the mbr we have another view :

# /sbin/sfdisk -l ./final-sda.mbr

Disk ./final-sda.mbr: 0 cylinders, 0 heads, 0 sectors/track

Warning: The first partition looks like it was made
  for C/H/S=*/255/63 (instead of 0/0/0).
For this listing I'll assume that geometry.
Units = cylinders of 8225280 bytes, blocks of 1024 bytes, counting from 0

   Device Boot Start     End   #cyls   #blocks   Id  System
./final-sda.mbr1          0       -       0         0    0  Empty
./final-sda.mbr2   *      0+   2256    2257- 18129321    7  HPFS/NTFS
./final-sda.mbr3       2257    2661     405   3253162+   5  Extended
                start: (c,h,s) expected (1023,254,63) found (1023,0,1)
./final-sda.mbr4       2662    4426    1765  14177362+  83  Linux

So it's clear that :

The mess has been produced by the way Windows puts itself in the last
place just in order to occupy all the slots of the partition table.

Linux seems to number (to be verified) the partition in the order of the
partition table while GRUB seems to number them in the logical
increasing sector number. This seems to be the correct way since it is
NOT possible to access the first sector of the partition without
chaining the sizes given for the partitions (it is clear that the primary
Linux partition can not start where it claims it is; it would seem
better for the Linux partition to claim the 255th head, putting itself
fakely after the Windows partition, since claiming the 0th head is
putting itself before; even if these partitions can't be accessed via
CHS, the size is coded on 4 bytes [in _sectors_] so the size is still
relevant).

So the problem is caused by Windows, triggering problems that are linked
to the way Linux numbers the partitions relying partly on a legacy
partition table that is less and less relevant.

So, for GRUB users, in order to access correctly the partitions you must
have the numbers in sector increasing numbers.

The solution for the distributions, at the moment, is probably to fix the
MBR.

There are probably reflexion to be conducted by people writing
partitionning software, due to the fact that M$ is systematicly trying
to break compatibility.

And the solution, in the long term, is to enforce trusts that do not
play fairly to not play at all, that is : don't buy their products!

Cheers,
-- 
Thierry Laronde <address@hidden>
Site Debian Francophone (aka SDF) : http://www.debian-france.org/