Dag Wieers wrote:
On Tue, 5 Sep 2006, John Summerfied wrote:
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 :)
I'm thinking you may be expecting too much for it to work all the time:-)
The commands run are on one of the ttys; turn off "reboot" and do some
inspection. The grub stuff is written to one of the ttys, bout tt4 or 5
I think, and you can always use tty2 to poke around and see what's happened.
I think a patch to allow the installer (person) to view grub's device
map and change if required would be a good start, and probably a good
interim solution.
You could also try changes to your BIOS configuration to see whether you
can influence what happens at install time.
--
Cheers
John
-- spambait
1aaaaaaa@xxxxxxxxxxxxxxxx Z1aaaaaaa@xxxxxxxxxxxxxxxx
Tourist pics http://portgeographe.environmentaldisasters.cds.merseine.nu/
Please do not reply off-list
