Bug 617115 - rawhide live spins showing black screen instead of syslinux boot menu
rawhide live spins showing black screen instead of syslinux boot menu
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: livecd-tools (Show other bugs)
14
All Linux
low Severity medium
: ---
: ---
Assigned To: Bruno Wolff III
Fedora Extras Quality Assurance
AcceptedBlocker
:
Depends On:
Blocks: F14Alpha/F14AlphaBlocker
  Show dependency treegraph
 
Reported: 2010-07-22 04:53 EDT by Jens Petersen
Modified: 2010-09-04 01:19 EDT (History)
16 users (show)

See Also:
Fixed In Version: livecd-tools-033-3.fc14
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-08-08 06:39:18 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Jens Petersen 2010-07-22 04:53:14 EDT
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.
Comment 1 satellitgo 2010-07-22 14:48:47 EDT
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
Comment 2 Jens Petersen 2010-07-22 22:56:39 EDT
Yes, thanks for that tip - I did generic spin here and also confirm it works.

I guess generic-logos needs breaking^Wtweaking too. :)
Comment 3 James Laska 2010-07-23 08:43:48 EDT
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 "
Comment 4 Adam Williamson 2010-07-23 12:38:51 EDT
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
Comment 5 Chris Lumens 2010-07-23 13:42:24 EDT
Where are you getting these images from?
Comment 6 Bruno Wolff III 2010-07-23 13:53:03 EDT
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
Comment 7 Chris Lumens 2010-07-23 13:59:58 EDT
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.
Comment 8 Adam Williamson 2010-07-23 14:16:19 EDT
clumens: the nightlies are at:

http://alt.fedoraproject.org/pub/alt/nightly-composes/



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 9 satellitgo 2010-07-23 14:58:09 EDT
"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
Comment 10 Bruno Wolff III 2010-07-23 15:34:43 EDT
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.
Comment 11 Jasper O'neal Hartline 2010-07-23 22:09:47 EDT
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.
Comment 12 Jasper O'neal Hartline 2010-07-23 23:02:17 EDT
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.
Comment 13 Bruno Wolff III 2010-07-25 00:59:43 EDT
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.
Comment 14 Bruno Wolff III 2010-07-25 02:47:07 EDT
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.
Comment 15 Bruno Wolff III 2010-07-25 13:13:30 EDT
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.
Comment 16 satellitgo 2010-07-25 13:32:11 EDT
how will this affect the use of generic-logos in Soas-remixes?
Comment 17 Bruno Wolff III 2010-07-25 23:32:27 EDT
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.
Comment 18 Bruno Wolff III 2010-07-26 02:02:57 EDT
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.
Comment 19 Chris Lumens 2010-07-26 10:03:21 EDT
> 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.
Comment 20 Bruno Wolff III 2010-07-26 10:09:47 EDT
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.
Comment 21 Bruno Wolff III 2010-07-27 06:48:38 EDT
livecd-tools-033-1 has been built for rawhide and should fix this.
Comment 22 satellitgo 2010-07-27 20:33:48 EDT
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.
Comment 23 Jasper O'neal Hartline 2010-07-27 20:55:48 EDT
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.
Comment 25 Jens Petersen 2010-07-27 21:49:17 EDT
Confirming this fixes for the problem for me too.  Thanks!
Comment 26 Peter Robinson 2010-07-28 11:23:39 EDT
(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.
Comment 27 Jasper O'neal Hartline 2010-07-28 14:42:44 EDT
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.
Comment 28 Bug Zapper 2010-07-30 08:44:12 EDT
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
Comment 29 Adam Williamson 2010-07-30 12:41:02 EDT
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
Comment 30 Bruno Wolff III 2010-07-30 21:20:28 EDT
Since I claimed responsibility for doing another bump to deal with the python update fallout, I changed the assignee to myself.
Comment 31 Fedora Update System 2010-07-30 22:54:35 EDT
livecd-tools-033-3.fc14 has been submitted as an update for Fedora 14.
http://admin.fedoraproject.org/updates/livecd-tools-033-3.fc14
Comment 32 Fedora Update System 2010-08-01 15:24:29 EDT
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
Comment 33 Jasper O'neal Hartline 2010-08-03 01:25:52 EDT
Can we get a package push for Fedora 13 updates
for livecd-tools-033.3 Bruno?
Comment 34 Bruno Wolff III 2010-08-03 11:12:50 EDT
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.
Comment 35 Fedora Update System 2010-09-04 01:19:36 EDT
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.

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