Hello:

OK.

[root@devuan ~]# apt --simulate --autoremove purge firmware-amd-graphics
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following packages will be REMOVED:
  amd64-microcode* firmware-amd-graphics* firmware-linux* firmware-linux-nonfree* intel-microcode* iucode-tool*
0 upgraded, 0 newly installed, 6 to remove and 0 not upgraded.
Purg amd64-microcode [3.20160316.3]
Purg firmware-linux [20190114-2~deb9u1]
Purg firmware-linux-nonfree [20190114-2~deb9u1]
Purg firmware-amd-graphics [20190114-2~deb9u1]
Purg intel-microcode [3.20200616.1~deb9u1]
Purg iucode-tool [2.1.1-1]

[root@devuan ~]# apt install amd64-microcode
Reading package lists... Done
Building dependency tree       
Reading state information... Done
amd64-microcode is already the newest version (3.20160316.3).
amd64-microcode set to manually installed.
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
[root@devuan ~]# apt install intel-microcode
Reading package lists... Done
Building dependency tree       
Reading state information... Done
intel-microcode is already the newest version (3.20200616.1~deb9u1).
intel-microcode set to manually installed.
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
[root@devuan ~]# apt install iucode-tool
Reading package lists... Done
Building dependency tree       
Reading state information... Done
iucode-tool is already the newest version (2.1.1-1).
iucode-tool set to manually installed.
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
[root@devuan ~]# 

[root@devuan ~]# apt --simulate --autoremove purge firmware-amd-graphics
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following packages will be REMOVED:
  firmware-amd-graphics* firmware-linux* firmware-linux-nonfree*
0 upgraded, 0 newly installed, 3 to remove and 0 not upgraded.
Purg firmware-linux [20190114-2~deb9u1]
Purg firmware-linux-nonfree [20190114-2~deb9u1]
Purg firmware-amd-graphics [20190114-2~deb9u1]
[root@devuan ~]#

[root@devuan ~]# apt --autoremove purge firmware-amd-graphics
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following packages will be REMOVED:
  firmware-amd-graphics* firmware-linux* firmware-linux-nonfree*
0 upgraded, 0 newly installed, 3 to remove and 0 not upgraded.
After this operation, 31.0 MB disk space will be freed.
Do you want to continue? [Y/n] 
(Reading database ... 140831 files and directories currently installed.)
Removing firmware-linux (20190114-2~deb9u1) ...
Removing firmware-linux-nonfree (20190114-2~deb9u1) ...
Removing firmware-amd-graphics (20190114-2~deb9u1) ...
[root@devuan ~]# 

That should do it.  =-)
I'll come back if I hit a snag.

Edit: package amd64-microcode also removed without ill effects as I run on Intel hardware.

Thanks a lot for your input.

Cheers,

A.

Hello:

It's not Data Validation, it is something else that these DHs enable by default, à la Microsoft Office.
Incredible that they have not learned anything from their nemesis' shortcomings ...

This is yet another feature called, not surpringly, autoreplace.

To answer my question: one turns off autoreplace by going to the menu bar, selecting Tools > AutoCorrect Options...
You then click on the Options tab and uncheck the "Use replacement table".

My apologies for the noise.

Cheers,

A.

Hello:

See this post https://forums.linuxmint.com/viewtopic.php?t=326047

Questions:

Does your system work properly?

Are you using VirtualBox or VMware?
Any issues?

Do you have the latest BIOS available for your laptop?

Is this the same Fujitsu Worksation Laptop with Nvidia Quadro FX770m Graphics you were installing Nvidia legacy drivers for?
If so and most important: are you certain that the graphics card you have added is compatible/supported?

Cheers,

A.

Hello:

You're welcome.

With the solution.  8^7

The nvidia-legacy 340.xx is the last driver with updates from Nvidia and has suffered very little change in the past years.
The cards it is for are no longer manufactured or supported, hence the 'legacy'.
See the link to the nvidia web sire I posted when answering one of your earlier posts.

The information is all there but you have to read it. -> https://dev1galaxy.org/viewtopic.php?pid=24965#p24965

If you are on a one screen system you probably do not need it.

It is not my walkthrough.
HevyDevy wrote it up.
It applies to Linux in general.

Cheers,

A.

Hello:

Spot on!   8^D

(thunar:2500): Gdk-ERROR **: 16:08:14.176: The program 'thunar' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadWindow (invalid Window parameter)'.
(Details: serial 18413 error_code 3 request_code 141 (Composite) minor_code 8)     <---- here it is
(Note to programmers: normally, X errors are reported asynchronously;
that is, you will receive the error a while after causing it.
To debug your program, run it with the GDK_SYNCHRONIZE environment
variable to change this behavior. You can then get a meaningful
backtrace from your debugger if you break on the gdk_x_error() function.)

Commenting the compton & line in /home/groucho/.config/openbox/autostart solved the problem.
So it seems that there will be no compositing for me in Beowulf+Openbox.

But the .xsession-errors file is absolutely huge, Way over the 6000 line scollback I've set in terminal so I cleared it with :> and will start to check all that.

Thanks for your input.

Cheers,

A.

Hello:

Unless I am mistaken, you can install ascii or Beowulf and the non-free 340XX legacy drivers with no issues.

See here https://www.nvidia.com/en-us/drivers/unix/legacy-gpu/ ...

... and here https://nvidia.custhelp.com/app/answers … /a_id/3142

Devuan will be a great choice for your workstation.
Fit a fast solid state drive and as much memory as it will accept and it will fly.

Cheers,

A.

Hello:

You are quite right, I did not express myself correctly.
I should have written: ... seems that setting the /dev/kdm to world-read-write was ...

Why not do it when installing qemu-kvm?
Not a question that I bring up for I would have not known of its existence if I had not looked at my dmesg, which I always do.

It was so out of place that a maintainer actually filed it as a bug. (see the thread I linked to)

Yes, as it should (if it needs it, obviously).
Right?

Because ...

... it is there?
... people who know much more than I have made what seems to be a strong case against it being there/generated?
... the (seemingly valid) arguments against this were railroaded by Poettering?

Isn't that how systemd came to be?

You may or may not agree with me, but it is not so much what is there but how it got to be there.

I agree.

Thanks so much for your input.

Cheers,

A.

Hello:

I don't think that would have any effect.
The qemu-kvm package was never installed and I think what is happening is not because of configuration file from the qemu-kvm installation.

~# apt purge qemu-kvm
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Package 'qemu-kvm' is not installed, so not removed
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
~# 

Normally, the qemu-kvm package would set up a 'kvm' group and set up user r+w access to /dev/kvm.

For reasons that do not seem at all clear, this has changed in Beowulf.

Like ralph.ronnquist points out, now the system has a default udev rule (set up at OS install time and overwritten on every update) that wants to set /dev/kvm to world-read-write.

I expect that it also wants a 'kvm' group and not finding it, prints out the result in dmesg. 

At least that is how I understand it, corrections welcome.  =-)

Cheers,

A.

Hello:

I'll have a read.
But you know I have a thing for cats.  8^D

No.

Yes, but if I'm not installing qemu ...

Apparently not.
From what I make from the thread linked below, only the qemu package uses it.

I found a bug report from 2017 with respect to this here -> https://github.com/systemd/systemd/issues/6360

It would seem that PR #5597 introduced a rule for /dev/kvm in Debian unstable, the result of which is the line in dmesg and someone filed the bug report.

What the OP wrote makes (to me) a lot of sense, more so if we take into account that there seem to be no applications which would need a system generated 'kvm' group save the qemu package.

The thread is really worth a read.

It seems this 'kvm' group was another one of Poettering's brilliant ideas.
And as such, it was shoved through in the usual fashion:

There you have it.
That's how we got a systemd-udevd: Specified group 'kvm' unknown line in dmesg.

@Poettering: no [asshole], it does not make any sense.

Cheers,

A.

Hello:

I see.

Not so 'bare-bones' as I expected a net-install to be.

Thanks for the heads-up, good to know.
I'm not doing installations so often, but I'll keep it in mind.

On the other hand, maybe it would be easier to make a list of the Recommends included in the net-install and a script to purge them when the installation is finished and you are logged in as root for the first time.

Followed by a double portion of apt install -f ...   8^D !!!
Just in case.

Thanks for your input.

Cheers,

A.

Hello:

Seems so.

Any idea why?
ie: why Debian does not have it in its repository?

Thanks a lot.  8⁾)

What can you tell me about the warning messages?
ie: update-rc.d and cryptsetup.

Cheers,

A.