Bug 250301 - livecd installer does not honor / format option
livecd installer does not honor / format option
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
All Linux
low Severity urgent
: ---
: ---
Assigned To: Jeremy Katz
Fedora Extras Quality Assurance
Depends On:
Blocks: F8Test3
  Show dependency treegraph
Reported: 2007-07-31 13:47 EDT by Jane Dogalt
Modified: 2007-11-30 17:12 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-09-06 11:48:45 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
probably less than ideal solution, but it might work (4.09 KB, patch)
2007-08-01 07:20 EDT, Jane Dogalt
no flags Details | Diff
better patch, best of both worlds, initial testing suggests it works (3.42 KB, patch)
2007-08-01 15:24 EDT, Jane Dogalt
no flags Details | Diff

  None (edit)
Description Jane Dogalt 2007-07-31 13:47:24 EDT
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:
Actual results:

Expected results:

Additional info:
Comment 1 Jane Dogalt 2007-08-01 07:20:00 EDT
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.
Comment 2 Chris Lumens 2007-08-01 11:06:43 EDT
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.
Comment 3 Jane Dogalt 2007-08-01 11:37:41 EDT
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.
Comment 4 Jane Dogalt 2007-08-01 11:41:02 EDT
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.
Comment 5 Jane Dogalt 2007-08-01 13:34:19 EDT
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).
Comment 6 Jane Dogalt 2007-08-01 13:59:55 EDT
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.
Comment 7 Jane Dogalt 2007-08-01 15:24:23 EDT
Created attachment 160456 [details]
better patch, best of both worlds, initial testing suggests it works
Comment 8 Jane Dogalt 2007-08-01 15:25:35 EDT
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.
Comment 9 Jane Dogalt 2007-08-01 15:53:39 EDT
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.
Comment 10 Jane Dogalt 2007-08-01 17:43:29 EDT
Comment 11 Jane Dogalt 2007-08-03 01:29:26 EDT
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.
Comment 12 Jane Dogalt 2007-08-11 00:53:57 EDT
This should definitely be added to the known f7 issues page ASAP


(unless there is a more appropriate place I am unaware of)
Comment 13 Jeremy Katz 2007-09-06 11:48:45 EDT
This actually got applied prior to test1

Note You need to log in before you can comment on or make changes to this bug.