Hello:

I beg to differ.

The only Debian packages compatible with Devuan are the ones you will find in the Devuan repositories.
No consideration needed, it has already been considered by our devs.

Now ...
If you see a package in the Debian repositories but not in the Devuan repositories it is either because a) it is being sanitised* or b) because it is not compatible due to systemd requirements.
* something which can be a truly time consuming endeavour for our devs.

Then you have *.deb packages which are not in the Debian or Devuan repositories.
In all probability, there are very sound reasons for that being so.

Those are the ones that "shouldn't be used without careful consideration" or not at all.

Just my 0.02.

Best,

A.

Hello:

Sorry to see it did not work out.

Q: is the data you need to send your brother really the type of stuff that needs your using a veracrypt solution?

You may want to consider doing something simpler, more straightforward.
eg:
.tar.gz compression which MS stuff can handle for the directory where all the files are located and then 7zip to encrypt and PW protect.
A strong PW and AES-256 should suffice.  8^°

That ^^^ or something similarly simple.

Best,

A.

Hello:

Thanks for the data.
I was wondering about the apparent slow write speed.
But then I realised you did not mention how many hours. 8^°

Glad you sorted it out.

Best,

A.

Hello:

Yes,
That is what it seems to me also.

Best,

A.

Hello:

Nah ...
It was a fluke.

Probably remembered to take the green one this morning.
Or was it the red one? Can't recall.

That said, what's wrong with the proven and reliable chroot that it now has to have such a useful feature?
It never ends, does it?

Best,

A.

Hello:

Yes, it is.

But it is a local privilege escalation and (for now) it only affects sudo 1.9.14 to 1.9.17.

See here: https://gbhackers.com/poc-published-for … e-to-root/

I wonder what happened to do one thing and do it well?

That said, my up-to-date Devuan Daedalus (and yours) runs 1.9.13p3:

$ apt list | grep installed | grep sudo
--- snip ---
sudo/stable,stable-security,now 1.9.13p3-1+deb12u2 amd64 [installed]
$ 

So ...
Stay the course, everything wil be back to normal soon.

Best,

A.

Hello:

And now ... 
A side-note to a side-note.  ; ^ )

I have a Devuan Daedalus VM I can run (for experimental / testing purposes) on my Devuan Daedalus box.
It is the bog-standard image from the download repository and I can log in (via SLiM) as root:

# whoami
root
# 
# uname -a
Linux daedalus 6.1.0-37-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.140-1 (2025-05-22) x86_64 GNU/Linux
# 

My box works the same way.
I have no issue with that, just have to take the necessary precautions.

That said, I have never (ever) needed to do it.
I have specific sudoers entries for all-things I allow as sudo.

Best,

A.

Hello:

They may have moved somewhere less conspicuous.
ie: hidden it

Or maybe it has become a part of the systemd OS.

I don't have one in my Daedalus system: I deleted it.
No issues.

That one you can delete.
If what we have seen up to now holds, the system behaviour should be that the -0 file gets overwitten at boot.

Best,

A.

Hello:

Without knowing anything much about how/why this happens, what I have observed is that, wherever it is that a */.dbus/session-bus/ directory is located*, stale files remained.
ie: stale in the sense that they are session-id files belonging to previous sessions.
* /root, /home/user, /var/lib/lightdm or anywhere but /tmp

This is something that has (evidently) been happening for the longest while and gone unnoticed, never before reported as an anomaly.
A bug? Most probably.
A feature to track previous dbus sessions?
If so, to what practical end?

It is definitely related to installations with some sort of desktop or WM.
eg: my 1000HE runs a dated Devuan (5.10 kernel and Openbox) and when I went to look I found a staggering amount of stale files going back to 2017, which I promptly nuked.
Now, with @greenjean's script, that does not happen any more.
My headless Chimaera VM does not have a */.dbus/session-bus/ directory.

All this to say that this looks like a dbus problem albeit (most probably) related to systemd.

Just a guess, a possibly educated one.

Best,

A.

Hello:

Done.
From what I can see, works as advertised.  8^)
Logs to /var/log/user.log.

--- snip ---
Sep 19 18:28:03 devuan shutdown[11658]: shutting down for system halt
Sep 19 18:28:03 devuan rm-machineid: dbus session-bus cleanup: removing session-bus files
Sep 19 18:28:03 devuan rm-machineid: Cleaned /root/.dbus/session-bus
Sep 19 18:28:03 devuan rm-machineid: Cleaned /home/groucho/.dbus/session-bus
--- snip ---

Good job.

Best,

A.

Hello:

That certainly would not be me, so I cannot comment on it save to say that logging is a great idea.

What I can comment on, without any reservation, is your commitment to getting the problem solved.
And extend a heartfelt thank you for all the work you have put into doing so.

Kudos to you.

Best,

A.

Hello:

No, I get it.
The machine-id is used by .dbus.
The problem was having a fixed one, so I nuked /etc/machine-id.
Now I get a different one after every boot.
Which is what the patch mentioned in the ASCII release notes was for.

root@localhost:~# cat ~/.bash_logout
rm -f ~/.dbus/session-bus/*

Right.
That would (?) purge the random generated machine-id at every shutdown, solving the problem of the accumulation of files in ~/.dbus/session-bus.

But ...
That it is not what I see in my Daedalus installation:

$ cat ~/.bash_logout
# ~/.bash_logout: executed by bash(1) when login shell exits.
# when leaving the console clear the screen to increase privacy

if [ "$SHLVL" = 1 ]; then
    [ -x /usr/bin/clear_console ] && /usr/bin/clear_console -q
fi
$

[root@devuan ~]# cat ~/.bash_logout
cat: /root/.bash_logout: No such file or directory
[root@devuan ~]# 

^^^^ same as /etc/skel/.bash_logout

Maybe manually adding the script would do it?

There is a thread here at Dev1 related to ~/.bash_logout:
https://dev1galaxy.org/viewtopic.php?id=5559

Now, if this is right and agetty clears the screen by default, ~/.bash_logout would not be needed?

Thanks for your input.

Best,

A.