LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Debian (https://www.linuxquestions.org/questions/debian-26/)
-   -   Maddening Display Issue - Stretch on Thinkpad (https://www.linuxquestions.org/questions/debian-26/maddening-display-issue-stretch-on-thinkpad-4175610264/)

gIn_gOut 07-20-2017 09:57 AM

Maddening Display Issue - Stretch on Thinkpad
 
Greetings.

Simply put, off-the-rack Debian 9 can't render a display properly on the Thinkpad Edge 15. 1024x768 will certainly not do on a 1366x768 display.

So, I loaded the Stretch "nonfree" drivers. Reboot. No dice.

Dumped all of that and dropped a complete set of drivers from a known-compatible Ubuntu variant into /lib/firmware/ Reboot. Still no good.

Proprietary wifi verified OK with both firmware sets.

If nothing else, I thought all of this was handled directly via the bin-blob placements on /lib/firmware/ -- What gives?

TIA


Edit/footnote:
Same crap with Jessie.
Why does Ubuntu have no problem with this box going all the way back to Precise???
(ugh)

Edit 2:
Looks like an absolutely ancient AMD/Radeon Linux video driver screwup which was fixed most places 5+ years ago.

The fact that this is still a problem in Debian is a huge showstopper in my corner.

Any ideas as to how one can turn the key in this without tearing everything apart first is gratefully appreciated...

Thanks again --

IsaacKuo 07-20-2017 02:30 PM

What is the output of "lspci"? This should give info on what graphics chip is used.

It sounds really weird and not likely to work to copy files from Ubuntu to Debian in firmware.

Anyway, how did you install the Stretch "nonfree" drivers? My usual thing is:

1) Edit /etc/apt/sources.list to add " contrib non-free" to each line.

2) Run the following:

Code:

apt-get update
apt-get dist-upgrade
apt-get install firmware-linux-nonfree

But this only installs firmware for AMD/ATI graphics chips along with a whole bunch of other things with small firmware files. Other non-free firmware with big firmware blobs have their own packages. For example, my various laptops have different wifi cards, which I install support for with:

Code:

apt-get install zd1211-firmware
apt-get install firmware-iwlwifi
apt-get install firmware-brcm80211

https://packages.debian.org/stretch/...phics/filelist
https://packages.debian.org/stretch/...nfree/filelist

Note that if your graphics chip is an NVIDIA chip that requires their proprietary driver, installation involves a kernel module and is definitely not as simple as copying over something into /lib/firmware. Fortunately, the open source nouveau driver works pretty well for most older NVIDIA chips, which reduces my need to avoid NVIDIA to avoid dealing with its headaches. But this may be an issue for you. Ubuntu went out of their way to automate the process of installing the proprietary NVIDIA drivers, but Debian has a different philosophy about closed source proprietary blobs.

gIn_gOut 07-20-2017 08:01 PM

Thank you so much for dropping by, IsaacKuo.

lspci:

Quote:

VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] RS880M [Mobility Radeon HD 4225/4250]
...which is why I was discouraged.

Looks like a similar issue which drove me to put Ubuntu on this system back in 2012 in place of XP.

Did the original driver install from the non-free debs/zipfile at http://cdimage.debian.org/cdimage/un...retch/current/ Looking at the respective DEBIAN folders, it wasn't much more than an automated /lib/firmware/ dump for the most part.

firmware-linux-nonfree was one of those packages that got installed with the mess.

So, after the previous hyjinks and a bit of bumping about, got as far as this:

https://packages.debian.org/jessie/fglrx-driver

...which seemed to indicate there was nothing for the chipset in question; and could find nothing native to Stretch.

(sigh)

I'll be back in the 'morrow to check in again!

Cheers --

IsaacKuo 07-20-2017 09:14 PM

I've never used that cd image method of doing such an install...do you not have an internet connection working on this laptop? The preferred method of installing software is via the internet using apt-get. That way, you will get the latest versions, with all the latest security updates (and other updates), and apt also handles any dependency issues.

But in any case, I imagine what's on that cd is more or less the same as what you'd get using apt-get.

My own experience with AMD/ATI Radeon is that the apt-get install firmware-linux-nonfree works well and I've never bothered with the fglrx-driver. However, if this doesn't support your RS880M (Mobility Radeon HD 4225/4250), then obviously that's not a working solution. If it were me, I'd just swallow my Debian pride and install Ubuntu (my own preference is XFCE4 desktop, so in practical usage it's not too different).

AwesomeMachine 07-21-2017 12:35 AM

You could use xrandr to set the correct resolution.
Code:

$ cvt 1280 1024 60
will give you the modeline
Code:

$ sudo xrandr --newmode "1280x1024_60"  109.00  1280 1368 1496 1712  1024 1027 1034 1063 -hsync +vsync
$ sudo xrandr --addmode VGA-1 1280x1024_60
$ sudo xrandr --output VGA-1 --mode 1280x1024_60

will set the resolution. But use the values you want for your display

gIn_gOut 07-21-2017 10:49 AM

@IsaacKuo:

Thank you for coming back and contributing to the thread. I like to suss through what I download when working out a base distro for plural installs; hence the zipfile download/scripted dpkg -i in place of apt-get.

Had a wild hair and decided to dig out a parallel non-free Jessie ISO from the downloaded mess and did a quick wipe/copy onto a thumbdrive. All loaded fast and the screen issue was gone.

So, official deb + non-free drivers != complete unofficial ISO. I smell kernel blobs in the woodwork. Which leads me to...

@AwesomeMachine:

What you present would be a more livable solution than being forced into another term of Ubuntu, or even into the "unofficial" spin of deb. Like the vetting which the official devel team uses; and, though unlikely, the official distro has a lot to lose in the event of a malicious code-poisoning scenario.

Off to try your suggestion...

One more thing in the meantime, could someone point to a resource which would give a breakout of the differences between the official & unofficial releases? Interested to know just what we're looking at here ;o)

Thanks again --

gIn_gOut 07-21-2017 12:59 PM

@AwesomeMachine:
Code:

user@debian:~$ cvt 1280 1024 60
# 1280x1024 59.89 Hz (CVT 1.31M4) hsync: 63.67 kHz; pclk: 109.00 MHz
Modeline "1280x1024_60.00"  109.00  1280 1368 1496 1712  1024 1027 1034 1063 -hsync +vsync
user@debian:~$ sudo xrandr --newmode "1280x1024_60.00"  109.00  1280 1368 1496 1712  1024 1027 1034 1063 -hsync +vsync
xrandr: Failed to get size of gamma for output default
user@debian:~$ sudo xrandr --addmode default 1280x1024_60.00
xrandr: Failed to get size of gamma for output default
user@debian:~$ sudo xrandr --output default --mode 1280x1024_60.00
xrandr: Failed to get size of gamma for output default
xrandr: Configure crtc 0 failed
user@debian:~$

Fail?

jim_p 07-22-2017 12:14 AM

To put things in order...

- Your card is supported by fglrx legacy, because ati, back in 2013 or so, decided to drop 2xxx, 3xxx and 4xxx cards to that driver version. Fglrx legacy supports xorg up to 1.12 and kernel up to 3.4, which means it has no reason to even exist in today's linux... ecosystem :P

- The plain fglrx is for 5xxx and newer cards, it supports xorg up to 1.17 and kernel up to 3.19. Installing this one for your card and expecting it to work is like installing nvidia's one and expecting it to work too. It just won't work because it does not support your card.

- So you are left with the opensource driver for ati's cards, radeon, which comes preinstalled because it is part of xorg. This one, in order to work properly, requires the relevant firmware for your card to be installed as well, which is either in firmware-linux-nonfree or in firmware-amd-graphics. So you just install these and you are done. And do not waste your time with ancient versions of packages or distros in order to get fglrx to work, its not worth it.

gIn_gOut 07-25-2017 11:11 AM

Thank you, jim_p, for that information. However, in the end, it didn't pan out as should be expected...

FWIW, our beloved video card is not included in the supported lineup for firmware-amd-graphics.

OTOH, I affirm the RS880 chipset is explicitly called out in the description for the xserver-xorg-video-radeon package which has been installed all along in this "Official" ISO distro.

So, I thought perhaps we have an early userspace problem. Decided to try something:

Dug in and replaced /live/initrd.img-4.9.0-3-686 in an otherwise as-distributed "Official" i386 ISO with its "+nonfree" version's counterpart.

Having done this, the "Official" ISO now has no problem whatsoever with the video card in question; without any separate non-free firmware blobs/debs of any kind. A strange boot hitch on an ancient Dell test system cleared up as well.

Of note, the "+nonfree" initrd.img-4.9.0-3-686 has many Mb of additional firmware blobs which didn't get the axe during the Kernel Team's "Official" cleanout. This might explain why most other modern distros out there will run out of the box without issue on the ThinkPad Edge 15.

Again, the only diff which flushed the issue from an otherwise stock "Official" ISO: initrd.img-4.9.0-3-686 No packages listed as broken upon live boot.

So, starting with this initrd variant in a new install context, how might one ensure any subsequent system updates follow along with this particular early userspace, and don't slip in an "Official" version with the inevitable loss of functionality?

Thanks again --

IsaacKuo 07-25-2017 11:34 AM

Quote:

Originally Posted by gIn_gOut (Post 5739670)
Thank you, jim_p, for that information. However, in the end, it didn't pan out as should be expected...

FWIW, our beloved video card is not included in the supported lineup for firmware-amd-graphics.

OTOH, I affirm the RS880 chipset is explicitly called out in the description for the xserver-xorg-video-radeon package which has been installed all along in this "Official" ISO distro.

So, I thought perhaps we have an early userspace problem. Decided to try something:

Dug in and replaced /live/initrd.img-4.9.0-3-686 in an otherwise as-distributed "Official" i386 ISO with its "+nonfree" version's counterpart.

Having done this, the "Official" ISO now has no problem whatsoever with the video card in question; without any separate non-free firmware blobs/debs of any kind. A strange boot hitch on an ancient Dell test system cleared up as well.

Of note, the "+nonfree" initrd.img-4.9.0-3-686 has many Mb of additional firmware blobs which didn't get the axe during the Kernel Team's "Official" cleanout. This might explain why most other modern distros out there will run out of the box without issue on the ThinkPad Edge 15.

Again, the only diff which flushed the issue from an otherwise stock "Official" ISO: initrd.img-4.9.0-3-686 No packages listed as broken upon live boot.

So, starting with this initrd variant in a new install context, how might one ensure any subsequent system updates follow along with this particular early userspace, and don't slip in an "Official" version with the inevitable loss of functionality?

Thanks again --

I would do the following commands (as root, of course):

Code:

cd /boot
cp -vax initrd.img-4.9.0-3-686 initrd.img-mycustom
cp -vax vmlinuz-4.9.0-3-686 vmlinuz-mycustom
update-grub

This should detect the "mycustom" boot entries and I think it will also give them highest priority. If there are any kernel/initrd updates, this "mycustom" pair will remain. You can manually choose between "mycustom" and the normal entries by selecting "advanced options" in Grub.

I believe that you will be okay without making this pair of files for a custom boot option. But this will give you the option to stick with the current working initrd just in case.

Anyways, I have my own machine which has issues with the default 4.9.0-3 initrd/kernel, so maybe your solution will work for me also. Currently, I have it booting up using a 3.16.0-4 pair (built on a machine still running Debian 8). So, thanks for figuring that out - it might help me with one of my machines also!

gIn_gOut 07-25-2017 11:51 AM

@IsaacKuo:

Glad this might've helped at your end. And, having a backup copy of the 'turd on-hand is of potential use at mine ;)

However, I'd like to "goose" things a bit more and allow nonfree automatic updates to take place with respect to this one particular piece only.

So, what would one do to ensure initrd gets the "+nonfree" updates while allowing the rest of the system to continue along its merry "Official" way?

Cheers --

gIn_gOut 07-27-2017 01:27 PM

Well, there doesn't seem to be any queer "mystery meat" in the "+nonfree" initrd.img after all...

Following some additional rummagework, I seem to have isolated the root issue: There is no postinst file in firmware-amd-graphics to call update-initramfs -u after dpkg dumps out the archive's firmware folders onto /lib/firmware/. This effectively keeps the provided firmware out of early userspace after "installing" on the target. Adding further confusion, the RS880 series is not listed among the supported chipsets for this package; so there seemed to be no point beating a dead horse after things didn't tick over post-reboot.

Indeed, when the +nonfree initrd.img-4.9.0-3-686 archive is dug open, /lib/firmware/radeon/ is actually there; with a selection of blobs which are hash-matched to their counterparts on /lib/firmware/radeon/ in the original .deb archive. I'm going to try a couple of other things to be sure, but it does indeed seem as though the packagers boofed the deb on this particular set; with all the attendant confusion when early userspace support is needed (and not provided) for these blobs. Preliminary tests point strongly toward firmware-amd-graphics actually being the key; with update-initramfs -u followed by a reboot to simply wrap things up.

Back again with more for the record --

IsaacKuo 07-27-2017 01:58 PM

Interesting. I'll keep that tip in mind and see if it helps with my problem system (the previous thing wouldn't have worked anyway since I'm using a weirdly customized initrd for my RAMBOOT experiments).

gIn_gOut 07-28-2017 12:17 PM

Summary for the record:
  • Despite documentation issues, all necessary firmware blobs for a baseline, "Official" release of Stretch are provided in firmware-amd-graphics to resolve the Edge 15 Radeon chipset issue.
  • The original deb for this firmware set does not include the necessary postinst file which is needed to call update-initramfs -u to copy the required early userspace subset over to initrd.img for boot-time loading; and must be called manually after installation of the package.
  • A reboot is required to bring the system back up again with the necessary firmware loaded at early userspace.
Problem solved.

Slightly off-topic, here's what else I found while running through all of this:

After expansion and automated comparison of both debian-live-9.1.0-i386-xfce.iso and debian-live-9.1.0-i386-xfce+nonfree.iso (encompassing approximately 130,000 common files), somewhere in the neighborhood of 130 total hashes failed to mesh. This, again, looked at the file sets which both distros share in common; with the objective of finding what config file(s), if any, may be present to distinguish the "Official" and "+nonfree" releases.

After a little basic sifting, there wasn't much to differentiate the two; essentially pointing at a single common release. The Stretch "+nonfree" variant seems to literally be an "Official" release with a pile of unofficial kitsch just tacked on; bearing no operatively distinguishing features which would affect update processing apart from the additional items registered directly with package management itself.

Also, and while I'm not a "turdologist" by any means, it seems update-initramfs -u, after a common (dumped) firmware "installation", does nothing more than synchronize /lib/firmware/ on the target with its compressed counterpart located within /boot/initrd.img; depositing a culled subset of blobs onto that dir.

Further experimenting/characterization has shown that a complete firmware folder copy from target to the parallel foldering within /boot/initrd.img does not hinder operation of the subsequently-loaded distro, apart from increased bootup time and initial memory footprint. Any subsequent call to update-initramfs -u after boot will cause initrd to be culled of all "unnecessary" blobs; thereby reducing the bootup footprint to typical levels.

Finally and accordingly, a usable and installable "Official" live 9.1 ISO release with any necessary firmware blobs in early userspace might be formed by a simple bench modification of both /live/initrd.img-4.9.0-3-686 and /boot/initrd.img-4.9.0-3-686*, along with an update of the single relevant SHA-1 hash for both located in /var/lib/initramfs-tools/4.9.0-3-686*.

In sum: 3 tweaks, and cleanly done. No need to throw in the kitchen sink (and everything else) that comes along with the "unofficial" release ;o)

Hope that helps someone along the way...

Cheers --


*located on the ISO within filesystem.squashfs


All times are GMT -5. The time now is 06:56 PM.