Hello:

Hmm ...
Password managers might be are very attractive targets to compromise.

There you go.

Best,

A.

Hello:

Not the right media to use for a test unless you are absolutely certain than you can read it in any other drive.

Consider using an OEM written media to test the drive.

Have you checked the dmesg printouts?

A.

Hello:

From the linked screen capture, it would seem that the hardware is working.

Just in case, boot the box without the optical drive plugged in, plug it in and check the dmesg printout.
If the drive is correctly recognised by the system and no errors are reported, it would mean that it is not a Devuan issue.

If the drive is working properly, the problem would lie either with the media or with the laser optic itself.
Check with a known/working factory stamped (readable) CR-ROM or DVD to rule out the media being bad.

Q: can you hear the drive spin when you load a DC/DVD? What does the dmesg printout say?

If the problem is the laser optic, it may come down to something as simple as a dirty lens or a more complicated issue like eg: a damaged laser assembly or a power problem*.

A properly working drive should recognise the media it was designed for.

Check here for the manual and specs for that drive (SH-S162L?).
https://samsung.manymanuals.com/optical … nual-14158    <- see page #32 of the manual

Best,

A.

* From a a fast look at the manual, it would seem that the drive is an internal ATA/ATAPI (E-IDE) model (?). ie: needs both 12v and 5v power.

It could be that whatever adapter you are using is not providing enough power for the laser to read properly.

Hello:

These are the first two lines in my dmesg printout:

$ sudo dmesg | more
groucho@devuan:~$ sudo dmesg
[    0.000000] microcode: microcode updated early to revision 0xa0b, date = 2010-09-28
[    0.000000] Linux version 6.1.0-38-amd64 (debian-kernel@lists.debian.org) (gcc-12 (Debian 12.2.0-14+deb12u1) ...
--- snip ---
$

ie: first the microcode and then the kernel

Further on, I get this:

$ sudo dmesg | more
--- snip ---
[    0.155960] MDS: Vulnerable: Clear CPU buffers attempted, no microcode
--- snip ---
[    3.399828] microcode: sig=0x1067a, pf=0x10, revision=0xa0b
[    3.400056] microcode: Microcode Update Driver: v2.2.
--- snip ---
$ 

I also have the intel-microcode package installed and the module blacklisted in /etc/modprobe.d.

$ apt list | grep installed | grep intel-microcode
--- snip ---
intel-microcode/stable-security,now 3.20250512.1~deb12u1 amd64 [installed]
$ 

The directory /lib/firmware/intel-ucode has 125 files in it, all with a Modify time = May 18 20:06, so they receive updates.

Some insight from Intel:

I'd say that the module is blacklisted so that only the kernel deals with the respective microcode file at the very start of the boot process.
Just an edguess.

Best,

A.

Hello:

Not so fast.  8^°

The current status of the Devuan releases can be seen here.

As you can see, the stable/maintained releases are these:
Daedalus / Bookworm
Chimaera / Bullseye

The archived releases are these:
Beowulf / Buster
ASCII / Stretch
Jessie / Jessie

The next* Devuan release, Excalibur (Trixie) is still in the developement / testing phase and has not been released yet.
* as always, it will be ready when it is ready.

Last but not least, there is Ceres, Devuan unstable (Sid).
It has not and will not ever (?) be a release as we know it.
It is a platform for experimentation which is why you have a 340XX package available.

As for the nvidia-legacy-340xx-driver, it is still available for Beowulf but not for Daedalus or Excalibur.
It has been so for a good while now and I have serious doubts as to its viability in future releases.

I asked (previous post) to see if anyone out there had experimented with the various recipes for installing that are making the rounds in the web lately. 

Best,

A.

Hello:

Hmm ...
Now it is working for me also.
It was down (for my end) for at least 10',

Most probably.

Best,

A.

Hello:

For someone who knows zilch about any and all of that, the answer is, a definitive 'yes'.

It is both much easier and reassuring for me to simply avoid using keypassXC.
I am quite sure a great many Linux users think along the same lines.

Because ...
You know, "it might be a sort of spyware".

Right ...

Well ...
That is but one way of looking at it.
If it were the only way, inherently trusted distributions and repsitories (Like Devuan Linux and others) would not even exist.

As always, YMMV.

A.

Hello:

I cannot imagine why you would seem slow.
Your questions were clear enough for everyone to know what you were asking about.

Most times I can't, even if I cook it myself.  8^°
No big deal.

All part of the Devuan team.

Probably because that is exactly what they were doing.

Glad you were able to get things sorted.

Best,

A.

Hello:

If it is not visible, it does not.
ie: a DB25F is a bulky thing.  8^)

My workstation does not have visible DBxx ports (male or female), but there is an available header on the MB and a BIOS setting to activate a serial port.
I doubt that is the case with your laptop.

Now, even though there is no parallel port available to Linux, the line printer module (lp) is loaded at boot time, probably (?) by CUPS and as a result, the other printer modules. eg: parport, ppdev and parport_pc.

You could check with dmesg and lsmod to see if they are being loaded by any other software and eventually blacklist them if they are not needed.

Best,

A.

Hello:

Indeed ...

And then, there's also this bit:

Right on the dot.  8^)

Best,

A.

Hello:

Quite so.
And then, Devuan (and every other distribution built on it) will be toast.

Best,

A.