Bug 73697 - Can easily confuse boot loader to use wrong partition
Can easily confuse boot loader to use wrong partition
Product: Red Hat Linux
Classification: Retired
Component: anaconda (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jeremy Katz
Mike McLean
Depends On:
  Show dependency treegraph
Reported: 2002-09-08 20:24 EDT by jrjohns
Modified: 2007-04-18 12:46 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-05-25 10:59:39 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description jrjohns 2002-09-08 20:24:08 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):

How reproducible:

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!
Comment 1 Jeremy Katz 2002-09-20 11:51:01 EDT
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.
Comment 2 jrjohns 2002-09-20 17:10:33 EDT
"...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

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.
Comment 3 Jeremy Katz 2003-01-22 19:59:30 EST
This should be fixed now
Comment 4 Brent Fox 2003-05-25 10:59:39 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.