Bug 503310
|
Description
Allen Kistler
2009-05-31 08:31:48 UTC
Created attachment 346022 [details]
Really simple ks without any storage lines (w/password=password)
I'll attach some files from one of my "real-world" examples to provide something tangible. The disks are laid out as follows:
sda1 RAID-1 md0 /boot
sdb1
sda2 swap
sdb2 swap
sda3 RAID-1 md1 lvm (assorted and variable uses)
sdb3
sda4 RAID-1 md2 / (currently F9)
sdb4
It's a little weird maybe, but not too weird.
Created attachment 346023 [details]
i386 Preview anaconda.log (ks works)
Created attachment 346024 [details]
i386 Preview program.log (ks works)
Created attachment 346025 [details]
i386 Preview storage.log (ks works)
Created attachment 346026 [details]
i386 Preview syslog (ks works)
Created attachment 346027 [details]
i386 RC2 anaconda.log (ks doesn't work)
Created attachment 346028 [details]
i386 RC2 program.log (ks doesn't work)
Created attachment 346029 [details]
i386 RC2 storage.log (ks doesn't work)
Created attachment 346030 [details]
i386 RC2 syslog (ks doesn't work)
Adding to F11AnacondaBlocker. Although I like to do manual layout (my maze of twisty little machines are all different), I think the RAID config is lost before the manual part starts, so it would affect more people than just my use case. It's unfortunately really too late to add things to F11AnacondaBlocker unless they are data corrupters or prevent installation for a very large percentage of users. Re: Comment 11 Even though it's late to report a bug like this, it has only recently occurred. It didn't/doesn't occur on installations from the Preview DVD, just the RC2 DVD. (I didn't try the RC1 DVD, though.) That's why I included logs from the Preview for comparison, i.e., to compare to a working installation. I think that the bug would affect anyone doing kickstart installations that reuse existing RAID. My use case was just one example. I understand it's a judgment call, but how large does a very large percentage of users have to be? Would it at least be large enough to include in the Release Notes as "kickstart installation with preexisting RAID arrays is not supported." It's a pretty drastic statement for a final release. I'm not trying to be argumentative. I'm just wondering what the best way to handle the situation is. Mostly I'd recommend not ignoring it, because I would expect questions later and as of now it's a known issue. ackistler: we can certainly work up an entry on the Common_F11_Bugs page that describes this issue (see https://fedoraproject.org/wiki/Common_F11_bugs). I'll be happy to help draft content if you like. Alternatively, you can edit that page directly if you are comfortable ... and we can modified as needed then. I can confirm 1) the behavioural difference when running a semi-automated kickstart install on top of a set of RAID disks, and 2) this is indeed a change from F10. Certainly worthy of a Common_F11_Bugs entry. The tests I performed (with results) are below. = Test#1 = Perform manual install on top of raid0 installed disks == Actions == 1) Install raid0 setup 2) Initiate a manual install and select "Custom partition" == Results == * /dev/md0 is setup already, see http://jlaska.fedorapeople.org/raid0-no-ks.png = Test#2 = Perform a semi-automated kickstart install (without any partition options) on top of raid0 installed disks. Proceed manually when prompted for disk partitioning. == Actions == 1) Install raid0 setup 2) Initiate a new kickstart install with *no* ks partition options, when prompted select "Custom partition" == Results == * /dev/md0 is *not* setup already, see http://jlaska.fedorapeople.org/raid0-ks.png James: You can test F11-rc2 vs. F11-preview, too, not just vs. F10. RAID config is okay in the Preview, but lost in RC2. I'll try one more use case on my own to confirm that this bug is as bad as I think it could be, i.e., with a fully-automated ks install over existing RAID, I expect the install to just bomb. Then I'll think up what to say on the wiki. Give me another day or so to make it happen. added to common issues: https://fedoraproject.org/wiki/Common_F11_bugs#503310 i don't think i phrased it very well, please do feel free to improve my wording. thanks. Created attachment 346182 [details]
ks to reuse existing raid-1 arrays
I was able to verify the worst case I could think of. Kickstarting and reusing existing RAID doesn't work at all. I set up a test machine in F9 as follows:
sda1
sdb1 md0 RAID-1 /boot
sda2 swap
sdb2 swap
sda3
sdb3 md1 RAID-1 F9 /
sda4
sdb4 md2 RAID-1 unused (to be F11 /)
Then using the attached kickstart, the idea is to set up dual-boot with F11.
The installation fails using F11-rc2.
After storage detection:
The following error was found while parsing your kickstart configuration
The following problem occurred on line 24 of the kickstart file
No preexisting RAID device with the name "md0" was found
The installation succeeds using F11-Preview.
Created attachment 346183 [details]
i386 Preview anaconda.log (ks works)
Created attachment 346184 [details]
i386 Preview program.log (ks works)
Created attachment 346185 [details]
i386 Preview storage.log (ks works)
Created attachment 346186 [details]
i386 Preview syslog (ks works)
Created attachment 346187 [details]
i386 RC2 anaconda.log (ks doesn't work)
Created attachment 346188 [details]
i386 RC2 program.log (ks doesn't work)
Created attachment 346189 [details]
i386 RC2 storage.log (ks doesn't work)
Created attachment 346190 [details]
i386 RC2 syslog (ks doesn't work)
Changed bug name to reflect that *all* kickstarting, including fully automated, loses RAID info in RC2. (In reply to comment #16) > added to common issues: > > https://fedoraproject.org/wiki/Common_F11_bugs#503310 > > i don't think i phrased it very well, please do feel free to improve my > wording. thanks. Thanks Adam, your phrasing matches my current understanding of this issue. The latest attached logs seem to point to the same issue as in https://bugzilla.redhat.com/show_bug.cgi?id=503681#c9. (In reply to comment #27) > (In reply to comment #16) > > added to common issues: > > > > https://fedoraproject.org/wiki/Common_F11_bugs#503310 > > > > i don't think i phrased it very well, please do feel free to improve my > > wording. thanks. > > Thanks Adam, your phrasing matches my current understanding of this issue. Heh. Thanks, James. The version you like is mine. yeah, it's much better than mine =) -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers Doh! Nice find on both these issues (RAID and LVM). I posted a patch which should fix the problem for a review. If you want you can try this updates file, it is for version .58 of anaconda: http://rvykydal.fedorapeople.org/updates.clearpart.img Doh! I just noticed I screwed up the order of the sd.2 and sd.3 partitions in Comment 17. Oh, well.... Re: Comment 32 Confirmed. The patch works for me. I actually tried it with two ks files, the one included and the one I'll actually use when I install real systems. You can set this bug to MODIFIED, too. Thanks for the effort. it gets set to MODIFIED only once the code is actually committed somewhere 'live', not just to a random test image :) -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers Should be fixed in next build of anaconda for rawhide. This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle. Changing version to '11'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping Re: Comment 36 Moving from F11 back to rawhide. It only makes sense there. According to koji, there have been no builds for anaconda since 2 June. Therefore this bug cannot be fixed yet. Am I missing something? You are missing that bugs are allowed to be closed as soon as a fix is committed to CVS, in Rawhide. It would have been nice to have an explanation of the closure, though - it helps make it clear for cases like this. Andy? Unable to verify fix in anaconda-12.0 due to Bug 509572 Unable to verify fix in anaconda-12.1 due to Bug 510172 Putting to modified, fix has been pushed into anaconda 12.0. I was able to verify the fix in anaconda-12.3 with today's (21 July 2009) boot.iso. Closing... Does this mean that the fix is not going to be available for Fedora 11? Is there a way for me to make this fix available in Fedora 11? (In reply to comment #43) > Does this mean that the fix is not going to be available for Fedora 11? > Is there a way for me to make this fix available in Fedora 11? The update in Comment #32 still seems to be available. It's not really an "official" fix, but it might get you by if you really need to kickstart F11. Since it's in a developer's "people" directory, there's no guarantee it will stay available. Otherwise manual F11 installs work fine. Since anaconda runs only from the installation medium, there would have to be a re-issuance of the F11 CD/DVD images to get a fix into F11. That won't happen until there's a respin. Since I've never used a respin myself, I can't comment on whether even a respin would have an updated anaconda in it. HTH |
