Red Hat Bugzilla – Bug 431254
Fails to configure correct boot device with autopart + bootloader defined in kickstart
Last modified: 2010-10-22 18:13:33 EDT
Description of problem:
when using a kickstart file that has autopart and bootloader grub location=mbr
driverorder=xxx, the server receives a grub error at first boot after the
install is complete. Using same kickstart command lines with RHEL4u6 snapshot
4, the server will boot appropriately.
This requires CCISS as local disks and a SAN attached device (sda)
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Configure system to have both cciss and san attached devices, install to
locak disk (cciss)
2. Use following kickstart :
clearpart --all --initlabel
bootloader grub --location=mbr --driveorder=cciss/c0d0
auth --useshadow --enablemd5
Grub fails to install itself to correct mbr
Bootloader installs correctly.
/mnt/sysimage/boot/grub $ cat device.map
# this device map was generated by anaconda
/mnt/sysimage/boot/grub $ cat menu.lst
# grub.conf generated by anaconda
# Note that you do not have to rerun grub after making changes to this file
# NOTICE: You have a /boot partition. This means that
# all kernel and initrd paths are relative to /boot/, eg.
# root (hd1,0)
# kernel /vmlinuz-version ro root=/dev/VolGroup00/LogVol00
# initrd /initrd-version.img
serial --unit=0 --speed=9600
terminal --timeout=5 serial console
title Red Hat Enterprise Linux Server (2.6.18-53.el5)
kernel /vmlinuz-2.6.18-53.el5 ro root=/dev/VolGroup00/LogVol00 console=ttyS0
Should be setup on hd0,0.
This request was evaluated by Red Hat Product Management for
inclusion, but this component is not scheduled to be updated in
the current Red Hat Enterprise Linux release. If you would like
this request to be reviewed for the next minor release, ask your
support representative to set the next rhel-x.y flag to "?".
There's no indication here that there's anything wrong with where the bootloader
is being written. /boot/ is going to /dev/sda1 , which is allowed by this
kickstart, and that's why the bootloader configuration is pointing at sda. If
you want /boot on the cciss device, you need to specify that. There's nothing
going wrong here.
HP has re-tested this and reports that nothing is being placed on /dev/sda1 -
all of grub is being placed on cciss/c0d0 (which is the desired behavior),
however the system does not boot after installation.
*something* is going wrong here.
Can you please attach the anaconda logs from the installation.
Does reinstalling the grub on the device fix the problem?
HP confirms that reinstalling grub on the cciss drive allowed the system to boot
up properly. I'm attaching the logs that you've asked for.
Created attachment 311750 [details]
Anaconda log file from install
Created attachment 311751 [details]
Anaconda syslog file from install
Created attachment 311752 [details]
Anaconda xlog file from install
Created attachment 311753 [details]
Anaconda kickstart file from install
I'd like to estimate possibility of fixing the bug but I am not able to reproduce it - seems to be cciss specific. Would it be possible to reproduce the bug with update image file containing patches for getting more debugging information? The files are:
http://rvykydal.fedorapeople.org/updates.driveorder.img for RHEL 5.4
http://rvykydal.fedorapeople.org/updates.driveorderU3.img for RHEL 5.3.
You can use them by adding updates=<URL> to anaconda boot parameters. After reproducing, I'd need to have this files
collected from the system.
Adam, David, if one of you has access to cciss hardware and can try Radek's updates.img, we'd appreciate the feedback.
Event posted on 10-27-2009 05:35pm EDT by dwa
Looks like HP's previous feedback didn't get automatically mirrored to
BZ. Re-posting it here:
We tried this with RHEL 5.4 and were not able to reproduce the issue.
After installing OS correctly (/boot in local cciss, LVM in both cciss and
SAN) the system booted without any problem. We also checked the
grub/menu.lst file and the root is specified correctly as hd(0,0).
This event sent from IssueTracker by dwa
Based on the feedback in the previous comment, I'm closing this BZ. Thanks for verifying the behavior.