Bug 740280 - /dev/live no longer exists
Summary: /dev/live no longer exists
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: spin-kickstarts
Version: 17
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Jeroen van Meeuwen
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: RejectedBlocker AcceptedNTH
Depends On:
Blocks: F17-accepted, F17FinalFreezeExcept
TreeView+ depends on / blocked
 
Reported: 2011-09-21 14:16 UTC by Mads Kiilerich
Modified: 2012-09-18 00:56 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 858041 (view as bug list)
Environment:
Last Closed: 2012-05-18 23:34:05 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
Mount live device on /mnt/live, link it to /dev/live (1.51 KB, patch)
2012-03-30 01:00 UTC, Frederick Grose
no flags Details | Diff
Mount live device on /mnt/live, & link device to /dev/live (1.52 KB, patch)
2012-03-30 13:46 UTC, Frederick Grose
no flags Details | Diff
Substitute /run/initramfs/live for /mnt/live. (2.67 KB, patch)
2012-04-30 04:19 UTC, Frederick Grose
no flags Details | Diff
livecd-iso-to-disk transcript with mkswap error (1.47 KB, text/plain)
2012-05-09 19:09 UTC, Frederick Grose
no flags Details

Description Mads Kiilerich 2011-09-21 14:16:29 UTC
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 .

Comment 1 Harald Hoyer 2011-09-21 16:39:59 UTC
move to F17... /dev/live is present again in F16

Comment 2 Adam Williamson 2011-09-21 21:11:24 UTC
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.

Comment 3 Mads Kiilerich 2011-09-21 21:40:42 UTC
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.

Comment 4 Adam Williamson 2011-09-22 00:25:50 UTC
yeah...and I'm fairly sure RC1 has /dev/live. But I'll double-check.

Comment 5 Harald Hoyer 2011-09-22 13:24:50 UTC
back in dracut-013-12.fc16 

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

but it will go away in F17

Comment 6 Frederick Grose 2012-03-22 15:49:47 UTC
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.

Comment 7 Harald Hoyer 2012-03-22 15:55:17 UTC
(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?

Comment 8 Frederick Grose 2012-03-22 16:12:08 UTC
(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.

Comment 9 Harald Hoyer 2012-03-22 16:22:00 UTC
(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 ...

Comment 10 Harald Hoyer 2012-03-22 16:24:19 UTC
(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

Comment 11 Adam Williamson 2012-03-22 19:17:26 UTC
adjusting version.



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

Comment 12 Harald Hoyer 2012-03-26 11:02:14 UTC
in essence: please use "/run/initramfs/live-baseloop" instead of "/dev/live"

Comment 13 Frederick Grose 2012-03-26 15:06:16 UTC
(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.

Comment 14 Frederick Grose 2012-03-26 15:09:10 UTC
Please also comment on the (lack of) mounting of /LiveOS/home.img.  Should a separate bug be filed for this?

Comment 15 Adam Williamson 2012-03-27 18:48:13 UTC
nominating as a final blocker, though we shipped 16 like this, apparently...



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

Comment 16 Harald Hoyer 2012-03-29 10:53:16 UTC
(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

Comment 17 Frederick Grose 2012-03-29 14:15:02 UTC
(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.)

Comment 18 Frederick Grose 2012-03-30 01:00:24 UTC
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.

Comment 19 Harald Hoyer 2012-03-30 08:56:49 UTC
(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

Comment 20 Harald Hoyer 2012-03-30 08:59:48 UTC
(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 ???

Comment 21 Frederick Grose 2012-03-30 13:46:42 UTC
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.)

Comment 22 Adam Williamson 2012-04-20 21:10:21 UTC
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.

Comment 23 Frederick Grose 2012-04-30 04:19:41 UTC
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.

Comment 24 Bruno Wolff III 2012-04-30 10:36:10 UTC
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.

Comment 25 Bruno Wolff III 2012-05-01 03:10:08 UTC
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.)

Comment 26 Frederick Grose 2012-05-01 03:54:06 UTC
(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.

Comment 27 Adam Williamson 2012-05-03 19:45:00 UTC
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

Comment 28 Peter Robinson 2012-05-03 19:52:09 UTC
(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?

Comment 29 Kevin Fenzi 2012-05-03 20:00:29 UTC
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.

Comment 30 Frederick Grose 2012-05-03 20:14:49 UTC
(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.

Comment 31 Adam Williamson 2012-05-08 06:16:33 UTC
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

Comment 32 Bruno Wolff III 2012-05-08 11:02:03 UTC
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.

Comment 33 Kevin Fenzi 2012-05-08 11:46:35 UTC
It seems a reasonable patch, although it's quite late in the cycle. ;)

Comment 34 Adam Williamson 2012-05-08 17:54:00 UTC
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

Comment 35 Adam Williamson 2012-05-08 19:35:03 UTC
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

Comment 36 Bruno Wolff III 2012-05-08 20:06:49 UTC
I tested the patch in attachment 2 [details] and can confirm that it doesn't work.

Comment 37 Bruno Wolff III 2012-05-08 20:30:21 UTC
I started another test with the patches that Adam just applied. But I won't be finished with it until later tonight sometime.

Comment 38 Adam Williamson 2012-05-08 21:12:05 UTC
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

Comment 39 Bruno Wolff III 2012-05-09 14:56:24 UTC
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.

Comment 40 Adam Williamson 2012-05-09 15:44:32 UTC
is that a regression, or no worse than before?



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

Comment 41 Bruno Wolff III 2012-05-09 16:17:02 UTC
I don't know. I don't normally use swap on live images.

Comment 42 Adam Williamson 2012-05-09 16:22:53 UTC
i guess just check with tc3 and compare? or i could do it.



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

Comment 43 Bruno Wolff III 2012-05-09 18:47:55 UTC
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.

Comment 44 Frederick Grose 2012-05-09 19:09:35 UTC
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.

Comment 45 Adam Williamson 2012-05-11 03:09:53 UTC
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

Comment 46 Adam Williamson 2012-05-12 01:01:52 UTC
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

Comment 47 Frederick Grose 2012-05-13 02:21:13 UTC
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

Comment 48 Adam Williamson 2012-05-18 23:34:05 UTC
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


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