Description of problem: I would have thought a given image produced by livecd-creator could be transferred to disk with livecd-iso-to-disk with equivalent results regardless of the OS release on which livecd-iso-to-disk was run. I was surprised to find this was not the case. Does upstream have a philosophy on whether this should be expected or if this would be considered a bug? For example, I've produced a specialized AOS spin based first on Fedora 10 and another later on Fedora 13. These images run on embedded systems from CompactFlash and use extlinux to boot. I have also developed a system that makes it possible to perform an upgrade in place for an embedded system to upgrade from one image (e.g., the one based on F10) to another (e.g., the one based on F13). The original images and the entire upgrade process had been tested and verified for production use. Everything worked as expected until we started transferring the images to flash using livecd-iso-to-disk on F14 hosts -- previously we had been using a mix of F10-13. We just discovered that flash cards imaged using a F14 host cannot be upgraded in place due to something affecting syslinux/extlinux at boot. I can image the card using the exact same ISO, but on a F13 host and the upgrade process will work. Thus it would seem that when extlinux is installed on the flash cards by livecd-iso-to-disk that the extlinux installer is being run from the host system rather than from the ISO itself. While this certainly is one approach, I wonder if it's the best one or if this has even been contemplated. At the very minimum, I think a caveat should be noted in the man page for livecd-iso-to-disk.
This is probably related to getting rid of the syslinux perl dependency that happened in F14. You might need to install syslinux-extlinux. It could also be related to the syslinux version bump. F14 uses version 4.
I'm not familiar with that change, but what you're describing sounds like something different and shows that I may not have been clear enough about the problem. My upgrade process basically does a wholesale swap of the LiveOS and syslinux directories. After the swap has been made, I run 'extlinux --update' to patch the MBR up (or whatever that is accomplishing exactly). I originally was trying to run that extlinux from the old LiveOS, but found that doesn't always work. I really need to run extlinux from the new LiveOS, but couldn't do that either because F10 cannot read a F13 squashfs image due to a format change. My solution was to bundle a copy of syslinux-3.86.tar.bz2 obtained from upstream and run from that one instead. Here's where it gets interesting. If the CF card was originally prepared on a F10-F13 system, the extlinux --update runs fine and the system can successfully be rebooted into the new LiveOS. However, if the CF card had been prepared by F14, the extlinux --update fails with "no previous extlinux boot sector found" and upon reboot with "vesamenu.c32: not a COM32R image". It then shows "boot:" and after a short timeout repeats with the vesamenu error message and cycles this way indefinitely. So I suspect when the CF card is prepared with F14, syslinux-4.02 lays something down that syslinux-3.86 cannot understand or find. This is why I wonder if it might make more sense for livecd-iso-to-disk to run the syslinux embedded within the LiveOS image, if possible, rather than the one provided by the host running livecd-iso-to-disk.
I'd like to keep the tools backwards compatible, but this isn't always going to be possible (hence my branching of the repo for each release). In this case, yes, the syslinux stuff is coming from the host system. I'm not sure why it was written this way, and I agree that it would make sense to pull it from the iso being installed.
One use case where using the iso's binary could be a problem is if you are making a live usb using a different arch (eg. using x86_64 to make a i686 usb disk). syslinux also isn't available on the iso without mounting the squashfs and ext3fs images. I think you could solve your problem by updating the syslinux version you are using understands whatever newer setup the syslinux 4.02 is using.
(In reply to comment #4) > One use case where using the iso's binary could be a problem is if you are > making a live usb using a different arch (eg. using x86_64 to make a i686 usb > disk). syslinux also isn't available on the iso without mounting the squashfs > and ext3fs images. Aren't you arguing for exactly what I was proposing? If you're building an ISO for a i686 target, don't you want to be using an i686 syslinux instead of the x86_64 variant from the build host? Of course, I do see the valid point you're making in that the build host may not even be able to run the target-arch's syslinux. > I think you could solve your problem by updating the syslinux version you are > using understands whatever newer setup the syslinux 4.02 is using. That's essentially the route I was forced to take, but it quickly got messy. I would have preferred to simply pull a few syslinux files from the newer Fedora release for use within the upgrade process of the older release. I didn't get far with that because of what appeared to be dependencies on shared libs. Stuff just wouldn't run no matter what I tried. I eventually had to resort to pulling the full pre-compiled syslinux tarball from upstream, which must be statically linked. It worked this time, but I worry about niggling little incompatibilities for future upgrades -- I don't closely follow syslinux development nor the differences between upstream and what Fedora ships. Maybe there's a need for a run-time option to specify which syslinux to use. I think both approaches are valid, but the choice depends on the circumstances.
Created attachment 610112 [details] livecd-iso-to-disk using chroot to run in source environment This version of livecd-iso-to-disk is reworked to use the source root filesystem in a chroot by default, along with the livecd-iso-to-disk script embedded in the source. A --nochroot as well as a --avoidsourcescript option are available for cases where the launching filesystem and/or installation script is called for. One can load a Live USB by these steps: 1. mounting the source.iso 2. determine its loop device, /dev/loopN 3. call /mountpoint/LiveOS/livecd-iso-to-disk /dev/loopN /dev/target All 3 steps could be avoided by providing some appropriate autorun scripts for the iso, or including some standard install scripts that could be invoked by clicking on them in Nautilus.
By mounting the source.iso LiveOS filesystem in a chroot enviroment, the current version of software components, including the installation script, on the source can be used for installation. (If syslinux-extlinux is not in the source, ext234,btrfs target devices will have to use the --nochroot option and a system with the proper bootloader.) An --avoidsourcescript option is also added to allow installation with alternative scripts. This new version of livecd-iso-to-disk prefers builtin functions, finds and offers to unmount mounted targets, and reorders some compatibility checks in order to bailout early, if needed. If this passes further testing (the DVD and netinst installer paths are untested), I can submit incremental patches for these changes.
Created attachment 610337 [details] livecd-iso-to-disk using chroot to run in source environment Updated with some patches to master, http://git.fedorahosted.org/cgit/livecd/tree/tools/livecd-iso-to-disk.sh