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): anaconda-11.1.2.93 How reproducible: 100% 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 install nfs --server=engarchive.rdu.redhat.com --dir=/engineering/archives2/released/RHEL-5-Server/U1/i386/os keyboard "us" text zerombr yes clearpart --all --initlabel autopart bootloader grub --location=mbr --driveorder=cciss/c0d0 rootpw password auth --useshadow --enablemd5 firewall --disabled timezone America/New_York reboot %packages @ 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 #boot=/dev/cciss/c0d0 default=0 timeout=5 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.
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 and 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 /var/log/anaconda.log /root/anaconda-ks.cfg /boot/grub/device.map /boot/grub/grub.conf 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 issue 134184
Based on the feedback in the previous comment, I'm closing this BZ. Thanks for verifying the behavior.