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 .
move to F17... /dev/live is present again in F16
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.
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.
yeah...and I'm fairly sure RC1 has /dev/live. But I'll double-check.
back in dracut-013-12.fc16 https://admin.fedoraproject.org/updates/FEDORA-2011-13103 but it will go away in F17
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.
(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?
(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.
(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 ...
(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
adjusting version. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
in essence: please use "/run/initramfs/live-baseloop" instead of "/dev/live"
(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.
Please also comment on the (lack of) mounting of /LiveOS/home.img. Should a separate bug be filed for this?
nominating as a final blocker, though we shipped 16 like this, apparently... -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
(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
(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.)
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.
(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
(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 ???
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.)
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.
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.
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.
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.)
(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.
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
(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?
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.
(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.
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
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.
It seems a reasonable patch, although it's quite late in the cycle. ;)
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
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
I tested the patch in attachment 2 [details] and can confirm that it doesn't work.
I started another test with the patches that Adam just applied. But I won't be finished with it until later tonight sometime.
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
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.
is that a regression, or no worse than before? -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
I don't know. I don't normally use swap on live images.
i guess just check with tc3 and compare? or i could do it. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
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.
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.
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
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
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
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