Description of problem: The Fedora-7-Live-i686 LiveCD installer (anaconda) will let you choose a destination volume, with mountpoint '/', and have it not be formatted. It will then proceed to format it. This is related to the double-formatting bug which I posted and fixed a while back. I don't know if this has been fixed already in anaconda cvs. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Created attachment 160404 [details] probably less than ideal solution, but it might work This patch is somewhat better than the first one I posted to anaconda-devel, which just added a couple extra lines of warning to queryNoFormatPreExisting. But this does appear to work. I haven't tested on the non-livecd case though. This seems like almost a bad enough bug to be worth applying and testing this patch for f8t1, under the assumption that it is highly probable a better solution will be in place for f8t2. Or perhaps more likely and better, this patch will inspire someone else to create a better patch more quickly than they would have otherwise.
I've committed a fix that checks this where we do lots of other checks, but it's very difficult to test livecd fixes. We'll have to verify once a new anaconda package has been built.
Note, I'm leaving this comment in tact just for fun. I had a mid-air collision. What is most important, is my last comment about flags.livecd. Please take note of it, and either refute or confirm. --- I just noticed that in the files in which the patch uses os.environ.has_key, that os is not explicitly imported at the top. Since it did work for me, patching the f7livecd installer, that must(?) mean that os is available via one of the things that _has_ been imported(?) This basically just reflects my lack of experience with python. What I'm getting at is that if this patch is used, make sure to test the text/lvm/raid code paths which I did not. Or even better, perhaps find something more elegant than the LIVE_BLOCK environment variable mechanism used to detect livecd installer versus traditional installer. Note that I think flags.livecd is some leftover cruft from kadischi days, and should probably be extricated, as it only seemed to serve to confuse me.
Just to reiterate, I'm pretty sure I'm right (until convinced otherwise). I.e. flags.livecd (which was the first method I tried to use for this patch), involves the old command line flag to anaconda, when used with kadischi. Which is not relevent in this case (or ever anymore AFAIK). I even went as far as having a version of my patch which more or less did a printf of request.mountpoint and flags.livecd. The latter was 0, which reminded me that flags.livecd is kadischi junk, and of no contemporary usefulness. yes I did have flags imported just as in bootloader.py.
to clarify, that means the change you put in cvs isn't going to do anything. FYI- the way I tested mine, was to generate a patch, which even though against top of trunk cvs, applied easily to the installed anaconda in the f7-livecd when booted under qemu. I used a -hdb fat:ro:/path/holding/patch , and a newly created image, which I fdisked (and mkfs.ext3-d) before running the installer. At which point I was able to verify that my patch worked. (and more importantly, how my earlier patch attempting to use flags.livecd failed to work). Of course what was worse is I went through the exact same process when I fixed the double root format in the first place, but I forgot in the interim how useless flags.livecd is. I suppose you might be able to add a commandline arg to anaconda in liveinst.sh, which would make flags.livecd do something, but you would have to make sure first that it doesn't cause any other behavior related to its original kadischi purpose (which was in conjunction with rootpath, entirely outside of the installer scenario, i.e. used to create livecds, not to install from them).
Also, another thing that seems to be wrong with your patch is the comparison with mustbeonlinuxfs. That is overly restrictive I think. I'm pretty sure it is fine e.g. if you have a separate /usr (or whatever else) that does not get scheduled for formatting. This is because the way the installer works, is that after it dds the ext3 image to / (thus nuking it, i.e. you MUST 'format' it), it then does a copy of files to /usr if the user specified that. So, while I can't say I've actually tested any of that, or would personally bet the f8t1 release on it, that is my understanding of how things work.
Created attachment 160456 [details] better patch, best of both worlds, initial testing suggests it works
Here is a patch (to current cvs, unless more changes have been made recently) which takes the best aspects of your (clumens) patch, along with the subsequent comments I've made. I'm doing an install under qemu right now. It worked as desired when I tried to leave / unformatted, and it also worked as desired when I tried to leave a seperate /tmp unformatted (i.e. it let me do it). We'll see if after the install completes, if I can boot the system, and see the test files that I had placed in the pre-existing /tmp. I know jkatz is out of the office this week. I strongly urge you (redhat?) to review this somehow, and get it fixed for f8t1. The patch should be pretty clear. It adds a commandline arg --liveinst, creating flags.liveinst, which can be used as flags.livecd is so easily mistakenly thought to useful for. It also loosens the restriction on the check to what it actually needs to be (i.e. just /). I can and will answer any questions ASAP.
qemu test succeeded flawlessly. REVIEW AND APPLY ASAP! Before watching the prior fix go in, I didn't have the confidence to say something like this, but now I do! If the fedoraproject is so completely mismanaged that jkatz is the only person trusted and qualified to review this, then there is a serious problem. And definitely not just because he happens to be out of the office this week, and really shouldn't be bothered with this issue.
ty
I just want to make every attempt to make sure this gets fixed for f8t1 since it eats peoples root filesystems, specifically their /home that they thought was safe given the buggy UI behavior. So I'm going to attempt to add it to the f8t1 blocker. Also, it would be nice if my name got put in a changelog related to this, as I did put in quite a bit of work on it (a sleepless night even), which did translate into the code that fixed the problem, even if my patches weren't ultimately applied directly.
This should definitely be added to the known f7 issues page ASAP http://fedoraproject.org/wiki/Bugs/F7Common (unless there is a more appropriate place I am unaware of)
This actually got applied prior to test1
Prior to Test 1 OK. Fedora Core 7 then. I didn't see this bug report when it was filed against using Qemu to load CDs.