Everything works flawlessly with the exception that the installation writes the GRUB Boot Loaders on the USB stick instead of the destination hard drive and hence can only be booted from the USB stick.

Afterwards I can solve this manually by editing grub.conf to point to the hard drive and using the grub utility I can nstall the Grub loader on the hard drive MBR instead and then it boots normally.

The aim is however to create a fully automated installation since the end users in question are expected to be technically proficient so my question is if there is a kickstart option to explicitly write GRUB correctly to the hard drive from the very beginning?

There seems to be a kickstart "bootloader" option but I can not really see any flags that would explicitly set the GRUB on a specified hard drive?

* --driveorder ? Specify which drive is first in the BIOS boot order. For example:

bootloader --driveorder=sda,hda

* --location= ? Specifies where the boot record is written. Valid values are the following: mbr (the default), partition (installs the boot loader on the first sector of the partition containing the kernel), or none (do not install the boot loader).

Still can't guarantee that a totally automated approach is possible, unless the hardware is identical, as the devices and ordering will be system-dependent.

AlanBartlett wrote:In the CentOS wiki article that you reference, under the heading Notes, there is a [color=ff1480]cherry-red[/color] block of text. Isn't that appropriate?

If not, do you have any suggestions for improvement to the article?

To my understanding this specific part of the text refers to an interactive installation but since I deal with a fully automatic installation I do not think that part is appropriate so that is why I am looking for corresponding kickstart options to achieve the same thing. To be fair it also mentions the line bootloader --driveorder=cciss/c0d0,sda --location=mbr" that might be appropriate but since I am not very proficient with completely comprehending the parameters.

* --driveorder ? Specify which drive is first in the BIOS boot order. For example:

bootloader --driveorder=sda,hda

* --location= ? Specifies where the boot record is written. Valid values are the following: mbr (the default), partition (installs the boot loader on the first sector of the partition containing the kernel), or none (do not install the boot loader).

I was aware of these parameters but I am not fully sure about how to apply them... the "--location" flag seemed easy enough and also driveorder but the "append" kernel parameters eludes me but perhaps this is not required.

I know that the kernel and Grub part should reside on the first partition of disk "sda" and the USB stick on "sdb" so would setting the "--driveorder=sda,sdb" insure that grub.conf points to the sda disk?

Also, would that automatically write the GRUB loader on "sda" as well or do you need to use the "partition flag" for that?

As a matter of fact I tried the --driveorder flag and that actually worked as it now can boot directly without USB stick which is a great step forward.The only remaining obstacle is that somehow the FAT32 partition disappear from the USB stick so it cannot be used for future installations.This can however be fixed by using FDISK to create a new FAT32 partition in the same space and somehow this also restores the previous file in the partition.

Since the GRUB bootloader seems to be written to the destination disk I must say that I cannot understand at all why the FAT32 partition disappears?Are additional flags required to prevent this from happening?

andersbiro wrote:...Since the GRUB bootloader seems to be written to the destination disk I must say that I cannot understand at all why the FAT32 partition disappears?Are additional flags required to prevent this from happening?

I have not seen that happen. You have both FAT32 and ext3 partitions, and the FAT32 one is gone after the install? I'd check the kickstart file carefully to be sure it is not inadvertently messing with the USB drive.

Thanks for reporting back, and please keep us posted. Any recommendations for the Wiki article appreciated.

I managed to solve the issue by adding the "ignoredisk --drives=sdb" parameter for the USB drive and now the installer leaves the USB stick intact and the installation works flawlessly.I however still do not know why the installer affected the disk in the first place but this flag did at any rate solve the problem for me.

Hi. I ran into this recently kickstarting both 5.5 and 6.2 hosts. Kickstarts worked one day and the next the bootloader wanted to be on the usb key, odd. This is was an example of what worked for me with 5.5 where the usb key was consistently seen as sdb. Both at their respective parts in the preamble section of ks.cfg.