Hello:

That is a good thing (IMO) and what I was wanting to accomplish by starting sudo service.

OK.

Yes.
My installation gets to root by means of su.

Now I do, thanks to your post.   =-)

Indeed ...
That's exactly what it is doing, as there is a group called 'groucho'.
I cannot recall creating it myself, but that does not mean much.  8^/.

BTW:
Group 'groucho has Group ID 1000 and my user 'Julis Henry Marx' belongs to it.

I'll have to look into that and see where group 'groucho' came from.
I think it was created at installation time. (?)

I'll see what happens if I take myself out of it.

But then, if I am the user groucho, why didn't using groucho (instead of %groucho) work?
Could it be that there's a sort of hierachy which which sudo works?
ie: first groups matching and then users?

I have a feeling that there being a group with a name that matches a user name is confusing sudo.
ie: user groucho belonging to group groucho.

I'll try to clean this up and see how it goes.

Thank you very much for your input.

Cheers,

A.

Hello:

Indeed ...
But just how was I to know what I was doing wrong?

The existing file in /etc/sudoers.d was copied exactly and properly edited with visudo.
And still ...

OK.
The solution ended up being this: ---> %

The line that makes up any file you want to add to the /etc/sudoers.d/ directory (apparently) has to be preceded by a percent (%) sign.
Otherwise it will not work.

I have not been able to find a place where the syntax for these files is explained.

This example I posted above was wrong:

The correct thing to do was to add a percent sign at the beginning of the line, like this:

%groucho ALL= NOPASSWD: /usr/bin/linssid

I found out about this by reading this post: https://askubuntu.com/questions/930768/ … sodoers-fi.
And although it makes no mention of the percentage sign thing,  I saw that a line in a /etc/sudoers.d file used it.

So I tried it and it worked.  =^º

[rant mode]
How could I have possibly known this if the existing /etc/sudoers.d/users_shutdown file reads like this:

[root@devuan groucho]# cat /etc/sudoers.d/user_shutdown
groucho ALL= NOPASSWD: /usr/sbin/pm-suspend, /usr/sbin/pm-hibernate, /sbin/halt, /sbin/reboot  <-- just [u]where[/u] is the % sign?
[root@devuan groucho]# 

And if using visudo to look at it shows me the exact same string of characters?

I mean, where is the f***ing percent sign?
[/rant mode]

Moral of the story:
Want to make a /etc/sudoers.d/file to avoid mucking up (very easy to do) the sudoers file?

1. copy an existing one.
2. edit it with visudo.

ie:

visudo -f /etc/sudoers.d/[file_name]

3. make sure that you add a % sign at the start of the line.
4. save it with the intended name eg: user_whatever so you'll know what it is for.
5. make sure the file has 440 permissions.

ie:

5. check it all with visudo -c

[root@devuan groucho]# visudo -c                            
/etc/sudoers: parsed OK
/etc/sudoers.d/README: parsed OK
/etc/sudoers.d/user_whatever: parsed OK
/etc/sudoers.d/user_shutdown: parsed OK
[root@devuan groucho]# 

Of course, remember that you have to be a member of the sudoers group otherwise this is all moot.

Caveat: I'm no expert and WRT Linux I'm sort of playing by ear, so if any of the Devuan forum members with experience could take a minute to check that all this is not hogwash or has any errors, I'd be very obliged.

Cheers,

A.

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.