Bug 672265 - "Install to harddrive" fails with "not a live image"
"Install to harddrive" fails with "not a live image"
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
rawhide
All All
medium Severity high
: ---
: ---
Assigned To: Bruno Wolff III
AcceptedBlocker
:
: 673395 673430 674220 678767 (view as bug list)
Depends On:
Blocks: F15Alpha/F15AlphaBlocker 676904
  Show dependency treegraph
 
Reported: 2011-01-24 11:12 EST by John Reiser
Modified: 2011-04-18 09:49 EDT (History)
38 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 676904 (view as bug list)
Environment:
Last Closed: 2011-02-18 13:05:01 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
/var/log/messages from the livecd (254.81 KB, text/plain)
2011-01-26 15:31 EST, Brian Lane
no flags Details
losetup -a from the livecd (235 bytes, text/plain)
2011-01-26 15:32 EST, Brian Lane
no flags Details

  None (edit)
Description John Reiser 2011-01-24 11:12:11 EST
Description of problem: "Install to harddrive" from a LiveCD of rawhide for fedora 15 fails with message "Can't do live image installation unless running from a live image."



Version-Release number of selected component (if applicable):
livecd-tools-15.2-2.fc15.x86_64

How reproducible: every time


Steps to Reproduce:
1.download and burn http://alt.fedoraproject.org/pub/alt/nightly-composes/desktop/desktop-x86_64-20110123.17.iso
2.boot and login to GNOME shell
3.Activities > Applications > Install to ...
  
Actual results:"Can't do live image installation unless running from a live image."  The same message appears when running /usr/bin/liveinst from a text shell on VT2; and the shell also reports a Segmentation violation from zenity.



Expected results: install to harddrive


Additional info:
Comment 1 Brian Lane 2011-01-26 15:31:14 EST
This error is because there is no /dev/mapper/live-osimg-min which is created by the dracut script in /usr/share/dracut/modules.d/90dmsquash-live/dmsquash-live-root

This line appears to be failing:

echo "0 $( blockdev --getsz $BASE_LOOPDEV ) snapshot $BASE_LOOPDEV $OSMIN_LOOPDEV p 8" | dmsetup create --readonly live-osimg-min

I've attached the output of losetup -a and /var/log/messages, the relevant part is:

Jan 26 18:18:44 localhost kernel: [    3.506154] device-mapper: table: 253:1: snapshot: Cannot get COW device
Jan 26 18:18:44 localhost kernel: [    3.506157] device-mapper: ioctl: error adding target to table


I tried to manually setup the snapshot and got the same result, except that it said table: 253:3: instead of :1:

This is using the nightly livecd from 20110123.17

The dracut differences between f14 and rawhide are fairly minimal where livecd is concerned so I think the problem lies with device-mapper or something deeper.
Comment 2 Brian Lane 2011-01-26 15:31:58 EST
Created attachment 475479 [details]
/var/log/messages from the livecd
Comment 3 Brian Lane 2011-01-26 15:32:28 EST
Created attachment 475480 [details]
losetup -a from the livecd
Comment 4 Milan Broz 2011-01-26 15:47:36 EST
Cannot get COW device
means that second paramater - $OSMIN_LOOPDEV - is wrong (points to nonexistent device)

can you post:
echo $BASE_LOOPDEV ; blkid -p $BASE_LOOPDEV
echo $OSMIN_LOOPDEV ; blkid -p $OSMIN_LOOPDEV
?
Comment 5 Brian Lane 2011-01-26 16:04:32 EST
I'm pretty sure BASE_LOOPDEV is /dev/loop3 and OSMIN_LOOPDEV is /dev/loop1


/dev/loop3: LABEL="_desktop-x86_64-" UUID="a0516eda-8620-4fb1-ab01-5f06b78686d4" VERSION="1.0" TYPE="ext4" USAGE="filesystem"

And there is no output for /dev/loop1
Comment 6 Brian Lane 2011-01-27 23:43:20 EST
*** Bug 673395 has been marked as a duplicate of this bug. ***
Comment 7 Kenny Strawn 2011-01-28 08:37:44 EST
[liveuser@localhost ~]$ echo $BASE_LOOPDEV; blkid -p $BASE_LOOPDEV

The low-level probing mode requires a device
[liveuser@localhost ~]$ echo $OSMIN_LOOPDEV; blkid -p $OSMIN_LOOPDEV

The low-level probing mode requires a device
[liveuser@localhost ~]$ 

In my case, from a USB key running on the latest (20110126.16) image, returns nothing.
Comment 8 Kenny Strawn 2011-01-28 08:49:55 EST
And that previous comment is from a 32-bit Rawhide 20110126.16, not a 64-bit one.
Comment 9 Milan Broz 2011-01-28 14:08:13 EST
osmin.img in that livecd is corrupted in some format which is not recognized, it is unmoutable. (tried one from F14 and it works)

not sure where to reassign it, trying LiveCD component.
Comment 10 Kenny Strawn 2011-01-28 23:58:12 EST
Well then I guess I will try F14 and preupgrade to Rawhide as a workaround for now.
Comment 11 Brian Lane 2011-01-30 08:56:48 EST
*** Bug 673430 has been marked as a duplicate of this bug. ***
Comment 12 Bruno Wolff III 2011-01-31 10:05:46 EST
This is possibly an artifact of being built on an F14 system with only a rawhide squashfs. Kevin is going to be looking at moving the build system to rawhide shortly. (Possibly a few days after he gets back from FUDCON.)
osmin.img is compressed using xz which 2.6.38 kernels can mount. The liveOS uses a 2.6.38 kernel which is why the system runs at all (otherwise squashfs.img couldn't be mounted). I am not sure why the file wouldn't be mounted when liveinst is run. This may or may not be related to xz compression.
Comment 13 Bruno Wolff III 2011-01-31 10:53:10 EST
I was able to confirm that osmin.img is mountable from the live image. I didn't get to trying to do it in a way that liveinst should be able to use as that needed more time than I have right now.
Comment 14 Bruno Wolff III 2011-01-31 10:54:40 EST
Would running the F14 version of dracut break things?
Comment 15 Milan Broz 2011-01-31 11:17:48 EST
I am not sure what is dracut doing, but if you are able to mount osimg.min, it also must contain valid snapshot COW device in file (it starts with SnAp signature).

(If the file have no such signature, then shapshot creation fails with "Cannot get COW device" when accessing it trough loop as mentioned above.)
Comment 16 Bruno Wolff III 2011-01-31 12:21:14 EST
[root@games1 mnt1]# od -c osmin|more
0000000   S   n   A   p 001  \0  \0  \0 001  \0  \0  \0  \b  \0  \0  \0
0000020  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0
Comment 17 Chris Lumens 2011-02-01 12:56:14 EST
*** Bug 674220 has been marked as a duplicate of this bug. ***
Comment 18 Jim Meyering 2011-02-03 09:20:13 EST
FYI, I too have just encountered this bug.
Needed rawhide to test very latest btrfs against failing coreutils test...
Comment 19 Matěj Cepl 2011-02-03 13:13:03 EST
Me too. Hoped to reinstall completely busted Rawhide system :(
Comment 20 Bruno Wolff III 2011-02-07 11:16:28 EST
I spent some time this weekend looking at this, but I didn't understand enough about how osmin is used and the device mapper to be able to isolate what is happening.
It would be nice if a dracut or dm expert to take a look at this.
While live images don't seem to be release blockers, I think this would be a nice to have fixed for the alpha release.
Comment 21 Kenny Strawn 2011-02-07 22:01:36 EST
I think the problem is the coding of the scripts. Apparently, the scripts somehow use variables instead of the paths to the files when the variables themselves don't point to them.

I think a workaround would be:

Mount the live image in /mnt, then set the variables in the script to equal the paths to the live image.

Example patch for this would be (near the beginning of the script):

+++ mkdir /mnt/{osmin,base}
+++ mount -t btrfs /mnt/live/base.img /mnt/base -o loop #don't know for certain if it is base.img
+++ mount -t btrfs /mnt/live/osmin.img /mnt/osmin -o loop
+++ BASE_LOOPDEV=/mnt/loop0
+++ OSMIN_LOOPDEV=/dev/loop1

I will test this out when I boot the image and see what happens.
Comment 22 Kenny Strawn 2011-02-07 22:07:01 EST
Sorry, here's the corrected proposed patch that just might work (when I test it; again near the beginning of the script):

+++ mkdir /mnt/{osmin,base}
+++ mount -t btrfs /mnt/live/base.img /mnt/base -o loop
+++ mount -t btrfs /mnt/live/osmin.img /mnt/osmin -o loop
+++ BASE_LOOPDEV=/dev/loop0
+++ OSMIN_LOOPDEV=/dev/loop1

I am currently downloading the image right now; will test this and see if it actually works. Unless, of course, mounting the loop devices automatically assigns the variables. Will test that too.
Comment 23 Brian Lane 2011-02-09 14:10:24 EST
Those variables are setup in the /usr/share/dracut/modules.d/90dmsquash-live/dmsquash-live-root script. The problem is that the dmsetup snapshot isn't working on the provided images.
Comment 24 Milan Broz 2011-02-09 14:30:49 EST
(In reply to comment #23)
> The problem is that the dmsetup snapshot isn't working on the provided images.

DM snapshot target works perfectly, the COW image is either broken or script mangles it somehow.

When I tried it, loop was properly set up, variables were also set but the mapped COW image was not correct and snapshot target (correctly) rejected it.
Comment 25 Bruno Wolff III 2011-02-09 15:05:44 EST
Any ideas on how it is mangled? Does it look truncated or anything else relatively obvious. That might help us figure out where to look.
Comment 26 Bruno Wolff III 2011-02-09 20:58:50 EST
I did notice that there is a fixed size of 64 MiB for what looks to be the osmin image in fs.py. Is it possible that osmin has outgrown that limit? (It might be that I don't really understand the code.)
Comment 27 Bruno Wolff III 2011-02-09 23:33:59 EST
I found some recent builds had messed on osmin.img files. I am grabbing a more currently nightly desktop build to see if that is still happening.
Comment 28 Bruno Wolff III 2011-02-10 07:21:04 EST
I double check a recent Desktop nightly and the osmin.img file doesn't appear to be a proper squashfs image.
Comment 29 Bruno Wolff III 2011-02-10 09:09:49 EST
I just checked a live image I built this morning and osmin.img looks OK. I'll test it on a usb drive later so that I know I am testing one with a mountable image.
There may be multiple problems. I am pretty sure I had a problem with one with a good osmin.img before, so it looks like there may be two issues.
Comment 30 Bruno Wolff III 2011-02-10 12:06:59 EST
I checked the live image I rebuilt and it fails to mount osmin, but I can manually mount osmin.img.
So it does seem that there are two problems. One is that in some cases osmin.img is bad and in some cases there is a problem with the osmin even when osmin.img seems OK.
Comment 31 Adam Williamson 2011-02-11 03:35:24 EST
Leaving notes on proposed blockers as I won't be at the meeting tomorrow most likely:

+1 blocker, hits the intersection of "The installer must boot (if appropriate) and run on all primary architectures from default live image, DVD, and boot.iso install media" and "In most cases, the installed system must boot to a functional graphical environment without user intervention (see Blocker_Bug_FAQ)" (implication of the criteria is clearly that live install should be possible at Alpha stage).
Comment 32 Jóhann B. Guðmundsson 2011-02-11 13:29:09 EST
mentioned on the alpha blocker meeting if the corruption could be relate due to the change to xz?
Comment 33 Bruno Wolff III 2011-02-11 13:43:06 EST
I'd really like it if some DM expert could look at osmin when osmin.img is a valid squashfs image and note if it is corrupted or if there is some other problem. osmin does seem to start with the correct magic word, but that is about as far as I can check.
Comment 34 Bruno Wolff III 2011-02-11 13:46:43 EST
Brian's memory is that the problem predates the switch to xz.

For the issue of osmin.img not being a valid squashfs image, please followup in the cloned bug 676904. Squashfs got updated to 4.2 before xz was being used for builds and perhaps we have found a bug there. (Though I haven't seen squashfs.img get corrupted, not the test cases I have.)
Comment 35 Robyn Bergeron 2011-02-11 14:43:36 EST
Per 2011-02-11 alpha blocker meeting:

* AGREED: 672265 - Accepted as F15Alpha blocker, impacts *all* live image installs. (jlaska, 18:27:11)

* Could use some extra eyes to determine what might be causing this issue (possibly introduction of xz compression)
Comment 36 Bruno Wolff III 2011-02-12 10:39:08 EST
I tested the latest F14 livecd-creator and the install to hard drive command got past where it had been stuck. (I didn't do an actual install since I didn't have a place to do so.)
There were some patches right after that that were only committed to master. One that looks possible is the addition of the --uid option to dmsetup.
When I started grabbing an F15 local repo I removed my rawhide repo (as with the mass rebuild almost every package was an update) and I am now waiting for my rsync to complete. Probably this will be done in around 12 hours.
At that point I am going to do another test compose without the commit mentioned above. If that still fails, I will try build an F14 image on an F15 system an see if that also has the problem. (That might be the case if a kernel or dm related tool upgrade since F14 is causing an issue.) And I'll also check to see if gzip compression doesn't show the same problem.
Comment 37 John Reiser 2011-02-12 11:34:57 EST
(Side comment about speed of rebuild, In reply to comment #36)
> When I started grabbing an F15 local repo I removed my rawhide repo (as with
> the mass rebuild almost every package was an update) and I am now waiting for
> my rsync to complete. Probably this will be done in around 12 hours.

Taking 12 hours seems slow to me.  When I composed an install DVD using pungi at 0500 UTC today (9pm PST Friday), my demand-driven download of 1939 packages from rawhide took less than one hour.  I use cable modem (max. 10Mbit/s to 20Mbit/s) and connect directly to the .redhat. server to avoid version skew in the mirror system.  In the .ks file I comment out all the @Languages, which reduces the .iso from 3.6 GB to 2.5 GB.  My daily pungi run to compose a new .iso with a few dozen updated packages often takes less than 15 minutes.
Comment 38 Bruno Wolff III 2011-02-12 12:09:50 EST
I am in the process of getting a full copy of i386 F15 that started very late Thursday night. I have a T1 so I only get 1.5 Mb/s. Though the last part seems to be going a bit better than I expected. I am up to vegastrike-data. So it might end up being somewhat sooner before it finishes.
Comment 39 Milan Broz 2011-02-12 14:33:12 EST
I checked that image again (desktop-x86_64-20110123.17.iso, latest doesn't work for me at all - seems GNOME is crashing during boot).

The problem is that loop device (loop1 / osimage COW) is mounted read-only and kernel refuses to use create snapshot with read-only COW. (Using read-write loop of the same image works.)

I am not sure if it is regression (with dmsetup --readonly it should work IMHO), but I'll check using some old version.
Comment 40 Bruno Wolff III 2011-02-12 20:14:04 EST
I tested not using the --uuid option and that didn't affect the problem. I am now building an F14 image on F15 and will be testing it out shortly.
Comment 41 Milan Broz 2011-02-12 20:43:44 EST
I am almost sure it is a kernel bug, caused by 2.6.38 changes in block layer.
(Block device read only flag handling.)
I have already reproducer and the bisected commit. I'll post here more later.
Comment 42 Milan Broz 2011-02-12 21:15:27 EST
Reported here https://lkml.org/lkml/2011/2/12/209
Unfortunately it cannot be easily reverted (it was part of more complex changes).
Comment 43 Brian Lane 2011-02-12 21:55:50 EST
Thank you for tracking this down!
Comment 44 Bruno Wolff III 2011-02-13 00:48:25 EST
Could this also explain why sometimes osmin.img got corrupted?

P.S. I'll echo Brian's thanks for figuring this out.
Comment 45 Bruno Wolff III 2011-02-13 00:57:16 EST
I also saw the loop device errors today that you reported. It was messing up my live image building. I ended up rebooting before doing each new build.
Comment 46 James Laska 2011-02-14 08:52:21 EST
(In reply to comment #42)
> Reported here https://lkml.org/lkml/2011/2/12/209
> Unfortunately it cannot be easily reverted (it was part of more complex
> changes).

Nice work gang!  Any thoughts on how to proceed for F15 Alpha with this issue?  Do we need input from the kernel folks for resolving this properly?  Is there an interim workaround to try?  Should we reassign this bug to the kernel?
Comment 47 Bruno Wolff III 2011-02-14 09:34:27 EST
It probably makes sense that the component be changed to kernel. The rest of us can still watch for progress. Milan probably has a better idea of whether having other Fedora kernel guys look at this would actually be helpful.

There is ongoing discussion on lkml, but I am not seeing a quick resolution. I don't know how long we would want to hold up the alpha for this fix. We may be able to do a temporary work around and not set the cow device as readonly. I am not sure how well that would work. I think that part is in dracut.
Comment 48 Jóhann B. Guðmundsson 2011-02-14 09:45:46 EST
We could slip this for alpha and move it to a beta blocker instead and make note of that in the release notes for alpha and point people out the live image is only "live" and they have to use the DVD image if they want to install alpha.

I'm not sure how strict we need to be for the live image since we have a working install on the dvd image?
Comment 49 Milan Broz 2011-02-14 09:48:15 EST
(In reply to comment #47)
> It probably makes sense that the component be changed to kernel. The rest of us
> can still watch for progress. Milan probably has a better idea of whether
> having other Fedora kernel guys look at this would actually be helpful.

I would prefer to add patch to Fedora kernel for now.

> We may be able to do a temporary work around and not set the cow device as readonly.

Better do not do that - the COW device is very small and if it is be read-write, it can very easily be invalidated (by some random access which updates atime or so).
Comment 50 John Reiser 2011-02-14 10:05:57 EST
(In reply to comment #49)
> Better do not do that - the COW device is very small and if it is be
> read-write, it can very easily be invalidated (by some random access which
> updates atime or so).

Can the specific problem of atime can be avoided by mounting with 'noatime'?
Comment 51 Milan Broz 2011-02-14 10:14:31 EST
(In reply to comment #50)
> Can the specific problem of atime can be avoided by mounting with 'noatime'?

sure but that was just an example.
Comment 52 James Laska 2011-02-14 10:17:15 EST
(In reply to comment #48)
> I'm not sure how strict we need to be for the live image since we have a
> working install on the dvd image?

We are pretty strict about having a working live install experience in all releases.

http://fedoraproject.org/wiki/Fedora_15_Alpha_Release_Criteria

   "The installer must boot (if appropriate) and run on all primary
    architectures from default live image, DVD, and boot.iso install 
    media"
Comment 53 Milan Broz 2011-02-14 10:43:51 EST
What I am proposing here is to build kernel with this patch
https://lkml.org/lkml/2011/2/14/119
and then try to rebuild liveCD with it. It should be enough for this case.

(But it is possible that patch is still not complete.)
Comment 54 Bruno Wolff III 2011-02-14 10:53:09 EST
Note that for the last couple of releases we haven't produced official live images until release. Before that people are supposed to use the nightly composes. Those aren't checked the same way as the offical install images, nor is the one from the release date kept. Given that I don't think we want to hold up the alpha for very long times based on problems with the live images.
Comment 55 Bruno Wolff III 2011-02-14 13:59:27 EST
It looks like some consensus on how to the attack the issue has formed in the discussion. I can't tell for sure, but it seems we may have a fix in something on the order of a few days.
Comment 56 Adam Williamson 2011-02-14 15:54:55 EST
"Note that for the last couple of releases we haven't produced official live
images until release."

That's not correct. We shipped live images with both Alpha and Beta of F14.
Comment 57 Bruno Wolff III 2011-02-14 16:15:18 EST
I may not be clearly remembering the situation. Possibly this was a subset of the spins? I thought there were dependency issues that was blocking at least games spin builds for at least one of the alpha or beta.
Comment 58 Adam Williamson 2011-02-14 16:26:07 EST
yeah, it is a subset, just the desktop spins - gnome, kde, xfce, lxde.
Comment 59 Bruno Wolff III 2011-02-14 16:26:25 EST
Yeah, it looks like there were releases for the 4 desktop live spins and for the rest people were pointed to the nightlies. I was mostly worrying about the nightly compose issues and didn't notice there were also official releases for some of them.
Comment 60 Flóki Pálsson 2011-02-14 18:32:23 EST
Still in TC2 Fedora-15-Alpha-x86_64-Live-Desktop.iso
Comment 61 Bruno Wolff III 2011-02-15 12:23:26 EST
Discussion on lkml continues. Some messages are copied to the dm-devel list, but most if not all of these are copied to lkml. There is discussion about possibly reverting the feature and delaying it to 2.6.39.
Comment 62 Milan Broz 2011-02-15 15:10:34 EST
Before the discussion finishes, please add this patch to Fedora kernel, it should help in this case.

http://www.kernel.org/pub/linux/kernel/people/agk/patches/2.6/editing/dm-fix-opening-log-and-cow-devices-for-read-only-tables.patch
Comment 63 Bruno Wolff III 2011-02-16 12:29:17 EST
While the risk of the sub-bug was asked about, I do want to note that I think this bug has a significant risk of delaying the alpha. Getting a kernel person to look at and evaluate what milan has done so far in supplying patches and starting discussions on dm-devel and lkml would be really nice at this time.
Comment 64 Bruno Wolff III 2011-02-16 17:14:04 EST
It looks like a patch in Fedora's kernel might have been made to solve this issue. There hasn't been a new kernel build submitted with this change yet, but I'll keep an eye out for it and do test after it shows up.
+# rhbz#672265
+Patch12442: revert-block-check-bdev-readonly.patch
+
Comment 65 Fedora Update System 2011-02-17 00:59:21 EST
kernel-2.6.38-0.rc5.git1.1.fc15 has been submitted as an update for Fedora 15.
https://admin.fedoraproject.org/updates/kernel-2.6.38-0.rc5.git1.1.fc15
Comment 66 Chuck Ebbert 2011-02-17 02:01:31 EST
(In reply to comment #64)
> +# rhbz#672265
> +Patch12442: revert-block-check-bdev-readonly.patch

This is now upstream as commit e51900f7d38cbcfb481d84567fd92540e7e1d23a, so we're not going off on our own with this fix.
Comment 67 Bruno Wolff III 2011-02-17 06:20:26 EST
Thanks. I tested a live image using kernel-2.6.38-0.rc5.git1.1.fc15 and install to hard drive properly started. I only went far enough to make sure it got past the problem as I didn't really want to do a reinstall. So it looks like the fix does solve the problem we were having.
Comment 68 Kenny Strawn 2011-02-17 18:14:39 EST
Downloading the nightly 20110217.00 image right now; will see what it does.
Comment 69 Raphael Groner 2011-02-17 18:25:43 EST
(In reply to comment #68)
It does not work with the xfce nightly.
Comment 70 Bruno Wolff III 2011-02-18 01:05:10 EST
The nightlies won't work until kernel-2.6.38-0.rc5.git1.1.fc15 or later hits stable. For the RC that kernel will be forced in. You can enable updates-testing or use a local repo to test this early.
Comment 71 Fedora Update System 2011-02-18 01:56:21 EST
kernel-2.6.38-0.rc5.git1.1.fc15 has been pushed to the Fedora 15 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 72 Brian Lane 2011-02-19 10:23:14 EST
*** Bug 678767 has been marked as a duplicate of this bug. ***
Comment 73 Raphael Groner 2011-02-20 12:53:26 EST
Works for me with xfce-i386-20110219.iso nightly, thank you!
Comment 74 James Laska 2011-02-22 08:24:52 EST
Also confirmed fix with anaconda-15.20.1-1.fc15
Comment 75 Scott Williams 2011-04-17 00:29:32 EDT
This is back in the 20110409.16 XFCE nightly (to date, the latest to compile on koji).  

If liveinst is run, there is an error: "Can't do live image installation unless running from a live image."

If the desktop link is clicked, or anaconda --liveinst is ran, it quickly fails with an unhandled exception.

anaconda-15.27-1 with kernel 2.6.38.2-9

If this was fixed at once time, it appears to be back.  At least in the XFCE spin.
Comment 76 Bruno Wolff III 2011-04-17 08:23:24 EDT
This is unlikely to be the same bug, even though the systems are similar. I think it would better to open a new bug rather than reopen this one. It should also be tentatively marked as a final blocker.
Comment 77 Bruno Wolff III 2011-04-17 08:24:01 EDT
That should have been symptoms, not systems.
Comment 78 satellitgo 2011-04-17 09:28:30 EDT
I have also seen this failure with f15 live desktop CD's It seems to occur if liveinst has failed for another reason and then liveinst or anaconda is tried a second time on the running system. The first attempt appears to have changed the file system to a non-live one.
Comment 79 David Lehman 2011-04-18 09:49:33 EDT
The new reports of similar behavior are probably related to bug 694712, which is fixed in F15Beta.

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