Any more ideas to improve font appearance?

[kubicle]

Does booting with "video=radeon:modeset=1" make a difference?

Also the output of "dmesg | grep radeon" might give some clues (although it's unfortunate if you can't get to a text tty when the boot fails)

IIRC, the radeon driver requires modesetting these days (so it wouldn't be surprising you have problems like wrong resolution if you use "nomodeset" or "radeon.modeset=0").

[quiddity]

Does booting with "video=radeon:modeset=1" make a difference?

Thanks for your reply.... No, I'm afraid it doesn't. Same stripy coloured screen.

Also the output of "dmesg | grep radeon" might give some clues (although it's unfortunate if you can't get to a text tty when the boot fails)

Well, here's the output that I can get when booted with nomodeset:

[ 1.491678] [drm] VGACON disable radeon kernel modesetting.
[ 1.491682] [drm] radeon userspace modesetting enabled.
[ 1.492318] [drm] Initialized radeon 1.34.0 20080528 for 0000:01:05.0 on minor 0

IIRC, the radeon driver requires modesetting these days (so it wouldn't be surprising you have problems like wrong resolution if you use "nomodeset" or "radeon.modeset=0").

OK, that makes some kind of sense of the phenomenon... So basically to get the right resolution I need to somehow enable modesetting, but to actually boot with a working display at all it seems I need to use nomodesetting! Man. What a pain.

[oshunluvr]

Just found this site: http://www.randarlabs.com/

Supposedly, they have an upgrade to the kernel to 3.13 kernel that fixes the Radeon KMS issue, however I read one report that the supplied 3.13 kernel breaks networking. The post was from March 18, so maybe it's fixed by now.

EDIT: reading a bit more, that site supplies a script that will upgrade you to 3.15.5 from Ubuntu. Might be worth a try...

[quiddity]

Just found this site: http://www.randarlabs.com/

Supposedly, they have an upgrade to the kernel to 3.13 kernel that fixes the Radeon KMS issue, however I read one report that the supplied 3.13 kernel breaks networking. The post was from March 18, so maybe it's fixed by now.

EDIT: reading a bit more, that site supplies a script that will upgrade you to 3.15.5 from Ubuntu. Might be worth a try...

Well, I'm game -- I'll give it a go. If you don't hear from me for a while, I've borked it all and am reinstalling!

[quiddity]

Well, I'm game -- I'll give it a go. If you don't hear from me for a while, I've borked it all and am reinstalling!

OK -- I updated the kernel to 3.14.4, which seemed to be the latest stable. That hasn't made any difference. Booting with nomodeset deleted or with it replaced by radeon.modeset=1 both worked perfectly once -- right resolutions and everything -- but on a second and subsequent boots I got the coloured line screen.

So I guess I could update to 3.15.n now, and see if that works, or wait for it to be stable and try then. I might give it a go over the weekend. I'll report back if I do.

Thanks again.

[quiddity]

So I guess I could update to 3.15.n now, and see if that works, or wait for it to be stable and try then. I might give it a go over the weekend. I'll report back if I do.

I got impatient and tried 3.15.0.rc5 -- freshest I could find. On the one hand, repeatedly booting without nomodeset seems to work -- right resolution, no coloured lines. On the other hand, as you suggested before, it breaks networking/wireless. So... I guess I hang for the next release(s) of 3.15.n and hope it all works out soon. I mean, basically, the problem(s) are clearly being worked on, and I just need to be patient and wait.

Once I get a kernel that does everything -- resolution, networking, etc -- I'll report back and mark the thread solved.

Thanks again for the help.

[SteveRiley]

Wow, lots of nice interaction here. Good to see.

I've been using various iterations of the 3.14 and 3.15 kernels and haven't seen any network breakage. Ethernet, wireless, and OpenVPN (on both) are working fine. My wired interface is an Intel 82579LM Ethernet controller; my wireless interface is an Intel N-6300.

Now about graphics mode setting... Long ago, the kernel would only boot into a text console. Then X would switch the video hardware into graphics mode. This would cause flickers and other un-pretty things ("pretty" being very much in the eye of the beholder). Current-day (as in post 2011) kernels now take care of graphics video modesetting during boot. You get a nice flicker-free start up, some attractive splash screens, and your desktop.

nomodeset is a kernel parameter that instructs the kernel to behave in the old-fashioned way. That is, the kernel will not perform any graphics mode setting at all; instead, this needs to be done in user space. At one time, the traditional method for performing user (space) mode setting was to let the X graphics drivers do it, as specified in the xorg.conf file. But this is no longer the case. Many X graphics drivers no longer support user mode setting. Intel dropped it a couple years ago; the open source drivers for nVidia (Nouveau) and AMD (Radeon) have also stopped supporting user mode setting. These drivers require kernel mode setting, which is the opposite of nomodeset. Without kernel mode setting, X on this video hardware will fall back to the basic VESA driver. The Xorg log file attached in post #13 shows that's what happened. Post #22 confirms that your computer has been booting with nomodeset. When you removed it, kernel mode setting operated as expected, the correct kernel module for your hardware was loaded, and X correctly picked the proper driver for your graphics hardware. (Kubicle mentions this in post #31, too.)

Wait, there's more. The presence of GRUB really adds some screwiness here. It stems from the perception that "smooth, flicker free graphical boot" is somehow a thing that matters. You can see where my cynicism is leading. You should think of GRUB as a miniature operating system all on its own. Your computer does not boot the Linux kernel. It boots GRUB. GRUB gives you a menu of the things it knows about and can boot for you. GRUB is quite earnest about maintaining that "smooth, flicker free graphical boot" experience. So it needs to switch the hardware into graphics mode very early during the boot process, and it relies a completely different way of detecting hardware than do either the kernel or X. How's that for consistency?

Let's consider the symptoms you've revealed. You achieve a successful graphics configuration in X by hand-removing nomodeset when it is included in the kernel options in GRUB's boot stanza. If you edit this stanza, remove the parameter, and reconfigure GRUB, then GRUB itself is unable to boot. GRUB also will not boot if you hand-add the parameter. It's been a while since I've used GRUB, but I wonder if the update-grub routine (which just calls grub-mkconfig) is altering the way it sets up GRUB's method of configuring graphics based on the presence or absence of nomodeset. I'm not sure, really. You could also be seeing some weird left-over graphics mode setting that persists between soft reboots.

I'd like you to try something. Edit /etc/default/grub and remove nomodeset in the quotes after GRUB_CMDLINE_LINUX_DEFAULT (and GRUB_CMDLINE_LINUX if it's there, too). Make sure that quiet splash are not in either one also. Next, remove the # in front of the line containing GRUB_TERMINAL=console. Save the file and then run update-grub. Now power down the machine. Unplug the power cord from the wall socket and wait one minute. Plug the cord back in. Boot the computer. GRUB should load in text mode, not graphical mode. Can you proceed to boot normally, and get the crisp display?

[quiddity]

Thanks very much for the reply, and the detailed explanation. I've been doing a bit of reading on this, to see if I could work it out myself (I can't!). This helps.

So... To take your post out of order...

I'd like you to try something. Edit /etc/default/grub and remove nomodeset in the quotes after GRUB_CMDLINE_LINUX_DEFAULT (and GRUB_CMDLINE_LINUX if it's there, too). Make sure that quiet splash are not in either one also. Next, remove the # in front of the line containing GRUB_TERMINAL=console. Save the file and then run update-grub. Now power down the machine. Unplug the power cord from the wall socket and wait one minute. Plug the cord back in. Boot the computer. GRUB should load in text mode, not graphical mode. Can you proceed to boot normally, and get the crisp display?

No. In fact, I can't do anything. When I boot, the first thing after the BIOS screen is a message that's something like `error: no video mode loaded'; a bunch of text commands run quite fast; and then I'm left with a black screen from which nothing can be done (no bootlog, no tty, so I'm thinking no graphics at all have been enabled). It does seem that things are happening in the background, since the wireless light comes on.

Let's consider the symptoms you've revealed. You achieve a successful graphics configuration in X by hand-removing nomodeset when it is included in the kernel options in GRUB's boot stanza. If you edit this stanza, remove the parameter, and reconfigure GRUB, then GRUB itself is unable to boot. GRUB also will not boot if you hand-add the parameter. It's been a while since I've used GRUB, but I wonder if the update-grub routine (which just calls grub-mkconfig) is altering the way it sets up GRUB's method of configuring graphics based on the presence or absence of nomodeset. I'm not sure, really. You could also be seeing some weird left-over graphics mode setting that persists between soft reboots.

I've obviously not been quite clear (it's been a long thread!). Here's the symptoms: if nomodeset is included, then I get the wrong resolution, whether it's included by reconfiguring GRUB by by hand-adding at boot. However, nomodeset guarantees that I will get graphics. If I boot without nomodeset (either deleted, or replaced by video.radeon=1 or any of the other options suggested), then very, very occasionally I will get graphics with the correct resolution, but much more often, that stripey screen. This is again the same whether GRUB is reconfigured or edited on the fly.

I've not experimented more with kernel 3.15 yet, but it does seem that that might fix the issue.

I think your diagnosis might be right, though, if not the solution -- there's something about GRUB. I took quiet splash out early in this process, so I could see what was going on. On the `successful' boots (graphics in correct resolution), the resolution switches after GRUB has run some commands/processes. On the ones that go to stripey screens, they do so at the point where the resolution is `meant' to switch.

I've been using various iterations of the 3.14 and 3.15 kernels and haven't seen any network breakage. Ethernet, wireless, and OpenVPN (on both) are working fine. My wired interface is an Intel 82579LM Ethernet controller; my wireless interface is an Intel N-6300.

3.14 is fine. 3.15, when I tried it, broke wireless -- I don't have access to ethernet at the moment. When I say `broke' -- the card was apparently working ok, but network manager would make rapid, repeated, failed attempts to connect to a network and never actually manage it. So it's de facto broken. I don't seem to be the only person reporting this, so perhaps it'll get fixed soon.

As it happens: in a new development (I assume an unrelated one), the LCD screen backlight on the laptop in question has started to fail, and I'm not going to be able to replace it till next week at the earliest. This means the computer is borderline unuseable for now (you have no idea how much I've had to squint into a dim screen to type this!), so I won't be doing any more on this software/video issue till I've fixed the hardware. Once I've done so next week, I'll try updating my kernel to the latest 3.15, see what happens, and report back.

Thanks again!

[SteveRiley]

Well, if you end up having to buy a new laptop, go for a ThinkPad (avoid the other Lenovo laptop lines). ThinkPads run Linux admirably well. Have had zero long-term issues with my T520 and my X1.

[quiddity]

Well, if you end up having to buy a new laptop, go for a ThinkPad (avoid the other Lenovo laptop lines). ThinkPads run Linux admirably well. Have had zero long-term issues with my T520 and my X1.

Thanks, that's useful advice. My first thought is just to replace the screen, but I'll look into how cheaply I can get one of those.

[quiddity]

Solved, though not in a way that's going to be very useful to others.

As mentioned above, the screen needed replacing. The replacement I got hold of was almost the same as the one being replaced -- same manufacturer, same model -- but v2 rather than v4. I also re-installed 14.04 again, just to clean things up having messed around with the kernels. And now the resolution is perfect, and I have all the choices of resolution available to me.

Since it was exactly that OS that caused the problem in the first place, I have to think that the change of screen to a very similar but slightly different part was the solution. So: if you have this problem, you might be able to solve it by spending 70 quid on a new screen.

[SteveRiley]

Wow. I don't think I would have ever actually thought to suggest that. I'm glad you got everything working now.

[birdux]

Would you guys, please, post here some printscreens with the fonts ( web, OS ) from your Kubuntu OS ?
Thank you