Hello:

OK.
I see ...
The Debian kernel has mei built into it.
Is it at all necessary?

I had the idea that Devuan maintainers built the kernel from the source code.
The same way that some people build their own custom kernels.

Thanks for your input.

A.

Hello:

Thanks for the links.
I'm more or less up-to-date wrt this.

But my questions remain:

1.
Why is the Devuan kernel loading the IME module?
What is it necessary for and in what environment?

2.
Why is the module present in the kernel files for 4.9.0-7-amd64 but not for 4.9.0-8-amd64?
Not being in the 4.9.0-8-amd64 kernel files, how is it that it is still being loaded by a running 4.9.0-8-amd64 kernel?

3.
How is it being loaded and how can this be prevented in Devuan ASCII and the upcoming kernels?

Thanks in advance,

A.

Hello:

I thought that the driver version would be the issue (340.102 in Devuan vs 340.107 in PCLOS), so i went about updating the driver the wrong way and that got me a damaged X.

Well ...
That was exactly the problem I was in: stuck in tty1 without much idea as to how to proceed, hence my OP.

I eventually figured it out.

groucho@devuan:~$ dpkg --list | grep -i nvidia

... gave me a screen with any and all the nvidia stuff in my Devuan installation.

Then I made sure that /etc/apt/sources.list would not have ascii contrib and ascii non-free enabled.

[root@devuan groucho]# cat /etc/apt/sources.list
## package repositories

# Changed - 20180619
# deb http://pkgmaster.devuan.org/merged/ ascii main 
# deb http://pkgmaster.devuan.org/merged/ ascii-security main 
# deb http://pkgmaster.devuan.org/merged/ ascii-updates main 
# deb http://pkgmaster.devuan.org/merged/ ascii-backports main 

deb http://deb.devuan.org/merged/ ascii main 
deb http://deb.devuan.org/merged/ ascii-updates main 
deb http://deb.devuan.org/merged/ ascii-security main 
# deb http://deb.devuan.org/merged/ ascii-backports non-free contrib main 

# deb http://deb.devuan.org/devuan/ ascii-proposed main 

# added x nvidia non-free installation
# deb http://deb.devuan.org/merged/ ascii contrib  
# deb http://deb.devuan.org/merged/ ascii non-free  

Once that was done, I did some cleaning up:

[root@devuan groucho]# apt-get clean
[root@devuan groucho]# apt-get autoclean
Reading package lists... Done
Building dependency tree       
Reading state information... Done
[root@devuan groucho]#

[root@devuan groucho]# apt-get purge
Reading package lists... Done
Building dependency tree       
Reading state information... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
[root@devuan groucho]

[root@devuan groucho]# apt-get check                             
Reading package lists... Done
Building dependency tree       
Reading state information... Done
[root@devuan groucho]#

Then I went about uninstalling everything that had an nvidia label.
This is just one of the files:

[root@devuan groucho]# apt-get purge xserver-xorg-video-nvidia

Eventually, the list shown by dpkg --list | grep -i nvidia came up empty.
To be on the safe side, I did apt-get check again and verified that I had not broken anything else.   8^/

I then enabled http://deb.devuan.org/merged/ ascii contrib and http://deb.devuan.org/merged/ ascii non-free in etc/apt/sources.list.
Without that, I would not be able to find the non-free drivers I wanted to install.

As I did not know the exact name/version I would have available, I asked:

[root@devuan groucho]# apt list | grep -i nvidia-legacy-340 | more 

In the list I saw that there was an updated version, albeit not 340.107 (340.106), but closer than the previous 340.102 version.

So I installed it via apt-get install and that was it. The only thing I found odd was that at some point of the installation it listed as recommended nvidia-legacy-340xx-driver-libs-i386 but it was not available in in the repositories.
I thought it was odd because of i386.

On reboot X started as usual but the artifacts I mention in my OP are still there, so I'll have to see if there's some setting in Xorg.conf that may be causing them.

As having http://deb.devuan.org/merged/ ascii contrib and http://deb.devuan.org/merged/ ascii non-free enabled in etc/apt/sources.list as a default option is not a good idea, I commented them out again.

This is how I recall the recovery process, hopefully I have not skipped anything important.
It may be useful for someone who ends up in the same situation.

The lesson I learned:
All -contrib and -non-free stuff should be updated by hand and individually, just like when they were installed.

Cheers,

A.

Hello:

Thanks a lot ...
I was not looking in the right place (with the browser).

Thanks a lot for your input. =-)

Best,

A.

Hello:

I have read in a couple of pages I came across while searching for information that it was deprecated but ...

It does not seem to be deprecated in Devuan: I edited the grub2 entry in Devuan, it was picked by when I did grub-upgate from PCLinuxOS and worked perfectly well when I selected to boot Devuan from PCLinuxOS.

But I also tried vga=ask and the screen said that it was a deprecated option.

Anyway, I also discovered something else, the real origin of the problem (and I am rather embarrased about this).

I use grub-customizer (yes, I know ... ) and it happens that when I was booting Devuan from PCLinux's grub2, I was inadvertently selecting a 'custom' entry which I do not have a clue about or where it came from but I now know that update-grub does not modify it.

It's so damn obvious so as to go unnoticed but makes prefect sense: update-grub only modifies the scripts generated by OS prober, a 'custom' script entry remains just that so it stays unchanged. No idea where it came from or when.

Having tried out by editing and then adding vga=845 to the Devuan grub2 (and seen it worked) and seeing that it was not getting picked up by the PCLinux grub2, I started pouring over the grub.conf files and that's when I discovered this uncomfortable tidbit.  =^/

The vga=845 bit is now part of the grub2 command line in Devuan and it does get picked up by the grub2 in PCLinuxOS when I update-grub.
I was just not selecting the correct entry. What a dick ...

I see (sort of): it is what I am saying above?

Hmm ...
It took me a good while to sort of understand and get a (light) hold on what was going on, so I'll pass on that. =-)
I'll chalk all this up to experience and a lesson learned.

Irrespectively of this, if vga=XXX is deprecated then there must be a substitute way to do the same thing.

With time, I'll see about trying out different options in grub2: after all, I boot into PCLinuxOS without VGA=XXX, vesafb gets loaded without nokmsboot present and still get the monitor resolution I want using the Nvidia drivers.

I gues I can mark this as [Solved] - hopefully it will be of use to others.

Thank you very much (to all) for your input.

Best,

A.

Hello:

Yes.

My first drive hosts a PCLinuxOS installation, it is set as the first drive to boot in the SAS adapter card and uses grub2.
My second drive hosts my Devuan ASCII installation, it is set as the second drive to boot in the SAS adapter card and uses grub2.
My third drive is an old W7 installation I keep for reference purposes, it is set as the third drive to boot in the SAS adapter card (getting scrubbed soon).

When I boot my rig it starts from the first drive and its grub2 installation offers me to boot into PCLinuxOS, Devuan ASCII or W7 from there.
If I remove this first drive (or if the drive fails), the rig boots from the second drive and its grub2 installation offers me me to boot into PCLinuxOS Devuan ASCII or W7 from there (obviously it does not find PCLOS).

If the first and second drives change places, the same thing happens, with the first OS order changed.

No. (I don't think so)

Each installation (PCLinuxOS first and a year later Devuan) was done with only one drive in the first bay.
That way I could only screw up only one thing at a time.=^D! 

I'm sorry but it's not too clear to me which of these I am doing.
It has worked well and I've always had an OS at hand, which was my primary objective.

For emergencies, I also have a TinyCore Linux installation on an old 1Gb pendrive plugged into a USB socket I discovered on the mobo (Sun Ultra24).   
It's actually saved my skin a couple of times.

I'm sorry for that oversight on my behalf.

What files would you need to see?

No.
The screen output at boot is in the correct console resolution.

Both PCLinuxOS and Devuan use the non-free Nvidia drivers.

I do not remember adding it so it must have been added by the Nvidia drivers installation?

Looking for some info on this, I came across a post from 2012 in the Mageia forum:
https://forums.mageia.org/en/viewtopic. … 971#p14396

I expect that the nokmsboot parameter was set after I installed the Nvidia drivers in PCLinuxOS. I have not seen anything acting up since I removed it.
Since then I have seen the Nvidia drivers get updated more than once, so maybe they have caught up and the nokmsboot is no longer needed.

It was not put in Devuan when I installed the Nvidia drivers.
Let's see if any problems arise.

--- EDIT ---

I may have come across something:

You're quite right.

From my PCLinuxOS terminal

[groucho@groucho ~]$ dmesg | grep vesafb
[    0.341689] vesafb: mode is 1280x1024x32, linelength=5120, pages=0
[    0.341692] vesafb: scrolling: redraw
[    0.341700] vesafb: Truecolor: size=8:8:8:8, shift=24:16:8:0
[    0.341724] vesafb: framebuffer at 0xfb000000, mapped to 0xffffac3140800000, using 5120k, total 5120k

The frame-bufefr is only loaded if I boot Devuan from it's own drive ie: not from PCLinuxOS's grub2.
From my Devuan terminal (booted independently)

[root@devuan groucho]# dmesg | grep vesafb
[    0.645586] vesafb: mode is 1280x1024x32, linelength=5120, pages=0
[    0.645590] vesafb: scrolling: redraw
[    0.645594] vesafb: Truecolor: size=8:8:8:8, shift=24:16:8:0
[    0.645612] vesafb: framebuffer at 0xfb000000, mapped to 0xffffad6701800000, using 5120k, total 5120k

--- EDIT ---

Thank you very much for taking the time to write this up.
Much appreciated.

Best,

A.

Hello:

Sorry for the delay in answering.
Automatic subscription was off ... =^/

Yes. I am using the Nvidia non-free drivers.

It was the only way to get my two cards and three monitors to play nice.
RandR gets disabled because of Xinerama but I don't think it has anything to do with this.

I was looking into a possible version mismatch this morning.

PCLinuxOS uses Grub2 2.02.0-3
Devuan uses 2.02Beta3-5

I don't know if there's any real difference between these two, but ...

If both installations run of the same hardware and the problem in the Devuan installation arises when I boot it from the grub2 in PCLinuxOS and not with it's own grub2, then the problem seems to be with how grub2/PCLinuxOS "talks" with grub2/Devuan.

Is it a version mismatch or is it a configuration issue?
ie: is there something that grub2/PCLinuxOS needs to know or find to boot Devuan the same way it boots from its own grub2?

Thanks for your input.   =-)

Cheers,

A.

Hello:

Spoke too soon.  =^/

This is how it is done:
https://wiki.debian.org/GrubTransition

It happens that it does work ...
But if I boot directly from the drive hosting Devuan that is.

In my setup, my first drive hosts a PCLinuxOS installation, another systemd free OS I have been using since before Devuan.

My second drive hosts my Devuan ASCII installation which also has a grub2 setup just in case my PCLinuxOS drive goes south.
My third drive is an old W7 installation I keep in a SATA drive for reference purposes, it's getting scrubbed soon.

In any case, when I boot my rig it starts from the first drive and its grub2 installation offers me to boot into PCLinuxOS, Devuan ASCII or W7 from there.
If I remove this first drive, the rig boots from the second drive and its grub2 installation offers me me to boot into PCLinuxOS Devuan ASCII or W7 from there (obviously it does not find PCLOS).

If the second drive gets set up as a first drive, the same thing happens, with the order changed.

The thing is that when I boot my rig without the first drive in place, Devuan ASCII boots as I want to, with the screen size I set.
But if I boot into Devuan ASCII selecting it from the grub2 menu, it does not.

I had the idea that grub2 looks for other OSs and boots them according to what the grub.conf file in the drive hosting that OS says.
ie: the screen size set by GRUB_GFXMODE.

But it seems this is not the case.

Or am I doing something wrong?

Thanks in advance.

A.

Hello:

Ok.

I started there and saw that x11-xkb-tools was not installed.
Assuming x11-xkb-tools should be there (and maybe other missing configuration files) and that an update would install whatever was needed, I exited aptitude and decided to try apt-get update.

I first checked that the /etc/apt/sources.list was this one and that everything else was remmed out:

deb http://pkgmaster.devuan.org/merged ascii main
deb http://pkgmaster.devuan.org/merged ascii-updates main
deb http://pkgmaster.devuan.org/merged ascii-security main
deb http://pkgmaster.devuan.org/merged ascii-backports main

Then I did apt-get update and got a warning about dpkg having been interrupted which got fixed with the instructions on the screen with ...

dpkg --configure -a

... and then ran apt-get update again.

It started to do its work but complained about /etc/pam.d/login having been modified and asking about which version to keep.
I guessed that that could have been the glitch that affected my kb/mouse (?) so I kept the existing script version (default option) and continued.
If that one did not work, I could try the new version which obviously was not an option if I accepted the new one from the start.

When it was done (it was a lot) I exited, rebooted and got my desktop, this time with working kb and mouse.  =^ )

Once there, I started SPM and updated everything again.
Then for safe measure, I did the same through apt.

Now, it seems everything is well again:

root@devuan:/home/groucho# apt-get dist-upgrade
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Calculating upgrade... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
root@devuan:/home/groucho#

root@devuan:/home/groucho# uname -a
Linux devuan 3.16.0-5-amd64 #1 SMP Debian 3.16.51-3+deb8u1 (2018-01-08) x86_64 GNU/Linux
root@devuan:/home/groucho# 

groucho@devuan:~$ lsb_release -a
No LSB modules are available.
Distributor ID:	Devuan
Description:	Devuan GNU/Linux 2.0 (ascii)
Release:	2.0
Codename:	ascii
groucho@devuan:~$ 

A big thank you to all of those who pitched in to help.
Really appreciated your input.

That said, it I think I have to brush up and deepen my command line skills.

Best,

A.

Hello:

I have read them.
But have not been able to identify anything specific that would help me solve this.
At least not with my level of exposure to Linux.

Perhaps you could point out anything I may have (surely) missed?

Thanks in advance.

A.

Hello:

Anyone?

I tried using a different mouse directly connected to a USB port (instead of a PS2 connected to a port on the Kb) but still no dice.
Is there any way I can get out of this problem without having to do a full reinstall?
That's the MS way out...

I was wondering about using a live Jese/Ascii *.iso to boot and do an update to see if that fixes anything or change repos to Jesse and then do an update to see if I can get to where I started from ie: a healthy and perfectly working Jesse installtion 8^/.

Or try to do the same things from the terminal, but I'd need some instructions.

Thanks in advance.

A.