Hello:

Check here: https://discussion.fedoraproject.org/t/ … own/124911

TL;DR
Disable the “Wake on LAN” option in the BIOS.

If that does not work, check this link where you will find many hits with posts by people having the same issue.

Sometimes, Google can be a friend. 8^°

Best,

A.

Hello:

As you have seen, the difference in perfomance is huge.

And there is basically one main motive for this being so.

Best,

A.

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.