Description of problem: Current F14 rawhide live spins don't display the SysLinux boot menu. The copyright message appears briefly then a black blank screen. Apparently this is due to path changes in fedora-logos for anaconda. Version-Release number of selected component (if applicable): livecd-tools-032-4.fc14 fedora-logos-13.0.3-3.fc14 How reproducible: every time Steps to Reproduce: 1. spin rawhide live desktop with livecd-creator 2. write to USB with livecd-iso-to-disk 3. boot Actual results: syslinux hangs at blank black screen Expected results: syslinux menu to appear or system to boot anyway Additional info: Workaround: pressing Shift at boot time and typing linux0 at the boot: prompt. autopsy says adding splash.jpg, etc and it boots again.
I get a functioning CD which boots if the soas.ks file is edited to use generic logos Using f14(rawhide) usb HD Build system with livecd-creator updated to kernel 2.6.35-0.36.rc5.git.fc14
Yes, thanks for that tip - I did generic spin here and also confirm it works. I guess generic-logos needs breaking^Wtweaking too. :)
I believe this qualifies as a F14Alpha blocker per the following criteria (https://fedoraproject.org/wiki/Fedora_14_Alpha_Release_Criteria): "# The installer must boot (if appropriate) and run on all primary architectures from default live image, DVD, and boot.iso install media "
Discussed at the 2010/07/23 blocker bug review meeting. We accept this as a blocker (it breaks the criterion "The installer must boot (if appropriate) and run on all primary architectures from default live image, DVD, and boot.iso install media"). It's not entirely clear whether it's the logos package, the livecd-tools stuff or anaconda that's broken here, so I'm adding Spot and a randomly-chosen Anaconda maintainer. Hopefully this way someone will own up. =) -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Where are you getting these images from?
If you compare where generic-logos and fedora-logos put images for anaconda you can see there is some significant differences. Probably the correct location needs to be conveyed to those package owners to have them put them in the correct locations. From fedora-logos: /usr/share/anaconda/pixmaps/anaconda_header.png /usr/share/anaconda/pixmaps/progress_first.png /usr/share/anaconda/pixmaps/splash.png /usr/share/anaconda/pixmaps/syslinux-splash.png /usr/share/anaconda/splashtolss.sh /usr/share/anaconda/syslinux-splash.png /usr/share/anaconda/syslinux-vesa-splash.jpg From generic-logos: /usr/lib/anaconda-runtime/syslinux-vesa-splash.jpg /usr/share/anaconda/pixmaps/anaconda_header.png /usr/share/anaconda/pixmaps/progress_first-lowres.png /usr/share/anaconda/pixmaps/progress_first.png /usr/share/anaconda/pixmaps/splash.png /usr/share/anaconda/pixmaps/syslinux-splash.png
Well, generic-logos is incorrect. anaconda looks for syslinux-vesa-splash.jpg like so: scripts/mk-images.x86: if [ -f $IMGPATH/usr/share/anaconda/syslinux-vesa-splash.jpg ]; then scripts/mk-images.x86: cp $IMGPATH/usr/share/anaconda/syslinux-vesa-splash.jpg $MBD_BOOTTREE/splash.jpg However, I'm a little confused. Doesn't the initial comment say that fedora-logos is being used? If that's the case, the layout of generic-logos shouldn't matter.
clumens: the nightlies are at: http://alt.fedoraproject.org/pub/alt/nightly-composes/ -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
"However, I'm a little confused. Doesn't the initial comment say that fedora-logos is being used? If that's the case, the layout of generic-logos shouldn't matter." Boot to blank screen=fedora-logos boot correctly=generic-logos
Could there have been a mismatch in the development anaconda code and what had been pushed to rawhide? I think another anaconda update has come through since my last test of nightly builds, so I look at making sure the symptoms are still the same tonight or tomorrow.
The bug here hinges on teh fact that no splash.jpg and no background splash.jpg entry nor image file are in the isolinux/syslinux directories. Line 373 of python-imgcreate live.py starts dealing with the image files. def __copy_syslinux_background(self, isodest): background_path = self._instroot + \ "/usr/lib/anaconda-runtime/syslinux-vesa-splash.jpg" if not os.path.exists(background_path): return False shutil.copyfile(background_path, isodest) return True If this file name has changed in RAWHIDE, the splash.jpg will not exist. Nor will the entry in isolinux.cfg due here: def __get_basic_syslinux_config(self, **args): return """ default %(menu)s timeout %(timeout)d %(background)s menu title Welcome to %(name)s! menu color border 0 #ffffffff #00000000 menu color sel 7 #ffffffff #ff000000 menu color title 0 #ffffffff #00000000 menu color tabmsg 0 #ffffffff #00000000 menu color unsel 0 #ffffffff #00000000 menu color hotsel 0 #ff000000 #ffffffff menu color hotkey 7 #ffffffff #ff000000 menu color timeout_msg 0 #ffffffff #00000000 menu color timeout 0 #ffffffff #00000000 menu color cmdline 0 #ffffffff #00000000 menu hidden menu hiddenrow 5 """ % args In the nightly-spin security spin around the 19th, "background" was not in the isolinux.cfg which tells me the is in't expanding, because it doesn't exist. If fedora-logos has changed any files around or file names, this will cause this behaviour with nightly live spins like the security spin only being black screened, when it is supposed to load ISOLINUX.
Here is the RAWHIDE repository created live spin which in testing shows the BLACK BLANK SCREEN: [root@ip70-190-121-13 isolinux]# ls boot.cat initrd0.img isolinux.bin isolinux.cfg vesamenu.c32 vmlinuz0 [root@ip70-190-121-13 isolinux]# cat isolinux.cfg default vesamenu.c32 timeout 100 menu title Welcome to livecd-livecd-201007231929! menu color border 0 #ffffffff #00000000 menu color sel 7 #ffffffff #ff000000 menu color title 0 #ffffffff #00000000 menu color tabmsg 0 #ffffffff #00000000 menu color unsel 0 #ffffffff #00000000 menu color hotsel 0 #ff000000 #ffffffff menu color hotkey 7 #ffffffff #ff000000 menu color timeout_msg 0 #ffffffff #00000000 menu color timeout 0 #ffffffff #00000000 menu color cmdline 0 #ffffffff #00000000 menu hidden menu hiddenrow 5 label linux0 menu label Boot kernel vmlinuz0 append initrd=initrd0.img root=live:CDLABEL=livecd-livecd-i686-201007231929 rootfstype=auto ro liveimg quiet rhgb rd_NO_LUKS rd_NO_MD rd_NO_DM menu default label check0 menu label Verify and Boot kernel vmlinuz0 append initrd=initrd0.img root=live:CDLABEL=livecd-livecd-i686-201007231929 rootfstype=auto ro liveimg quiet rhgb check label local menu label Boot from local drive localboot 0xffff [root@ip70-190-121-13 isolinux]# cd /tmp [root@ip70-190-121-13 tmp]# umount iso ================================================================================ Here is the F13 Everything repository used with livecd-creator, which boots FINE: [root@ip70-190-121-13 isolinux]# ls boot.cat initrd0.img isolinux.bin isolinux.cfg splash.jpg vesamenu.c32 vmlinuz0 [root@ip70-190-121-13 isolinux]# cat isolinux.cfg default vesamenu.c32 timeout 100 menu background splash.jpg menu title Welcome to livecd-livecd-201007231955! menu color border 0 #ffffffff #00000000 menu color sel 7 #ffffffff #ff000000 menu color title 0 #ffffffff #00000000 menu color tabmsg 0 #ffffffff #00000000 menu color unsel 0 #ffffffff #00000000 menu color hotsel 0 #ff000000 #ffffffff menu color hotkey 7 #ffffffff #ff000000 menu color timeout_msg 0 #ffffffff #00000000 menu color timeout 0 #ffffffff #00000000 menu color cmdline 0 #ffffffff #00000000 menu hidden menu hiddenrow 5 label linux0 menu label Boot kernel vmlinuz0 append initrd=initrd0.img root=live:CDLABEL=livecd-livecd-i686-201007231955 rootfstype=auto ro liveimg quiet rhgb rd_NO_LUKS rd_NO_MD rd_NO_DM menu default label check0 menu label Verify and Boot kernel vmlinuz0 append initrd=initrd0.img root=live:CDLABEL=livecd-livecd-i686-201007231955 rootfstype=auto ro liveimg quiet rhgb check label local menu label Boot from local drive localboot 0xffff [root@ip70-190-121-13 isolinux]# It is clear the only difference is the splash.jpg which if were renamed in RAWHIDE's fedora-logos package, would cause this issue.
I am still seeing this with desktop-i386-20100723.01.iso from the nightlies. I can't get it to boot, but it's a wireless keyboard on that machine and maybe there is a separate problem.
I also did a compose using livecd-creator on an F14 system and I still saw the same issue. I tried both a dd directly to a usb device and a burn to a DVD RW. I see a syslinux announcement and then it looks like the boot process crashes or hangs. There is no activity on the boot media and the screen stays black. Trying to use the wireless keyboard has no effect. I've waited more than the expect time for the boot to continue unattended and it still doesn't seem to be doing anything.
I know what this one is now. live.py needs to be changed to refer to the new location of the vesa splash image. I'll work up a patch tonight and submit it to the livecd list for acks. I'll also file a bug against generic logos.
how will this affect the use of generic-logos in Soas-remixes?
It would break it until it gets fixed. I would expect it to get fixed soon, but we can discuss on the patch review whether its worth looking in both places for a while. As far as I can tell the vesa splash image is only used for syslinux and hence live image boots. The other option is to push back against the anaconda change that is reflected in fedora-logos. But I expect it is simpler to just change generic-logos and live.py.
I tested a patch to live.py and that fixes the problem for fedora-logos. It will break using generic-logos until that package gets changed to match fedora-logos if applied as is. This seems reasonable since generic-logos should pretty much match fedora-logos, but maybe we'll do something to handle both versions for a bit.
> I know what this one is now. live.py needs to be changed to refer to the new > location of the vesa splash image. I'll work up a patch tonight and submit it > to the livecd list for acks. I'll also file a bug against generic logos. Yep, this is correct. The file location in comment #11 is incorrect.
As was pointed out on the livecd list, we want to be able to handle both the new and the old locations so that we can support building from older repos with the current livecd-creator. So while, I'll file a bug against generic-logos, spins using generic-logos will continue to work in the meantime. A patch has been agreed upon (approved) on the livecd list and I'll be getting it applied and a new livecd-tools package built tonight.
livecd-tools-033-1 has been built for rawhide and should fix this.
I just did a build from f13 with livecd-tools (031-1-fc12.1) and fedora-livecd-soas.ks (0.13.5-1fc13.noarch.) It worked fine. No need for generic-logos -Used AMD Turion64 laptop.
In reply to Comment 22 There isn't an issue with F13 livecd-tools and F13 repositories. There was an issue with F13 livecd-tools and using RAWHIDE. I also don't see where you attached any soas.ks so your comment is irrelevant. This is fixed anyways and should be closed.
http://koji.fedoraproject.org/koji/buildinfo?buildID=186685
Confirming this fixes for the problem for me too. Thanks!
(In reply to comment #23) > In reply to Comment 22 > > There isn't an issue with F13 livecd-tools and F13 repositories. > There was an issue with F13 livecd-tools and using RAWHIDE. > > I also don't see where you attached any soas.ks so your comment is irrelevant. The fedora-livecd-soas.kskickstart in spin-kickstarts-0.13.5-1.fc13 configured to use rawhide repos is completely relevant and what is used to build the spins. There is also absolutely no need to be rude.
In reply to Comment 26 If you cannot provide evidence or some more factual data supporting your claims about my rudeness, you might want to refrain from suggesting that I am being rude. I am not being rude, there are several bugs here which users are posting in which are completely not relevant, not only that but uninformative, much like your comments. This bug has absolutely nothing to do with a kickstart file.
This bug appears to have been reported against 'rawhide' during the Fedora 14 development cycle. Changing version to '14'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Discussed at today's blocker review meeting. Several of us confirmed the bug is fixed with 033-2, but that build was whacked in Rawhide by the python 2.7 rebuild 032-5. So we need another livecd-tools build with the 033-2 changes (033-3). thanks! -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Since I claimed responsibility for doing another bump to deal with the python update fallout, I changed the assignee to myself.
livecd-tools-033-3.fc14 has been submitted as an update for Fedora 14. http://admin.fedoraproject.org/updates/livecd-tools-033-3.fc14
livecd-tools-033-3.fc14 has been pushed to the Fedora 14 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update livecd-tools'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/livecd-tools-033-3.fc14
Can we get a package push for Fedora 13 updates for livecd-tools-033.3 Bruno?
I am a bit leery of doing f13 updates while I am on vacation. There will also be another patch rollup soon and I'd rather do one update instead of two. I'll start a discussion on this on the livecd list.
livecd-tools-033-3.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report.