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

[Graeme Vetterlein]

Thanks for that Thierry,

...so in simple language:

        Doze (W2K) managed to get installed in 4th slot of MBR (slot#3)
        Doze refers to this a partition#1 ... simply because it's the only
one :-)

        Once RH install creates extra partitions for Linux (actually I used
fdisk
        in the example sent ... the problem also occurred with disk druid
and auto-       install)

        The fix is:

                iff doze is the ONLY partition AND it is NOT in slot#0, do
                an fdisk fix BEFORE install ... this move doze to slot#0
then
                the distro can put it's partitions after and not disturb
doze.


Thierry thanks for you help WRT this, lets hope it helps a few people.

        Can you get this info to a place where RH distro builders will see
it?
        I'm assuming you can bring it to the attention of debian devleopers?

        (I didn't want to post your comments back in to the redhat install
        maillist thread without your OK .... feel free to send my comments
to
        anywhere you wish)



        
 

> -----Original Message-----
> From: Thierry Laronde [mailto:address@hidden
> Sent: 27 July 2003 18:16
> To: Graeme Vetterlein
> Cc: address@hidden
> Subject: Re: windows 2000 could not start because the 
> following file is
> mi ssing or corrupt: <windows 2000 root>/system32/ntoskrnl.exe
> 
> 
> 
> 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/
> 


The contents of this email and any attachments are sent for the personal 
attention
of the addressee(s) only and may be confidential.  If you are not the intended
addressee, any use, disclosure or copying of this email and any attachments is
unauthorised - please notify the sender by return and delete the message.  Any
representations or commitments expressed in this email are subject to contract. 
 
ntl Group Limited