Description of problem: When kickstarting a server we get a anaconda crash saying this is most likely a bug. We installed a machine using raid for everything, including swap. Upon install it runs the autopartitionexecute script and fails. It might be having problem seeing the size of the raid volumes. Version-Release number of selected component (if applicable): RHEL 4U4 with satellite 4.1.5 kickstarting the machine How reproducible: Every time. Steps to Reproduce: 1. Put RHEL 4u4 WS disk in machine. 2. Boot machine. 3. Specify kickstart files. 4. Wait and watch. Actual results: Systems locks up and gives me the option to save the trace log. Expected results: System should install. Additional info: Here is the partition layout in the kickstart file: partition raid.06 --onpart=sdb3 partition raid.04 --onpart=sdb2 partition raid.08 --onpart=sdb5 partition raid.07 --onpart=sda5 partition raid.03 --onpart=sda2 partition raid.02 --onpart=sdb1 partition raid.01 --onpart=sda1 partition /d2 --fstype=ext3 --onpart=sdb6 --noformat partition raid.05 --onpart=sda3 partition /d1 --fstype=ext3 --onpart=sda6 --noformat raid /boot --level=1 --device=md0 --fstype=ext3 raid.01 raid.02 raid swap --level=1 --device=md3 --fstype=swap raid.07 raid.08 raid swap --level=1 --device=md2 --fstype=swap raid.06 raid.05 raid / --level=1 --device=md1 --fstype=ext3 raid.03 raid.04
Please attach the traceback to this bug report so we can see exactly what the failure case is.
Created attachment 150613 [details] anaconda trace log Sorry, I thought I had attached it when I opened this ticket.
I don't see how this should be caused by the --noformat flags. It's erroring out on the partition line with raid.06 and raid.05. Have you tried restricting it to just a single swap filesystem and seeing if that causes the error to go away?
Yea, I removed that raid.05 and raid.06 as well as the "raid swap" line. One thing I did notice is that it still tried to create the raid "md2" but it used sda2 and sdb5.
Just to help out. Here is the previous kickstart used to create the partitions: clearpart --all --initlabel part raid.07 --size=2000 --ondisk=sda part raid.05 --size=2000 --ondisk=sda part /d1 --fstype=ext3 --size=1 --grow --ondisk=sda part raid.08 --size=2000 --ondisk=sdb part /d2 --fstype=ext3 --size=1 --grow --ondisk=sdb part raid.06 --size=2000 --ondisk=sdb part raid.03 --size=8000 --ondisk=sda part raid.02 --size=120 --ondisk=sdb part raid.01 --size=120 --ondisk=sda part raid.04 --size=8000 --ondisk=sdb raid swap --level=1 --device=md2 --fstype=swap raid.06 raid.05 raid /boot --level=1 --device=md0 --fstype=ext3 raid.01 raid.02 raid / --level=1 --device=md1 --fstype=ext3 raid.03 raid.04 raid swap --level=1 --device=md3 --fstype=swap raid.07 raid.08 And here is whta the new kickstart config looks like: part raid.01 --onpart=sda1 part raid.06 --onpart=sdb3 part raid.03 --onpart=sda2 part /d1 --fstype=ext3 --onpart=sda6 --noformat part raid.05 --onpart=sda3 part raid.02 --onpart=sdb1 part raid.08 --onpart=sdb5 part raid.07 --onpart=sda5 part raid.04 --onpart=sdb2 part /d2 --fstype=ext3 --onpart=sdb6 --noformat raid swap --level=1 --device=md2 --fstype=swap raid.06 raid.05 raid /boot --level=1 --device=md0 --fstype=ext3 raid.01 raid.02 raid swap --level=1 --device=md3 --fstype=swap raid.07 raid.08 raid / --level=1 --device=md1 --fstype=ext3 raid.03 raid.04
Some testing reveals that this is also a bug in RHEL5 (and Fedora as well). I've cloned bug 235279 for tracking this issue on RHEL5. I will be committing a fix to Fedora and attaching a patch to the cloned bug to fix this issue. For RHEL4, I'm going to need to do some further work. The issue is the same, but the code is completely different. I'll attach a patch to this bug when I have one ready. I can also provide an updates image at that time if the customer would like to test it out.
Could you please have the customer download http://people.redhat.com/clumens/233308.img, put it on a floppy or USB key drive, and add the "updates" option to the boot parameters? I believe this should fix the issue you are seeing here.
is there a way that we can update the stage2.img file with new autopart.py file. to avoid using the manual updates boot option? as is, we have to manually update each install which is okay except we have hundreds of installs to do and we'd like to avoid manual steps if possible. thanks..jeff davis, hess
a new cd1 for rehdat 4 update 4 with updated autopart.py would also work thanks....jeff
when running updated autopart.py we get the following error File "/usr/lib/anaconda", line 362, in ? import dispatch File "/usr/lib/anaconda", line 26, in ? from autopart import doAutoPartition ImportError: cannot import name doAutoPartition install exited abnormally sending terminal signal.....done : : you may safely reboot your system
seems we had a bad update floppy so error ile "/usr/lib/anaconda", line 362, in ? import dispatch File "/usr/lib/anaconda", line 26, in ? from autopart import doAutoPartition ImportError: cannot import name doAutoPartition install exited abnormally sending terminal signal.....done seems to be alleviated but we'd still like make the update occur without manual intervention of loading floppy. regards...jeff
Let's verify that the updates.img fixes the problem before figuring out a way to get this more automated.
sounds good latest status is that we've run 2 kickstarts using the 233308.img file as updates floppy. these seem to be working well except for the automation. will run more on monday to further test the problem is fixed. regards....jeff
two more kickstarts run using updates floppy.....jeff
Created attachment 152166 [details] patch to fix raid probing Attaching a patch for my future reference to fix this bug in an update release. This is the same as the contents of the update image I also linked in this bug report, so there's nothing the reporter needs to do here.
install method is http
You can download the image I previously linked in this bug report, rename it to updates.img, and put it in the /images directory of your HTTP install tree. anaconda should pick that up and use it in the same way that updates= works in RHEL5.
does this work for rhel4 update 4?
It should. The /usr/share/doc/anaconda-*/install-methods.txt file mentions this method for updating.
do i still need to add the "updates" option to the boot parameters? or will placing updates.img in RedHat/base directory automatically cause update to occur. if i leave updates option in boot parameter will it still look for floppy disk and halt the automatic nature of the kickstart? thanks....jeff
You'll need to remove the updates option or the installer will stop and ask you for the updates disk. anaconda should look for the updates.img in RedHat/base automatically.
is update in redhat 4 update 5 ? if not, still put updates.img into redhat 4 update 5 directory as described earlier?
This fix is not included in RHEL 4.5, so you will have to use the updates.img as described above. It is currently slated for possible inclusion in RHEL 4.6.
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2007-0816.html