On Tue, 5 Sep 2006, John Summerfied wrote: > Dag Wieers wrote: > > > I have a particular problem, only verified with RHEL4AS U4, where Anaconda > > happily installs and reboots but there does not seem a bootloader installed > > (or it is installed at the wrong location). > > > > This happens on a HP Proliant DL580 G2 with the cciss driver. If I install > > the bootloader with grub-install myself (using a rescue cd and mount/chroot) > > then the grub device.map lists /dev/cciss/c0d0 as hd4 and sda as hd0. > > > > Not sure if that is the problem, but manually overwriting the device.map and > > making /dev/cciss/c0d0 hd0 works as expected. > > > See this, from grub.info: > 3.3 Installing GRUB using grub-install > ====================================== > > *Caution:* This procedure is definitely less safe, because there are > several ways in which your computer can become unbootable. For example, > most operating systems don't tell GRUB how to map BIOS drives to OS > devices correctly--GRUB merely "guesses" the mapping. This will succeed > in most cases, but not always. Therefore, GRUB provides you with a map > file called the "device map", which you must fix if it is wrong. *Note > Device map::, for more details. > > > Grub has some difficuly detecting which drive you really use to boot from. > I've not tried to do so, but I expect I could reproduct your problem at will > by setting my BIOS to boot from any drive other than the first. Well, that's the odd thing. We booted from a virtual CD image (which is normal with HP hardware using iLO) and this process has worked before with RHEL3 and RHEL4 on HP Proliant DL380 and DL580 (different models) without a problem. Not sure what was different this time, but booting from a rescue ISO image revealed that grub used the Virtual CD (sda) as hd0 and the cciss as hd4 ! Is there some way to influence this decision, we know that the cciss disks are going to be the one that we boot from. On all the systems *always*. PS There are no other disks available on the system except cciss, a real CDROM drive and the virtual CDROM drive (which booted anaconda). So there should be no problem detecting which one it should boot from, still... But... (and this is my real point regarding the email) How would I be able to see from anaconda what command is being run and what output it got back. I am not looking for a solution to this problem directly, I am looking for a way to make obvious what is going on from (during or after) the installation. If something was available to see exactly what happens, what decisions are being made and what programs are run (even without the output) it would positively affect bug-reports and help from the community to improve Anaconda. I know the source-code is available for anyone to see, but a teaser to help people to understand what is happening might help to get them involved in the process. Trying to reproduce a problem at Red Hat is far more worse and complicated than getting proper feedback/analysis and maybe even a patch. Expecting people to check the source blindfolded without much understanding of what happened or what the cause could be, is clearly having bad faith in the abilities of most peoÃple :) Kind regards, -- dag wieers, dag@xxxxxxxxxx, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power]
