On Tue, 2012-05-29 at 10:00 -0400, Adam Jackson wrote: > On Sat, 2012-05-26 at 20:22 -0700, John Reiser wrote: > > > Peter, how in general do you want to proceed where we have documented > > > cases of graphics mode setting failure in grub2? Do you want individual > > > bug reports for each affected bit of hardware? Downstream, upstream? > > > What kind of info should be included? Thanks! > > > > What's not good enough about using [the equivalent of] vesafb, > > so as to to avoid problems with mode-setting? Or, use vesafb > > unless the PCI vendor:device:version is on a known-good list? > > Only all the things wrong with VBE, which I don't especially feel like > repeating yet again. > > Graphical bootloader is not my favorite idea. I did propose disabling it again before release, but a bit too late; we didn't really have enough solid data to justify the change. I'm hoping it won't turn out _too_ terribly. I did spend some time looking into what Ubuntu does (since they've been using grub2 for some time and have a wide base of consumer hardware among their users, I was thinking this may give an indication as to what their experience with graphical grub has taught them). They default to graphical grub, but with quite a few caveats: 1) Unless you're multi-booting, they set the default timeout to 0, so you never see grub by default (you have to edit the timeout or hold down a key on boot). 2) They have an explicit blacklist of hardware that's forced to text mode - the list is in the 'grub-gfxpayload-lists' package. 3) They have a patch to grub that explicitly blacklists a particular mode that is known to be problematic on a specific system: ubuntu_blacklist_1440x900x32.patch , the result of https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/701111 . This is obviously an insane road to go down. 4) They have a somewhat large patch to grub which implements a 'failsafe mode', rather similar to the one pjones recently posted for UEFI mode to devel@ under the title "[PATCH] Add check_completed_boot command on EFI systems." Briefly, after a successful boot, a setting is flipped somewhere which grub can check. At each boot, grub checks it. If it's not flipped - indicating the last attempt to boot the system was unsuccessful - grub starts up in the 'failsafe' mode, which among other things, uses text mode, not graphical. This patch has not gone upstream, and Ubuntu are still using grub2 1.99 - not any of the 2.0 betas (probably precisely because of this and several other large, non-upstreamed patches) - so we can't easily adopt the patch for Fedora or get it upstreamed. The patch that creates this 'failsafe' mode is 'ubuntu_failed_boot_menu.patch' in the grub2 package; it should be considered to also include the new files grub-common.init and grub-common.pm-sleep that are created in the Ubuntu package (seriously, Debian/Ubuntu, grow a sane fucking patch system already). The use of text mode during failsafe is actually part of the patch ubuntu_gfxpayload_filter.patch . The good news from the Ubuntu investigation I did is that their blacklisting taken in full doesn't actually cover a huge amount of hardware. The ubuntu_blacklist_1440x900x32.patch covers one system (albeit a fairly popular one) - the Thinkpad T400. The grub-gfxpayload-lists blacklist appears to cover only a single Radeon adapter and all VMware VMs. Obviously, I would be more worried if Ubuntu had a huge blacklist, as that would indicate there was lots of known-bad hardware out there we were about to run into trouble with. On the principle of things, I agree broadly with ajax that what's going on here seems suboptimal, with two different projects trying to duplicate the same work (modesetting, and handling hardware that isn't good at modesetting). I believe there are some legitimate reasons why it may make sense to do it in the bootloader, though. Maybe kernel/X and grub need to sit down and thrash out who's going to do the modesetting? If that's not happened already? This obviously has implications for the whole 'smooth boot' idea. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
