Created attachment 716733 [details] extlinux.conf (as created) with two kernel choices, but no default Description of problem: My kickstart for livecd-creator contains %packages kernel.i686 kernel-PAE.i686 # kernel.x86_64 When I transfer the resultant image over to a CompactFlash card formatted with ext3 with livecd-iso-to-disk, the extlinux.conf does have the two kernel entries configured, but: * both are labeled as PAE when one in fact is PAE and the other is not * no menu label is marked as a default (with 'menu default'), so the 3 second timeout for automatic procession becomes an infinite way for a user to make a selection Version-Release number of selected component (if applicable): livecd-tools-18.14-1.fc18.x86_64 How reproducible: always Expected results: Ideally, I would be able to specify on the cmd-line which kernel is to be the default, or at least the non-PAE kernel initially. Additional info: I'm trying to produce a Fedora Live spin for embedded deployment which has both kernels aboard so that I can use a single spin on a variety of hardware, some of which has PAE and some which doesn't. My goal was to boot without PAE (safest) and somewhere early in the boot process detect if PAE is available. If so, reconfigure extlinux.conf to change the default and reboot. Ideally I could also support kernel.x86_64 too, but I cannot seem to get livecd-creator to find and install that package despite having i386 and x86_64 repositories configured in the kickstart. I've attached the extlinux.conf that results.
Please attach isolinux.cfg from the iso, livecd-iso-to-disk just modifies what livecd-creator creates.
Created attachment 717062 [details] isolinux.cfg as per request in comment #1.
(In reply to comment #1) > livecd-iso-to-disk just modifies what livecd-creator creates. I was unaware of that fact, but it is quite apparent now; thanks for the info. I've diff'ed the two files and it appears that the faults (or design choices, if that's the case) can be found in livecd-creator itself. I don't see where livecd-iso-to-disk did anything unexpected.
Created attachment 717889 [details] patch
(In reply to comment #4) > Created attachment 717889 [details] > patch I applied this patch to my installed python-imgcreate-18.14-1.fc18.x86_64 and can confirm that: * the two extlinux menu options are now labeled distinctly and correctly * the first menu entry is the default and proceeds automatically after the 3s timeout expires Thanks Brian! With respect to the desire to also incorporate a kernel.x86_64 into an otherwise 32-bit spin, should I file a separate bug report for that? It seems that livecd-tools does not honor the arch tag of a package name in the kickstart file as does yum. See also bug #124456 (kickstart %packages should support name.arch package inputs).
Different problems should be different bugs.
livecd-tools-19.2-1.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/livecd-tools-19.2-1.fc19
livecd-tools-18.15-1.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/livecd-tools-18.15-1.fc18
livecd-tools-17.16-1.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/livecd-tools-17.16-1.fc17
Package livecd-tools-19.2-1.fc19: * should fix your issue, * was pushed to the Fedora 19 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing livecd-tools-19.2-1.fc19' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-4856/livecd-tools-19.2-1.fc19 then log in and leave karma (feedback).
livecd-tools-17.16-1.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.
livecd-tools-18.15-1.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.
livecd-tools-19.2-1.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.