2:10 a.m.
[Officially off-topic, as this is a problem with Fedora 18, not testing.
I'm afraid I didn't get a chance to try out F18 before it was released.
Next time ...]
I have a major F18 regression, which makes it unusable: The Gnome/X11
environment sets the screen resolution 10 1280x1024 - but the actual
resolution is 1920x1080. Also, an external display is not seen, even when
I click "Detect Displays" in the "Displays" portion of System
Settings.
This is vanilla Gnome 3. (I assume KDE wouldn't make a difference, though
I'm willing to try it.) This is, alas, an "Optimus" laptop: a GeForce GT
555M,
along with Intel Sandybridge Mobile GT2+. Also alas: There is no way to
disable
the Nvidia chip by booting into the BIOS settings.
F18 was installed from scratch, so I may have missed installing or
setting something.
So for now I'm stuck on Fedora 17 or running Fedora 18 under VirtualBox
under Windows - neither of which makes me happy. Please save me from this
unpleasant choice! What do I look for to fix this?
--
--Per Bothner
per(a)bothner.com http://per.bothner.com/
2:25 a.m.
On Fri, 2013-02-01 at 00:10 -0800, Per Bothner wrote:
[Officially off-topic, as this is a problem with Fedora 18, not
testing.
I'm afraid I didn't get a chance to try out F18 before it was released.
Next time ...]
I have a major F18 regression, which makes it unusable: The Gnome/X11
environment sets the screen resolution 10 1280x1024 - but the actual
resolution is 1920x1080. Also, an external display is not seen, even when
I click "Detect Displays" in the "Displays" portion of System
Settings.
This is vanilla Gnome 3. (I assume KDE wouldn't make a difference, though
I'm willing to try it.) This is, alas, an "Optimus" laptop: a GeForce GT
555M,
along with Intel Sandybridge Mobile GT2+. Also alas: There is no way to
disable
the Nvidia chip by booting into the BIOS settings.
F18 was installed from scratch, so I may have missed installing or
setting something.
So for now I'm stuck on Fedora 17 or running Fedora 18 under VirtualBox
under Windows - neither of which makes me happy. Please save me from this
unpleasant choice! What do I look for to fix this?
well, for a start, Xorg.0.log and xrandr output would probably help. The
graphical tools are too high level to tell us much of use. ajax may have
some ideas regarding optimus specifically, I'm still pretty clueless on
debugging that.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
2:47 a.m.
On 02/01/2013 12:25 AM, Adam Williamson wrote:
well, for a start, Xorg.0.log and xrandr output would probably help.
The
graphical tools are too high level to tell us much of use. ajax may have
some ideas regarding optimus specifically, I'm still pretty clueless on
debugging that.
Xorg.0.log is available at: http://per.bothner.com/tmp/F18-Xorg.0.log
The F17 version at: http://per.bothner.com/tmp/F17-Xorg.0.log
The former does seem to be loading the VESA driver.
xrandr output:
xrandr: Failed to get size of gamma for output default
Screen 0: minimum 640 x 480, current 1280 x 1024, maximum 1280 x 1024
default connected 1280x1024+0+0 0mm x 0mm
1280x1024 0.0*
1024x768 0.0
800x600 0.0
640x480 0.0
Fedora 17 produces:
Screen 0: minimum 320 x 200, current 3840 x 1200, maximum 8192 x 8192
LVDS1 connected 1920x1080+1920+90 (normal left inverted right x axis y
axis) 345mm x 194mm
1920x1080 59.9*+
1400x1050 60.0
1280x1024 60.0
1280x960 60.0
1024x768 60.0
800x600 60.3 56.2
640x480 59.9
VGA1 disconnected (normal left inverted right x axis y axis)
HDMI1 connected 1920x1200+0+0 (normal left inverted right x axis y axis)
610mm x 350mm
1920x1200 60.0*+
1920x1080 50.0 60.0 25.0 30.0
1680x1050 59.9
1680x945 60.0
1400x1050 59.9
1600x900 60.0
1280x1024 75.0 60.0
1440x900 75.0 59.9
1280x960 60.0
1366x768 60.0
1360x768 60.0
1280x800 74.9 59.9
1152x864 75.0
1280x768 74.9 60.0
1280x720 50.0 60.0 60.3
1440x576 25.0
1024x768 75.1 70.1 60.0
1440x480 30.0
1024x576 60.0
832x624 74.6
800x600 72.2 75.0 60.3 56.2
720x576 50.0
848x480 60.0
720x480 59.9
640x480 72.8 75.0 66.7 60.0 59.9
720x400 70.1
DP1 disconnected (normal left inverted right x axis y axis)
--
--Per Bothner
per(a)bothner.com http://per.bothner.com/
3:16 a.m.
On 2013-02-01 00:47 (GMT-0800) Per Bothner composed:
Xorg.0.log is available at: http://per.bothner.com/tmp/F18-Xorg.0.log
It says your cmdline contains nomodeset.
The former does seem to be loading the VESA driver.
Intel driver does not work with nomodeset on cmdline, so X falls back to
VESA, which doesn't do widescreen modes.
xrandr output:
xrandr: Failed to get size of gamma for output default
Screen 0: minimum 640 x 480, current 1280 x 1024, maximum 1280 x 1024
default connected 1280x1024+0+0 0mm x 0mm
1280x1024 0.0*
1024x768 0.0
800x600 0.0
640x480 0.0
1280x1024 is usually the highest available VESA mode.
--
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata *** http://fm.no-ip.com/
10:46 a.m.
On 02/01/2013 01:16 AM, Felix Miata wrote:
On 2013-02-01 00:47 (GMT-0800) Per Bothner composed:
> Xorg.0.log is available at: http://per.bothner.com/tmp/F18-Xorg.0.log
It says your cmdline contains nomodeset.
> The former does seem to be loading the VESA driver.
Intel driver does not work with nomodeset on cmdline, so X falls back to
VESA, which doesn't do widescreen modes.
Thanks! I manually edited /boot/grub2/grub.cfg
to remove the nomodeset options, and that fixed the problem.
I then removed it from GRUB_CMDLINE_LINUX in /etc/default/grub,
so hopefully it won't re-appear.
That leaves the question is where did this come from in the first place?
I did a clean install of Fedora 18. However, I did have a few older
partitions on the disk, and perhaps the Fedora 18 installer used
data from those other partitions to initialize /etc/default/grub.
Sees strange, but that is all I can think of. Unless there is a
bug in the Fedora 18 installer ...
--
--Per Bothner
per(a)bothner.com http://per.bothner.com/
11:39 a.m.
On Fri, 2013-02-01 at 08:46 -0800, Per Bothner wrote:
On 02/01/2013 01:16 AM, Felix Miata wrote:
> On 2013-02-01 00:47 (GMT-0800) Per Bothner composed:
>
>> Xorg.0.log is available at: http://per.bothner.com/tmp/F18-Xorg.0.log
>
> It says your cmdline contains nomodeset.
>
>> The former does seem to be loading the VESA driver.
>
> Intel driver does not work with nomodeset on cmdline, so X falls back to
> VESA, which doesn't do widescreen modes.
Thanks! I manually edited /boot/grub2/grub.cfg
to remove the nomodeset options, and that fixed the problem.
I then removed it from GRUB_CMDLINE_LINUX in /etc/default/grub,
so hopefully it won't re-appear.
That leaves the question is where did this come from in the first place?
I did a clean install of Fedora 18. However, I did have a few older
partitions on the disk, and perhaps the Fedora 18 installer used
data from those other partitions to initialize /etc/default/grub.
Sees strange, but that is all I can think of. Unless there is a
bug in the Fedora 18 installer ...
Are you sure you didn't install in Basic Graphics Mode?
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
12:01 p.m.
On Fri, 2013-02-01 at 08:46 -0800, Per Bothner wrote:
That leaves the question is where did this come from in the first
place?
I did a clean install of Fedora 18. However, I did have a few older
partitions on the disk, and perhaps the Fedora 18 installer used
data from those other partitions to initialize /etc/default/grub.
Sees strange, but that is all I can think of. Unless there is a
bug in the Fedora 18 installer ...
If you foolishly installed with "basic video mode" or whatever thing
we're calling it these days, that'd have been nomodeset, and the install
would copy that into the initial grub config.
If you didn't, then there's a bug somewhere else.
- ajax
11:11 a.m.
On Fri, 2013-02-01 at 04:16 -0500, Felix Miata wrote:
On 2013-02-01 00:47 (GMT-0800) Per Bothner composed:
> Xorg.0.log is available at: http://per.bothner.com/tmp/F18-Xorg.0.log
It says your cmdline contains nomodeset.
> The former does seem to be loading the VESA driver.
Intel driver does not work with nomodeset on cmdline, so X falls back to
VESA, which doesn't do widescreen modes.
If you have 'nomodeset' on the cmdline, you must have either set it
yourself, or installed Fedora in 'Basic Graphics Mode', which causes
this to happen.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
12:44 p.m.
On 02/01/2013 09:11 AM, Adam Williamson wrote:
If you have 'nomodeset' on the cmdline, you must have either
set it
yourself, or installed Fedora in 'Basic Graphics Mode', which causes
this to happen.
The latter might have happened - I had various problems first copying
my SSD to a new larger one, unexpectedly trashing grub when doing some
partition re-arranging, and having to install F15 (! - the most recent
CD I could find in a hurry) so I could boot and then download and
burn F18.
Though it seems a bug to set the installed default mode line to
nomodeset based on whether one boots up the live DVD in basic graphics
mode. Better to install the settings appropriate for the hardware
*plus* some kind of "safe mode" in the grub menu.
--
--Per Bothner
per(a)bothner.com http://per.bothner.com/
2:41 p.m.
On Fri, 2013-02-01 at 10:44 -0800, Per Bothner wrote:
Though it seems a bug to set the installed default mode line to
nomodeset based on whether one boots up the live DVD in basic graphics
mode. Better to install the settings appropriate for the hardware
*plus* some kind of "safe mode" in the grub menu.
(To be clear: when I said "foolishly" in my other mail, I meant it in
the sense that we're fools for making that trap so easy to fall into.
Apologies if offense was taken; none was intended.)
Well, we don't normally set video parameters in the grub config at all.
The theory is that you'll only hit 'nomodeset' if you had to use it to
install, and in that case if we then defaulted to booting a KMS
configuration you'd probably be booting a configuration that you _know_
won't work, since it's the same kernel as you just used to run the
installer (if you're not enabling updates at install time).
So really, to me, this suggests that we should hide the 'nomodeset'
install option a little better. I suspect that showing it early in the
install process suggests to people that it's somehow more likely to
succeed and therefore desirable.
- ajax
4:58 p.m.
On 02/01/2013 12:41 PM, Adam Jackson wrote:
(To be clear: when I said "foolishly" in my other mail, I
meant it in
the sense that we're fools for making that trap so easy to fall into.
Apologies if offense was taken; none was intended.)
I appreciate the clarification - I thought it seemed a bit obnoxious.
Well, we don't normally set video parameters in the grub config
at all.
The theory is that you'll only hit 'nomodeset' if you had to use it to
install, and in that case if we then defaulted to booting a KMS
configuration you'd probably be booting a configuration that you _know_
won't work, since it's the same kernel as you just used to run the
installer (if you're not enabling updates at install time).
Disabling KMS in the installed system just because it was disabled during
installation is at least conceptually wrong, IMO. It's rather like
disabling wireless (or networking in general) when installed because
wireless wasn't configured at install time. Or disabling graphics
because you chose to use a text-mode installer.
So really, to me, this suggests that we should hide the
'nomodeset'
install option a little better. I suspect that showing it early in the
install process suggests to people that it's somehow more likely to
succeed and therefore desirable.
Ideally, I'd have the installer ask something like:
You are currently running in a basic graphics mode (no kernel
mode-setting).
Do you want basic graphics mode for your installation?
Or words to that effect. We'd only need to show it when actually running
in basic graphics mode, so it wouldn't clutter up normal installs.
Also, it always friendly to explain:
(You can change it later by doing xxx.)
though of course you don't want to be too verbose.
--
--Per Bothner
per(a)bothner.com http://per.bothner.com/
5:51 p.m.
On Fri, 2013-02-01 at 14:58 -0800, Per Bothner wrote:
On 02/01/2013 12:41 PM, Adam Jackson wrote:
> (To be clear: when I said "foolishly" in my other mail, I meant it in
> the sense that we're fools for making that trap so easy to fall into.
> Apologies if offense was taken; none was intended.)
I appreciate the clarification - I thought it seemed a bit obnoxious.
> Well, we don't normally set video parameters in the grub config at all.
> The theory is that you'll only hit 'nomodeset' if you had to use it to
> install, and in that case if we then defaulted to booting a KMS
> configuration you'd probably be booting a configuration that you _know_
> won't work, since it's the same kernel as you just used to run the
> installer (if you're not enabling updates at install time).
Disabling KMS in the installed system just because it was disabled during
installation is at least conceptually wrong, IMO. It's rather like
disabling wireless (or networking in general) when installed because
wireless wasn't configured at install time. Or disabling graphics
because you chose to use a text-mode installer.
Well, no it isn't. You might not bother to configure wireless when you
install if you don't need it. But that just doesn't apply to this case
at all. 'basic graphics mode' is pretty clearly positioned as a
workaround for dealing with graphics problems. It is not offered as an
option very prominently, you have to go dig and find it. There's no
particular reason you'd do so unless you had an explicit reason to. It's
not like, on a 'normal' install path, you have a dialog that lets you
pick Basic or Not-Basic and some kind of compelling reason to pick
Not-Basic. Not-Basic is what 99% of people will see. Basic is something
you only see if you picked it explicitly from a fairly obscure place,
which is only going to happen if a) you figured or read that you needed
to do so to deal with a graphics problem you encountered when first
trying in Non-Basic, or b) you twiddle with stuff way more than is good
for you.
I'm just not convinced we need to go to great lengths to deal with case
b), which is you. It happened to you. You complained. We told you what
happened. You now know. This seems like a perfectly appropriate way of
dealing with the problem, given the very small number of people who are
likely to encounter it.
> So really, to me, this suggests that we should hide the
'nomodeset'
> install option a little better. I suspect that showing it early in the
> install process suggests to people that it's somehow more likely to
> succeed and therefore desirable.
Ideally, I'd have the installer ask something like:
You are currently running in a basic graphics mode (no kernel
mode-setting).
Do you want basic graphics mode for your installation?
Or words to that effect. We'd only need to show it when actually running
in basic graphics mode, so it wouldn't clutter up normal installs.
This is way over-engineered.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
6:06 p.m.
On 02/01/2013 03:51 PM, Adam Williamson wrote:
Well, no it isn't. You might not bother to configure wireless
when you
install if you don't need it. But that just doesn't apply to this case
at all. 'basic graphics mode' is pretty clearly positioned as a
workaround for dealing with graphics problems. It is not offered as an
option very prominently, you have to go dig and find it. There's no
particular reason you'd do so unless you had an explicit reason to. It's
not like, on a 'normal' install path, you have a dialog that lets you
pick Basic or Not-Basic and some kind of compelling reason to pick
Not-Basic. Not-Basic is what 99% of people will see. Basic is something
you only see if you picked it explicitly from a fairly obscure place,
which is only going to happen if a) you figured or read that you needed
to do so to deal with a graphics problem you encountered when first
trying in Non-Basic, or b) you twiddle with stuff way more than is good
for you.
I'm just not convinced we need to go to great lengths to deal with case
b), which is you. It happened to you. You complained. We told you what
happened. You now know. This seems like a perfectly appropriate way of
dealing with the problem, given the very small number of people who are
likely to encounter it.
Ok - fair enough. I did the install a couple of weeks ago, so I don't
remember exactly why I had to (or thought I had to use) Basic mode.
(Using was F17 was an acceptable work-around which is one reason I
didn't investigate earlier. I'll now see if I can get F18 usable.
I'm having some problems on F18 with it dying - probably due to
overheating; maybe BumbleBee will help.)
--
--Per Bothner
per(a)bothner.com http://per.bothner.com/
6:26 p.m.
On Fri, 2013-02-01 at 16:06 -0800, Per Bothner wrote:
On 02/01/2013 03:51 PM, Adam Williamson wrote:
> Well, no it isn't. You might not bother to configure wireless when you
> install if you don't need it. But that just doesn't apply to this case
> at all. 'basic graphics mode' is pretty clearly positioned as a
> workaround for dealing with graphics problems. It is not offered as an
> option very prominently, you have to go dig and find it. There's no
> particular reason you'd do so unless you had an explicit reason to. It's
> not like, on a 'normal' install path, you have a dialog that lets you
> pick Basic or Not-Basic and some kind of compelling reason to pick
> Not-Basic. Not-Basic is what 99% of people will see. Basic is something
> you only see if you picked it explicitly from a fairly obscure place,
> which is only going to happen if a) you figured or read that you needed
> to do so to deal with a graphics problem you encountered when first
> trying in Non-Basic, or b) you twiddle with stuff way more than is good
> for you.
>
> I'm just not convinced we need to go to great lengths to deal with case
> b), which is you. It happened to you. You complained. We told you what
> happened. You now know. This seems like a perfectly appropriate way of
> dealing with the problem, given the very small number of people who are
> likely to encounter it.
Ok - fair enough. I did the install a couple of weeks ago, so I don't
remember exactly why I had to (or thought I had to use) Basic mode.
(Using was F17 was an acceptable work-around which is one reason I
didn't investigate earlier. I'll now see if I can get F18 usable.
Just dropping 'nomodeset' from the cmdline should probably do the job.
It's actually also supposed to write an xorg.conf snippet which forces
use of the vesa driver, but I believe that mechanism's been broken for a
while, so you only have to kill 'nomodeset' and it should bounce back to
normal.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
10:01 a.m.
On Fri, 2013-02-01 at 16:26 -0800, Adam Williamson wrote:
Just dropping 'nomodeset' from the cmdline should probably do
the job.
It's actually also supposed to write an xorg.conf snippet which forces
use of the vesa driver, but I believe that mechanism's been broken for a
while, so you only have to kill 'nomodeset' and it should bounce back to
normal.
It had done so, historically. Part of the reason it doesn't anymore is
that asking for vesa is wrong on efifb. It's better to just let the KMS
X driver decide it won't work and fall back to whichever of vesa or
fbdev is appropriate.
---
If I can abuse this thread for design discussion for a moment, what if
instead of the grub editor horrorshow for things like this, we had a
list of debugging tickboxes you could check that appended the right
thing to kcmdline (and just remember the defaults for them across
boots). That way you're not writing two boot stanzas for every kernel,
and it's more obvious that:
[X] Disable accelerated graphics
is something you should just uncheck.
- ajax
10:04 a.m.
Once upon a time, Adam Jackson <ajax(a)redhat.com> said:
If I can abuse this thread for design discussion for a moment, what
if
instead of the grub editor horrorshow for things like this, we had a
list of debugging tickboxes you could check that appended the right
thing to kcmdline (and just remember the defaults for them across
boots). That way you're not writing two boot stanzas for every kernel,
and it's more obvious that:
[X] Disable accelerated graphics
is something you should just uncheck.
That would be nice. Another useful option would be rescue/single-user
mode.
--
Chris Adams <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
12:24 p.m.
On Feb 4, 2013, at 9:01 AM, Adam Jackson <ajax(a)redhat.com> wrote:
If I can abuse this thread for design discussion for a moment, what
if
instead of the grub editor horrorshow for things like this, we had a
list of debugging tickboxes you could check that appended the right
thing to kcmdline (and just remember the defaults for them across
boots). That way you're not writing two boot stanzas for every kernel,
and it's more obvious that:
[X] Disable accelerated graphics
is something you should just uncheck.
Yes absolutely.
On Feb 4, 2013, at 9:04 AM, Chris Adams <cmadams(a)hiwaay.net> wrote:
That would be nice. Another useful option would be rescue/single-user
mode.
Yes exactly.
Chris Murphy
10:20 p.m.
On 02/01/2013 03:51 PM, Adam Williamson wrote:
Well, no it isn't. You might not bother to configure wireless
when you
install if you don't need it. But that just doesn't apply to this case
at all. 'basic graphics mode' is pretty clearly positioned as a
workaround for dealing with graphics problems. It is not offered as an
option very prominently, you have to go dig and find it. There's no
particular reason you'd do so unless you had an explicit reason to. It's
not like, on a 'normal' install path, you have a dialog that lets you
pick Basic or Not-Basic and some kind of compelling reason to pick
Not-Basic. Not-Basic is what 99% of people will see. Basic is something
you only see if you picked it explicitly from a fairly obscure place,
which is only going to happen if a) you figured or read that you needed
to do so to deal with a graphics problem you encountered when first
trying in Non-Basic, or b) you twiddle with stuff way more than is good
for you.
I tried booting from the install disk, which reminded me the reason
I had to use Basic mode for the installation: Basically in the default mode
the laptop would just sit there and never present anything than a
spinning cursor.
It is possible the disk was corrupted - but I was able to use the same
disk to boot in Basic mode. Furthermore, I was able to use the same
disk to boot in non-basic mode and install F18 in a VirtualBox VM
under Windows 7.
--
--Per Bothner
per(a)bothner.com http://per.bothner.com/
5:37 p.m.
On Fri, 2013-02-01 at 15:41 -0500, Adam Jackson wrote:
On Fri, 2013-02-01 at 10:44 -0800, Per Bothner wrote:
> Though it seems a bug to set the installed default mode line to
> nomodeset based on whether one boots up the live DVD in basic graphics
> mode. Better to install the settings appropriate for the hardware
> *plus* some kind of "safe mode" in the grub menu.
(To be clear: when I said "foolishly" in my other mail, I meant it in
the sense that we're fools for making that trap so easy to fall into.
Apologies if offense was taken; none was intended.)
Well, we don't normally set video parameters in the grub config at all.
The theory is that you'll only hit 'nomodeset' if you had to use it to
install, and in that case if we then defaulted to booting a KMS
configuration you'd probably be booting a configuration that you _know_
won't work, since it's the same kernel as you just used to run the
installer (if you're not enabling updates at install time).
So really, to me, this suggests that we should hide the 'nomodeset'
install option a little better. I suspect that showing it early in the
install process suggests to people that it's somehow more likely to
succeed and therefore desirable.
I don't see how we could show it any _later_ - it has to be before the
kernel is booted, obviously. Or do you just mean 'put it lower in the
list of options'? I don't know, though. I've been doing this for several
years now and I can count on one hand the number of cases where people
have picked 'basic graphics mode' without actually needing to, including
this one. I don't think it's really a problem. You already have to dig
down into an 'advanced' menu to find it.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
5:48 p.m.
On 2013-02-01 15:37 (GMT-0800) Adam Williamson composed:
On Fri, 2013-02-01 at 15:41 -0500, Adam Jackson wrote:
> So really, to me, this suggests that we should hide the
'nomodeset'
> install option a little better. I suspect that showing it early in the
> install process suggests to people that it's somehow more likely to
> succeed and therefore desirable.
I don't see how we could show it any _later_ - it has to be
before the
kernel is booted, obviously. Or do you just mean 'put it lower in the
list of options'?
Maybe what should happen is when basic graphics mode has been selected at
installation, an extra stanza should be added to grub.cfg, an additional one
containing nomodeset and labeled something like failsafe or nomodeset
fallback or video setup mode, and the default/first omitting it.
--
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata *** http://fm.no-ip.com/
5:52 p.m.
On Fri, 2013-02-01 at 18:48 -0500, Felix Miata wrote:
On 2013-02-01 15:37 (GMT-0800) Adam Williamson composed:
> On Fri, 2013-02-01 at 15:41 -0500, Adam Jackson wrote:
>> So really, to me, this suggests that we should hide the 'nomodeset'
>> install option a little better. I suspect that showing it early in the
>> install process suggests to people that it's somehow more likely to
>> succeed and therefore desirable.
> I don't see how we could show it any _later_ - it has to be before the
> kernel is booted, obviously. Or do you just mean 'put it lower in the
> list of options'?
Maybe what should happen is when basic graphics mode has been selected at
installation, an extra stanza should be added to grub.cfg, an additional one
containing nomodeset and labeled something like failsafe or nomodeset
fallback or video setup mode, and the default/first omitting it.
Sure, because we absolutely need to make our grub configuration *more*
complex and fragile!
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
1 p.m.
On Feb 1, 2013, at 4:48 PM, Felix Miata <mrmazda(a)earthlink.net> wrote:
Maybe what should happen is when basic graphics mode has been selected at installation,
an extra stanza should be added to grub.cfg, an additional one containing nomodeset and
labeled something like failsafe or nomodeset fallback or video setup mode, and the
default/first omitting it.
Isn't the context booting of install media? On BIOS computers this uses isolinux, not
GRUB. UEFI computers use GRUB2. I don't know how sophisticated the graphics mode
settings can be in isolinux without putting more modules on the media and a more
sophisticated isolinux.cfg.
Chris Murphy
1:46 p.m.
On 2013-02-02 12:00 (GMT-0700) Chris Murphy composed:
Felix Miata wrote:
> Maybe what should happen is when basic graphics mode has been
selected
> at installation, an extra stanza should be added to grub.cfg, an
> additional one containing nomodeset and labeled something like failsafe
> or nomodeset fallback or video setup mode, and the default/first
> omitting it.
Isn't the context booting of install media?
No. User has selected basic graphics mode for Anaconda to use. Anaconda could
follow up with the extra stanza in the bootloader config file it configures
for booting the installed system.
--
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata *** http://fm.no-ip.com/
3:01 p.m.
On Feb 2, 2013, at 12:46 PM, Felix Miata <mrmazda(a)earthlink.net> wrote:
No. User has selected basic graphics mode for Anaconda to
use.Anaconda could
follow up with the extra stanza in the bootloader config file it configures
for booting the installed system.
OK so you're saying when the user chooses, from the ISOLINUX based menu:
Troubleshooting > Install Fedora in basic graphics mode, that somehow anaconda knows
this was selected. As far as I know, the only preservation of this selection that anaconda
has access to is 'cat /proc/cmdline' to reveal 'nomodeset quiet' was
chosen. But in such case you want grub2-mkconfig to contain another entry (ala Recovery
Mode entries).
Anaconda doesn't create the grub.cfg, fyi. It directly calls grub2-mkconfig to create
it. So the feature you need would be anaconda getting and parsing /proc/cmdline/ and then
feeding an option to grub2-mkconfig, possibly via /etc/default/grub. So the feature
ultimately is both an anaconda and grub2 request.
(Honestly it would be helpful if the basic graphics mode selection deleted quiet. The
option is being chosen to deal with video related problems on boot, seeing as much
information as possible on screen the better.)
Chris Murphy
3:38 p.m.
On 2013-02-02 14:01 (GMT-0700) Chris Murphy composed:
On Feb 2, 2013, at 12:46 PM, Felix Miata wrote:
> No. User has selected basic graphics mode for Anaconda to
use.Anaconda
> could follow up with the extra stanza in the bootloader config file it
> configures for booting the installed system.
OK so you're saying when the user chooses, from the ISOLINUX
based menu:
Troubleshooting > Install Fedora in basic graphics mode, that somehow
anaconda knows this was selected. As far as I know, the only preservation
of this selection that anaconda has access to is 'cat /proc/cmdline' to
reveal 'nomodeset quiet' was chosen. But in such case you want
grub2-mkconfig to contain another entry (ala Recovery Mode entries).
Anaconda doesn't create the grub.cfg, fyi. It directly calls
grub2-mkconfig to create it. So the feature you need would be anaconda
getting and parsing /proc/cmdline/ and then feeding an option to
grub2-mkconfig, possibly via /etc/default/grub.
Something must be looking at /proc/cmdline already or the installed grub.cfg
wouldn't be including nomodeset in the default stanza.
So the feature ultimately
is both an anaconda and grub2 request.
Presumably mkconfig is using a default /etc/default/grub (<512 bytes). After
finding nomodeset in /proc/cmdline, Anaconda could specify mkconfig use an
alternate such file or perform some other magic to get the extra stanza
included, maybe an /etc/grub.d/49_nomodeset.
(Honestly it would be helpful if the basic graphics mode selection
deleted
quiet. The option is being chosen to deal with video related problems on
boot, seeing as much information as possible on screen the better.)
+1
Quiet is never in any of my Grub stanzas after firstboot.
--
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata *** http://fm.no-ip.com/
4:58 p.m.
On Sat, 2013-02-02 at 16:38 -0500, Felix Miata wrote:
On 2013-02-02 14:01 (GMT-0700) Chris Murphy composed:
> On Feb 2, 2013, at 12:46 PM, Felix Miata wrote:
>> No. User has selected basic graphics mode for Anaconda to use.Anaconda
>> could follow up with the extra stanza in the bootloader config file it
>> configures for booting the installed system.
> OK so you're saying when the user chooses, from the ISOLINUX based menu:
> Troubleshooting > Install Fedora in basic graphics mode, that somehow
> anaconda knows this was selected. As far as I know, the only preservation
> of this selection that anaconda has access to is 'cat /proc/cmdline' to
> reveal 'nomodeset quiet' was chosen. But in such case you want
> grub2-mkconfig to contain another entry (ala Recovery Mode entries).
> Anaconda doesn't create the grub.cfg, fyi. It directly calls
> grub2-mkconfig to create it. So the feature you need would be anaconda
> getting and parsing /proc/cmdline/ and then feeding an option to
> grub2-mkconfig, possibly via /etc/default/grub.
Something must be looking at /proc/cmdline already or the installed grub.cfg
wouldn't be including nomodeset in the default stanza.
> So the feature ultimately
> is both an anaconda and grub2 request.
Presumably mkconfig is using a default /etc/default/grub (<512 bytes). After
finding nomodeset in /proc/cmdline, Anaconda could specify mkconfig use an
alternate such file or perform some other magic to get the extra stanza
included, maybe an /etc/grub.d/49_nomodeset.
This still strikes me as all kinds of unnecessary. What problem are you
guys trying to solve here? Do you know of a horde of users that wants to
install in basic graphics mode but then use regular driver after
install? Cos I haven't met them.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
6:15 p.m.
On 2013-02-02 14:58 (GMT-0800) Adam Williamson composed:
On Sat, 2013-02-02 at 16:38 -0500, Felix Miata wrote:
> Presumably mkconfig is using a default /etc/default/grub (<512
bytes). After
> finding nomodeset in /proc/cmdline, Anaconda could specify mkconfig use an
> alternate such file or perform some other magic to get the extra stanza
> included, maybe an /etc/grub.d/49_nomodeset.
This still strikes me as all kinds of unnecessary. What problem are
you
guys trying to solve here? Do you know of a horde of users that wants to
install in basic graphics mode but then use regular driver after
install? Cos I haven't met them.
Are you sure?
date 1:
GM is released
Intel announces driver release for last quarter's new gfxchipset XYZ
6 weeks later:
GM plus updates include kernel that includes XYZ video driver
Another 6 weeks later:
Non-tester Joe User installs from GM DVD to his new latest greatest laptop
with XYZ chipset, which has no native Intel driver support on the DVD, and
thus requires basic graphics mode to get Anaconda's X going
What should Joe have to do to get native 2048x1152 instead of VESA 1280x1024
or worse?
--
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata *** http://fm.no-ip.com/
5:20 p.m.
On Feb 2, 2013, at 2:38 PM, Felix Miata <mrmazda(a)earthlink.net> wrote:
Something must be looking at /proc/cmdline already or the installed grub.cfg wouldn't
be including nomodeset in the default stanza.
?
OK forgive me for not paying attention if this has been said, but I'm not
understanding if this is a feature request or a behavior complaint. Does the grub.cfg in
question contain nomodeset? Or you want it to include nomodeset?
> So the feature ultimately
> is both an anaconda and grub2 request.
Presumably mkconfig is using a default /etc/default/grub (<512 bytes).
There is a minimal /etc/default/grub as part of the grub2 package. But anaconda (or maybe
lorax?) is writing more into that file during the installation, specifically the
GRUB_CMDLINE_LINUX= line. This modification is made before anaconda calls grub2-mkconfig.
After finding nomodeset in /proc/cmdline, Anaconda could specify
mkconfig use an alternate such file or perform some other magic to get the extra stanza
included, maybe an /etc/grub.d/49_nomodeset.
Requires anaconda be much more capable of creating grub2 grub.cfg entries than it
presently is; as it defers to grub2-mkconfig to do this sort of thing.
Chris Murphy
6:01 p.m.
On 2013-02-02 16:20 (GMT-0700) Chris Murphy composed:
Felix Miata wrote:
> Something must be looking at /proc/cmdline already or the
installed
> grub.cfg wouldn't be including nomodeset in the default stanza.
?
OK forgive me for not paying attention if this has been said, but
I'm not
understanding if this is a feature request or a behavior complaint. Does
the grub.cfg in question contain nomodeset? Or you want it to include
nomodeset?
My first response to thread, subsequent to time OP provided access to
Xorg.0.log.
http://lists.fedoraproject.org/pipermail/test/2013-February/113591.html
>> So the feature ultimately is both an anaconda and grub2
request.
> Presumably mkconfig is using a default /etc/default/grub (<512
bytes).
There is a minimal /etc/default/grub as part of the grub2 package.
But
anaconda (or maybe lorax?) is writing more into that file during the
installation, specifically the GRUB_CMDLINE_LINUX= line. This modification
is made before anaconda calls grub2-mkconfig.
Almost perfect. So if Anaconda sees itself putting nomodeset into
GRUB_CMDLINE_LINUX, nomodeset inclusion should be aborted, and a generic
/etc/grub.d/49_nomodeset be enabled that actually contains it. Or some
equivalent process that provides a conventional stanza plus at least one
nomodeset stanza. Just don't put nomodeset in every stanza unless lspci |
grep VGA finds a string that means KMS is incompatible with a required X
driver included in the release.
The way I understand GRUB_CMDLINE_LINUX_DEFAULT and GRUB_CMDLINE_LINUX dox,
the roles are reversed from what's needed. I can imagine several cmdline
parameters that should only be in one or the other and not both, one of which
is nomodeset.
> After finding nomodeset in /proc/cmdline, Anaconda could specify
> mkconfig use an alternate such file or perform some other magic to get
> the extra stanza included, maybe an /etc/grub.d/49_nomodeset.
Requires anaconda be much more capable of creating grub2 grub.cfg
entries
than it presently is; as it defers to grub2-mkconfig to do this sort of
thing.
I thought I was being clear enough. Anaconda must have already known cmdline
contained nomodeset or it it wouldn't have caused its inclusion in the
installed grub.cfg, however that was implemented within Anaconda.
--
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata *** http://fm.no-ip.com/
7:05 p.m.
On Feb 2, 2013, at 5:01 PM, Felix Miata <mrmazda(a)earthlink.net> wrote:
My first response to thread, subsequent to time OP provided access to Xorg.0.log.
http://lists.fedoraproject.org/pipermail/test/2013-February/113591.html
It's unclear that nomodeset is coming from grub.cfg, rather than user edited entry in
grub shell, or even if it does come from grub.cfg that it's also in
/etc/default/grub. We need to see that file. And even then I'd sooner believe that
file was user modified.
Almost perfect. So if Anaconda sees itself putting nomodeset into
GRUB_CMDLINE_LINUX, nomodeset inclusion should be aborted, and a generic
/etc/grub.d/49_nomodeset be enabled that actually contains it. Or some equivalent process
that provides a conventional stanza plus at least one nomodeset stanza. Just don't put
nomodeset in every stanza unless lspci | grep VGA finds a string that means KMS is
incompatible with a required X driver included in the release.
And I think anaconda producing an /etc/grub.d/49_nomodeset entry is not so straightforward
for a distro because it's unclear (to me) that the GRUB syntax is now stable. To have
to update this file as GRUB is updated obviates the whole point of grub2-mkconfig. Better
to base a new "Nomodeset" creation feature in grub-mkconfig along the lines of
Recovery entries, which merely add single to the end of the kernel parameter line,
currently suppressed with:
GRUB_DISABLE_RECOVERY="true"
So the feature you're suggesting is perhaps, by default:
GRUB_ENABLE_NOMODESET="false"
And for anaconda to be able to flip that value to true if it detects cat /proc/cmdline
contains nomodeset. Then when grub2-mkconfig is called, one nomodeset entry is created per
kernel or something… but anyway, even this is not a trivial amount of code. It's a
feature.
I thought I was being clear enough. Anaconda must have already known
cmdline contained nomodeset or it it wouldn't have caused its inclusion in the
installed grub.cfg, however that was implemented within Anaconda.
I've read nothing that conclusively demonstrates anaconda presently behaves this way
now.
Chris Murphy
7:17 p.m.
On Sat, 2013-02-02 at 18:05 -0700, Chris Murphy wrote:
> I thought I was being clear enough. Anaconda must have already
known
cmdline contained nomodeset or it it wouldn't have caused its
inclusion in the installed grub.cfg, however that was implemented
within Anaconda.
I've read nothing that conclusively demonstrates anaconda presently
behaves this way now.
C'mon, it's not THAT hard.
[adamw@adam anaconda (master %)]$ grep -R nomodeset *
anaconda.spec.in:- I don't need to pass "nomodeset" to stage2 after all.
(clumens)
anaconda.spec.in:- Make sure "nomodeset" and "xdriver=" get passed on
to stage2 (#623129).
pyanaconda/bootloader.py: "nompath",
"nomodeset", "noiswmd", "fips",
oh hey, pyanaconda/bootloader.py, huh?
*open pyanaconda/bootloader.py*
*search for nomodeset*
# this is so stupid...
global_preserve_args = ["speakup_synth", "apic",
"noapic", "apm", "ide",
"noht", "acpi", "video",
"pci", "nodmraid",
"nompath", "nomodeset",
"noiswmd", "fips",
"selinux"]
oh hey, 'global_preserve_args', well that looks nice and easy to search
for. So, let's search for it!
#
# preservation of some of our boot args
# FIXME: this is stupid.
#
for opt in self.global_preserve_args + self.preserve_args:
if opt not in flags.cmdline:
continue
arg = flags.cmdline.get(opt)
new_arg = opt
if arg:
new_arg += "=%s" % arg
self.boot_args.add(new_arg)
and then we search for boot_args, and after a few other places it gets
set, we see:
log.info("bootloader.py: used boot args: %s " % self.boot_args)
defaults.write("GRUB_CMDLINE_LINUX=\"%s\"\n" %
self.boot_args)
defaults.write("GRUB_DISABLE_RECOVERY=\"true\"\n")
defaults.write("GRUB_THEME=\"/boot/grub2/themes/system/theme.txt\"\n")
defaults.close()
and there you go. and that took me all of two minutes. it ain't rocket
science, guys!
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
7:39 p.m.
On Feb 2, 2013, at 6:17 PM, Adam Williamson <awilliam(a)redhat.com> wrote:
On Sat, 2013-02-02 at 18:05 -0700, Chris Murphy wrote:
and there you go. and that took me all of two minutes. it ain't rocket
science, guys!
Ok it's like learning to ski and then get on a snowboard. OK, no it's like
learning to snowboard and then take up telemark. Or brick laying. I'm simply
unaccustomed to considering searching source, because well, Apple doesn't do that.
I'm used to poking things with sticks.
So the feature being asked for means changing anaconda to not pass through nomodeset to
/etc/default/grub GRUB_CMDLINE_LINUX=, but rather write out a trigger in /etc/default/grub
for a whole new function in grub2-mkconfig that doesn't yet exist, to create advanced
submenu options that contain nomodeset. *shrug* Maybe patches would be accepted, I'd
post on grub-devel@ before doing the work though.
Chris Murphy
7:56 p.m.
On Sat, 2013-02-02 at 18:39 -0700, Chris Murphy wrote:
On Feb 2, 2013, at 6:17 PM, Adam Williamson
<awilliam(a)redhat.com> wrote:
> On Sat, 2013-02-02 at 18:05 -0700, Chris Murphy wrote:
>
> and there you go. and that took me all of two minutes. it ain't
rocket
> science, guys!
Ok it's like learning to ski and then get on a snowboard. OK, no it's
like learning to snowboard and then take up telemark. Or brick laying.
I'm simply unaccustomed to considering searching source, because well,
Apple doesn't do that. I'm used to poking things with sticks.
Well, thing is, if you find yourself in a conversation which is strongly
predicated on what some code does, you should develop the reflex of
*just going and looking at the code*. As long as you're in Fedoraland,
anyway. Especially if we're talking about anaconda, since it's written
in Python, which is an outstandingly readable language. You don't need
to know zip about coding to read the anaconda source, though it helps to
have an understanding of approximately how anaconda works and what
you're looking for, which I'm sure you do. If the code's written in
perl, think twice and take tylenol with you. :)
So the feature being asked for means changing anaconda to not pass
through nomodeset to /etc/default/grub GRUB_CMDLINE_LINUX=, but rather
write out a trigger in /etc/default/grub for a whole new function in
grub2-mkconfig that doesn't yet exist, to create advanced submenu
options that contain nomodeset. *shrug* Maybe patches would be
accepted, I'd post on grub-devel@ before doing the work though.
I think this is definitely patches-accepted territory. I can imagine
pjones' face if he ever reads this thread. It's a fun mind picture, but
it is not which suggests that he would be highly motivated to go and
write the patches.
Hell, to be honest, this is an area where even if you submit a patch, it
might not get taken. This code already has a bunch of #this is ugly
comments on it (I cut out several). So...make it a *good* patch. :)
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
12:10 a.m.
On Feb 2, 2013, at 6:56 PM, Adam Williamson <awilliam(a)redhat.com> wrote:
Well, thing is, if you find yourself in a conversation which is
strongly
predicated on what some code does, you should develop the reflex of
*just going and looking at the code*.
Obviously. Maybe there's the equivalent of RTFM here? STFU and STFSB. That'd
probably agitate my reflexes.
Hell, to be honest, this is an area where even if you submit a patch, it
might not get taken.
That's why I suggested grub-devel@ first before putting in the effort. I see patches
posted there all the time that get charitable *yawn* as responses.
Chris Murphy
12:52 a.m.
On 2013-02-02 23:10 (GMT-0700) Chris Murphy composed:
Adam Williamson wrote:
> Hell, to be honest, this is an area where even if you submit a
patch,
> it might not get taken.
That's why I suggested grub-devel@ first before putting in the
effort. I
see patches posted there all the time that get charitable *yawn* as
responses.
IIRC, Fedora is the only distro I've installed since the first appearance of
KMS in which the bootloader menu didn't have at least two entries, the latter
of which including nomodeset on kernel line in addition to whatever else
constitutes "failsafe" mode. My guess is it's the easiest approach to
avoiding the OP's problem. I suspect implementation isn't really an upstream
issue. nor do I have a clue whether upstream has or would consider a feature
to facilitate implementation.
--
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata *** http://fm.no-ip.com/
4:16 p.m.
On Fri, 2013-02-01 at 10:44 -0800, Per Bothner wrote:
On 02/01/2013 09:11 AM, Adam Williamson wrote:
> If you have 'nomodeset' on the cmdline, you must have either set it
> yourself, or installed Fedora in 'Basic Graphics Mode', which causes
> this to happen.
The latter might have happened - I had various problems first copying
my SSD to a new larger one, unexpectedly trashing grub when doing some
partition re-arranging, and having to install F15 (! - the most recent
CD I could find in a hurry) so I could boot and then download and
burn F18.
Though it seems a bug to set the installed default mode line to
nomodeset based on whether one boots up the live DVD in basic graphics
mode. Better to install the settings appropriate for the hardware
*plus* some kind of "safe mode" in the grub menu.
I'm not sure I agree. The logic is that if the installer failed to work
in 'normal' graphics mode, it is very unlikely that the installed system
will either, as the two use the same graphics stack and in fact our
default desktop requires *more* functionality than the installer. It's
very unlikely that you'd need to use Basic Graphics Mode to make the
install run, but be able to use the installed system with your native
driver just fine.
Really the case where you use the option by mistake is about the only
one where it's not sensible behaviour.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
4107
days inactive
4110
days old
35 comments
6 participants
participants (6)
-
Adam Jackson -
Adam Williamson -
Chris Adams -
Chris Murphy -
Felix Miata -
Per Bothner