Hide Forgot
The standard redhat 7.3 images are isntalled OK. An nfs/http system image updated with packages from updates (in a proper way) also works OK, EXCEPT when the kernel packages are updated. When kernel is updated and images re-generated this causes a strange bug - grub either do not get installed, or just doe not work. The messages on Atl-Ctl-F3 console are the same: * self.hostname=linuxserver * GRUB command root (hd0,0) install /grub/stage1 d (hd0) /grub/stage2 p (hd0,0)/grub/grub.conf * Writing X configuration No error messages printed (is it possible that error messages got somehow lost?) but grub does not get installed. All anaconda generated files are correct (they are the same as with original installation). Booting from in a rescue mode and then running /sbin/grub-install fixes the problem with non-installed grub.. P.S.RedHat images are regenerated as: idir="/home/redhat-7.3/cdrom/" export PYTHONPATH=/usr/lib/anaconda export PATH="$PATH:/usr/lib/anaconda-runtime" genhdlist $idir pkgorder $idir i386 >./pkgorder.txt buildinstall --pkgorder ./pkgorder.txt --comp dist-7.3 --version 7.3 $idir
In addition: the described problem with non-installed grub happens during kickstart installation.
The /sbin/grub-install uses these command to install grub: root (hd0,0) setup --stage2=/boot/grub/stage2 --prefix=/grub (hd0) quit
Note that this is a very unsupported configuration; unfortunately, the kernel tends to change in ways that can't be predicted in advance by the installer... If you look at tty5, do you see anything in the grub shell output along the lines of "file does not exist" or similar? If so, then you need to add some sync()'s in bootloader.py before grub-install is run.
It gives this error on tty5: ------------------------------------------------------- grub> root (hd0,0) Filesystem type is ext2fs, partition type 0x83 grub> install /grub/stage1 d (hd0) /grub/stage2 p (hd0,0)/grub/grub.conf Error 2:Bad file or directory type ------------------------------------------------------- If I add in %post anaconda script this: /sbin/grub --batch --device-map=/boot/grub/device.map <<EOF root (hd0,0) setup --stage2=/boot/grub/stage2 --prefix=/grub (hd0) quit EOF which is translated to ----------------------------------------------- grub> root (hd0,0) Filesystem type is ext2fs, partition type 0x83 grub> setup --stage2=/boot/grub/stage2 --prefix=/grub (hd0) Checking if "/grub/stage1" exists... yes Checking if "/grub/stage2" exists... yes Checking if "/grub/e2fs_stage1_5" exists... yes Running "embed /grub/e2fs_stage1_5 (hd0)"... 22 sectors are embedded. succeeded Running "install --stage2=/boot/grub/stage2 /grub/stage1 d (hd0) (hd0)1+22 p ( hd0,0)/grub/stage2 /grub/grub.conf"... succeeded Done. ------------------------------------------ Everything works OK and grub gets sucessfully installed.
And with the original Redhat 7.3 image the command install /grub/stage1 d (hd0) /grub/stage2 p (hd0,0)/grub/grub.conf installs grub just fine. No that "Error 2:Bad file or directory type" error message.
In addition: I would also recommend to modify anaconda to print an error message if grub installation failed. Currently - even if it failed - the screen looks as everything is OK and computer just does not boot.
I also tested on SCSI computer. Same poblem. The grub command install /grub/stage1 d (hd0) /grub/stage2 p (hd0,0)/grub/grub.conf command does not work on image with updated kernel and adding the code below to %post section is required to make a booting system. /sbin/grub --batch --device-map=/boot/grub/device.map <<EOF root (hd0,0) setup --stage2=/boot/grub/stage2 --prefix=/grub (hd0) quit EOF I have a question: is it possible that grub has some hidden/undocumented dependance on kernel version?
The newer kernel is less aggressive about actually writing blocks to disk so you have to be more aggressive about syncing to get the blocks written to disk before grub runs. This is done in our current release but is not a problem with Red Hat Linux 7.3 as shipped; changing the kernel used for the installer is not really a supported configuration due to the multitude of things which can change over an errata cycle for a release.
Time tracking values updated