Makes perfect sense, and your idea is more elegant to ensure it doesn't get clobbered via the user-intervention you mentioned.

For the lease files I added /var/lib/NetworkManager/*.lease to both the snapshot and installer excludes files, cleans 'em when you snapshot and cleans the one generated during the live-session too, so first boot into the installed system will only generate one new correct one tied to the new connection file.

I added lines to clean out the dbus/session-bus files too, the new init script I use cleans them at shutdown anyway but still didn't see a point in letting old useless files from the live-session get into the new install.

Okay, two folders at issue here:

/etc/NetworkManager/system-connections/(connection files i.e. "wired connection 1" "*.nmconnection", either way is valid)
If NM is used to create either an ethernet or wifi connection, it will append it with the ".nmconnection" and place it in this folder.

/var/lib/NetworkManager/*.lease file(s)
This is where the lease files appear, wlan0.lease or eth0.lease.

Your .nmconnection file was created by NM at some point, and was tied to a single specific .lease file, this is what you want.

If on boot, NM does NOT find a connection file in etc/NM/ system-connections, it will generate a new .lease file, but NOT a new connection file, so it will keep doing this every boot. You'll always connect just fine, but you'll also get neverending new .lease files every boot.

This only becomes a thing if at some point your eth0 connection file gets wiped out in /etc/NetworkManager/system-connections, such as when doing a snapshot that excluded those network files. We just need to put one back into the new system on install. Or the user can do it manually with some simple commands in terminal and force NM to make a new one. This just seemed more elegant.

To test, now that you moved that connection file, go count your /var/lib/NetworkManager/*.lease files, then reboot a couple times, you'll have new ones each time.

I can see the difference as it boots on the partitions i've fixed, the NM applet used to blink and hang up a bit before appearing in the panel, now it's just flick and it's on. I think I can lower my conky delay now, lol.

So I tried the modded script and it worked perfectly, no more .lease file bloat! I also fine-tuned the excludes files for both snapshot and installer to exclude the .lease files and also the  dbus session-bus files on both, they all get auto-genned both in live-session and in a newly installed system, so this way you get a perfectly clean new install with no extra old files hanging around.

My bad, sorry. Yeah, my guess is you're missing the mediatek firmware package I mentioned, the misc firmware package got updated and the new one no longer has the mediatek and ralink firmware in it that it used to have.

Well dang, it worked! Used some script to create a new system-connections file, a basic one for eth0 only (wi-fi doesn't have issues), and now the system is using it and not genning new .lease files at every boot!

So I am wondering if this can be added to the Refracta Installers post-install script (cleanup-install.sh) so a new one will be created on a new install, worked great in a local install. So here's how I think cleanup-install.sh would look with this proposed addition:

#!/usr/bin/env bash
# cleanup-install.sh

# You can add other commands here that you want to run at the end of 
# the installation process, before script self-cleanup (while the
# installed system is still mounted.)
#
# Anything you add must come before the "exit 0"

# Send errors to the installer's error log.
error_log=$(grep error_log /etc/refractainstaller.conf | cut -d"\"" -f2)
exec 2>> "$error_log"

# This removes the installer icon from the desktop upon installation.
for file in /target/home/*/Desktop/refractainstaller.desktop ; do
	rm -f "$file"
done

# Create a generic eth0 system-connections file for NetworkManager
tee /target/etc/NetworkManager/system-connections/Wired\ connection\ 1 << EOF
[connection]
id=Wired connection 1
uuid=$(uuidgen)
type=ethernet
autoconnect=true

[ethernet]
auto-negotiate=true

[ipv4]
method=auto

[ipv6]
addr-gen-mode=stable-privacy
method=auto
EOF

# Set appropriate permissions for the connection file
chown root:root /target/etc/NetworkManager/system-connections/Wired\ connection\ 1
chmod 600 /target/etc/NetworkManager/system-connections/Wired\ connection\ 1

exit 0

What say you?

Off your meds again Igor?

Really appreciate the info @grunchy! I only have Mate and Openbox here to test on.

Dbus really gets around it seems.

So looks like whatever display manager is used, a folder is created in /var/lib/(display-manager)/.dbus/session-bus/*

But i'm still trying to figure out what purpose it serves and how they got there, after logging in and out of that partition multiple times yesterday, that folder was not added to by the system, still just 21 files that all show they were created when I started a snapshot last week.

The init script is working perfectly it seems, several days of testing now and no issues.

To clean /var/lib/(display-manager)/.dbus/session-bus/* in a similar fashion would take some extra work, have to list all available display managers, there's not that many but still.

And now I just found in /var/lib/NetworkManager some 181 files, 5 of which are config/info files of one sort or another, and all the rest are eth0-lease files, and all of those say they were created at the exact same time I started that snapshot last Wednesday.

So 176 files that all do the same thing, sample filename and it's contents:
internal-f368e190-5bd0-37e6-b42d-75f71b63df1d-eth0.lease

# This is private data. Do not parse.
ADDRESS=192.168.2.5

On a new Devuan install there shouldn't be an /etc/machine-id, so that seems correct.

I don't even have that folder on my Daedalus installs, just ~/.dbus/session-bus/, perhaps somebody has renamed it in Ceres.

Sonofagun...nice find! I wonder if we can safely delete those on shutdown as well?

Interesting...much smaller accumulation of files in there than was in the other two folders.

Curiouser and curiouser...on my build partition where I make and snapshot Vuu-do, there are 21 files in that folder, and according to the properties tab, every single one of them was created at the same time, date, hour, even down to the same second. And that was last Wednesday the 17th at the exact same time a snapshot of Vuu-do (mini-ob-z) was started, but off by exactly an hour (that may be a daylight savings time discrepancy).

@fsmithred, this seems strange, no?

The other partitions have some files as well, but the dates are not all the same.

Looks like from the screenshot that you are using the default (card 0) which is your headphones, when what you want is card 2, should be as simple as changing the card number in your ~/.asoundrc to 2 instead of 0. (Assuming you have that file, if not you may need to make one.)

I noticed it mentions "Broadcom Mixer", that I am unfamiliar with. If it's a genuine mixer, then it likely has control of alsa starting with boot-up, in which case the alsamixer will likely only be good for adjusting main volume. But perhaps that's just something local to the headphones.

Shucks...thanks my friend for the kind words! And right back at you, it wouldn't be the same around here without you.

So I tested the script, installed it into another partition running Vuu-do openbox-mini and shutdown/rebooted multiple times and it's working perfectly so far. Seems like a nice workaround that preserves Devuan's unique functionality in this area.

vuudo rm-machineid: dbus session-bus cleanup: removing session-bus files
vuudo rm-machineid: Cleaned /root/.dbus/session-bus
vuudo rm-machineid: Cleaned /home/vuudo/.dbus/session-bus