[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Prevention and Recovery of XP Dual Boot Problems



Credit where credit is due.. This is a great and well written document,
thanks to the writers and the people who are publishing it

The only sections i'd like to see added is "Set your BIOS disk mode to LBA"
to prevention (which works for some ppl, very new bios'es only have auto/chs
though), and i would also love to see a small chapter on "How did this bug
ever happen" (From what i've been able to gather, it is caused by changes in
the 2.6.x kernel where it was decided HD layout translation should be
handled in user space (which obviously we didn't do..) which causes this
problem)


----- Original Message ----- 
From: "Jack Aboutboul" <jaboutboul speakeasy net>
To: <fedora-devel-list redhat com>
Sent: Tuesday, May 25, 2004 23:25
Subject: Prevention and Recovery of XP Dual Boot Problems


> This is the whole document for those who didnt get it.
>
> <---BEGIN--->
>
> Dual Booting Issues With Fedora Core 2 and Windows: Prevention & Recovery
>
> NOTICE: Please read this document in its entirety.
>
> This guide was inspired by the solution developed by Radu Cornea and
> Alexandre Oliva in this thread:
> http://www.redhat.com/archives/fedora-test-list/2004-May/msg02114.html .
> This guide aims to integrate the original solution with the refinements
> evolved in that thread.  This guide offers an explanation of why the
> refinements are beneficial and some workarounds to problems that may
prevent
> the uninitiated from using the solution. It also provides a means of
> preventing the problem entirely.
>
> Primer:
>
>         There is a bug in Fedora Core 2 that causes the hard disk geometry
as
> reported in the partition table to be altered during installation.  This
> change may cause Windows boot failure.  Although this bug is severe, it is
> recoverable and no data should be lost.  It is important not to panic if
and
> when this happens so you do not cause further problems or cause actual
loss
> of data in the process of recovering from the error.
>
> Prevention:
>
>         This bug can be avoided entirely by using some preventative steps
while
> installing Fedora Core 2.  Thanks go out to Cero (cero coolnetworx net)
for
> discovery and testing of this solution.
>
>         To avoid the hard disk geometry to be altered you may enter it
manually
> during installation by using the hdN=<drive geometry> parameter (where N
is
> the letter representing the drive with the MBR you will use).  To discover
> the current geometry before installing Fedora Core 2 you should use a
> utility that can read the drive geometry as reported in the partition
table.
> It is important to understand that some tools may not be reporting the
> actual data from this location, but, rather, some derived value, so your
> surest way is to use the fdisk utility.  You can get this information by
> following these steps.
>
> Note: This example will assume you are looking at /dev/hda, which is the
> master on the primary IDE interface. If your MBR is located on another
> device you should use its name (eg: /dev/hde )
>
> Download and burn the Fedora Core 2 Rescue CD.
>
> Boot from the Rescue CD (there is no need to start networking or mount
> drives)
>
> Issue the command: fdisk -l /dev/hda   to print the current partition
table
> to screen in non-interactive mode.
>
> Write down the drive geometry as reported at the beginning of the output
> from fdisk. This is reported as number of Cylinders, Heads, and Sectors
> (hence the name CHS).
>
> You can now reboot the computer by simultaneously holding down the keys
> Ctrl-Alt-Delete.
>
> You can now boot the Fedora Core 2 installation CD. At the first menu
prompt
> you should now choose to run the installer with the known geometry.
>
> Example: linux hda=14593,255,63
>
>         The installer should now run normally and not alter your partition
table
> geometry entry.  If, for any reason, this geometry should be changed
> regardless of this preventative step, please use the recovery steps to
> correct the geometry of the drive as reported by the partition table.
>
>
> Recovery:
>
>         You have installed Fedora Core 2 and find that you cannot boot
Windows.
> Typically the boot process will terminate with the words
>
>         Rootnoverify(hd0,0)
>         Chainloader +1
>
>         These are the boot parameters from your Grub configuration.  The
parameters
> are likely to be correct, but Windows fails to boot because Fedora Core 2
> altered the hard disk geometry as reported by the drives partition table.
>
> IMPORTANT: Do not panic and do not begin using multiple tools in an
attempt
> to correct this error. Automated tools can be very dangerous. The actual
> changes that need to be made are minor and benign.  By running 3rd party
> applications to recover a bootable Windows installation may cause you to
> lose your data.  You have been warned.
>
>         For those who are technically inclined I include here a brief
explanation
> of what is going on.  The drive has not been damaged and your partition
> table is fine.  The problem is that Windows demands a "sane" CHS table.
> This table has been altered by Fedora Cores installer and Windows hangs.
> Luckily, the actual table, in LBA format, is not  corrupted.  For those
> seeing a strange partition table, take note that you are probably looking
at
> the table in CHS values and these values are derived from the geometry.
The
> GNU/Linux operating system does not use these values and operates purely
> with LBA values.  Windows should not be using CHS either, but for some
> reason it at least checks this geometry and can be prevented from booting
by
> them being bad.  Changing the drive geometry changes the CHS partition
table
> because this is a virtualization of the true state of affairs on the drive
> which are best described as being mystical.  Think of CHS geometry as a
> compass.  If you change the geometry you have recalibrated where the
> needles reference point is and you are no longer looking at true north.
>
>         The solution to this problem is very simple, but it may confuse
people
> because most people will question why they are seeing strange values
> reported from their partition table in CHS format.  If you do not trust
this
> solution or your ability to follow these steps then you should stop and
seek
> hard disk recovery consulting services.  The Fedora Project is in no way
> liable for any data loss and this guide is offered without guarantees.
You
> are taking responsibility for what happens.  Now, let us go through the
> solution.
>
>         Because only the drive geometry is altered there is no need for
manual
> intervention in the form of discovering and entry of partition
information.
> The information in your partition table is correct.  However, you need to
> alter the geometry entry and normally this would require you to re-enter
the
> partition table by hand using a tool like fdisk.  This is where the
> application sfdisk comes to the rescue. Sfdisk can be very powerful in
> non-interactive mode, it can output information that can be used as input
> elsewhere, and it can accept data as input at run-time.  This makes sfdisk
> ideal for this solution because you can ask it to read the partition table
> and deliver the result in a way that itself can write back when you tell
it
> to change your drive geometry.  This makes the process fast and less prone
> to human error as very few values need to be supplied.  The solution can
be
> summed up in a single line with two commands:
>
>         sfdisk -d /dev/hda | sfdisk --no-reread -H255 /dev/hda
>
>         So that the reader may better understand what is going on here,
lets go
> through what each section does and what the parameters mean.
>
> sfdisk -d /dev/hda
>
> This part runs sfdisk non-interactively and dumps the partition table in a
> format that sfdisk can also use for input (as we are doing).  Try this
> command by itself to see your partition table as it is very safe.  You
will
> want to check to check for warnings in the output.  Warnings pose a
problem
> because they interfere with the use of this data as input. Output
containing
> a warning may look like the example below:
>
> $ sfdisk -d /dev/hda
> Warning: extended partition does not start at a cylinder boundary.
> DOS and Linux will interpret the contents differently.
> # partition table of /dev/hda
> unit: sectors
>
> /dev/hda1 : start=       63, size= 16771797, Id= 7, bootable
> /dev/hda2 : start= 16771860, size=217632555, Id= f
> /dev/hda3 : start=        0, size=        0, Id= 0
> /dev/hda4 : start=        0, size=        0, Id= 0
> /dev/hda5 : start= 16771923, size=104856192, Id= 7
> /dev/hda6 : start=121628178, size=112776237, Id= 7
>
>
> For reasons unknown, using the option -- quiet does not suppress all
> warnings so it becomes the task of the user to discover a way to still use
> the output as input.  The simplest way is to write the output to a plain
> text file, editing out the warning in that text file, and using the edited
> text file as the input, thus:
>
> sfdisk -d /dev/hda > MyPartitionTable.txt
>         editing MyPartitionTable.txt to remove the warnings, saving the
edited
> text, and
> cat MyPartitionTable.txt | sfdisk --no-reread -H255 /dev/hda
>
> The output from "sfdisk -d /dev/hda" should begin like this (this is the
> edited version of the example given before):
>
> # partition table of /dev/hda
> unit: sectors
>
> /dev/hda1 : start=       63, size= 16771797, Id= 7, bootable
> /dev/hda2 : start= 16771860, size=217632555, Id= f
> /dev/hda3 : start=        0, size=        0, Id= 0
> /dev/hda4 : start=        0, size=        0, Id= 0
> /dev/hda5 : start= 16771923, size=104856192, Id= 7
> /dev/hda6 : start=121628178, size=112776237, Id= 7
>
>         Note that "cat MyPartitionTable.txt" takes the place of "sfdisk -d
> /dev/hda" as these are now equivalent. In this case the warning portion
has
> been stripped, preserving the needed data used by sfdisk in step two of
the
> command.
>
> sfdisk --no-reread -H255 /dev/hda
>
>         This portion of the two-part command performs the actual change to
your
> hard disk.  This main operation is in -H255. This tells sfdisk to write a
> head count of 255 into the drive geometry.  This command executed by
itself
> would ask for user input of the partition table (just like fdisk).
However,
> by piping the table we just read in the first command, this is avoided and
> work is saved and we know the data is correct (or, at least, unchanged).
> This is why sfdisk is used.
>
>         The --no-reread option allows the command to run even when the
disk has a
> mounted partition.  Some users may find they need to further force the
> operation to complete. This is done by using --force (sfdisk --no-reread
> --force -H255 /dev/hda).
>
>         In this example we are only changing the number of heads in the
geometry.
> If you know the correct number of cylinders before the Fedora Core
> installation changed these values you may also write back this number.
An
> example with 14,593 cylinders is provided below.
>
> sfdisk -d /dev/hda | sfdisk --no-reread -H255 -C14593 /dev/hda
>
>         The number of reported sectors (S) should not have changed and
remained as
> 63.
>
>         This is the part most likely to be met with the question "if I
change the
> number of heads, must I not also change the the number of cylinders?"  The
> answer to this question is "no."  When the geometry was changed the number
> of heads changed from 255 to 16 and the number of cylinders was increased
to
> compensate.  As long as the values are large everything should be ok.
Only
> the pedantic need worry about changing the number of cylinders manually.
If
> you do not know the value from before you are best off not supplying this
> number.
>
>         By using this method there is no need, and indeed you should not,
run a
> program that wipes the MBR (like fdisk /mbr).  Doing so will cause you to
> lose the Grub pointer installed in the MBR and you will have to use the
> Recovery CD to regain access to your Fedora Core installation.
>
>         Updating Grub after installation seems to have no effect on the
drive
> geometry as the problem seems strictly limited to the Fedora Core
installer.
>
> Good luck and join us on the IRC at #fedora on irc.freenode.net for any
> questions you have or contributions to the community you wish to make.
>
>
> -- 
> fedora-devel-list mailing list
> fedora-devel-list redhat com
> http://www.redhat.com/mailman/listinfo/fedora-devel-list
>



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]