Red Hat Bugzilla – Bug 73697
Can easily confuse boot loader to use wrong partition
Last modified: 2007-04-18 12:46:29 EDT
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):
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.
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.
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
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
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
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.