LinuxQuestions.org
Help answer threads with 0 replies.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Debian
User Name
Password
Debian This forum is for the discussion of Debian Linux.

Notices


Reply
  Search this Thread
Old 07-20-2017, 09:57 AM   #1
gIn_gOut
Member
 
Registered: Jul 2015
Posts: 35

Rep: Reputation: Disabled
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 --

Last edited by gIn_gOut; 07-20-2017 at 02:14 PM.
 
Old 07-20-2017, 02:30 PM   #2
IsaacKuo
Senior Member
 
Registered: Apr 2004
Location: Baton Rouge, Louisiana, USA
Distribution: Debian 9 Stretch
Posts: 2,349
Blog Entries: 8

Rep: Reputation: 384Reputation: 384Reputation: 384Reputation: 384
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.
 
1 members found this post helpful.
Old 07-20-2017, 08:01 PM   #3
gIn_gOut
Member
 
Registered: Jul 2015
Posts: 35

Original Poster
Rep: Reputation: Disabled
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 --
 
Old 07-20-2017, 09:14 PM   #4
IsaacKuo
Senior Member
 
Registered: Apr 2004
Location: Baton Rouge, Louisiana, USA
Distribution: Debian 9 Stretch
Posts: 2,349
Blog Entries: 8

Rep: Reputation: 384Reputation: 384Reputation: 384Reputation: 384
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).
 
1 members found this post helpful.
Old 07-21-2017, 12:35 AM   #5
AwesomeMachine
LQ Guru
 
Registered: Jan 2005
Location: USA and Italy
Distribution: Debian testing/sid; OpenSuSE; Fedora; Mint
Posts: 5,513

Rep: Reputation: 1003Reputation: 1003Reputation: 1003Reputation: 1003Reputation: 1003Reputation: 1003Reputation: 1003Reputation: 1003
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
 
1 members found this post helpful.
Old 07-21-2017, 10:49 AM   #6
gIn_gOut
Member
 
Registered: Jul 2015
Posts: 35

Original Poster
Rep: Reputation: Disabled
@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 --
 
Old 07-21-2017, 12:59 PM   #7
gIn_gOut
Member
 
Registered: Jul 2015
Posts: 35

Original Poster
Rep: Reputation: Disabled
@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?
 
Old 07-22-2017, 12:14 AM   #8
jim_p
Member
 
Registered: Aug 2009
Distribution: Debian testing
Posts: 557

Rep: Reputation: 127Reputation: 127
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.
 
2 members found this post helpful.
Old 07-25-2017, 11:11 AM   #9
gIn_gOut
Member
 
Registered: Jul 2015
Posts: 35

Original Poster
Rep: Reputation: Disabled
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 --

Last edited by gIn_gOut; 07-25-2017 at 11:15 AM.
 
1 members found this post helpful.
Old 07-25-2017, 11:34 AM   #10
IsaacKuo
Senior Member
 
Registered: Apr 2004
Location: Baton Rouge, Louisiana, USA
Distribution: Debian 9 Stretch
Posts: 2,349
Blog Entries: 8

Rep: Reputation: 384Reputation: 384Reputation: 384Reputation: 384
Quote:
Originally Posted by gIn_gOut View Post
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!
 
1 members found this post helpful.
Old 07-25-2017, 11:51 AM   #11
gIn_gOut
Member
 
Registered: Jul 2015
Posts: 35

Original Poster
Rep: Reputation: Disabled
@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 --
 
Old 07-27-2017, 01:27 PM   #12
gIn_gOut
Member
 
Registered: Jul 2015
Posts: 35

Original Poster
Rep: Reputation: Disabled
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 --
 
1 members found this post helpful.
Old 07-27-2017, 01:58 PM   #13
IsaacKuo
Senior Member
 
Registered: Apr 2004
Location: Baton Rouge, Louisiana, USA
Distribution: Debian 9 Stretch
Posts: 2,349
Blog Entries: 8

Rep: Reputation: 384Reputation: 384Reputation: 384Reputation: 384
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).
 
Old 07-28-2017, 12:17 PM   #14
gIn_gOut
Member
 
Registered: Jul 2015
Posts: 35

Original Poster
Rep: Reputation: Disabled
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

Last edited by gIn_gOut; 07-30-2017 at 03:12 PM.
 
1 members found this post helpful.
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
[SOLVED] Stretch: issue installing flashplayer floppy_stuttgart Debian 3 03-24-2017 01:35 PM
grep is maddening sharky Programming 6 11-01-2008 09:39 PM
stretch xorg display? shanenin Linux - Software 5 11-02-2004 02:12 PM
thinkpad 600 redhat 9 display issue mccord Linux - Laptop and Netbook 2 08-18-2004 11:57 AM
thinkpad 600 redhat 9 display issue mccord Linux - Newbie 5 08-17-2004 11:18 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Debian

All times are GMT -5. The time now is 07:45 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration