Description of problem: If you try to install (not upgrade) over the top of existing raid devices, the anaconda install will fail with a python exception. This can be worked around if in the %pre scriptlet one zeros the raid superblock. It would be desirable to have a feature whereby one could tell anaconda to just ignore the existing raid devices. Something like: clearpart --raiddevs would be great. The problem was discussed in the issue tracker at: https://enterprise.redhat.com/issue-tracker/? module=issues&action=view&tid=17840&gid=292 And in the following emails to the kickstart list: https://listman.redhat.com/pipermail/kickstart-list/2003-April/007892.html https://listman.redhat.com/pipermail/kickstart-list/2003-April/007921.html Version-Release number of selected component (if applicable): How reproducible: Every time. Steps to Reproduce: 1. Install a system with raid using kickstart. 2. Run the same kickstart on the same system. Actual results: You will receive a python exception. Expected results: The install should have reinstalled just fine. Additional info:
By George, I think I've got it. In partitions.py, there are the lines if tmp and tmp.type == REQUEST_RAID: boot = [] for member in tmp.raidmembers: boot.append(self.getRequestByID(member)) elif tmp: boot = [tmp] else: boot = [] My attempt to debug the process show that the boot.append(self.getRequestByID(member)) line makes boot be an array of None types (with as many Nones as partitions in the raid) and that it is because the IDs stored in tmp.raidmembers don't correspond to any actual partition IDs in self. Why that is happening, I don't know yet. Is there a way in KickStart to make Anaconda launch the debugger at the very beginning? It would really come in handy.
I'm new to this bug and it's been a while without any activity, so I'll ask the obvious question. Have you tried this against a recent Rawhide, Fedora Core, or RHEL? There's been a pile of changes so it's hard to say whether or not this has been inadvertently fixed since the bug was originally reported.
*** Bug 149992 has been marked as a duplicate of this bug. ***
Going to try it this weekend.(In reply to comment #2) > I'm new to this bug and it's been a while without any activity, so I'll ask the > obvious question. Have you tried this against a recent Rawhide, Fedora Core, or > RHEL? There's been a pile of changes so it's hard to say whether or not this > has been inadvertently fixed since the bug was originally reported. Going to try with Fedora Core 3 this weekend.
Well it still crashes with FC3, see the bug which has just been closed as a duplicate of this one.
I have a potential fix for this in testing here. I believe it's caused by the same problem as 156283. Stay tuned.
Committed a potential fix to CVS. Please try with fc4 when available and let me know.
This problem has been fixed in Rawhide.