Hello:

Indeed.
As it should be.

This provided that the package installed (like the printout you posted shows) actually comes from the Devuan repository.

Like I pointed out, the problem* posted by kapqa (not related to the original post) would seem to indicate that the package installed may not be from the Devuan repository.    * printout points to a typical error in Linux systems using systemd.

That said, note that the link posted leads to a Debian open-iscsi wiki page. 

@kapqa
You may want to consider opening a separate thread with your problem and start by posting the terminal printout from this:

$ uname -a

$ cat /etc/apt/sources.list

$ apt list | grep -i installed | grep -i open-iscsi

Best,

A.

Hello:

Crikey !... 
Seems espresso had not kicked in yet.

But not a proper excuse though.

The thing is that I'm just lowly hack who most always finds the answers to difficult stuff under the same two names.
ie: fsmithred / ralph.ronnquist

Yes, that's the best (true one) I can come up with.  8^D

Best,

A.

Hello:

There is no viber package in the Debian repositories.

As a result, there is no viber package in the Devuan repositories either.

The reason being (most probably) that viber is "Proprietary cross-platform IM and VoIP software".

With respect to it working on Arch, bear in mind that the package in queston is part of their user repository ie: not an official AUR package.

Seems that none of that has changed in the last three years.

Best,

A.

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.