Fedora Core Doesn't Like to Dual Boot?

schwatoo writes "It seems Fedora Core doesn't like to boot alongside Windows 2K or XP. According to a bug first reported in February on Fedora's bugzilla site it has a tendency to chew up partition maps making it impossible to dual boot into Windows. No one seems to know quite what is causing the problem and a lot of people are ending up with unbootable machines."

Comments

W2K3?

[LittleLebowskiUrbanA]

Works fine here with Windows Server 2003.

Obviously only happens in some cases

[Anonymous Coward]

I've installed FC2 on 4 machines: 2 were XP dual boot and still are with no problems whatsoever.

Uh, YEAH

[Anonymous Coward]

I had this happen to me twice. One machine, the Athlon XP, it corrupted the partition table so bad I had to low-level format the disk... and I lost a ton of data!

Some hints for safe partitioning

[ultrabot]

1. Partition in an older, safe system. E.g. knoppix.

2. Install grub in an older, safe system. You should have grub installed already, if you have been using Linux on the machine previously. I never install bootloader anymore, I've been using the same one forever. Just edit the grub config to point to new kernel & root system.

3. Grub should be on the beginning of small boot partition. Never on MBR, if you can avoid it. Always create a 80MB or so partition on the start of every disk, even if you don't plan on using it (yet). This also applies to secondary disks. Kernels should always go to these partitions.

Re:Some hints for safe partitioning

[TheRaven64]

As I mentioned in the last article about this topic it has nothing to do with GRUB, and happens even if you don't tell Anaconda to partition your system. Quite where the article submitter got the idea that this was an unknown or new problem from I have no idea.

Re:Some hints for safe partitioning

[UnderScan]

It may not be necessary to completely format and wipe clean the HD if you lose the partition table. To repair/write a partition table to disk, normally you might use fdisk and have to hand enter the sectors/blocks boundaries of the partitions.There is a open source tool called gpart. gpart will guess the partitions on the HD and can also write a new partition table to HD. I have had an instance where electrical outages & fluctuations caused the HD to lose its partition table. The table was inacurately identified the HD as one FAT16 patition when there was really a linux partition and a swap partition. gpart was able to clear this up and I did not lose and data. Go to http://www.stud.uni-hannover.de/user/76201/gpart/ to get the source or a binary for linux and freebsd. I think gpart is available on knoppix and perhaps also Gentoo LiveCDs.

Re:Some hints for safe partitioning

[Sweetshark]

I think gpart is available on knoppix and perhaps also Gentoo LiveCDs.
Dunno about that, but it is definitly available on SystemRescueCd

its a hardware problem

[ozzy_cow]

Copy and paste from here


It turns out that the bug (#115980) is a result of a few subtle but key changes within the 2.6 kernel. A certain functionality with regards to hard disk geometry has been pulled out, as the kernel developers thought it would be better if userspace utilities took care of this instead. The Bugzilla bug is related to CHS geometry problems, which most likely stems from an error within the parted utility, addressing the BIOS incorrectly. It turns out that BIOS updates tend to fix problems for many users that have been bitten by this "bug". On newer machines, this is basically non-reproducible.

Re:its a hardware problem

[hurtta]

Actually if you check Mandrake's bugzilla, they have the same problem. You can check it out at here. Mandrake listed the bug as resolved/fixed although it doesn't look like it actually was fixed.

On there is quite good description what is happening:

Part of the reason I could not understand the bug, is that I could not
believe windows XP was still using the error prone int13 function 2
(CHS based) instead of the (available everywhere for some time) int13
function 0x42. Under linux, grub and lilo only use function 2 when
function 0x42 fails (they don't even ask the BIOS if it manages 0x42
since some BIOS don't report correctly having this functionality, cf
FORCE_LBA in grub)

The other reason is that I thought BIOS faking heads number (the
so-called LBA mode) was a choice independant of the content of the
drive. This is wrong, the BIOS tries to adapt its mode based on the
partition table [1]

So here is what happened:
- kernel 2.6 doesn't try to give the logical geometry, and gives the
physical geometry instead [2]
- diskdrake uses the physical geometry to generate the CHS information
(which is a broken duplicate of the linear sector number)
- the BIOS sees the partition table uses a different CHS geometry, and
adapt to it
- ... and Windows computes the CHS to read its stage1.5 based on the
previous geometry that it keeps in its boot sector. Alas the CHS
doesn't get the same sector and Windows's boot dies (with very bad
error detection) [3]

That is comment 21. That same comment indicates that problem is fixed:

Code fix description: inspired by the way new fdisk and parted detects
the logical geometry based on the partition table [4]. parted code
is especially quite robust.
The fix is now included in cooker (DrakX #1.912), so:

I still would like to access the BIOS geometry, esp. for empty
partition tables. But kernel 2.6 doesn't give us this
(/sys/firmware/edd/int13_dev80/default_heads is plain wrong on a box
here)

Known workaround: forcing LBA mode in the BIOS

Mandrake also

[cyphr555]

Mandrake 10.0 Official also suffers from this problem. This is leading many to believe that it is an issue with the 2.6 kernel, rather than a specific distro.

Re:Mandrake also

[Pros_n_Cons]

Finally half way down the thread someone admits It's not just a Fedora issue. SuSe 9.1 also has the problem
Mandrake Bug
SuSe Bug
Read This Page If you want to find out whats responsible.

no retard, it's a software problem

[Anonymous Coward]

It says it "most likely stems from an error within the parted utility, addressing the BIOS incorrectly"... i.e., the utility!

Re:Now

[Timesprout]

well it was first reported in Feb so oviously they are in no great hurry to fix it.

Re:IF it boots at all!

[ozzy_cow]

tsk tsk. known bug, check the release notes. i dont think theres a workaround for it yet

Related issue

[arvindn]

Network install and hard disk install no longer work the old way with Fedora Core 2 (via bootdisk.img and netdrv.img), for the simple reason that the kernel no longer fits on a floppy disk. But there are workarounds. I made some notes on this issue.

...Could it be this problem?

[orzetto]

I had a similar booting problem when installing Gentoo. As Gentoo is very hands-on, and has quite a community, it was easy to find the fix.

First, the fault is Microsoft's. (Seriously, did you expect anything else?). The point is that Windows XP is a hog which believes that it is the one and only system on the computer. Therefore, if it is not on hda, it will put its hands on its ears and start singing aloud "La-la-la-la I can't hear you!". I have Linux on my hda, and WXP getting dustier and dustier on hdb. It would not start until I added the following lines in grub.conf:

title=Windows Xp
rootnoverify (hd1,0)
map (hd1,0) (hd0,0)
map (hd0,0) (hd1,0)
chainloader (hd1,0)+1

I'm not aware of how much Fedora lets the user write their grub.conf, but if they have a GUI tool, it might just not be programmed for this. After all, on my office machine, where Windows has been left on hda1, things works well out-of-the-box. Maybe they assumed everybody would use this configuration.

Re:...Could it be this problem?

[Sigma 7]

I have Linux on my hda, and WXP getting dustier and dustier on hdb. It would not start until I added the following lines in grub.conf:

title=Windows Xp
rootnoverify (hd1,0)
map (hd1,0) (hd0,0)
map (hd0,0) (hd1,0)

If you have to do that, then that means you've either moved a hard drive around, or did not install Windows XP in the directory it currently runs on (with the path including Drive and partition numbers.)

The solution is to modify Boot.ini in order to update the pointers to the Windows directory. You can either modify the raw references to the disk and partition number, or change it to a Dos-style path of "C:\WINDOWS". If you really wanted to, you can even run install multiple copies of Windows XP on the same partition (with features such as System Restore being considered unstable.)

As you should know, Bootstrapping requires an absolute path pointing to an application, even on Linux. If the absolute path on the hard drive changes, the absolute path given in or to the Bootstrap must be changed as well.

Maybe they assumed everybody would use this configuration.

No, they assumed that everybody would not change partitions or hard drives around after the Windows XP installation. This is a fairly reasonable assumption, since modifing partition tables or hard drive configurations implies that you know how to restore operating systems to a workable state if something messes up.

It's also why you see warnings with reparitioning software to backup your harddrive. If something breaks and you don't know how to fix it, then you have something to fall back to.

Re:Now

[akeru]

Had you bothered to understand my post, you would have seen that I acknowledge that Fedora "messes with the partition table". However, it does so by correcting a technically-invalid-but-working one to a technically-valid-and-working-for-everything-but-X P one.

**MOD PARENT DOWN**

[Anonymous Coward]

akeru is wrong. Fedora isn't 'fixing' the partition table... Fedora is /hosing/ it.

Re:Now

[Anonymous Coward]

Fedora is at fault.

It makes the "fix" without any use interaction.

Re:So THATS why windows partition is borked =\

[TheRaven64]

See this post for a fix.

Re:Now

[DJStealth]

The windows boot loader searches a file called boot.ini, inside it, it contains disk and partition numbers.

Since you swapped your HD's around, the disk #'s are now different, therefore it won't boot.

Re:jesus...

[anthonyclark]

As you'll have seen from various other comments; Mandrake 10 has the same problem therefore if you're using M10 without problems then FC2 will work just as well.

OK, just use the XP bootloader

[Sleepy]

I hate to rain on people's parades, but if you're making a system dual-boot with Windows, the conservative/safe thing to do is NOT install a bootloader.

Just use the one that comes with NT/XP. Of course it is limited in features (esp. compared to GRUB) but it works.

It's not a ton of work either:
Write a LILO bootloader to a partition, use 'dd' to copy that to a file (floppy helps), copy the "file" to Windows, and edit boot.ini to point to it.

Sure, it's not automated, but we're talking just a few steps, and then your're 100% confident that the next upgrade of Windows will not choke.

It would be nice if the PC industry could get "all OS vendors" to agree to universal bootloader, and maybe even get it in the BIOS, but the situation is what it is. You've got to be very careful when dual booting, especially with BETA software.

Sounds like the GRUB and kernel people need to work closer together. I don't know about GRUB, but the kernel has some pretty good testsuites so I am surprised this was not caught by the Linux Test Project (LTP). I'm hearing it's actually a 2.6 kernel problem, and since not a lot of people have upgraded to 2.6 we're hearing about it now.

Re:Previous Linux partition tables invalid?

[Anonymous Coward]

FC2 refuses to accept the partition table created with previous versions of Red Hat. Anaconda is coming up with CHS values that NO other partitioning or boot loader reports.

Note that one of my drives works, and the other doesn't. There may be a bug in the drive or BIOS, but it only shows up with FC2. When something that used to work no longer works, I consider it broken.

I don't have, nor want, XP. I do want to install FC2 side by side with my existing Linux configuration for testing, so that I can decide whether to try an upgrade.

Not true

[Natdog]

I recently installed Fedora Core 2 on a computer alongside Windows 2000 and had no trouble dual booting. That particular bug has been seen more often with the Test releases of Fedora Core, as should be expected. If it does happen to you, the problem can be easily fixed by running fixmbr in Recovery Console for 2000/XP.

Re:... doesn't like to boot alongside Windows

[sbulut77]

Suse 9.1 has the same problem. :) I guess not as many people are using Suse 9.1, since Fedora Core 2 problem arrived to Slashdot sooner. :))

Dual Booting w/FC2 & 2K Adv Server Workaround

[Anonymous Coward]

Works like a charm here. I think the problem comes from inexperienced people using the installer- Anaconda offered to destroy the partition map at least twice during (FC1 Upgrade) setup, three times if you count my NTFS RAID.
The workaround here is don't let FC2 touch, read, or otherwise fold, spindle, or mutilate your non-ext3 partitions. I know that's not much of a solution, but it works for me.

Re:Previous Linux partition tables invalid?

[antime]

Some people were guessing the problem is due to the 2.6 kernel reporting a different geometry from 2.4 and the tools not being updated to correct for this. I know that even though I didn't repartition, after installing FC2 over my FC1 installation the start and end cylinders reported by fdisk -l are completely different.

Evil Bug. Simple Fix

[ProudClod]

Right, I was hit by this. I'm a linux newbie. But I solved it.

To fix it:

-If you don't already have it, get and install sfdisk (there are RPMs out there, no deps)

Run (presuming your hdd is hda) as root "sfdisk -d /dev/hda | sfdisk --no-reread -H255 /dev/hda"

You may have to cd to sbin and replace sfdisk with ./sfdisk to make it work. In my case, i had to add the -force flag to the right hand side of the pipe.

That command ran, and then i could run WinXP from Grub just fine :)

However, FC2 has many other major bugs that I and others have found:

- Nvidia drivers don't work (i know it's nvidia's fault, but it's a stumbling block)

- As Xorg is in use, ATI drivers are a bitch to install (although if you use google there is a very good howto out there).

- The kludge i had to use to get software mixing working (dmix under alsa) was inexcusable. With alsa in 2.6, you'd think by default you'd have software mixing. An OS where I can't listen to XMMS and hear GAIM alerts at the same time is just ludicrous. Even sillier is the fact that GAIM alerts are queued, so when i close XMMS i get a minute solid of notification noises playing. Simultaneous sounds SHOULD work out of the box. Esound and arts are not in the equation any more, as alsa mixing is a much better solution - so why isn't it implemented?

- Totem just won't work. G-Streamer broke totally shortly afterwards.

- There's no easy way to edit your applications menu, without either SUing, or logging in as root. This seems daft for a multiuser OS like linux.

I know these bugs aren't Fedora only, but they need addressing if Fedora wants to remain OS of choice for many.

Drive geometry fixed if for me

[AgelmarJagad]

It is interesting that BIOS updates fix that problem for most people. I recently installed FC2 and had exactly the same problem booting between it and XP. I was finally able to fix it by changing the drive geometry setting in my BIOS from Auto (which was using CHS) to LBA. As soon as I did that it started to boot XP again.

Re:Drive geometry fixed if for me

[sumdumass]

it has to do with the logical block adressing. if you are using any large drive you should be using that instead of chs. I forget the size, but large drives can't actually be possible under chs. there is a value limit that makes it limited to a certain size.

Lba will allow the chs of the drive be translated to another value in the bios giving it the ability to adress larger drives. one thing that is strange about lba is that it is stored in the boot sector of the partition and is dynamicaly created by the bios when the partition is made.

If you use a drive setup utility from the drive manufacturer you might get somethign different them if you let the regular fdisk, parted(or whatever) do it. Drive manufacturers are notorious for setting these paramiters a little differently then usual for performance reasons. also the lba could differ from bios to bios or mainboard to mainboard. I belive there is some standard for adressing the lba (wich is actually loaded into a little memory resident program on the mainboard) but it leaves room for play and i can't seem to find my links to it as if now or i would include it in this post.

if you want to learn a little morte about boot secters and such here is a link that gives some information in a plain easy to understand format.
http://www.geocities.com/thestarman3/asm/ mbr/STDMB R.htm#INTRO

it apears that this site has went over its alotewd bandwitdh SO here are a couple other sites that will give less detail and a more tecnical info. they don't explain the lba verses the chs but do ilistrate some of the different interactions and how it can become reall messy real fast.

http://www.cgsecurity.org/testdisk_doc/Technical No tes.html
http://www.cgsecurity.org/testdisk_doc/M enuGeometr y.html

and here is a little somethign describing the xp-boot process. it goes into a little detail around the disk access wich might give you an idea why the difference in chs verses lbh is important.

http://www.qvctc.commnet.edu/classes/csc277/boot -x p.html

Re:Drive geometry fixed if for me

[juhaz]

Heh. Other way here. Auto was using LBA and changing manually to CHS fixed it.

Re:Use Separate Disks

[Pros_n_Cons]

Seperate disks doesn't matter with this issue, I had XP on hda and installed FC2-test2 on hdb and this bug still bit me. If you install in a work enviornment you definatly should NOT dual boot but if you do there is a safe way of tricking the hard drives into thinking they are both hda and not touching the other. Learn about it here It doesn't work for everyone but if it does, problems like this wont happen again.

Mandrake 10 Official still has this

[scheme]

Despite what you said, if you look at bug 7959 in the mandrake bug database, you'll see that official still has the problem. Mandrake's fix is apparently setting the bios mode to lba before installation. However some people have reported the problem is still around with this workaround in effect.

Ouch!

[chronicon]

OOooOOoooohhh! Now they tell me!

I've been fighting with Win2k to boot again for the past 2 or 3 days now, ever since I did my (full install) upgrade to FC2. I finally wiped my poor drive of everything and now have Win2k only running on the box at the moment. So much for my FC2 (x86_64), Mandrake 10, SuSE 9.1 (x86_64), and Knoppix partitions. <sigh>

In all fairness though, FC1 seemed to upgrade to FC2 quite well when I chose that option initially. I was just having a problem getting the nVidia drivers loaded afterwards so I thought, "Let's just nuke the FC1 partition and do a full install and see how that goes." Little did I know that even with my old grub.conf ready to go it would wreck my Win2K booting. Oh everything else booted just fine, but Win2K would just sit there. I tried all the usual Win2K fixes, booting to console from the Win2k CD, doing FIXMBR (it complained of a non-standard/messed up partition table) & FIXBOOT but that did not solve the issue (I guess it might have helped if I'd had an ERD for the box but I didn't... I will this time around!). Those "fixes" just got me to the "Error loading operating system" message at boot.

Thank goodness for Knoppix 3.4!!! I was able to pull off all my user files from the NTFS partition with it. Oh yes, the NTFS partition was still there in all it's glory. But would it let me boot? NOOOOoooo....

Ack! How I loathe Windows OS, but once I get the wife used to another accounting package maybe I can rid myself of it. Until then, I guess it is "mission critical" to my household? (Aye! What a frightening thought!) Well, I guess that begs the question then, is it the love of money or micro$oft that is the "root of all evil"? Maybe the two are synonomous? Hmmm...

So here I am sitting with only one troublesome OS thinking to myself what should I dare install next... Maybe SuSE 9.1 again. SuSE seems to always "just work" for me...

I wonder what changed? I mean it all booted under grub from FC1. This is a brand new machine--AMD64 w/ nForce3 chipset, would the BIOS really need upgrading? Ah well, I will grab an image of the NTFS partition this time around and avoid the heartache again if possible...

:-|

Re:No Firewire Either

[tuffy]

There isn't firewire support compiled into the kernel. If you want to connect an iPod or use any other firewire devices you have to recompile the kernel. That is a really stupid omission especially when it was reported in bugzilla during test 2!

From what I remember, not only was Firewire unstable in time for release, but was causing instability even for people without Firewire. I'd rather they held off on including it until it is stable rather than risk data loss by including it prematurely.

Worked for me

[jjohnson]

I've been following this problem for a while, so it was with a diaper firmly taped in place that I installed FC2 on my laptop, a Dell Latitude D600 with a 30GB HD, with the following partition table:

HD1 Fat32 30MBs
HD2 NTFS 20GBs (Windows XP)
HD3 /boot 200MBs
HD4 extended
HD5 / 9GBs
HD6 swap 1GB

My read on the problem is that there's a combination of factors having to do with changes to HDs plus changes to the 2.6 kernel plus Windows XPs non-standard way of handling HD geometry. Put those together and you might hose your partition in a fixable or non-fixable way, depending on which conditions are present.

In my case, no problem. I repartitioned according to the existing scheme and did a clean install of FC2, which worked fine, and had no problems booting WinXP.

Dual Boot Fix

[wenck]

After screwing around with it for quite some time, I took the suggestion of someone who replied to me in fedoraforum.org and set the harddrive to LBA mode from auto. Windows began to boot :-), only problem is it had to finish a repair install of windows, and now the screen goes blank after the windows startup logo. I'm not sure how related it is to the initial problem, but for anyone having problems, try forcing LBA. It may save you a lot of time.

Re:Now

[bob65]

Are you sure? I encountered this "bug" when installing FC2 alongside Windows XP - in my case, changing my hd mode to "LBA" from "Auto" in the BIOS allows both FC2 and WinXP to boot. However, I didn't really like that, so I ended up booting to single-user mode in Fedora and doing the following, as suggested by someone in the bug discussion:

sfdisk -d /dev/hda | sfdisk --no-reread -H255 /dev/hda

(I may have needed a --force in there as well). After that, I was able to set the mode back to "Auto" and both Windows XP and FC2 would boot. Note that all I did though, was basically just recreate my partition table by dumping the info provided by sfdisk and piping it back in sfdisk.

One explanation I read is that the Anaconda screws up the CHS values in the partition table. Windows uses both CHS and LBA, and so when it reads the CHS values it cannot boot. However setting the mode to LBA manually in the BIOS forces Windows to read the LBA values. Linux only uses LBA, so it doesn't matter what mode your hd is set to in the BIOS.

Of course, I don't really know what I'm talking about, but if someone could provide a better explanation...

Re:Previous Linux partition tables invalid?

[Too Much Noise]

Actually, that's precisely what it is. 2.6 reports a different layout (typically 16 cylinders instead of, say 255 in the logical one) and grub sets itself up this way. Next, it appears that even when the BIOS was explicitly instructed to use LBA access, this is somehow overriden by GRUB, with the result that trying to launch the NT bootloader fails.

The sfdisk solution on Fedora's bugzilla fails when sfdisk figures a partition does not start at the right cylinder boundary. Apparently, one can try to change the head count only for the windows boot partition, with the hope that it fixes the boot-through-grub problem (I am yet to try this). I guess the biggest problem is for people who don't have an LBA option in BIOS.

As a proof that it's not Fedora-related, I have the same problem with mdk10.

Finally, there seems to be no problem if one sets up the installer's kernel to use LBA access for the hd (no switching to CHS occurs).

Re:Not comparable

[bob65]

There's more info in the bugzilla report, but it only affects drives larger than ~120GB (or so) and SOMETIMES can be fixed with fixmbr in the windows recovery startup.

Actually it affected me with my 30GB drive as well. Fixmbr didn't seem to work, but recreating the partition table using sfdisk did seem to work:

sfdisk -d /dev/hda | sfdisk --no-reread -H255 /dev/hda

How about we get a fscking clue before posting?

[jmorris42]

Fedora Core 2 ships an almost stock 2.6 kernel. Which it would have taken you a whole minute to confirm before opening your piehole.

Dynamic Disks

[thoth]

Win2K introduced "dynamic" disks, which changed how the partition table worked. Partition type 0x42 means the disk is dynamic and the real information is contained at the end of the disk. 0x42 is supposed to be a container partition meant to span the disk and say "don't mess with me". An exception are boot and/or system partitions, as those have to be read early during boot before the dynamic disk stuff is loaded. Thus, boot/system partitions can be type 0x42 but not span the disk.

Anyway, as a wild-assed guess I'd check that out. Perhaps lilo/grub doesn't play well with dynamic disks.

Re:WIN XP and Fedora Worked for me as well....

[HTMLSpinnr]

Upgrading doesn't seem to have problems - I upgraded my dual boot XP/FC1 box to FC2 yesterday as well, no issues.

My understanding is the issues lie when the partition table is edited. Upgrading generally doesn't modify the partition table.

There are also reports of people who don't have problems - it depends in the end on the BIOS. Some say using LBA on your drives solves the problem as well vs. the default Auto (CHS).

Re:It seems to me

[pyrrhonist]

It has never worked with any distro to my knowledge. Use partition magic and you should be fine.

It has worked fine for me in every Redhat since 6.0 and every Mandrake since 7.
PartitionMagic has also worked, although there were some issues with PM 7 that repartitioning with DiskDrake solved.

Re:Not comparable

[Anonymous Coward]

If they don't know how to fix their Master Boot Record (MBR) then they shouldn't be dual booting in the first place.

I find this statement comparable to saying anyone who is not a mechanic should not drive a car. But that's not true, and that's why mechanics exist. Same goes for the problem of the topic, and that's why techs exist...

Not Fedora.

[Nailer]

This is Linux kernel 2.6 - Mandrake 10, Suse 9.1 and Fedora Core 2 all suffer from this problem.

Switching to Debian won't help if you want Linux kernel 2.6. Your paritition table will be fubared.

Furthermore, people do know what's causing the problem. The Linux kernel now doesn't show the same disk geometry as the BIOS does. The fix is to use sfdisk to recreate the partition table.

Now This Bugs Me!

[Master of Transhuman]

A year or so ago, I tried to install Mandrake 9, Red Hat 8 and Red Hat 7.3 on my old Compaq Deskpro 4000 machine. None of them would install. All of them would either fail to read the partition table - after creating and partitioning and formatting it using the utilities supplied with those distros - or would completely trash the partition table.

Red Hat 7.0, however, would blow on the system with absolutely no problem or complaint whatsoever.

After doing some partition work on my latest system with parted, Partition Magic 5 and Partition Magic 8 cannot in any way read my partition table. Windows (98 first, now 2000 and XP) loads fine, Linux (RH 7.3, Knoppix, other Live CD distros) loads fine, all other partition managers (BootItNG, Ranish) see and handle the partition table. ONLY Partition Magic cannot do anything with the partition table - and it is supposed to be the "premier" partition table manager on the market!

So now we have THIS crap with Fedora Core 2!

Guys, the partition table is NOT rocket science. It's a few bytes on a disk with a few variations in what each byte means. It's been around for decades.

So why in hell can't people who write this stuff GET IT RIGHT? What is the goddamn problem with you programmers?

I realize that hard disk manufacturers are constantly screwing around with their geometry reporting to the BIOS, and of course not writing any Linux drivers, but still a bug of this sort should not exist in any modern OS.

Get it together.

Ooops, there was supposed to be a hyperlink there

[Nailer]

The fix is here.

VIA C3 Problem

[Alan Cox]

The VIA C3 problem didn't get caught because it worked in the betas. The bug involved is in all the 2.6.x kernels but depends on the alignment and size of the kernel. While the beta kernel worked the final kernel didnt get lucky.

Ingo and others are currently working through this one to try and find the cause. At the moment nobody is sure if it is a Linux bug or a CPU errata being tripped.

Re:Totally irresponsible

[Master of Transhuman]

I'll tell you why this happened.

Nobody bothered to test parted with the 2.6 kernel AND on various BIOS and HD geometries to see if it worked right. Which is not too surprising considering how much testing that would have entailed on Red Hat's part. The parted people, however, should have done it. Apparently they didn't.

Given that parted has screwed up before, this is not surprising.

Lessons learned: don't use parted for partitioning.

Re:No Kidding!

[Master of Transhuman]

Use a more reliable partitioning utility like BootItNG (not freeware, but you can use it from the install menu for partitioning without actually installing it) or the DOS partitioner Ranish Partition Manager.

Do not use parted or Partition Magic - parted is not reliable and Partition Magic can't handle partition tables after parted has screwed them up.

Also, apparently, make sure your BIOS is set to LBA mode, not Auto or CHS.

No Problem Here

[AlgUSF]

I have had no problem with my Dual Boot WinXP / FC2 machine. Boots by default to Linux, I only have windows on there for games, but since Doom3 will come out on Linux, I guess I will have 1 less reason to boot into windows.

Fedora Core 2 hates Vmware as well.

[Bajanman]

Wish I would have read this article, instead of downloading 3 iso cd's of Fedora core 2 and spending countless hours installing it into VMware! It couldn't boot with Grub, no matter what I did. I DID solve the problem:
1. Cursed
2. Downloaded Redhat 9 iso's
3. Installed in Vmware: worked like a charm.

Curse curse curse.

"You can talk about Cha Cha
Tango, Waltz, or de Rumba
Fedora's dance has more title
You jump in the saddle
Hold on to de bridle!"

Here are my observations on bootloaders from past

[Maljin Jolt]

Windows 2k has tendency to screw linux partitions by forcing dynamic discs on certain conditions, such as hardware change. Windows can render your linux unbootable just by adding another ide controller.

Sometimes, forcing lba solves the problem when bios geometry and reported native ide geometry differs. People with this problem should try bios autodetection feature before forcing LBA.

Grub is much less technologically advanced than lilo, because it does not care about many different bios bugs. For example, it is not possible to place grub on the zip drive media or flash card, becuase grub does not "recognise" bios drive number. I guess grub can have geometry problem on very large disks too, which may be symptomatic to article author.
Lilo is much friendly to windows than grub, at least it is tweakable to be friendly.

There are several board bios/controllers bios hard drive limits, by the age of technology: 2.4G, 8G, 32G, 128G, 1000G.
Often, flashing new bios will help, but I would not recommend that to lamers.
If your bios shall boot from bigger drive then limit is, WHOLE boot partition must reside in the limited area of the disk. So make sure you have a little /boot partition for any linux(es) at the beginning of your disc. Put Windows partion behind it and all others systems partitions behind windows.

I would not recommend to have both linux and windows 2k/XP on the same drive, because of dynamic discs partition change may emerge from windows at any time. This is insidious from Microsoft. I would also recommend to keep /home on separate drive, which allows to change distros, format, upgrade, reorganize system partions and so on, also keeps your home safe from windows, if you disable that drive in them.

If machine becomes unbootable to linux, it's easy to boot a linux CD (I have a pocket-size lnx-bbc 2.1/i386 cd within my portfeille), then mount a partition, then remount existing dev tree under it, then chroot to it, then rerun lilo. Last week I did that repair in just 40 seconds, and it was very impressive to bystanders.

Just for case, I keep lilo on beginning of every hard drive (6 hard drives on my desktop+2 other ide devices), with complete menu available to boot almost anything from any drive), so it is possible to swap my drives at will on their interfaces. It is also possible to boot from bios on another drive (bios C, D, E, F) if something goes wrong, then select correct system in lilo menu.

And last, but not least: keep your machine well cooling if you have lot of hard drives.