Bug 608992 - Add "Boot system with basic video driver" option at the initial screen
Summary: Add "Boot system with basic video driver" option at the initial screen
Alias: None
Product: Fedora
Classification: Fedora
Component: livecd-tools
Version: 14
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: David Huff
QA Contact: Fedora Extras Quality Assurance
Whiteboard: AcceptedBlocker
Depends On: 633827
Blocks: F14Beta, F14BetaBlocker
TreeView+ depends on / blocked
Reported: 2010-06-29 06:56 UTC by He Rui
Modified: 2010-09-16 03:48 UTC (History)
9 users (show)

Fixed In Version: livecd-tools-034-7.fc14
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2010-09-16 03:48:55 UTC
Type: ---

Attachments (Terms of Use)
Add basic video driver option to syslinux/isolinux configuration (2.33 KB, patch)
2010-08-14 22:02 UTC, Jasper O'neal Hartline
no flags Details | Diff

Description He Rui 2010-06-29 06:56:15 UTC
Description of problem:

So far F-13 GA Live images have two boot options at the initial screen: "Boot", "Verify and Boot". But similar to the Fedora install images, LIVE images should also have a base video driver boot option to allow the system boot with xdriver=vesa.

Therefore, I propose to add "Boot system with basic video driver" option, which  specifies the parameters: xdriver=vesa nomodeset, since xdriver=vesa working is an important workaround for display problems.

Comment 1 Jasper O'neal Hartline 2010-08-12 04:27:49 UTC
This functionality needs to be implemented in live.py in the syslinux configuration section so that the Live media created whether they be nightly spins, or homemade livecd media do reflect a base level of conformity between media. This being the DVD/CD GA media and Live media.

The points made in the original report stating these options are workarounds for some graphics chipsets is very important to users who already know they may have a problem which is ongoing or for users who would have no other way to boot thier Live media without this option.

adamw has also requested this be added as a feature.

Comment 2 Adam Williamson 2010-08-12 04:54:48 UTC
note that passing xdriver= doesn't currently work. I'm working up a patch to spin-kickstarts for this. But yes, I think we should add this, for F14 Beta and future builds.

Fedora Bugzappers volunteer triage team

Comment 3 Jasper O'neal Hartline 2010-08-14 19:10:00 UTC
This commit made to spin-kickstarts will allow us to implement this functionality in livecd-tools as soon as possible. The original discussion was that this could be added as soon or before Beta release time.


Comment 4 Jasper O'neal Hartline 2010-08-14 22:02:41 UTC
Created attachment 438805 [details]
Add basic video driver option to syslinux/isolinux configuration

Comment 5 Adam Williamson 2010-09-03 17:08:45 UTC
quick note on a wrinkle here - the 'nomodeset' parameter must not only be passed to the live environment but also set in the kernel configs for the *installed* system too (and of course the xorg config file must be installed), so that when you boot the live image with basic graphics mode and then install, the installed system also runs in 'basic graphics mode' (nomodeset and vesa as the X driver).

We discussed this at the blocker review meeting today and agreed to make it a beta blocker under the new Alpha criterion "The graphical boot menu for all installation images should include an entry which causes both installation and the installed system to use a generic, highly compatible video driver (such as 'vesa'). This mechanism should work correctly, launching the installer and attempting to use the generic driver". Technically this was added to the F15 criteria, not F14, but that was only because the F14 Alpha was already out, and we agreed that we can require it to be met for F14 Beta.

Comment 6 Bruno Wolff III 2010-09-03 17:20:08 UTC
What handles that part of the install? If it's anaconda, wouldn't it work the same as other installs? (I'm not sure which stuff is done by anaconda and which stuff is custom for livecd's.)

Comment 7 Bruno Wolff III 2010-09-03 17:22:04 UTC
As I tried to mention when I noticed that you guys were discussing something I could have helped with (but after endmeeting), the plan is to get a new livecd-tools release out this weekend with commited fixes and a couple of new scripts (that are used standalone).

Comment 8 Adam Williamson 2010-09-03 22:38:04 UTC
If you mean writing nomodeset to grub config for the installed system, I'm not entirely sure; there's a bug report indicating it may be broken for the traditional installer at present. We'd probably better test it and check what happens at present.

Comment 9 John Poelstra 2010-09-09 04:36:17 UTC
What are the plans for addressing and assessing this bug?  We'd love to have more information before the next blocker meeting this Friday.

Comment 10 Bruno Wolff III 2010-09-09 05:05:43 UTC
The plan is that I'm already supposed to have a new build of livecd-tools out, but am behind on getting it done. If Jasper's patch is good enough that may be enough. But I am not sure if there might be more to this based on other comments. I haven't personally looked into the problem. I'm just supposed to gather outstanding patches that are suitable and get them committed and a new version of the package built. Thursdays I am tied up all day, so it won't happen before Friday night.

Comment 11 Adam Williamson 2010-09-09 14:08:38 UTC
We'll need Jasper's patch as a minimum. I think it's probably also all we'll need to change in livecd-tools; the wrinkle I noted about having nomodeset written to the grub config post-install is still valid, but whether we need to do something to fix that or not, I don't think it would be in livecd-tools, but in anaconda. So I'd say go ahead and build a new livecd-tools with Jasper's patch and we'll work from there.

Comment 12 Bruno Wolff III 2010-09-11 19:01:41 UTC
I committed Jasper's patch for live.py upstream.
It looks like it is still a couple more hours of work collecting backlogged patches, but I expect to have a build ready for testing late tonight.

Comment 13 Fedora Update System 2010-09-12 04:20:36 UTC
livecd-tools-034-1.fc14 has been submitted as an update for Fedora 14.

Comment 14 Adam Williamson 2010-09-13 16:14:23 UTC
There's a small problem with the current implementation: it's configured as the *default* option, which is not what we want. We want the default to be 'Boot system', as it was before.

Fedora Bugzappers volunteer triage team

Comment 15 Adam Williamson 2010-09-13 16:14:49 UTC
well, the problem's small in term of the fix being easy. it's not small in impact, it must be fixed for release.

Fedora Bugzappers volunteer triage team

Comment 16 Bruno Wolff III 2010-09-13 16:23:12 UTC
I applied Jasper's patch in the 034 build. Does that fix the issue? If not what more is needed to fix it?
Is there a test case for this?

Comment 17 Adam Williamson 2010-09-13 16:34:05 UTC
i'm using 034, if I wasn't using that there wouldn't *be* any menu entry to test. what's needed to fix it is to make the newly-added menu entry not the default (I don't know how to do that).

I also just found a bigger problem in the 034 implementation: it doesn't add the 'nomodeset' parameter which is needed for this to work properly. just adding 'xdriver=vesa' isn't enough, the 'nomodeset' parameter must also be specified in this option (but not in any other, only this one).

Fedora Bugzappers volunteer triage team

Comment 18 Adam Williamson 2010-09-13 16:35:54 UTC
the test case for the first bug is simple - build a live image with the appropriate livecd-tools and boot it. hit tab at the 'ten second countdown' screen and check which menu entry is highlighted. for the second bug, well, an easy way to tell is that the graphical splash shouldn't be shown when using the 'basic video' boot option. you can also hit tab at the 'ten second countdown' screen and check if the 'nomodeset' parameter is in the default kernel parameters for the 'basic video' choice.

Fedora Bugzappers volunteer triage team

Comment 19 Bruno Wolff III 2010-09-13 16:54:50 UTC
So let me read that back to you, so I have an idea of what I should work on tonight if no one beats me to it:

There are multiple boot menus, but the vesa one is not supposed to be the default. So that having the default be the other one will solve one remaining aspect of this issue.

The grub config for the vesa boot menu item needs " nomodeset" added to it.

Unfortunately I won't get to work on a new build until tonight (possibly late). I do think I can figure out how to do the above two things using the earlier patch as an example. I may not have time to do test live image composes before I need to sleep, so I may not know if what I change actually fixes the problem.

Comment 20 Adam Williamson 2010-09-13 17:18:49 UTC
I'd say "There are multiple boot menu entries", but yes, that's right. I had a quick look myself but the format of the boot menu entries for syslinux or whatever the hell we're using is very bizarre and I just couldn't figure out what to poke to change it.

Fedora Bugzappers volunteer triage team

Comment 21 Fedora Update System 2010-09-13 18:10:26 UTC
livecd-tools-034-2.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: https://admin.fedoraproject.org/updates/livecd-tools-034-2.fc14

Comment 22 Bruno Wolff III 2010-09-14 00:25:25 UTC
I started looking at this. It looks like the nomodeset can be set where the basic video driver is set to vesa for live boots. That doesn't cover installs defaulting to the same option.
It looks like the basic video stanzas were copied at a level that it is hard to deal with. I think defining just one at a time (with and without the basic video driver options passed) makes more sense. Then I think where the default is set, you can get it applied to the right one. I think right now it applies to the previous one and the basic one is defined second in a pair, so this might be what's making it the default.
I don't fully grok this, but I think I have a good idea to try.

Comment 23 Bruno Wolff III 2010-09-14 04:05:30 UTC
Please give this another try. I got one to boot with the right default menu. Unfortunately the labels were the same. I have a new build with that supposedly fixed, but I need to sleep and don't have time to build another test ISO.
Only booting is fixed by what I did. I don't know what the status of installs is.

Comment 24 Adam Williamson 2010-09-14 11:23:10 UTC
This one looks pretty good - the default is correct and the 'basic video' option has nomodeset included. I'm going to test installation now. One thing, though: my built live image had a grey background for the bootloader menu, not a Fedora image (as it should be). I did use the new https://admin.fedoraproject.org/updates/fedora-logos-14.0.0-1.fc14 fedora-logos package for this live image, instead of the current one in dist-f14. does livecd-tools have to be changed with this new fedora-logos, or is this some other bug?

when running livecd-iso-to-disk to write the image to a USB stick I got this error:

chattr: No such file or directory while trying to stat /media/usbdev.arLObL/syslinux/extlinux.sys

not sure if that's new, or if it's actually a problem.

Comment 25 Adam Williamson 2010-09-14 12:17:41 UTC
Okay, so aside from the grey bootloader issue, after installation from the 'basic video driver' option we currently leave a bad config: nomodeset is correctly added to kernel parameters, but there is no xorg.conf or xorg.conf.d/blahblah.conf to set vesa as the X driver. This is probably mostly my fault =) I adjusted livesys service to set it during live boot but the file created there obviously doesn't carry over to the installed system. I'll see if I can figure out what we need to do to have that file in the installed system.

Comment 26 Bruno Wolff III 2010-09-14 12:24:18 UTC
For the background image it would be nice to know if that was introduced by livecd-iso-to-disk or if it happens in the original ISO as well. Also I seem to remember there were some issues with the artwork showing F13 and version neutral background was supposed to be developed for beta. Maybe this is related to that?

The chattr error is probably a new bug, but might not be that important. I won't get a chance to look at that until tonight at the earliest.

For the install, you'll probably want to have liveinst do something different based on the vesa driver being used when it is run.

Comment 27 Adam Williamson 2010-09-14 13:27:28 UTC
The ISO has grey background as well (I wrote it to a DVD to test installation). Yes, the artwork stuff you mention is what changed in that new fedora-logos build I referred to: you might want to take a look at what changed in that and see if livecd-tools needs to reflect it somehow.

I've talked to anaconda devs briefly about the install issue. akozumpl suggested running liveinst with --xdriver vesa parameter and see if that works. I'm testing that now. If it works, we can try to set up the livecd stuff so that, somehow, it runs liveinst with that parameter if you specify xdriver on the kernel command line. The other option is to use some other mechanism to have the live install process write an xorg.conf (or xorg.conf.d) file when xdriver= is specified in the command line. I'm not really familiar with what (if any) mechanisms we have to allow the live install process to modify the installed system differently from how anaconda usually does it, so I'm really not sure which of these options is best. Do you have thoughts on that? Do you know who else would know?

Comment 28 Bruno Wolff III 2010-09-14 14:20:16 UTC
I'll check out the artwork. Stuff really shouldn't move around as that makes it hard to have livecd-tools work across releases.

If liveinst --xdriver vesa works, then I think we could at least do a customization to the desktop icon for running liveinst for liveuser at boot. That would probably be a good enough solution.

Comment 29 Adam Williamson 2010-09-14 14:29:51 UTC
Brian's going to look at the anaconda side in the bug he's just marked as blocking this one, he has some ideas.

Comment 30 James Laska 2010-09-14 19:59:44 UTC
While testing the updated fedora-logos package using a custom build Live image, it seems the syslinux/syslinux.cfg created by livecd-tools doesn't properly reference the splash.png (see comparison between F-13 and F-14 syslinux.cfg at http://fpaste.org/gymS/).

Could the latest updates have introduced this change?

Comment 31 Bruno Wolff III 2010-09-14 20:14:03 UTC
That's what it looks like. Tom has committed a patch to the package. He hasn't done a build yet, but I'll do one tonight if he hasn't. I also commit the same change upstream.

Comment 32 James Laska 2010-09-15 00:02:37 UTC
Looks like a build is available.  I'll be able to test tomorrow.


Comment 33 Fedora Update System 2010-09-15 03:23:14 UTC
livecd-tools-034-7.fc14 has been submitted as an update for Fedora 14.

Comment 34 Fedora Update System 2010-09-15 06:52:34 UTC
livecd-tools-034-7.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: https://admin.fedoraproject.org/updates/livecd-tools-034-7.fc14

Comment 35 James Laska 2010-09-15 13:28:46 UTC
Confirmed that a new (non-default) boot option is present with live images created using livecd-tools-034-7.fc14.  The boot option is titled "Boot (Basic Video)" and contains the kernel options "xdriver=vesa nomodeset".

Comment 36 Adam Williamson 2010-09-15 16:26:27 UTC
with current livecd-tools this looks good, we can close when it goes stable i think. please submit it.

Comment 37 Bruno Wolff III 2010-09-15 16:41:21 UTC
I requested a push to stable.

Comment 38 Fedora Update System 2010-09-16 03:47:20 UTC
livecd-tools-034-7.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.