Bug 233308 - anaconda doesn't remove all invalid RAID requests under kickstart
anaconda doesn't remove all invalid RAID requests under kickstart
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: anaconda (Show other bugs)
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Chris Lumens
Depends On:
  Show dependency treegraph
Reported: 2007-03-21 11:27 EDT by Charlie Wyse
Modified: 2007-11-16 20:14 EST (History)
3 users (show)

See Also:
Fixed In Version: RHBA-2007-0816
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-11-15 11:35:42 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
anaconda trace log (90.58 KB, text/plain)
2007-03-21 15:22 EDT, Charlie Wyse
no flags Details
patch to fix raid probing (1.15 KB, patch)
2007-04-10 14:01 EDT, Chris Lumens
no flags Details | Diff

  None (edit)
Description Charlie Wyse 2007-03-21 11:27:37 EDT
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
Comment 1 Chris Lumens 2007-03-21 13:15:41 EDT
Please attach the traceback to this bug report so we can see exactly what the
failure case is.
Comment 2 Charlie Wyse 2007-03-21 15:22:48 EDT
Created attachment 150613 [details]
anaconda trace log

Sorry, I thought I had attached it when I opened this ticket.
Comment 3 Chris Lumens 2007-03-21 17:02:08 EDT
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?
Comment 4 Charlie Wyse 2007-03-21 18:13:02 EDT
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.  
Comment 5 Charlie Wyse 2007-03-22 12:16:30 EDT
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
Comment 7 Chris Lumens 2007-04-04 15:52:29 EDT
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.
Comment 8 Chris Lumens 2007-04-04 16:26:01 EDT
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.
Comment 11 jdavis 2007-04-05 10:51:40 EDT
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
Comment 12 jdavis 2007-04-05 10:53:00 EDT
a new cd1 for rehdat 4 update 4 with updated autopart.py would also work

Comment 13 jdavis 2007-04-05 11:14:48 EDT
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

Comment 14 jdavis 2007-04-05 12:11:11 EDT
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.

Comment 15 Chris Lumens 2007-04-05 13:04:51 EDT
Let's verify that the updates.img fixes the problem before figuring out a way to
get this more automated.
Comment 16 jdavis 2007-04-05 13:52:41 EDT
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.

Comment 17 jdavis 2007-04-09 15:42:00 EDT
two more kickstarts run using updates floppy.....jeff
Comment 18 Chris Lumens 2007-04-10 14:01:52 EDT
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.
Comment 21 jdavis 2007-04-24 15:22:36 EDT
install method is http
Comment 22 Chris Lumens 2007-04-24 15:54:53 EDT
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
Comment 23 jdavis 2007-04-24 16:59:21 EDT
does this work for rhel4 update 4?
Comment 24 Chris Lumens 2007-04-24 17:06:29 EDT
It should.  The /usr/share/doc/anaconda-*/install-methods.txt file mentions this
method for updating.
Comment 25 jdavis 2007-04-26 11:27:43 EDT
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?

Comment 26 Chris Lumens 2007-04-26 11:31:57 EDT
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
Comment 29 jdavis 2007-05-04 13:29:18 EDT
is update in redhat 4 update 5 ? if not, still put updates.img into redhat 4
update 5 directory as described earlier?
Comment 30 Chris Lumens 2007-05-04 13:51:11 EDT
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.
Comment 31 RHEL Product and Program Management 2007-05-09 01:29:40 EDT
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
Comment 36 errata-xmlrpc 2007-11-15 11:35:42 EST
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.


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