Okay, a generous community member has been so kind as to write a summary document outlining prevention and recovery on systems where the infamous harddrive geometry installer bug causes problems with XP dual booting.
Please, read over the attached document and test the preventative and recovery methods outlined. Suggestions on useful textual edits and corrections to make before this is widely broadcast are welcome. This is important enough of an issue to make sure the information in here is non-toxic before we broadcast a version of this widely, the goal being to prevent all unncessary dataloss.
Of particular interest:
1)test the preventative measure if you still have access to a machine where this is a problem. Prevention is always better, if it can be done reliably.
2)finding a better workaround stdisk warning messages that are being produced that intefere with simple sfdisk command pipe recovery.
-jef"Die CHS Die!"spaleta
------------------->Begin Summary Document Text<----------------------------
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
Hi Jeff, all..
Three notes i have, one of them somewhat 'bitter' i'm afraid.
First of all i found out about this bug by being hit by it .. Unfortunatly i only have one machine here and needed to get work on it done, so without knowledge of how to fix this, all that was left to me was to whipe my partitions completely, losing a bit of data and work in the process, and re-installing. Now this leads to my actual question.. Is it really smart to leave FC2 out there when this scenario will probably hit a lot of people? Not everyone has many computers setup you know, and completely hoosing you system is probably enough to make people somewhat non sympathetic to what seems to have caused it (fedora in this case). I know i had to swallow hard and take a very deep breath when it hit me
Secondly these notes do mostly seemed geared towards quite advanced users? Specificly "..you should use a utility that can read the drive geometry" .. I think you've lost quite a bit of your target audiance there already.. What utility, what do those values mean, how to use those values in the workaround.. ?
Last i'm missing the part about recovery.. I've read in the bug and in the email threads that you could use sfdisk (which can be usable by booting the install/rescue cd, going into rescue mode, installing sfdisk, and running that command..). Shouldnt we include a guide on how to do that to?
While i do think its great btw to send out a major call to read this info, with a guide to how to prevent and/or recover from it. I am to put it mildly, quite supprised the 'Fedora Project' allows this bug to exist in cd's that anyone can just download.. However well we describe the fix/workarounds and spread the news, it will not reach a lot of people.. Nevermind about people who just want to try linux out. I remeber the times when serious dataloss was considered a show-stopper bug.. Having had the experiance of having lost data and work due to this bug, it's easy to call this data loss.. So in my eyes a _serious_ show stopper for this release.. Recall is what my voice will shout if anyone will listen; Or atleast patch the installers on the cd to detect the miss-alignment and refuse to take any further actions or install..
Really how's it gonna look to the world: "Hey we have this great new release, but installing it might mean having to do high-tech complicated workarounds or reinstalling your complete system"
----- Original Message ----- From: "Jeff Spaleta" jspaleta@gmail.com To: fedora-devel-list@redhat.com Sent: Tuesday, May 25, 2004 20:58 Subject: Call for Discussion: Summary document concerning Prevention andRecovery of XP Dual Boot Problems
Okay, a generous community member has been so kind as to write a summary document outlining prevention and recovery on systems where the infamous harddrive geometry installer bug causes problems with XP dual booting.
Please, read over the attached document and test the preventative and recovery methods outlined. Suggestions on useful textual edits and corrections to make before this is widely broadcast are welcome. This is important enough of an issue to make sure the information in here is non-toxic before we broadcast a version of this widely, the goal being to prevent all unncessary dataloss.
Of particular interest:
1)test the preventative measure if you still have access to a machine where this is a problem. Prevention is always better, if it can be done reliably.
2)finding a better workaround stdisk warning messages that are being produced that intefere with simple sfdisk command pipe recovery.
-jef"Die CHS Die!"spaleta
------------------->Begin Summary Document Text<----------------------------
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=
---------------------------------------------------------------------------- ----
-- fedora-devel-list mailing list fedora-devel-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-devel-list
On Tue, 2004-05-25 at 21:34 +0200, Chris Chabot wrote:
Secondly these notes do mostly seemed geared towards quite advanced users? Specificly "..you should use a utility that can read the drive geometry" .. I think you've lost quite a bit of your target audiance there already.. What utility, what do those values mean, how to use those values in the workaround.. ?
I agree on this point totally. What format is the geometry in? I've seen various ways of reporting HD geometry from straight cylinder counts (4134788423 cyl), to the CHS 16/8/64 whatever style, etc. A sample of what the user would be looking for would probably be very helpful.
On Tue, 25 May 2004 16:26:14 -0400, David T Hollis dhollis@davehollis.com wrote:
I agree on this point totally. What format is the geometry in? I've seen various ways of reporting HD geometry from straight cylinder counts (4134788423 cyl), to the CHS 16/8/64 whatever style, etc. A sample of what the user would be looking for would probably be very helpful.
something is going wrong with getting the full document into the mailinglist... its getting chopped....there's no point really discussing this until the full doc can be seen correctly. Hell...even Jack's repost of the document got eaten by the list demon even though my forward directly to him was fine. I've used up my alotment of community goodwill today, other people can attempt to get the full document to the list again.
-jef
On Tue, 2004-05-25 at 17:31, Jeff Spaleta wrote:
something is going wrong with getting the full document into the mailinglist... its getting chopped....there's no point really discussing this until the full doc can be seen correctly. Hell...even Jack's repost of the document got eaten by the list demon even though my forward directly to him was fine. I've used up my alotment of community goodwill today, other people can attempt to get the full document to the list again.
-jef
Jeff, by default , mailman limits the size of the messages (configurable for each mailing list).. The best way is to attach it or post it on a website and send the link..
-- Pedro Macedo
On Tue, 25 May 2004 18:56:12 -0300, Pedro Fernandes Macedo webmaster@margo.bijoux.nom.br wrote:
Jeff, by default , mailman limits the size of the messages (configurable for each mailing list).. The best way is to attach it or post it on a website and send the link..
Jack got it through.... http://www.redhat.com/archives/fedora-devel-list/2004-May/msg00908.html that message has the whole document.
Please make 'specific' edit suggestions and test the stated prevention and recovery methods.
-jef
On Tue, 25 May 2004 16:31:31 -0400, Jeff Spaleta wrote:
On Tue, 25 May 2004 16:26:14 -0400, David T Hollis dhollis@davehollis.xxx wrote:
I agree on this point totally. What format is the geometry in? I've seen various ways of reporting HD geometry from straight cylinder counts (4134788423 cyl), to the CHS 16/8/64 whatever style, etc. A sample of what the user would be looking for would probably be very helpful.
something is going wrong with getting the full document into the mailinglist... its getting chopped....there's no point really discussing this until the full doc can be seen correctly. Hell...even Jack's repost of the document got eaten by the list demon even though my forward directly to him was fine. I've used up my alotment of community goodwill today, other people can attempt to get the full document to the list again.
The most common cause is a bug in mailman. It cuts off the message when it encounters a period '.' on a line by itself as if it were an SMTP message body delimiter. In your message, the last line was
utility that can read the drive geometry as reported in the partition table
and the period behind "table" is missing [compared with Jack's posting], because probably it was auto-wrapped into the next line where mailman then cut off the message. You should be able to reproduce this in every message by adding some text after a line which contains nothing else than a period.
Now this leads to my actual question.. Is it really smart to leave FC2 out there when this scenario will probably hit a lot of people?
This has been on my mind as well. The Mandrake bugzilla entry mentions a fix (or anaconda? grub?) being in Cooker (their unstable distro) and so assumedly in the just-released MDK10-Official. That leaves FC2 in the unenviable position of being the only(?) distro out there afflicted with this problem.
So in other words:
a) Is a fix being developed (by whom? if not, who wants it?)
b) Once it's developed, can we replace the FC2 ISOs on the website and mirrors with ones that incorporate the fix?
--Brad
On Tue, 25 May 2004 21:40:03 -0400, Brad Smith brads@redhat.com wrote:
This has been on my mind as well. The Mandrake bugzilla entry mentions a fix (or anaconda? grub?) being in Cooker (their unstable distro) and so assumedly in the just-released MDK10-Official. That leaves FC2 in the unenviable position of being the only(?) distro out there afflicted with this problem.
So much assumption making...so little useful information in that paragraph. Perhaps...next time...you cite the bugreport specifically instead of particpating in rumormongering. If you can't cite the report...don't bother mentioning it. Better yet do more than just cite it...actively keep an eye on it to watch the new reports roll in. Unless you can bring specific and accurate information to the discussion, you aren't moving it forward.
-jef" http://qa.mandrakesoft.com/show_bug.cgi?id=7959#c27 "spaleta
On Wed, 2004-05-26 at 10:00 -0400, Jeff Spaleta wrote:
On Tue, 25 May 2004 21:40:03 -0400, Brad Smith brads@redhat.com wrote:
This has been on my mind as well. The Mandrake bugzilla entry mentions a fix (or anaconda? grub?) being in Cooker (their unstable distro) and so assumedly in the just-released MDK10-Official. That leaves FC2 in the unenviable position of being the only(?) distro out there afflicted with this problem.
So much assumption making...so little useful information in that paragraph. Perhaps...next time...you cite the bugreport specifically instead of particpating in rumormongering. If you can't cite the report...don't bother mentioning it. Better yet do more than just cite it...actively keep an eye on it to watch the new reports roll in. Unless you can bring specific and accurate information to the discussion, you aren't moving it forward.
And unless your someone from @redhat.com, not sure there is anything you need to be telling him what he can/can't do on their own mailing lists (unless we are talking spamming it, abusing or that type thing), whether it's useful (to you?) or not.
Besides, maybe the bug # was posted to @redhat.com folks or someone already know of it from Red Hat and he was just posting what is already known.
And unless your someone from @redhat.com, not sure there is anything you need to be telling him what he can/can't do on their own mailing lists (unless we are talking spamming it, abusing or that type thing), whether it's useful (to you?) or not.
Besides, maybe the bug # was posted to @redhat.com folks or someone already know of it from Red Hat and he was just posting what is already known.
I've got to agree with Seth there. My job at Red Hat has nothing to do with development and I have no special access to anything to do with Fedora. Jeff, though I wish he'd been more polite about it, was correct in that I should have checked to see if there had been any more news (sure enough, the bug still exists in mdk10).
That said, this thread is getting focused on a relatively unimportant part of my post (IMO) and ignoring where I *was* trying to "move the discussion forward"
To wit:
a) Is a fix being developed (by whom? if not, who wants it?)
b) Once it's developed, can we replace the FC2 ISOs on the website and mirrors with ones that incorporate the fix?
My incorrect assertion that we were the only ones with this problem aside, I fail to see how asking these (still unanswered) questions fail to move the discussion forward.
--Brad
On Wed, 2004-05-26 at 10:57 -0400, Brad Smith wrote:
I've got to agree with Seth there. My job at Red Hat has nothing to do with development and I have no special access to anything to do with Fedora.
Agreed, sort of wasn't meant in the way it sounded, read below.
Jeff, though I wish he'd been more polite about it, was correct in that I should have checked to see if there had been any more news (sure enough, the bug still exists in mdk10).
I think I was just a little ticked at the way he did/said it and not being more polite as you pointed out.
That said, this thread is getting focused on a relatively unimportant part of my post (IMO) and ignoring where I *was* trying to "move the discussion forward"
Also agree and sorry to everyone for even bringing it up :(
And unless your someone from @redhat.com, not sure there is anything you need to be telling him what he can/can't do on their own mailing lists (unless we are talking spamming it, abusing or that type thing), whether it's useful (to you?) or not.
Besides, maybe the bug # was posted to @redhat.com folks or someone already know of it from Red Hat and he was just posting what is already known.
If fedora is supposed to be a community-included project then whether someone is @redhat.com should not affect whether they can attempt to contribute and influence the discussion in positive ways.
As Jef is involved in the fedora bug triaging efforts I think his input is uniquely qualified on this thread.
I hope @redhat.com are not the only people whose opinions matter.
-sv
On Tue, May 25, 2004 at 02:58:35PM -0400, Jeff Spaleta wrote:
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
Looking in the BIOS is another way for many boxes. Also if you set the bios to LBA that is reported by many to keep stuff happy
On Tue, 25 May 2004 18:45:23 -0400, Alan Cox alan@redhat.com wrote:
Looking in the BIOS is another way for many boxes. Also if you set the bios to LBA that is reported by many to keep stuff happy
yes looking around... it seems using the bios to put the drive into LBA mode even comes up as a workaround for madrake's release.
-jef
On Tue, 2004-05-25 at 20:04, Jeff Spaleta wrote:
On Tue, 25 May 2004 18:45:23 -0400, Alan Cox alan@redhat.com wrote:
Looking in the BIOS is another way for many boxes. Also if you set the bios to LBA that is reported by many to keep stuff happy
yes looking around... it seems using the bios to put the drive into LBA mode even comes up as a workaround for madrake's release.
-jef
I have to add that this corrects the problem in , let's say , 99% of the cases. However , sometimes it does nothing (here I had my drive set to LBA after FC1.92 was installed and it didnt work. Then when core 2 was released , the same bug appeared...)
-- Pedro Macedo
On Tuesday 25 May 2004 19:04, Jeff Spaleta wrote:
On Tue, 25 May 2004 18:45:23 -0400, Alan Cox alan@redhat.com wrote:
Looking in the BIOS is another way for many boxes. Also if you set the bios to LBA that is reported by many to keep stuff happy
yes looking around... it seems using the bios to put the drive into LBA mode even comes up as a workaround for madrake's release.
Yes, LBA is a key factor to this problem .... I have looked at the whole document and do not see much about the problem being related to LBA (versus the physical c/h/s) and I believe this is key to the problem as well as the preventative solution. This should be covered in more detail in the document.
From other discussions, as I understand it the problem is in the upstream 2.6
kernel and, since Fedora is trying to stay very close to what is in the upstream kernel, it needs to get fixed there.
A bad part to all of this is that it is likely to hit the new users who are trying to install FC2 on their Windows system. When finalized, this should be published on the fedora-announce-list ... it really should be in the release note but it is too late for that now.
One regret I have is that the warning popup saying that there was something "wrong" with the partition table was removed ... at least this would give users a pause where they might research the problem.