Red Hat Bugzilla – Bug 17885
reboot of a wrong installation after an update
Last modified: 2008-05-01 11:37:58 EDT
After updating an installation with a root at /dev/sdb8 anaconda automatically reboots a machine but into a "default" installation on /dev/sda2. Minor but annoying. Michal michal@harddata.com
Could you give some more details on the setup of your machine? As I understand, you had a bootable partition on /dev/hda2. Then you installed to /dev/hda8, and when the installer created the LILO configuration file, it put both hda2 and hda8 in the setup, and made hda2 the default, not hda8?
Ignore my previous comments - this is on the Alpha!
hmmm ... I am unable to reproduce this problem ... after installing onto more than one partition for a given drive, booting from that drive always boots the last partition installed for me ... are there any other details/conditions under which this occurs for you ...?
What can I say? I only reported what I have seen. It is possible that anaconda got confused by the fact that I installed with a root partition "deep" into /dev/sdb while on reboot it found my "main" installation on /dev/sda, i.e. on another disk earlier in the chain and even on /dev/sdb this was not the only installation. I do not think that my rig is that normal and anybody with a setup similar to mine would know what to do with a confused anaconda. :-) If this is not an "obvious" problem then I would not spent too much time and effort on this really minor imperfection. It is up to you, of course.
we were unable to see the same behavior using generic hardware in our test lab (that certainly doesn't mean your behavior didn't occur! :) ) ... this makes locating and fixing the problem harder ... :) what type of machine and what level of firmware did you see this on ...?
This happened when I was installing on my test UX. For firmware it is using ArcsBios (do not remember now version, but there was not a big variety of these) from a defunct Deskstation. It boots, obviously, via Milo. At this moment it has IBM DDRS-39130D on /dev/sda, IBM DDRS-34560D on /dev/sdb, IBM-DJNA-370910 (ATA) on /dev/hda and a SCSI CD (Toshiba XM-6201TA). Various more or less standard independent installations here and there. Definitely not a garden variety system. :) If it is not easy reproduce then I really think that this is that kind of a loose end you bother with when you do not have better things to do.
ok, we'll resolve this issue and work on other stuff ... :) please reopen if this issue occurs with a SRM based machine ... thanks for the report!