I had a previous version of CentOS installed on a multi-boot system (2 XP Pros, 1 Suse 10.0 x86_64 and CentOS 4.x x86_64). I use BootIt NG as my boot manager, and I have never had any issues with this type of set-up.

However, I decided to upgrade to the latest version of CentOS 4.2 x86_64. Instead of overwriting the old install, I decided to install from scratch. I use CentOS mostly for testing server setups, so no big loss if things were to go awry.

Bottom line ... after going through Anaconda, I kept getting an error message:

"Error informing the kernel about modifications to partition /dev/sdb16 ..."

Very odd since my installation of CentOS is set to go on a completely different drive:

hd2 (PATA)
hda5 = swap
hda6 = /
hda7 = /home
hda9 = var

The device specified in the error message is on hd1 (SATA).

I was given an option to ignore this, but clicking "ignore" forces a reboot without completing the installation. So much for ignoring (by the way, Suse 9.x and 10.x throw up similar warnings about RAID devices during use of its partitioning tool, but its "ignore" option actually works ... I don't have any RAID setup, anyway).

Okay ... so the only way I could figure out to get CenTOS loaded was to unplug my two SATA drives (hd0 & hd1) so they couldn't be seen during installation. This did allow installation to the PATA without any errors.

However, now when I boot the CentOS item in BootIt NG, all I get is GRUB (no prompt , system only responds to Control-Alt-Del). All other boot items in BootIt NG remain functional.

I though modifying grub.conf and device.map (using linux rescue shell) might do the trick, but it doesn't. Here is what Anaconda created during the "successful" installation:
----------------------------
- device.map:

(fd0) /dev/fd0
(hd0) /dev/hda


(Note: after plugging the two SATAs back in, the above should look more like this, shouldn't it?

(fd0) /dev/fd0
(hd0) /dev/sda
(hd1) /dev/sdb
(hd2) /dev/hda

----------------------------

- grub.conf

default=0
timeout=5
spalshimage=(hd0,5)/boot/grub/splash.xpm.gz
hiddenmenu
title blah blah
root (hd0,5)
kernel /boot/vmlinuz-2.6.9-22.EL ro root=LABEL=/ rhgb quiet
initrd /boot/initrd-2.6.9-22.EL.img

(Note: I may have transcribed some of the syntax incorrectly, but I think the important thing to note here is the drive and partition info).

---------------------------

I tried changing hd0 to hd2, which is where the hd is located after plugging the two SATA's back in, and tried adding the SATAs to the device map. I also tried just about every possible combination of drive and partition number, some that I knew didn't make sense, but I'm grabbing at straws by now.

Any thoughts on how to modify grub.conf, device.map or any other files to get CentOS fired up.

Thank you.

FIXED

Well, I posted my first message in both the CentOS forum and in the LinuxQuestions forum, and while many people seemed to have read the post, no one had any solutions to offer.

I still have not found any other solution to installation of CentOS in the environment I described in my first post as it seems many people are having similar difficulties with the "Error informing the kernel..." error message. The easiest thing for me was to simply unplug the drives that seemed to be causing CentOS to upchuck, apparently due to a bug, I believe, and the OS was able to be installed.

The next part of the problem caused by disconnecting the SATA drives during installation then reconnecting them seems to be a fairly basic GRUB concept that I was missing, so I'm not sure why I wasn't getting any responses to this part of the problem. Maybe I wrote so much that people didn't care to read it all.

Anyway, I continued to read about GRUB from various sources and it seems I was at least partially on the right track. I did indeed need to modify the device.map file. The corrections required for grub to successfully see the drive setup after re-plugging the SATAs were correct for my particular set-up:

(fd0) /dev/fd0
(hd0) /dev/sda
(hd1) /dev/sdb
(hd2) /dev/hda

Also, the drive / partition corrections to grub.conf that I mentioned were also correct (root = hd2,5).

ONE BIG MISTAKE: simply editing the files in "linux rescue" mode does not allow for proper booting. The required steps after reconnecting the SATAs were these:

1. Insert media in drive and boot to "linux rescue".
2. Modify the device.map file using a text editor (joe, etc.). The device map should match the drive order in your BIOS.
3. Run grub from the prompt and point it to the corrected "device.map" file (this is the key to success ... otherwise, grub has no clue what the correct device map is):

bash: grub --device-map=PATH/device.map

4. Run the root command in grub specifying the desired boot loader installation location. The command will return the partition file system info (eg, ext2):

grub > root (hd2,5)

5. Run the setup command using the desired boot loader location. The command will properly set-up all the necessary boot files for the specified location:

grub> setup (hd2,5)

6. Quit grub

grub > quit

7. Reboot

The above can be modified to suit a particular situation, but the bottom line is that if you have to resort to installing CentOS without all your drives attached in order to avoid installation errors, you will need to correct the automatically generated "device.map" file, re-attach the disconnected drives, run grub pointing to the corrected device.map and then run grub as shown above to allow for proper booting.

I'm posting this from within CentOS, so at least this worked for me.