Bug 431254 - Fails to configure correct boot device with autopart + bootloader defined in kickstart
Fails to configure correct boot device with autopart + bootloader defined in ...
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: anaconda (Show other bugs)
All Linux
high Severity high
: rc
: ---
Assigned To: Radek Vykydal
: Reopened
Depends On:
Blocks: 391501 499522 531114
  Show dependency treegraph
Reported: 2008-02-01 14:59 EST by Adam Stokes
Modified: 2010-10-22 18:13 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-10-28 09:41:23 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Anaconda log file from install (429.11 KB, text/plain)
2008-07-14 14:58 EDT, Gary Case
no flags Details
Anaconda syslog file from install (32.35 KB, text/plain)
2008-07-14 15:01 EDT, Gary Case
no flags Details
Anaconda xlog file from install (57.63 KB, text/plain)
2008-07-14 15:03 EDT, Gary Case
no flags Details
Anaconda kickstart file from install (1.45 KB, text/plain)
2008-07-14 15:04 EDT, Gary Case
no flags Details

  None (edit)
Description Adam Stokes 2008-02-01 14:59:07 EST
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):

How reproducible:

Steps to Reproduce:
1. Configure system to have both cciss and san attached devices, install to
locak disk (cciss)
2. Use following kickstart :
lang en_US
langsupport en_US
key --skip
network --bootproto=dhcp 
nfs --server=engarchive.rdu.redhat.com
keyboard "us"
zerombr yes
clearpart --all --initlabel
bootloader grub --location=mbr --driveorder=cciss/c0d0
rootpw password
auth --useshadow --enablemd5
firewall --disabled
timezone America/New_York

@ Base

Actual results:
Grub fails to install itself to correct mbr

Expected results:
Bootloader installs correctly.

Additional info:
/mnt/sysimage/boot/grub $ cat device.map
# this device map was generated by anaconda
(hd0)     /dev/cciss/c0d0
(hd1)     /dev/sda
/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)
       root (hd1,0)
       kernel /vmlinuz-2.6.18-53.el5 ro root=/dev/VolGroup00/LogVol00 console=ttyS0
       initrd /initrd-2.6.18-53.el5.img

Should be setup on hd0,0.
Comment 1 RHEL Product and Program Management 2008-02-01 17:37:53 EST
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 "?".
Comment 5 Peter Jones 2008-04-30 14:50:48 EDT
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.
Comment 6 David Aquilina 2008-05-02 17:45:19 EDT
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. 
Comment 7 Joel Andres Granados 2008-06-11 14:49:40 EDT
Can you please attach the anaconda logs from the installation.
Does reinstalling the grub on the device fix the problem?
Comment 8 Gary Case 2008-07-14 14:57:25 EDT
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.
Comment 9 Gary Case 2008-07-14 14:58:23 EDT
Created attachment 311750 [details]
Anaconda log file from install
Comment 10 Gary Case 2008-07-14 15:01:00 EDT
Created attachment 311751 [details]
Anaconda syslog file from install
Comment 11 Gary Case 2008-07-14 15:03:20 EDT
Created attachment 311752 [details]
Anaconda xlog file from install
Comment 12 Gary Case 2008-07-14 15:04:10 EDT
Created attachment 311753 [details]
Anaconda kickstart file from install
Comment 16 Radek Vykydal 2009-10-20 10:18:13 EDT
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.
Comment 17 Denise Dumas 2009-10-27 16:06:28 EDT
Adam, David, if one of you has access to cciss hardware and can try Radek's updates.img, we'd appreciate the feedback.
Comment 18 Issue Tracker 2009-10-27 17:35:55 EDT
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 
 issue 134184
Comment 19 Denise Dumas 2009-10-28 09:41:23 EDT
Based on the feedback in the previous comment, I'm closing this BZ. Thanks for verifying the behavior.

Note You need to log in before you can comment on or make changes to this bug.