Hello:

I was just about to post.
I managed to get things working with PMail.

The problem was that I had added myself the the sudo group but had not logged in again. :^ '
Wasn't going to get anywhere that way.

My *.desktop file for PMail is this ...

[Desktop Entry]
Type=Application
Name=PMail
Exec=wine start /unix /home/groucho/.wine/drive_c/PMAIL/Programs/winpm-32.exe
MimeType=application/x-ms-dos-executable;application/x-msi;application/x-ms-shortcut;
Icon=/home/groucho/pmail_32x32x32.png
NoDisplay=true
StartupNotify=true
GenericName=PMail32
Comment=
Terminal=false
Path=

... and it works as intended.

[root@devuan groucho]# cat /etc/sudoers
#
# This file MUST be edited with the 'visudo' command as root.
#
# Please consider adding local content in /etc/sudoers.d/ instead of
# directly modifying this file.
#
# See the man page for details on how to write a sudoers file.
#
Defaults	env_reset
Defaults	mail_badpass
Defaults	secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"

# Host alias specification

# User alias specification

# Cmnd alias specification

# User privilege specification
root	ALL=(ALL:ALL) ALL

# Allow members of group sudo to execute any command
%sudo	ALL=(ALL:ALL) ALL

# See sudoers(5) for more information on "#include" directives:

#includedir /etc/sudoers.d
[root@devuan groucho]# 

Seems it's like you say.

I have tried in the past to get around vi but I've found it very complicated to use.
I'm afraid I'm 20+ years late to that party, I learned the ropes with the early DOS 5.0 editors.

After trying three or four Linux CLI editors, I have finally settled on jed, it works for what I need to do.

groucho@devuan:~$ sudo -l
Matching Defaults entries for groucho on devuan:
    env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin

User groucho may run the following commands on devuan:
    (ALL : ALL) ALL
    (root) NOPASSWD: /usr/sbin/pm-suspend, /usr/sbin/pm-hibernate, /sbin/halt, /sbin/reboot
groucho@devuan:~$ 

groucho@devuan:~$ sudo -i
[sudo] password for groucho: 
[root@devuan ~]# 

It works ...  =-)

Just in case:

groucho@devuan:~$ groups
groucho adm dialout cdrom floppy tape sudo audio dip video plugdev netdev lpadmin scanner
groucho@devuan:~$ id
uid=1000(groucho) gid=1000(groucho) groups=1000(groucho),4(adm),20(dialout),24(cdrom),25(floppy),26(tape),27(sudo),29(audio),30(dip),44(video),46(plugdev),102(netdev),109(lpadmin),111(scanner)
groucho@devuan:~$ 

One thing:

# Allow members of group sudo to execute any command
%sudo	ALL=(ALL:ALL) ALL

I don't want to be able to do anything with sudo, I would like to strictly limit what I can do as a member of the sudo group.

This ALL=(ALL:ALL) ALL seems (to me) rather excessive.

How can this be effectively limited without hampering the use of the OS?

Thank you very much for your input.

Cheers,

A.

Hello:

Yes, I know that it will render any legacy grub system unbootable.
I have had good comments after introducing it into the PCLinux forum.

I think I looked at it but the Timeshift convinced me because of it being automatic and scheduling, etc.
Seems to be much like Norton Ghost-DOS, which I used a lot when I was prisoner of the MS camp.  =-)
It worked great most of the time.

On the contrary, thank you very much for taking the time to write and share your opinion/experience.
That's what this is all about, no?

Cheers,

A.

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.