Created attachment 454996 [details] The other grub picture Description of problem: Booted F14-final-rc1 in kvm and found that another grub picture was shown within a second before it turned to the common used grub menu. The total process is very quick but I can still see that picture. The picture was the nearly same as that(as attached) in bug#635330, only without the 'boot:'. Version-Release number of selected component (if applicable): anaconda 14.22 How reproducible: 100% Steps to Reproduce: 1. Boot F14-final-rc1 2. Stare at the screen without blinking! Additional info: I roughly compared the isoliux directory between this version and F14-final-TC1, and found out that a splash.lss file is in included in RC1 but not in TC1. Tell me if you need more debug info.
Haven't found a criterion fitting for this case, but this problem looks very weird during install, so propose it as NTH bug which should be fixed before released.
I've seen this in booting from the i386 and x86_64 DVDs as well.
I think this is also related to the speed of the guest. When I configure my guests for 1024 of memory, the transition between the default syslinux prompt, and the friendlier themed Fedora boot screen happens very quickly.
(In reply to comment #1) > Haven't found a criterion fitting for this case, but this problem looks very > weird during install, so propose it as NTH bug which should be fixed before > released. "1. Provide a polished final release ..." http://fedoraproject.org/wiki/Fedora_14_Final_Release_Criteria
(In reply to comment #4) > "1. Provide a polished final release ..." > http://fedoraproject.org/wiki/Fedora_14_Final_Release_Criteria Just to clarify, what you list above is the goal/objective for having release criteria, not a release criteria itself. We have nothing specific to capture the scenario described in this bug report. A more appropriate quote from the criteria might be from the Alpha release criteria ... "# All dedicated installer images must boot to the graphical boot menu and allow the user to select install options. If no option is selected, the installer should load after a reasonable timeout " However, my understanding is that the problem in this bug report doesn't prevent the above criteria from being met, as the graphical boot menu does appear. However, on some undetermined set of systems/hardware/environments, the isolinux/syslinux transition happens more slowly. This is definitely a valid issue and has been proposed for the 'nice-to-have' list so that if a fix is available, and Fedora 14 needs to respin, this issue would be included. However, we aren't yet able to make a determination that this impacts the release and qualifies as a release blocker. Also, I don't believe there is a recommendation or patch proposed to resolve this issue.
(In reply to comment #0) ... > Additional info: > I roughly compared the isoliux directory between this version and > F14-final-TC1, and found out that a splash.lss file is in included in RC1 but > not in TC1. Tell me if you need more debug info. You appear to be correct about splash.lss. I rebuilt the F14-Final-RC1 netinst ISO after renaming splash.lss to xsplash.xss and the spurious image does not appear. Procedure: 1. mount Fedora-14-x86_64-netinst.iso and "cp -a" to a tmp dir. 2. rename splash.lss to xsplash.xss 3. $ sudo genisoimage -D -r -V "F14-netinst-Rebuild" -cache-inodes -J -l -b isolinux/isolinux.bin -c isolinux/boot.cat -no-emul-boot -boot-load-size 4 -boot-info-table -o ../x3.iso . 4. test with VM: $ qemu-kvm -m 512m -cdrom x3.iso (I realize there are higher level tools for this, but this is what I know ... :-)) James said: "Also, I don't believe there is a recommendation or patch proposed to resolve this issue." Could this be related to: Bug 635330 - Boot menu is missing in F14 Beta RC2 install discs Bug 635330, Comment 5 notes there was a splash.lss file present.
https://admin.fedoraproject.org/updates/fedora-logos-14.0.1-500.fc14 is the update that introduced splash.lss.
(In reply to comment #7) > https://admin.fedoraproject.org/updates/fedora-logos-14.0.1-500.fc14 is the > update that introduced splash.lss. Thanks for pointing that out. Here is a quick-and-dirty timeline that could explain the absence of this bug in TC1 and its presence in RC1: 14.TC1.1/ 13-Oct-2010 09:07 fedora-logos-14.0.1-500.fc14 submitted for testing 2010-10-15 19:44:07 pushed to stable 2010-10-19 09:13:20 14.RC1/ 21-Oct-2010 21:11 http://serverbeach1.fedoraproject.org/pub/alt/stage/?C=M;O=A https://admin.fedoraproject.org/updates/fedora-logos-14.0.1-500.fc14
(In reply to comment #6) > James said: "Also, I don't believe there is a recommendation or patch proposed > to resolve this issue." > > Could this be related to: > Bug 635330 - Boot menu is missing in F14 Beta RC2 install discs > Bug 635330, Comment 5 notes there was a splash.lss file present. Nice detective work. All previous releases of Fedora (back to F-7) had *only* splash.jpg in the isolinux directory. However, in F-14-RC1 we have splash.lss, splash.jpg and syslinux-vesa-splash.jpg (which is the same as splash.jpg). The change to address bug#635330 is available at http://git.fedorahosted.org/git/?p=anaconda.git;a=commitdiff;h=20c9a6a6189eb912857263875ef79c890a6fb2d5 One suggestion on IRC was to remove the syslinux/isolinux graphic (splash.lss) altogether since it's not used. You're results confirm that this solution appears to work. Looking closer at the patch, following the if...elif...elif...else conditional checks in prepareBootTree(), only 1 image should be copied to the isolinux directory. I wasn't sure why *both* splash.lss *and* syslinux-vesa-splash.jpg are copied to the isolinux directory. But I see now the first line in prepareBootTree() copies *all* files from /usr/share/anaconda/boot/ into the isolinux directory. (cd $BOOTDISKDIR; find . -maxdepth 1 ! -name "*.msg" ! -type d | cpio --quiet -p $MBD_BOOTTREE) That line hasn't changed since 2006, but fedora-logos did just add splash.lss to it's package on Friday October 15 (see http://git.fedorahosted.org/git/?p=fedora-logos.git;a=commit;h=608883c2bee148ebb632cc242578db8870df7df1). So that explains why we now have multiple splash images being displayed. The first being the transient splash.lss, and the second being the more appropriate splash.jpg. I believe mk-images.x86 needs to be adjust to account for this? Or fedora-logos should no longer package splash.lss?
Backstory: fedora-logos used to include a script that could be used (by anaconda or others) to generate splash.lss. This script has dependencies on two other packages that provide the tools that actually do the work to manipulate the images and spit out splash.lss. A bug was filed to add these dependencies to fedora-logos, but when I did that, it was determined that these dependencies (while correct) added unwanted dependency bloat to fedora-logos (and thus, to all the images). So, instead, I reworked fedora-logos to simply BuildRequires these dependencies and to run the script during package build, and include the resulting splash.lss, instead of packaging the script at all. So, that brings us to here and now. The options are: A) Go back to packaging only the splash.lss script without proper dependencies. (BAD) B) Package the splash.lss script with proper dependencies (BLOAT) C) Package only the splash.lss D) Don't package either the splash.lss or the script. (This might break certain anaconda use cases?) My inclination is to go with option C, and fix anaconda to be less aggressive in copying every file out of /usr/share/anaconda/boot/.
Removing F14 NTH status as F14 is now out. Remaining open nice-to-have issues do NOT automatically become nice-to-have issues for Fedora 15. If you believe a Fedora 14 issue which was accepted as nice-to-have but not resolved in time for release should also qualify for nice-to-have status for Fedora 15, please re-propose it as nice-to-have for Fedora 15. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
This message is a notice that Fedora 14 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 14. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At this time, all open bugs with a Fedora 'version' of '14' have been closed as WONTFIX. (Please note: Our normal process is to give advanced warning of this occurring, but we forgot to do that. A thousand apologies.) Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, feel free to reopen this bug and simply change the 'version' to a later Fedora version. Bug Reporter: Thank you for reporting this issue and we are sorry that we were unable to fix it before Fedora 14 reached end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" (top right of this page) and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping