Red Hat Bugzilla – Bug 58063
Low robustness when installing LILO
Last modified: 2007-04-18 12:38:54 EDT
From Bugzilla Helper: User-Agent: Mozilla/4.78 [es] (X11; U; Linux 2.2.20BS1 i586) Description of problem: When installing LILO, anaconda is not robust. May crash in a scenary where it may not (trivially) be created the /etc/lilo.conf file. For example, when I upgraded Redhat linux from 7.1 to 7.2, if /etc/lilo.conf is a symbolic link to /boot/lilo.conf, anaconda does not check why it can not create /etc/lilo.conf, anaconda simply halts the installation process. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Install a Redhat Linux release, with LILO as boot loader. 2. Move /etc/lilo.conf to another place and then symlink to this file from /etc 3. Upgrade Redhat Linux and choose LILO install. anaconda will crash when trying to create lilo.conf file. Additional info:
It should be moving the old lilo.conf (even if a symlink) to be lilo.conf.rpmsave; if you're getting a crash, the full backtrace would be very handy.
I've not a python backtrace because it occurred during installation phase and I did not saved it. However, I remember anaconda stderr said "cannot open /etc/lilo.conf for writing", and when I booted my system again with a diskette, both the symlink and the "real" lilo.conf files are untouched.
katzj: do you think lilo.conf might be set to immutable?
It's possible ... without the backtrace, it's really difficult to say what happened :(
Was this an absolute symlink or a relative symlink (ie was it to ../etc/lilo.conf or /boot/lilo.conf)
Yes, if it was a relative symlink, I assume it would work. However, I did an absolute link, so when anaconda mounts existing partitions under /mnt, it does not check this issue.
Fixed in CVS