Hello:

... same errors at boot time.

These are not errors.
What you are seeing is information related to EVM being enabled, not errors.

And it seems that there is no easy or documented way to avoid / disable security which (for a desktop system) is probably not needed.
As always, YMMV.

That said, the usual/basic way to check for errors is to look at dmesg in a terminal:

1. in a line by line fashion:
sudo dmesg | more

2. using grep:
sudo dmesg | grep -i "error\|warning\|fail\|segfault\|fatal\|not"

3. sifting by type of message
sudo dmesg --level=alert,crit,err,warn

4. with a real time rolling printout:
sudo dmesg -wH

As this is Linux*, there are probably more ways to get that done as there are other logfies in human readable format which you can look at to get a more detailed idea as to what is going on.
* 8^D !

Best,

A.

Hello:

Indeed ...

That is one of the basic characteristics these security features have.
The main one one being that they are both installed and enabled by default / without your consent or knowledge.
Something that should be getting everyone thinking about it and the reasons for it being so.

We are slowly but steadily arriving at the point where booting a computer will require signatures, code or features over which you will have no control or access to.

Unless certain requirements are met, of course.

Best,

A.

Hello:

Hmm ...
Good luck with that.  8^°

Last time I followed an issue here at Dev1, it required a Debian bug report, which I encouraged the author of the OP to file.

The reply was this:

* "won't fix" "get lost".

You may (or may not) want to consider reading the whole Dev1 thread and the Debian bug report to get an idea of the severity of the (properly investigated) problem the OP reported to see where any non-systemd bug report stands.

Best,

A.

Hello:

As long as they generate no issues ... *

I thought likewise at one time but all the answers I found were in line with that I say above.
Like you, I don't like those errors either, but with most it's like chasing a rainbow.

So I ended up resorting to having a size limit on the /home/.xsession-errors file.

Check out this post.

* gist of most if not all the replies I got when asking about the entries in the huge /home/.xsession-errors file.

Best,

A.

Hello:

I see.

Right.
Makes sense.  8^)

Thank you for taking the time to figure that out.
I was worried that an unknown something had mucked around the system.
ie: the (manually or by a script) part of the postinst printout.

Not having been me, the only alternative offered was a script.
Not good.

My only intervention (as far as my memory serves me) in update-alternatives was long ago to set the default editor.
For obvious reasons, not vim.
Or emacs. 8^° !

Remember?
I did not have a clue, I'll have to learn it first.
Thanks for the heads up.

And I'm quite sure that you have worked out the most probable | feasible | likely one.
So I will mark this one as [solved].

As always, thank you very much for your input.

Best,

A.

Hello:

No idea.

That package is probably in my system since ascii or Jesse and I am now running on Daedalus, to which I arrived through succesive dist-upgrades.

Now ...

Looking at yesterday's timeshift snapshot of /etc/alternatives/lzma I see this:

/etc/alternatives/lzma: symbolic link to ../../usr/bin/xz

In the current version, I see the same thing:

/etc/alternatives/lzma: symbolic link to ../../usr/bin/xz

/usr/bin/xz exist in both cases, same size but different timestamp: 02/12/2023 and 03/04/2025 respectively.

So I don't get the part where apt reports ... /lzma has been changed ... and ... /xz is unknown.

Edit:

I checked to see how update-alternatives read:

$ update-alternatives --get-selections | grep lzma
lzma                           auto     ../../usr/bin/xz
$ 

So it seems it is on auto and not manual, maybe apt found it had been changed?

Edit_2:

I recalled I had once seen /var/log/alternatives.log.
The printout is rather unreadable but I have tried to split it so as to see what it is all about:

$ cat /var/log/alternatives.log
update-alternatives 2025-04-06 09:30:57: run with
--install /usr/bin/lzma lzma /usr/bin/xz 20

--slave /usr/share/man/man1/lzma.1.gz lzma.1.gz /usr/share/man/man1/xz.1.gz
--slave /usr/bin/unlzma unlzma /usr/bin/unxz
--slave /usr/share/man/man1/unlzma.1.gz unlzma.1.gz /usr/share/man/man1/unxz.1.gz
--slave /usr/bin/lzcat lzcat /usr/bin/xzcat
--slave /usr/share/man/man1/lzcat.1.gz lzcat.1.gz /usr/share/man/man1/xzcat.1.gz
--slave /usr/bin/lzmore lzmore /usr/bin/xzmore
--slave /usr/share/man/man1/lzmore.1.gz lzmore.1.gz /usr/share/man/man1/xzmore.1.gz
--slave /usr/bin/lzless lzless /usr/bin/xzless
--slave /usr/share/man/man1/lzless.1.gz lzless.1.gz /usr/share/man/man1/xzless.1.gz
--slave /usr/bin/lzdiff lzdiff /usr/bin/xzdiff
--slave /usr/share/man/man1/lzdiff.1.gz lzdiff.1.gz /usr/share/man/man1/xzdiff.1.gz
--slave /usr/bin/lzcmp lzcmp /usr/bin/xzcmp
--slave /usr/share/man/man1/lzcmp.1.gz lzcmp.1.gz /usr/share/man/man1/xzcmp.1.gz
--slave /usr/bin/lzgrep lzgrep /usr/bin/xzgrep
--slave /usr/share/man/man1/lzgrep.1.gz lzgrep.1.gz /usr/share/man/man1/xzgrep.1.gz
--slave /usr/bin/lzegrep lzegrep /usr/bin/xzegrep
--slave /usr/share/man/man1/lzegrep.1.gz lzegrep.1.gz /usr/share/man/man1/xzegrep.1.gz
--slave /usr/bin/lzfgrep lzfgrep /usr/bin/xzfgrep
--slave /usr/share/man/man1/lzfgrep.1.gz lzfgrep.1.gz /usr/share/man/man1/xzfgrep.1.gz
update-alternatives 2025-04-06 09:30:57: status of link group /usr/bin/lzma set to manual
update-alternatives 2025-04-06 09:30:57: auto-repair link group lzma
update-alternatives 2025-04-06 09:30:57: status of link group /usr/bin/lzma set to auto
$ 

Thanks for your input.

Best,

A.

Hello:

You're welcome.

Yes, Hama hardware is rather notorious for not playing nice with Linux. 

One is the [ quote ] button and the other is the [ code ] button.

Post a reply - ----> [ code ] [ quote ] [ url ] [ list ] [ * ]

You hit either button and you get somehing like this:

[ quote ]
Paste quoted text here
[ /quote ]

or this:

[ code ]
Paste code text here
[ /code ]

Now you know the ugly truth.
And to first check any hardware you want to purchase for Linux compatibility.
Granted, you already had this one.

Hmm ...
No.
No such thing.   8^)

What did happen is that at some point a Linux driver that works with Hama hardware was added to your system.
But it is not a miracle, not by a long shot.
It is the work of some Linux developer out there who researched, reverse engineered and wrote it.

That said, I seriously doubt that Hama would not know about a Linux driver that worked with your hardware.
So it is a bit petty that they made no mention something that I am sure they know about.
One good reason for not purchasing Hama hardware.

One problem was probably that (no idea why) that driver was missing (?) from your system.
Another is that it does not seem to be documented properly.
eg: I was not able to find any proper reference.

But fortunately, that can be fixed.

Please boot your box with the Hama card reader plugged in and then open a terminal and do:

$ lsusb 

Please post the output now that the camera is working as expected.

Then do:

$ usb-devices

For example, when I do usb-devices with an old Genius Webcam plugged in, I find this:

--- snip ---
T:  Bus=03 Lev=01 Prnt=01 Port=04 Cnt=01 Dev#=  4 Spd=480 MxCh= 0
D:  Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs=  1
P:  Vendor=0458 ProdID=6007 Rev=50.02
S:  Manufacturer=KYE Systems corp.
S:  Product=Genius Webcam
S:  SerialNumber=Genius Audio
C:  #Ifs= 4 Cfg#= 1 Atr=80 MxPwr=256mA
I:  If#= 0 Alt= 0 #EPs= 1 Cls=0e(video) Sub=01 Prot=00 Driver=uvcvideo          # <- video driver used
E:  Ad=81(I) Atr=03(Int.) MxPS=  16 Ivl=2ms                                                           
I:  If#= 1 Alt= 0 #EPs= 0 Cls=0e(video) Sub=02 Prot=00 Driver=uvcvideo          # <- video driver used
I:  If#= 2 Alt= 0 #EPs= 0 Cls=01(audio) Sub=01 Prot=00 Driver=snd-usb-audio     # <- sound driver used
I:  If#= 3 Alt= 0 #EPs= 0 Cls=01(audio) Sub=02 Prot=00 Driver=snd-usb-audio     # <- sound driver used
--- snip ---

Please check the printout on your terminal and see what comes up.
The data you post will probably be of use to anyone with the same problem.
ie: drivers needed for this Hama hardware.

Best,

A.

Hello:

Hard to say ...  8^°

You are not explaining much here.
Please bear in mind that an incomplete question will only get you incomplete answers.

For starters:

- Is this on a desktop or laptop/netbook, etc.?
- If a laptop/netbook, under AC or battery power?

- At what point does this (sudden reboot) happen?
ie: right after it boots?, after a while using the machine?

- Can you reproduce the problem if you boot from the current Devuan 5 Live-iso?

- Under what ambient conditions?
ie: hot summer / AC turned on?, any machinery running nearby or on the same circuit?

- Exactly what are you doing with the system when this happens?
- Do you see a pattern?
- Any peripherals connected to the system's hardware?

- When did this start to happen?
eg: Any changes in OS (updates/upgrades) hardware / ambient conditions?

Start by checking the last (previous) dmesg output for any warnings.
ie: /var/log/dmesg.0 file

Also check:

/var/log/syslog and /var/log/messages -> stores all global system activity data, including startup messages.
/var/log/auth.log stores all security-related events such as logins, root user actions.
/var/log/kern.log stores kernel events, errors, and warning logs.

Best,

A.

Hello:

I looked all over and found nothing, just links to fiddling around with power management settings.  8^/

But not on how to remove the %&$# brightness service.
Which probably exists because of crappy and unreliable PM applications.

All I can say with absolute a high degree of certainty is that I had nothing to do with the brightness service not running in my Devuan Daedalus box.

Had I been aware of it, I would have tried to get rid of the damn thing ipso facto.

Like I said, monitor controls have always worked well enough for me.
As far as I am concerned, this brightness service is just another solution looking for a problem.
No wonder it is enabled by default and it will not respond to any of the the usual service commands.
ie: start|stop|restart|reload|force-reload|status which (BTW) are specified in the script. 

In any case, some update/upgrade in the long list that have worked on my file system from Jesse to Daedalus had the common sense of doing away* with /etc/init.d/brightness and leaving /etc/init.d/brightness.dpkg-dist in its place and in doing so, kept the brightness service from being loaded.

I concluded that it was probably just a name change, so I did the same thing on my headless Devuan Chimaera VM.
And achieved the same result.  8^)

Now, the service --status-all request does not include brightness.

~# service --status-all
 [ - ]  bootlogd
 [ - ]  bootlogs
 [ - ]  bootmisc.sh
 [ - ]  checkfs.sh
--- snip ---
~#

I have looked over the logs and found no error.
Is there any special place I should look?

I think we can chalk one up for basic common sense.
Because ...
Wthf does the brightness service have to do running in a headless VM?

Better yet ...
Wthf does the brightness service have to do running in any Linux by default?

Please let me know if I have overlooked something.

Best,

A.

Hello:

Have you tried using another cable or that same cable/external display combination with another source.
ie: not your laptop.

Best,

A.

Hello:

You're welcome.

Laptops sometimes have power issues with card readers.

Right.

Unfortunately, I don't have good news for you.

I was looking around this morning and it seems that your hardware, while it may work properly with MS OSs, may now need a different/specific driver module with the newer Linux kernels, it seems it did have issues with 2.6.x kernels.
Not unheard of and as we have seen, this reader does not have Linux support.

You can download the manual here: https://at.hama.com/webresources/articl … en_300.pdf

Although it does not state that Linux OSs are not supported, it clearly states:

That said, I found the official Hama site and the german language support page:  https://support.hama.com/

You will need the eight digit item number to search for the driver to download, if it is available.
It is probably on a sticker or printed somewhere in the case.

There is also a service and contact web page here: https://www.hama.com/de/de/service/kontakt-hotline
Maybe they can give you precise information with respect to your reader and Linux support.

I'm sorry I have not been able to help you further.

Let us know what you find out.

Best,

A.