|Page 1 of 1|
|Author:||ggodw000 [ Tue Nov 14, 2017 3:09 am ]|
|Post subject:||grub problem|
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
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
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
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.
|Author:||ggodw000 [ Tue Nov 14, 2017 12:49 pm ]|
|Post subject:||Re: grub problem|
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 a new bootloader
- do not install a new bootloader
- no password
- install a bootloader on MBR
- install a bootloader on 1st sector of boot partition
- clear MBR
- do not clear MBR
- remove all existing partitions
- remove all existing linux partitions
Obviously the kickstart installation is placing the bootloader on different target than the target on which OS is installing.
|Author:||Octocontrabass [ Wed Nov 15, 2017 12:20 pm ]|
|Post subject:||Re: grub problem|
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.
|Page 1 of 1||All times are UTC - 6 hours|
|Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group