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