OSDev.org

I have encountered few problems in regards to dual boot and was thinking for quite a while at troubleshooting. It is a long story but will try to make it as short as possible. The Preboot execution server is setup with linux installation image with two
boot entries.
manual installation - install rhel manually from pxe server.
semi-auto installation - automated installation, the only thing that are manual are user's choice of target drive.

Now I normally do a dual boot with two distinct SATA drives: hdd0, hdd1. Simple and easy.
hdd0 - install windows server
hdd1 - install linux using preboot server.

Everything goes fine with hdd0 windows installation and if I install it manually redhat linux onto hd1. When I install it manually, the bootloader is created on second drive (BTW, is is uefi so winbootloader is fs0:\efi\boot\bootx.64.efi and lin bootloader is at fs1:\efi\redhat\grub.efi

Now trouble starts if I choose semi-automated installation method from pxe server, in which I only intervene to select the target drive as hdd1 as intended. For this installation, I obviously created kickstart ks.cfg. But no matter how I tell to ks.cfg, this automated kickstart installation will always place grub.efi onto hdd0 not hdd1.

In other words;
winbootloader is at fs0:\efi\boot\bootx64.efi as usual.
lin bootloader is now on fs0:\efi\redhat\grub.efi.

As a result, after installation, something goes wrong and it fails to boot. The grub error is flashed
with (“(hd1,0)/grub/splash.xpm.gz”) not found.

Now if I check the grub setting for both cases above, the root(x,x) lines are different, but it makes me more confused:

1. dual boot, manual installation (working case)
win loader: fs0:\efi\boot\bootx64.efi
linux loader: fs1:\efi\redhat\grub.efi

grub setting:
root(0,1)

2. dual boot, kickstart (semi-automated) installation (failing case)
win loader: fs0:\efi\boot\boox64.efi (no problema)
linux loader: fs0:\efi\redhat\grub.efi

grub setting:
root(1,0)

For the seconds case, I tried setting root(0,0), root(1,1) no avail.
The definition of root(x,x) statement is vague and murky at best when googling (probably done by amateurist), but the way I grasp is root(<driveNo>, <partition>)

but then, since for working case, linux bootloader is in fs1: so i though the appropriate statement would be root(1,1) but somehow root(0,1) works.

For failing case in which lin bootloader is in fs0:, then I imagine root(0,0) will work but obviously it does not.

investigating further the ks file, i found there is no optoin for UEFI boot loader. There are only followings related setting but all appears to be MBR for legacy BIOS system:

Install type:
- install a new bootloader
- do not install a new bootloader

GRUB options
- password
- no password

install options:
- install a bootloader on MBR
- install a bootloader on 1st sector of boot partition

MBR:
- clear MBR
- do not clear MBR

Partitions:
- remove all existing partitions
- remove all existing linux partitions
- preserve.

Obviously the kickstart installation is placing the bootloader on different target than the target on which OS is installing.

This doesn't have anything at all to do with OS development, did you mean to post it somewhere else? I don't think it's really a GRUB problem either, so maybe the thread title should be changed too.

After you finish a successful manual installation, check /root/anaconda-ks.cfg for the automatically-generated Kickstart script. It may show you what you need to do differently. If running the script gives you different results than a manual installation, you should probably report that as a bug to Red Hat.

yes, man you are genious! i used setting in anaconda ks to get it working!!
let me know if u got some btc addr i can send some award thx!

it should be appropriate here because it is "close to OS"

ggodw000 wrote:yes, man you are genious! i used setting in anaconda ks to get it working!!
let me know if u got some btc addr i can send some award thx!

bummer, it did not work after all. roller coaster emotion.