On Thu, 7 Sep 2006, John Summerfied wrote: > Dag Wieers 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:-) Hehe. Well, I know I would be more inclined to look deeper if I have some more information available. And I'm certain others would as well. I prefer to extend it beyond this particular case. And there's no hurting 'normal' users by making this information available on a different channel (tty or logfile) for those who need it. I'm worried about anaconda development in the sense that many people use it, but few people improve it. And anaconda is definitely something that could be improved wrt. debug output. But I can fully understand that from a developer point-of-view you don't see that as important as you have the tendency to dig into the code (or just into your local brain cache) to know how something worked. > 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. I was not looking for interim solutions really, I know how I can fix this or work around it from a kickstart file. (Using %pre etc...) But yes, printing the device.map would be a good idea in the general case specifically for grub. > You could also try changes to your BIOS configuration to see whether you can > influence what happens at install time. No, we already did that. I checked and the problem is the SAN disk. I thought we disabled the controller, but in fact we disabled it from the BIOS point of view, Linux does see it and does see the disk. And it it a bit awkward to ask the SAN people to remove a disk, just to be able to do an installation correctly :) How feasible is it to print the commands that are executed in some sort of debug-mode ? (both to a tty and to a log-file) I am not asking to implement anything, just looking at ways to improve the output. Â(In fact I thought there already was some way to do that but I just didn't know about it) Kind regards, -- dag wieers, dag@xxxxxxxxxx, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power]
