+++ This bug was initially created as a clone of Bug #740280 +++

Recent dracuts (for example dracut-013-11.fc16.noarch) will no longer create /dev/live.

# grep /dev/live `rpm -ql fedora-kickstarts-0.16.1-1.fc16.noarch`
/usr/share/spin-kickstarts/fedora-live-base.ks:if [ -b \`readlink -f /dev/live\` ]; then
/usr/share/spin-kickstarts/fedora-live-base.ks:   mount -o ro /dev/live /mnt/live 2>/dev/null || mount /dev/live /mnt/live
/usr/share/spin-kickstarts/fedora-live-base.ks:#/usr/sbin/eject -p -m \$(readlink -f /dev/live) >/dev/null 2>&1
/usr/share/spin-kickstarts/fedora-live-mini.ks:if [ -b \`readlink -f /dev/live\` ]; then
/usr/share/spin-kickstarts/fedora-live-mini.ks:   mount -o ro /dev/live /mnt/live 2>/dev/null || mount /dev/live /mnt/live
/usr/share/spin-kickstarts/fedora-live-mini.ks:/usr/sbin/eject -p -m \$(readlink -f /dev/live) >/dev/null 2>&1

It seems like the following thus is broken:
* mount live image on /mnt/live, and thus
* swap.img
* persistent home
* home.img

This might thus be a blocker for f16 live images.

haraldh confirms that dracut intentionally no longer clutters /dev . It should however already be mounted on /run/initramfs/live .

--- Additional comment from harald on 2011-09-21 18:39:59 CEST ---

move to F17... /dev/live is present again in F16

--- Additional comment from awilliam on 2011-09-21 23:11:24 CEST ---

when exactly did /dev/live go missing? we don't have -11 in the f16 stable tree. afaics, the last version which actually went stable was -8.

--- Additional comment from mads on 2011-09-21 23:40:42 CEST ---

I don't know exactly when /dev/live died - I noticed it in koji builds a couple of days ago, so I doubt it ever made it to stable. FWIW.

--- Additional comment from awilliam on 2011-09-22 02:25:50 CEST ---

yeah...and I'm fairly sure RC1 has /dev/live. But I'll double-check.

--- Additional comment from harald on 2011-09-22 15:24:50 CEST ---

back in dracut-013-12.fc16 

https://admin.fedoraproject.org/updates/FEDORA-2011-13103

but it will go away in F17

--- Additional comment from fgrose on 2012-03-22 16:49:47 CET ---

Confirmed that /dev/live, /mnt/live, and the creation of a loop device for /mnt/live/LiveOS/home.img fail in F17 (tested with Fedora-17-Beta-TC2-x86_64-Live-SoaS.iso).

This precludes the security of an encrypted-home option, and disrupts several work processes of Live USB projects.

Please make this a high priority bug.

--- Additional comment from harald on 2012-03-22 16:55:17 CET ---

(In reply to comment #6)
> Confirmed that /dev/live, /mnt/live, and the creation of a loop device for
> /mnt/live/LiveOS/home.img fail in F17 (tested with
> Fedora-17-Beta-TC2-x86_64-Live-SoaS.iso).
> 
> This precludes the security of an encrypted-home option, and disrupts several
> work processes of Live USB projects.
> 
> Please make this a high priority bug.

What exactly do you need? Is the debug output of /proc/self/mountinfo and "losetup" not enough to find out what you need?

--- Additional comment from fgrose on 2012-03-22 17:12:08 CET ---

(In reply to comment #7)
 
> What exactly do you need?

We use the home.img filesystem to avoid overlay consumption for Sugar on a Stick deployments.

Others may depend on the security of an encrypted-home for privacy of user data on a Live USB. 

Is the debug output of /proc/self/mountinfo and
> "losetup" not enough to find out what you need?

Yes, we could workaround the missing /dev/live, and /mnt/live links with some extended effort, but our scripts and livecd-iso-to-disk, liveimage-mount, edit-livecd, amoung others use this convention.

--- Additional comment from harald on 2012-03-22 17:22:00 CET ---

(In reply to comment #8)
> (In reply to comment #7)
> 
> > What exactly do you need?
> 
> We use the home.img filesystem to avoid overlay consumption for Sugar on a
> Stick deployments.
> 
> Others may depend on the security of an encrypted-home for privacy of user data
> on a Live USB. 
> 
> Is the debug output of /proc/self/mountinfo and
> > "losetup" not enough to find out what you need?
> 
> Yes, we could workaround the missing /dev/live, and /mnt/live links with some
> extended effort, but our scripts and livecd-iso-to-disk, liveimage-mount,
> edit-livecd, amoung others use this convention.

what we could do is:

/run/initramfs/dev/live -> /dev/whatever ...

--- Additional comment from harald on 2012-03-22 17:24:19 CET ---

(In reply to comment #9)
> (In reply to comment #8)
> > (In reply to comment #7)
> > 
> > > What exactly do you need?
> > 
> > We use the home.img filesystem to avoid overlay consumption for Sugar on a
> > Stick deployments.
> > 
> > Others may depend on the security of an encrypted-home for privacy of user data
> > on a Live USB. 
> > 
> > Is the debug output of /proc/self/mountinfo and
> > > "losetup" not enough to find out what you need?
> > 
> > Yes, we could workaround the missing /dev/live, and /mnt/live links with some
> > extended effort, but our scripts and livecd-iso-to-disk, liveimage-mount,
> > edit-livecd, amoung others use this convention.
> 
> what we could do is:
> 
> /run/initramfs/dev/live -> /dev/whatever ...

ah, we already have /run/initramfs/live-baseloop

--- Additional comment from awilliam on 2012-03-22 20:17:26 CET ---

adjusting version.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

--- Additional comment from harald on 2012-03-26 13:02:14 CEST ---

in essence: please use "/run/initramfs/live-baseloop" instead of "/dev/live"

--- Additional comment from fgrose on 2012-03-26 17:06:16 CEST ---

(In reply to comment #12)
> in essence: please use "/run/initramfs/live-baseloop" instead of "/dev/live"

This is not equivalent.  On a Live USB, /run/initramfs/live-baseloop is a link to /dev/loop3, the loop mount for ext3fs.img.

/dev/live should be a link to the installation partition of the USB device (/dev/sdc1, for example) or /dev/sr0 on a Live CD/DVD.

--- Additional comment from fgrose on 2012-03-26 17:09:10 CEST ---

Please also comment on the (lack of) mounting of /LiveOS/home.img.  Should a separate bug be filed for this?

--- Additional comment from awilliam on 2012-03-27 20:48:13 CEST ---

nominating as a final blocker, though we shipped 16 like this, apparently...



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

--- Additional comment from harald on 2012-03-29 12:53:16 CEST ---

(In reply to comment #13)
> (In reply to comment #12)
> > in essence: please use "/run/initramfs/live-baseloop" instead of "/dev/live"
> 
> This is not equivalent.  On a Live USB, /run/initramfs/live-baseloop is a link
> to /dev/loop3, the loop mount for ext3fs.img.
> 
> /dev/live should be a link to the installation partition of the USB device
> (/dev/sdc1, for example) or /dev/sr0 on a Live CD/DVD.

The live device is still mounted on /run/initramfs/live

--- Additional comment from fgrose on 2012-03-29 16:15:02 CEST ---

(In reply to comment #16)
> The live device is still mounted on /run/initramfs/live

Yes, thank you. Confirmed on Fedora-17-Nightly-20120328.13-x86_64-Live-desktop.

(The /run/initramfs/live directory is empty on Fedora-17-Beta-TC2-x86_64-Live-SoaS.)

--- Additional comment from fgrose on 2012-03-30 03:00:24 CEST ---

Created attachment 573850 [details]
Mount live device on /mnt/live, link it to /dev/live

Applying this patch to /etc/rc.d/init.d/livesys before booting a Live USB (such as with liveimage-mount from livecd-tools) will restore the lost features.

--- Additional comment from harald on 2012-03-30 10:56:49 CEST ---

(In reply to comment #17)
> (In reply to comment #16)
> > The live device is still mounted on /run/initramfs/live
> 
> Yes, thank you. Confirmed on Fedora-17-Nightly-20120328.13-x86_64-Live-desktop.
> 
> (The /run/initramfs/live directory is empty on
> Fedora-17-Beta-TC2-x86_64-Live-SoaS.)

The empty directory bug should be fixed with dracut-017-62.git20120322.fc17 which was probably not yet in Fedora-17-Beta-TC2-x86_64-Live-SoaS

--- Additional comment from harald on 2012-03-30 10:59:48 CEST ---

(In reply to comment #18)
> Created attachment 573850 [details]
> Mount live device on /mnt/live, link it to /dev/live
> 
> Applying this patch to /etc/rc.d/init.d/livesys before booting a Live USB (such
> as with liveimage-mount from livecd-tools) will restore the lost features.

+   mount -o ro $livedev /mnt/live 2>/dev/null || mount $livedev /mnt/live
+   ln -s $livedev /dev/live

Why don't you just symlink /mnt/live -> /run/initramfs/live ???

--- Additional comment from fgrose on 2012-03-30 15:46:42 CEST ---

Created attachment 573985 [details]
Mount live device on /mnt/live, & link device to /dev/live

This includes a more robust findmount() function.

The /mnt/live mount point is maintained in order to be robust to code that may derive the underlying partition from this mount point.  (/dev/live has not always been present.)

--- Additional comment from awilliam on 2012-04-20 23:10:21 CEST ---

Discussed at 2012-04-20 blocker review meeting: http://meetbot.fedoraproject.org/fedora-bugzappers/2012-04-20/fedora-bugzappers.2012-04-20-17.01.log.txt . We agreed that as the criteria stand, this issue is not covered, but we believe the criteria should be updated to require live image persistence to work. We will propose a new criterion for that.

Thomas Gillard (satellit_) reports that he's tested live image persistence with F17 Beta images and found it to work, so we're not sure live image persistence is in fact broken in F17 as things stand. has this been addressed without the bug being updated?

We will revisit both questions next week and update then.

--- Additional comment from fgrose on 2012-04-30 06:19:41 CEST ---

Created attachment 581139 [details]
Substitute /run/initramfs/live for /mnt/live.

With Fedora-17.TC2-x86_64-Live-Desktop.iso we have
/run/initramfs/livedev as a symlink to the block device for the source partition &
/run/initramfs/live as the mount point for that filesystem.

This substitute patch enables the mounting of home.img and swap.img filesystems with the substitute paths.

--- Additional comment from bruno on 2012-04-30 12:36:10 CEST ---

I ran into the no persistent home image issue this weekend. I was using livecd-tools-18.3-1.fc18.i686 to build an f17 image. I got asked for a passphrase during creation, but not when I boot the image. There is a home.img file on the USB drive.

--- Additional comment from bruno on 2012-05-01 05:10:08 CEST ---

Turns out in my case the liveuser home directory did seem to persist, but it wasn't using encryption for it. I am not sure if the overlay or home images were being used for this. (My guess is that if /home wasn't mounted, then I was getting persistence via the overlay.)

--- Additional comment from fgrose on 2012-05-01 05:54:06 CEST ---

(In reply to comment #25)
> I am not sure if the overlay or home images
> were being used for this. (My guess is that if /home wasn't mounted, then I was
> getting persistence via the overlay.)

Yes, that's how it works.  And if you hadn't requested an overlay, the /home/liveuser directory would have been created in a temporary root filesystem overlay and you wouldn't have had /home persistence (because the home.img filesystem you created wasn't mounted for lack of one of the attached patches).

The command losetup -a when issued following a boot reveals all of the available LiveOS filesystems and their source locations.

--- Additional comment from awilliam on 2012-05-03 21:45:00 CEST ---

Discussed at 2012-05-03 blocker review meeting. Agreed we still need to do some testing to figure out exactly what's working and what's broken, here. We think the special /home filesystem which is intended to avoid space exhaustion in the regular persistence overlay may not work as intended, and bcl thinks /dev/live may actually be back in recenyt 17 Lives.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

--- Additional comment from pbrobinson on 2012-05-03 21:52:09 CEST ---

(In reply to comment #27)
> Discussed at 2012-05-03 blocker review meeting. Agreed we still need to do some
> testing to figure out exactly what's working and what's broken, here. We think
> the special /home filesystem which is intended to avoid space exhaustion in the
> regular persistence overlay may not work as intended, and bcl thinks /dev/live
> may actually be back in recenyt 17 Lives.

The daily live composes seem to have broken since the 23/04 
http://alt.fedoraproject.org/pub/alt/nightly-composes/

Or have they moved?

--- Additional comment from kevin on 2012-05-03 22:00:29 CEST ---

The nightly live composes are done manually by me. I was out away from the internets, so they didn't happen. ;) 

I've launched off a new set of them now. 

If anyone would like to work on automating them and adding them to the branched script, see me out of bug and I will be happy to provide info.

--- Additional comment from fgrose on 2012-05-03 22:14:49 CEST ---

(In reply to comment #27)
> Discussed at 2012-05-03 blocker review meeting. Agreed we still need to do some
> testing to figure out exactly what's working and what's broken, here. We think
> the special /home filesystem which is intended to avoid space exhaustion in the
> regular persistence overlay may not work as intended, and bcl thinks /dev/live
> may actually be back in recent 17 Lives.

(From http://lists.fedoraproject.org/pipermail/livecd/2012-April/007151.html):

With Fedora-17.TC2-x86_64-Live-Desktop.iso we have
/run/initramfs/livedev as a symlink to the block device for the source
partition (as opposed to /dev/live) and
/run/initramfs/live as the mount point for that filesystem (as opposed to /mnt/live in F16 and earlier versions).

The substitute patch (2nd attachment above) enables the mounting of home.img and swap.img filesystems with the substitute paths:

The fix may be tested by applying the patch to /etc/rc.d/init.d/livesys on an installed Live USB.

--- Additional comment from awilliam on 2012-05-08 08:16:33 CEST ---

Bruno: Kevin: do you see any reason we shouldn't just apply this patch like now?



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

--- Additional comment from bruno on 2012-05-08 13:02:03 CEST ---

I can't say I know the live image stuff well enough to spot a problem easily. So while I don't have an objection to the patch, that doesn't really mean it's safe.
I would like to see the home stuff fixed though. I made custom live images a bit over a week ago and again late last week for use at a training session I was in last week and the /home stuff didn't work correctly which was a bit annoying.
I want to redo that live image again, and may get a chance to test the patch in the next day or two, but I don't think you need to wait on that.

--- Additional comment from kevin on 2012-05-08 13:46:35 CEST ---

It seems a reasonable patch, although it's quite late in the cycle. ;)

--- Additional comment from awilliam on 2012-05-08 19:54:00 CEST ---

I suppose the potential problem is that the functionality hasn't been in throughout the release, so 'fixing' it now may expose bugs we weren't aware of. But it'd be easy enough to revert. I think I'll pull it in for RC1/TC4. Blame me if things explode. :)



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

--- Additional comment from awilliam on 2012-05-08 21:35:03 CEST ---

Gah. Frederick, you dropped all the escapes from the variables in the file so it doesn't work right any more. It would work that way if you patch the *installed copy* of livesys, as you suggest for testing it, but if you patch the copy in spin-kickstarts and drop the / characters then all the vars get parsed away. Please just stick with the least possible change when patching...I'll try and fix it up.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

--- Additional comment from bruno on 2012-05-08 22:06:49 CEST ---

I tested the patch in attachment 2 [details] and can confirm that it doesn't work.

--- Additional comment from bruno on 2012-05-08 22:30:21 CEST ---

I started another test with the patches that Adam just applied. But I won't be finished with it until later tonight sometime.

--- Additional comment from awilliam on 2012-05-08 23:12:05 CEST ---

OK, I tested it with what's in git currently, and it works. At least, persistent encrypted home works. Tom Callaway found much the same. I didn't check noswap yet.

Setting to VERIFIED. If persistent /home is found to be good in TC4/RC1, I think we can close this as fixed.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

--- Additional comment from bruno on 2012-05-09 16:56:24 CEST ---

I tested it and while encrypted home works, swap doesn't. I found the following in my logs:
May  9 10:48:45 localhost livesys[680]: Enabling swap file swapon: /run/initramfs/live/LiveOS/swap.img: swapon failed: Read-only file system
top showed that no swap space was available.

--- Additional comment from awilliam on 2012-05-09 17:44:32 CEST ---

is that a regression, or no worse than before?



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

--- Additional comment from bruno on 2012-05-09 18:17:02 CEST ---

I don't know. I don't normally use swap on live images.

--- Additional comment from awilliam on 2012-05-09 18:22:53 CEST ---

i guess just check with tc3 and compare? or i could do it.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

--- Additional comment from bruno on 2012-05-09 20:47:55 CEST ---

I tried out just using swap (no home or overlay) with tc3 and swap wasn't used on boot. There was a swap.img file placed on the device. There was no password asked for while doing this. (Encrypted swap could use a random password each boot and no user input would be needed.)

Swap is really kind of an odd thing to use on a live image though. There are going to be few cases where it makes sense (little ram and a large USB drive), so I expect this would not be something we'd block on. And I'd be leery of NTH unless the change was very simple.

--- Additional comment from fgrose on 2012-05-09 21:09:35 CEST ---

Created attachment 583372 [details]
livecd-iso-to-disk transcript with mkswap error

Loading Fedora-17-Nightly-20120509.06-x86_64-Live-desktop.iso (with Adam's good patches) yielded a mkswap error (see transcript), and exited.

I moved the swap.img file to an ext4 formatted disc, performed a manual mkswap -f /path/to/swap.img, and then copied it back to the USB stick.

The booted stick now shows a working swap.img:

[root@localhost imgcreate]# swapon -s
Filename				Type		Size	Used	Priority
/dev/sda5                               partition	3341308	0	-1
/run/initramfs/live/LiveOS/swap.img     file		2096124	0	-2

(The Linux swap partition at /dev/sda5 on my system has always been activated for LiveOS boots.)

So the mkswap error is a separate bug.

--- Additional comment from awilliam on 2012-05-11 05:09:53 CEST ---

This is another close call. We don't have any criteria requiring persistence to work, so by the criteria, I'm -1 blocker. But I'm definitely +1 nth, it's a significant feature that we should fix.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

--- Additional comment from awilliam on 2012-05-12 03:01:52 CEST ---

Discussed at 2012-05-11 blocker review meeting: http://meetbot.fedoraproject.org/fedora-bugzappers/2012-05-11/f17-final-blocker-review-meeting-5.2012-05-11-17.04.html . This was rejected as a blocker as it doesn't affect vital live functionality, but accepted as NTH as obviously it affects a desirable feature (/home persistence).



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

--- Additional comment from fgrose on 2012-05-13 04:21:13 CEST ---

Testing Fedora-17.TC5-x86_64-Live-SoaS.iso shows no mounting of home.img.

Adam's patches need to be applied to fedora-live-mini.ks in order to fix Sugar on a Stick and any other builds based on fedora-live-mini.ks

--- Additional comment from awilliam on 2012-05-19 01:34:05 CEST ---

I added the fix to live-mini as suggested by fgrose around TC6. Checked RC2 SoaS and it's fine. So, closing.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers