From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1) Gecko/20020826 Description of problem: The boot configuration may choose the wrong partition to boot from. At one point I had /dev/hda1 as /boot and /dev/hda2 as /, but the system was absolutely confident that Red Hat Linux needed to boot from /dev/hda7. This confusion later contributed to a complaint from the system that I needed 'at least 1024 megabytes of space' on /usr when installing 1.6 gigs of packages, when I had made /usr 4096 megabytes. The installer had become confused about which partition was which. I had to bail out because it would not let me go back and reconfigure my disk partitions, and I could not go forward because it swore I didn't have enough space allocated for /usr. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1.Create a / (256), a /boot (256), and a swap (512) partition. Click NEXT 2.RHL wants to boot to /dev/hda3 (this is where / landed). Click BACK 3.Add a /var partition (512) and force it to be primary. / jumps to /dev/hda5. Click NEXT 4.Observe that RHL still wants to boot to /dev/hda3 (now swap). Oops! Actual Results: The boot loader is pointing to the swap partition. Expected Results: The boot loader should be pointing to the root partition. Additional info: This is a major gripe of mine, by the way. Once you get to package installation, if you haven't allocated enough space, you can't win, you have to start completely over because you can't return to Disk Druid. This is a major flaw in the way RedHat's installs have worked for a long time. Let me be blunt: Package selection should occur BEFORE disk partitioning. Do a quick probe to get the total disk space so the user can't select more packages than will fit on the disk -as a whole-, and worry about partitioning after packages have been chosen. If you let the user pick out their packages FIRST, then you can lay down minimum requirements for disk partitions. ("You have chosen 1.6 gigabytes of packages, therefore, /usr or whatever partition /usr goes onto, must be at least this size.) Make this change, and things will become SO much easier. Thank you!
This isn't a bug... when we say we're booting hda3, we're pointing out what the root partition is. I can't reproduce the other in trying here -- if you went forward far enough to try to install and then go back to the partitioning screen, you can probably have something weird like that happen but that shouldn't be a problem in the final release. As far as specifying package selections before partitioning, we unfortunately can't do this without a somewhat significant increase in the RAM requirements because the disk space calculations require loading the (large memory footprint) header list so we have to be able to turn on swap if needed.
"...when we say we're booting hda3, we're pointing out what the root partition is." The root partition is not on /hda3 after following the "Steps to Reproduce"! By step 4, the _root_ partition is now /dev/hda5, but the loader configuration still thinks it is /dev/hda3. That's the bug. At step 4, GRUB will attempt to boot from the SWAP partition. I was able to repeat this bug several times in a row on my home system, so I know it is definitely an issue. It's possible that it might not happen on a system with a completely blank hard drive. In my case, I installed onto a system that had partitions on it. I deleted all partitions, then began my test case as described above. This is the only thing I can think of that might make it not as easily replicable. However, I repeated the instructions as provided above several times on a system with a single IDE drive and the error happened every time. I only mentioned the "out of space on /usr" problem as a consequence of the boot loader bug. I guarantee that users who tinker with their partitions a lot before they're happy with them will get to the package installation stage, see the system bomb out, and report that as a bug, but they won't be able to explain why it happened (it's a result of the mistake in Disk Druid much earlier in the procedure). Very important: The issue only happens when you back up a step and change parititions in such a way that **moves the root partition to a different location**, such as adding or changing another partition and forcing it to be a primary partition.
This should be fixed now
I'm going through Bugzilla closing some bugs that have been marked as Modified for some period of time. I believe that most of these issues have been fixed, so I'm resolving these bugs as Rawhide. If the bug you are seeing still exists, please reopen this report and mark it as Reopened.