CentOS 6.5 and dL380 G5 boot problem

[press_altandF4]

I am attempting to install Cent OS 6.5 on a dl380 G5, and after installation and reboot, it simply won't load the OS. It hangs at the booting screen where it says "Attempting to boot from CD, Attempting to boot from C:/"

I am theorizing that it is a P400 Disk array issue and that CentOS can't see the drives because of the raid controller, but it can see all logical drives just fine during OS installation, so i'm skeptical.

I have all 8 drives full, and two logical drives (1 for OS, and 1 for storage). This is an older server, that used to run WIN server 2008, though I blew out the RAID and rebuilt it all before I attempted installation of Cent OS.

I have tried to do a "rescue" but after snooping around I didn't see anything that jumped out at me, but I could have overlooked it.

Has anyone ever run into this on a G5 before, and if so, what did you do to overcome it?

P.S. This thread has been moved from  Servers>General to ProLiant Servers (ML,DL,SL). -HP Forum Moderator

[Matti_Kurkela]

Sounds like the GRUB bootloader might be confused about which disk it should be booting from, or the installer might have put the GRUB boot record in the wrong place.

Boot to rescue mode, and check out the /boot/grub/device.map file in the installed OS. Is the GRUB disk identifier "(hd0)" associated with the correct disk device? If it isn't, fix it by editing the device.map file and then run "grub-install <device>", replacing <device> with the correct disk device.

The PC architecture has no universally-supported standard way for the BIOS to tell the OS which disk was used to boot the system, so the OS installer sometimes needs to make a semi-informed guess - and it won't always get it right.

[anthony11]

^ Exactly my thoughts, this happened to me with RHEL.

There's some emerging Linux tech for naming NICs and disks according to internal/external/PCI slots that holds great promise.  Yeah you can do some of this with udev, but udev is such a PITA

[Matti_Kurkela]

> There's some emerging Linux tech for naming NICs and disks according to internal/external/PCI slots that holds great promise.

Yes, but since the CPU cannot just grow legs, hop out of its socket and take a peek at the physical layout of the system, the OS will be at least partially reliant on a hardware description provided by either the hardware itself or the BIOS/firmware.
 

The slot information in /sys/bus/pci/slots/ is produced by looking for particular objects in ACPI tables provided by the firmware. On my system, this directory is empty, because those hardware description ACPI objects are not populated.

For booting, something like the CONFIG_EDD Linux kernel configuration option or UEFI is needed.

The kernel configuration help on CONFIG_EDD says:

CONFIG_EDD:                                                             

Say Y or M here if you want to enable BIOS Enhanced Disk Drive
Services real mode BIOS calls to determine which disk 
BIOS tries boot from.  This information is then exported via sysfs.

This option is experimental and is known to fail to boot on some
obscure configurations. Most disk controller BIOS vendors do
not yet implement this feature.

 Please note the last paragraph.

No matter what else is said of UEFI, I think it got this part right: there is a standard way for the firmware to provide a set of persistent boot variables to the OS, and the OS can examine those variables to identify the boot partition and the initial boot loader in an unambiguous way. And by modifying those variables, the OS can override the normal boot sequence for the next boot, or even modify the boot sequence in a persistent way.