* Cambridge-re0801.nightly (internal)
* kickstart install
* cpqarray box
* using the --onpart option
I'm getting a traceback (during kickstart validation i presume).
Traceback (most recent call last):
File "/usr/bin/anaconda", lin 986, in ?
File "/usr/lib/anaconda/kickstart.py", line 1239 in setInstallData
File "/usr/lib/anaconda/kickstart.py", line 691 in ReadKickstart
raise SyntaxError, "Unrecognized ks command: %s\n On the line: %s" %
Syntax error: unrecognized ks command: part
On the line: part / --size 1024 --onpart ida/c0d0p2 --noformat
Here is the partitioning section of the kickstart:
# clearpart is disabled
part /last --size 1024 --onpart ida/c0d0p1 --noformat
part / --size 1024 --onpart ida/c0d0p2 --noformat
part swap --onpart ida/c0d0p3
Note the order: anaconda complained on the *second* part command.
Also note that tons of kickstart cases for this same build have passed without
hitting this. Two things make this case special:
- the onpart option
- the cpqarray
Did you perhaps not have an ida/c0d0p3 partition? There was some exception
handling changed in Cambridge that was being over-zealous.
I'm pretty sure that the partition was there. This case does one install with
"/" and "/next" partitions. Then it does a second install with "/" on the old
/next partition and "/last" on the old / partition. The devices used for the
--onpart option would have been pulled from /etc/mtab.
I'll rerun the testcase just to be sure.
If this is the case, then the error message is very misleading.
Like I said, the exception catching was a bit broad there. I've fixed that
(should show up in tomorrow's nightly I think -- I'll build an anaconda before I
leave to ensure it). Then again, it could be some other exception entirely and
it would have been completely covered up :/
So results from tomorrow's tree would be interesting :)
I'm poking around on VC2 post-traceback. The partition appears in
/proc/partitions, and I am able to mount it manually.
Nothing odd appears in anaconda.log.
the cpqarray has nothing to do with it. The case has failed on several different
The traceback looks exactly the same in Cambridge-re0805.nightly
A slightly simpler testcase fails also (this one has no --noformat option).
Fixed for real