Bug 66561 - installer cannot upgrade boot loader in root partition
installer cannot upgrade boot loader in root partition
Product: Red Hat Linux
Classification: Retired
Component: anaconda (Show other bugs)
i686 Linux
medium Severity low
: ---
: ---
Assigned To: Jeremy Katz
Mike McLean
Depends On:
  Show dependency treegraph
Reported: 2002-06-12 05:11 EDT by Douglas Wooster
Modified: 2007-04-18 12:43 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:51:58 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
lilo.conf prior to running RH 7.3 install (551 bytes, text/plain)
2002-06-21 00:17 EDT, Douglas Wooster
no flags Details

  None (edit)
Description Douglas Wooster 2002-06-12 05:11:37 EDT
From Bugzilla Helper:
User-Agent: Mozilla/4.79 [en] (X11; U; Linux 2.4.18-3custom i686)

Description of problem:
When LILO is in / partition, the installer apparently cannot find it, since it
doesn't give the option of upgrading the current boot configuration, during an
Upgrade install.

When you choose to create a new boot configuration in an Upgrade install, or you
choose to do a new install, Red Hat Linux installations list the / partition as
one of the two places that the boot loader can be installed into.

Because your installer ( RH 6.1, in my case) suggested the / partition, I think
the Upgrade installer should look there for a boot configuration, and allow
updating it.  

Version-Release number of selected component (if applicable):

How reproducible:
(the first time RH 7.3 install got this, I cancelled the install and openned a
service request.  Rerunning the 7.3 Upgrade install got the same results.  I
have not tried installing a new 6.1 and then putting another 7.3 on top of it,

Steps to Reproduce:
1.Install Red Hat Linux 6.1 into empty partitions ( / /home /var /temp /opt )
2.When asked where to put LILO, select the root partition
3.Install Red Hat Linux 7.3 as a Upgrade
4.Observe that when it gets to locating the boot loader, the choice to upgrade
the current boot configuration is greyed out

Actual Results:  RH 7.3 installer would not allow upgrading the current boot
configuration.  When I selected create a new boot configuration, it offered me
the choice of putting LILO in the MBR or the / partition (i.e. where it already

Expected Results:  Since it understands installing into the / partition, I
expected it to look there, find the existing LILO install, and offer the choice
Update existing boot configuration.

Additional info:

This was originally Service Request 206001.  The technician there said that it
should be reported here.

OS/2 Boot manager is installed in the MBR

This probably won't cause serious difficulty to users with enough experience to
maintain their own LILO or GRUB configurations, but will likely stump users who
never go anyplace that menus can't take them.  This is the sort of user which
Linux will have to be able to draw, in order to have a large desktop presence.
Comment 1 Michael Fulbright 2002-06-12 12:06:50 EDT
Assigning to an engineer.
Comment 2 Jeremy Katz 2002-06-12 12:36:20 EDT
What did you lilo.conf look like before the upgrade?
Comment 3 Douglas Wooster 2002-06-21 00:17:53 EDT
Created attachment 61988 [details]
lilo.conf prior to running RH 7.3 install
Comment 4 Douglas Wooster 2002-06-21 00:21:57 EDT
I've attached the the last lilo.conf before the install.

When I reran the RH 7.3 install and selected create a new boot config, it
offered the choice between the MBR on /dev/hda and /dev/hda10 .

Comment 5 Jeremy Katz 2002-06-21 00:55:21 EDT
And am I correct in assuming that you don't have /boot as a separate partition?
Comment 6 Douglas Wooster 2002-06-23 00:57:49 EDT
That's correct.  Here's   df -T   output.  The first group of partitions are 
mounted R/W by default: 
[root@PII450DMW new]# df -T  
Filesystem    Type   1k-blocks      Used Available Use% Mounted on  
/dev/hda10    ext2      427796    190776    214933  48% /  
/dev/hdc7     ext2      979450    639559    289288  69% /home  
/dev/hdc9     ext2     2035606   1219739    710643  64% /opt  
/dev/hda14    ext2     2016016   1791392    122212  94% /usr  
/dev/hdc8     ext2     1018298    119806    845881  13% /usr/local  
/dev/hdc6     ext2      349910     65680    266159  20% /var  
none         tmpfs      127888         0    127888   0% /dev/shm  
/dev/hda2     hpfs      313266    191344    121922  62% /C:  
/dev/hda6   umsdos      120204     84364     35840  71% /D:  
/dev/hda7     hpfs      160618     67552     93066  43% /E:  
/dev/hda8     hpfs      208812    164834     43978  79% /F:  
/dev/hda9     hpfs       64228     40756     23472  64% /G:  
/dev/hda12    hpfs       32098     21183     10915  66% /I:  
/dev/hda13    hpfs     3076416   1620550   1455866  53% /J:  
/dev/hda16    hpfs     5767302   4940999    826303  86% /L:  
/dev/hdc12    hpfs     5245190   1290309   3954881  25% /M:  
These additional partitions aren't normally mounted.  They're used for backups 
and disaster recovery: 
/dev/hda11  umsdos       24002     12838     11164  54% /H: 
/dev/hdd5   umsdos      513776         0    513776   0% /N: 
/dev/hdd6     hpfs    38917430  24762379  14155051  64% /O: 
/dev/hdc11    ext2      101075     13357     82499  14% /altslash 
/dev/hdc5     ext2     5065710   3900780    902671  82% /home/backups 
The /?: partitions are shared with OS/2. 
Comment 7 Jeremy Katz 2002-11-06 15:46:24 EST
I've tweaked this code some and it gets it right for me in our current internal
development trees
Comment 8 Michael Fulbright 2002-12-20 12:38:25 EST
Time tracking values updated
Comment 9 Brent Fox 2003-05-25 10:51:58 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.