You are not logged in.
I have inadvertently installed the nvidia-driver 418.74-1 on a machine with a graphics card that is no longer supported. The problem can be corrected by installing nvidea-legacy-360xx-driver, and I would appreciate some advice on how to proceed. I assume I have to remove all the nvidia 418.74 packages and also xserver-xorg-video-nvidia 418.74-1 and replace them.
Which xserver package should be installed? Once that is done, I assume I can install the nvidia legacy meta-package and get X11 to function again. I also assume one can not, or should not try to install the replacement nividia packages over the existing ones. So, what is the best sequence of steps?
Last edited by Roger (2020-04-05 17:50:56)
Offline
sgfxi at https://smxi.org/ will automate everything. DISCLAIMER: I've been using onboad graphics and nouveau for years but the sgfxi script used to work wonders.
Offline
Hello:
sgfxi at https://smxi.org/ will automate everything.
Being a long time user of Nvidia legacy cards/drivers under Linux, I was interested in seeing what smxi was about and saw that the author is also the author of the inxi script.
Did not know that.
Although inxi is in the Devuan repositories, I see that smxi (or the other author's scripts) is not.
Further looking in https://pkginfo.devuan.org/ revealed that it smxi has never been included in any Devuan repository.
Is there a specific reason for that?
I have read posts from mid 2015 regarding some difficulty the smxi script seemed to have ID'ing Devuan but it seems to have been fixed.
EDIT:
Fix confirmed - https://github.com/smxi/inxi/blob/master/inxi.changelog
=====================================================================================
Version: 2.2.23
Patch: 00
Date: 2015-06-08
-----------------------------------
Changes:
-----------------------------------
New version, tarball. Tiny change. Added /etc/devuan_version file to distro id to handle
the switched file name. Kudos to anyone out there fighting to create a working alternative
to the unreliable and buggy and windows emulating systemd, I wish devuan luck. Maybe between
devuan and gentoo and slackware we can save the free software core systems before it's too late.
-----------------------------------
-- Harald Hope - Mon, 08 Jun 2015 15:43:52 -0700
=====================================================================================
Thanks in advance,
A.
Last edited by Altoid (2020-04-02 22:59:22)
Offline
@Altoid . . . thanks for tracking that down. I have always had great respect for HH and thank him for his contributions and making that script compatible with Devuan. You probably noticed that package comes directly from Debian - Origin: Debian.
Offline
Hello:
... thanks for tracking that down.
You're welcome. =-)
... had great respect for HH and thank him for his contributions and making that script compatible with Devuan.
Yes.
That website he's set up is great.
Really neat.
I have only used inxi which I find to be excellent, so I wanted to see about smxi, which I did not know about.
... that package comes directly from Debian ...
Indeed ...
But Debian also means (in some way, methinks) systemd related.
As I always try to avoid installing anything from outside the Devuan repositories, I went to synaptic expecting to find it there, just like inxi.
I did not find it so I went looking for it at https://pkginfo.devuan.org/ and it had not been / was not there either.
This called my attention, which is why I asked.
I'll install it from HH's site but maybe (?) it could be added to the stable/backport repositories in the future?
Thanks for your input.
A.
Offline
Hello:
golinux wrote:... that package comes directly from Debian ...
Indeed ...
But Debian also means (in some way, methinks) systemd related.
LOL! 98% of Devuan is pure Debian. These are the Debian packages banned in Devuan.
As I always try to avoid installing anything from outside the Devuan repositories, I went to synaptic expecting to find it there, just like inxi.
I did not find it so I went looking for it at https://pkginfo.devuan.org/ and it had not been / was not there either.This called my attention, which is why I asked.
I'll install it from HH's site but maybe (?) it could be added to the stable/backport repositories in the future?
If Debian had it, we would have it. We only touch files with systemd issues. If and when Debian offers it, then we will too.
Thanks for your input.
A.
YVW
Offline
Hello:
If Debian had it, we would have it.
Ahh ...
That's the reason.
Learn something new every day. 8^)
... only touch files with systemd issues.
... when Debian offers it, then we will ...
Right.
So my question should have been: why do the Debian repositories have inxi and not smxi and the rest.
Maybe they are not happy with his stance on systemd, the same one I acquired once I realised what was going on albeit only after a 4/5 year tour of Debian/RH based distributions.
Thanks a lot for bearing with me.
Cheers,
A.
Last edited by Altoid (2020-04-03 11:18:31)
Offline
I have inadvertently installed the nvidia-driver 418.74-1 on a machine with a graphics card that is no longer supported. The problem can be corrected by installing nvidea-legacy-360xx-driver, and I would appreciate some advice on how to proceed. I assume I have to remove all the nvidia 418.74 packages and also xserver-xorg-video-nvidia 418.74-1 and replace them.
Which xserver package should be installed? Once that is done, I assume I can install the nvidia legacy meta-package and get X11 to function again. I also assume one can not, or should not try to install the replacement nividia packages over the existing ones. So, what is the best sequence of steps?
Try to restore to the state you were in before you installed the wrong drivers.
After that determine which nvidia-legacy-... series you need to install.
If that's nvidia-legacy-360xx, then the only package you need should be nvidia-legacy-360xx-driver, it will drag in the necessary dependencies.
It may be safer to do it in single user mode.
Offline
HI
I wonder if we are seeing different closed source drivers?
If you have GeForce GT 440....according to my eyesight it might be the 390 series
https://www.nvidia.com/Download/driverR … 3832/en-us
which claims
GeForce 400 Series:
GeForce GTX 480, GeForce GTX 470, GeForce GTX 465, GeForce GTX 460 SE v2, GeForce GTX 460 SE, GeForce GTX 460, GeForce GTS 450, GeForce GT 440, GeForce GT 430, GeForce GT 420
Part 2
If you plan on doing a rebuild.....because it might be too hard etc....
I suggest you create a spare data partition quite large
or have a spare drive if its a tower to have this spare partition.
on a clean install....I then reboot with a live product.
My current one is system rescue cd (flashed as an USB) as it works well for my AMD graphics and auto boots to root
and I then create a mount point and run fsarchiver.
If you are lazy like me....and forget to make backup of backup....you may need to start again as we are only as good as our last backup.....I am sure you are aware of Murphy's law....or brown stuff happens.
any how if interested here is how I do it
mkdir /z # its a non writeable usb
mount /dev/sda3 /z
# create my first image
fsarchiver savefs /z/a.fsa /dev/sda1 -a
# or restore first image once created
fsarchiver restfs /z/a.fsa id=0,dest=/dev/sda1 # after id its a zero not an OH
Naturally you would change the target partition to write to if you are using an usb stick etc
Good luck
Offline
The problem is fixed. I composed a reply in some more detail, but the forum logged me out while I was working on it. More details later, but the essence is to install the alternate legacy driver and then get rid of the junk left by an abortive install of the wrong one.
Offline
Hopefully the system won't bounce me while I am working on a reply. As I said, the nvidia-driver problem associated with the Beowulf upgrade is fixed. The essential problem is that the upgraded nvidia-driver package can not handle older video cards. There is an alternative package nividia-legacy-390xx-driver that essentially keeps the previous components and works properly.
The difficulty comes with the way such a major package upgrade is dealt with by the apt system. During my Beowulf dist-upgrade, the system dutifully warned me that the nvidea-driver package would not work with my system, but the alternatives posed: to install or not to install both present difficulties. I made the wrong choice the first time and installed the driver that wouldn't work; the result was an unworking X11 and a mess of unwanted packages to get rid of that apt insisted were necessary. I fixed that problem by installing the correct driver, and then using some ingenuity, and knowledge of my way around the Debian/Devuan setup to persuade apt that I didn't want packages associated with the wrong driver. I had to put some soft links in place by hand thanks to the convoluted path of directories that xserver uses to get to its video driver.
With the second machine I chose the supposedly correct option, don't install, but then had a problem persuading apt-get to continue and install all the other packages. That was then fixed by installing the correct legacy driver, though I still had to remove unwanted packages with some difficulty. I had not realized that one can install several different video drivers, and select them from the command line, but in the case of nvidia there are complications because the driver needs compiled kernel modules, and one installation removes the ones from the previous choice. By saying "no" then installing the correct driver later, the proper kernel modules are compiled.
I did make a delightful discovery in dealing with this problem: xorg has a dummy video driver which can be used to start X11 on a machine without a working video card. It can then be accessed from elsewhere using "ssh -X".
In conclusion I should say that the package system makes maintaining and upgrading software a much more pleasant task than dealing with the horrendous messing around that is involved with Windows. It's fun too, which is another reason for working with Linux.
Offline
"nvidea-driver"? I don't think so:
https://pkginfo.devuan.org/cgi-bin/d1pk … elease=any
0 results for "nvidea-driver" in any (in 14.763921ms)
Try "nvidia-driver" instead:
https://pkginfo.devuan.org/cgi-bin/d1pk … elease=any
17 results for "nvidia-driver" in any (in 15.098441ms)
Offline
Re inxi and smxi:
I have always had great respect for HH and thank him for his contributions
+1.. A founding member of the Sidux project, well remembered here from the early days. https://smxi.org/site/smxi-story.htm is an interesting read, for those who didn't already know.
Offline
That reminds me, golinux, I got sgfxi, and it gave the correct version number for the nvidIa driver, but was unaware of the Debian legacy package and said it couldn't install. The author asked for feedback, which I dutifully sent.
Thanks for the reference.
Last edited by Roger (2020-04-05 23:58:13)
Offline
@Roger . . . Thanks for doing that. One question . . . did you install the incompatible driver from the Devuan repos, Debian repos directly of from nVidia? That might be a factor is why the old driver was not found. I'm not quite sure where/what his script checks. Or perhaps there was an instruction somewhere to remove the current driver before proceeding. I really can't remember the process. It was so long ago.
Offline
Golinux: I first had the nvidia problem in 2011 when the two computers in question were new, and I had a lot of trouble with stuff downloaded from the nvidia website. I was straightened out by one Len Sorenson (a compatriot at the University of Waterloo) who said "do NOT try to mix and match with the Debian installer. They do not get along." He set me on the right path and I have never touched anything that was not from the Debian sources.list (we can now thankfully update that to Devuan). It is now eight years on, and the problem is another nvidia change, but the Devuan packages have got it right; my only problem was how to handle the correct information I was given in the upgrade. If things are done properly, the Devuan way, the installation scripts will use dkms to handle installing the correct drivers. The dist-upgrade process warns of an incorrect kernel module and suggests rebooting as a cure.
As a matter of interest, the other problem I have had over the years was with setting up RAID1, and the solution to that problem involved ignoring what disk manufacturers say about RAID (false raid) and listening to Linux people and installing mdadm.
I am of course elderly, and a traditionalist, using command lines, and I prefer to avoid the unnecessary complexity of things like systemd, gnome (aka Windows) and even grub. Lilo works for me :-) One of these days when I have nothing better to do I'll try and figure out what the hell is the purpose of dbus. In the meantime I have fun computing - isn't that what computers are for (says the physicist)?
Last edited by Roger (2020-04-06 02:17:51)
Offline