Hi All!

Thanks for the answers.
I have had many changes, at least after removing mate, then re-installed xfce
(was no able to switch between desktops) and finally lightdm, due to fast user-switching.
For me, the mentioned variant using "defaults" was not working, but

update-rc.d lightdm disable

The question came up, because I do not understand the starup sequence for the desktop.

Thanks and solved,
Manfred

Hi!

Thanks for your investigation.
Not sure, if bridge-utils are really need, but I use them because its an easier way then "ip-link".
I usually use 'ifquery' ether with '--list' or '--state' but it does not show my second bridge, even
though 'ip link' shows it.
I know the problem with the member ports and on my current workstation the solution was to
give it a dummy address ("0.0.0.0"). The bridges are for containers and LXC, so there is no
definitiv port at computer start - which was never a problem to me.
But there is "/etc/network/if-pre-up.d/bridge -> /lib/bridge-utils/ifupdown.sh*"
which should solve the problem (that ip link is not persistent) and read "interfaces".
I have two comparable computers (hardware and VM), both Devuan5. If I look into /var/log/boot:

Starting: AppArmorLoading AppArmor profiles...done.
Configuring network interfaces...if-up.d/mountnfs[eth0]: waiting for interface eth1 before doing NFS mounts ... (warning).
invoke-rc.d: could not determine current runlevel
if-up.d/mountnfs[eth1]: waiting for interface lanbr before doing NFS mounts ... (warning).
invoke-rc.d: could not determine current runlevel

Note: waiting for interface lanbr ....
I am even not capable to write everthing, I saw. But a internet search for

Exactly this is part of my experience, were the bridge and even sometime
a hardware inferace shows this strange status!
This earch gives tons of similar messages, a hint of apparmor bug, of Kernel 6.1 bug and more.
You remove a VF from a dual-nic and suddenly, the other(!) port does not get carrier! I changed the NIC with the exact same from another computer (shown in the log-excerpt above) with not changes and the other box does not have that problem.
The whole story started with unexpected behavior of a kvm-guest, which had no traffic. But then I made the same, step-by-step on this host itself (create bridge, create macvlan) and everythings works - repeated this using LXC, works.
I made a port mirror on the hardware-switch - no packages came out, if the VM runs ..... but you see the packets on the host.
Something drops them. Due to the probability, this could be some of the "same subnet" things, I used a complete different, 10.10.10. ... (have enough free port on other computers). No change.
Now I removed systemtap, xtables-common, libvirt*, qemu*, xrdp, x2go, xfce4. Upgraded to kernel 6.5 - no changes.
There is no wait-message for the bridge and the assigned interface does not become member (can be done manually, after login). Even "/etc/network/interfaces.d/" is not read (was successful with: "/etc/network/if-pre-up.d/lanbr"
(my script with name of the bridge - but the membership problem remains). So the bridge can be created, but get no member ports.
Time to reinstall and hope.
I remember, what was the first fault on this box:
On shutdown, after the first boot (zfs on root), installed the usual way using chroot (like one of the other
boxes from the logs above, were the same things works), I got:
~ "cannot unmount /var/log" .....

Thanks anyway and
best regards,
Manfred

Hi!

LXC is not debootstrap and is intended to install containers for
different OS, like Ubuntu, Arch etc.
Thanks to @fsmithred's:

ln -s ceres daedalus

it works like a charm now (at least setup, not configured and runned it).
So the messages about "NN signatures not checked due to missing keys"
may be a conseqence of the missing reference.

Anyway, regards,
Manfred

Hi!
Thanks!

This is nearly, what I usually do (have only SSHD and some networking tools - I usually keep this as
a bootable installation on first partition as "repair-inst", with the same version of ZFS which I'll use
to setup zfs on root (onto anohter disk). Using ether netinstall, or, naturallay, for zfs on root the
debootstrap tool, how it is described. One different thing is, that I first install DKMS separately and
the wanted kernel with headers.

And you describe exactly ("image1"), what I am experiencing. What you see

is a dependency problem, which left a part uninitialized, which becomes "repaired" if you repeat the
step - independently, that you' made it a little differently (which is not neccessary, because all this
is in dependencies).

I have the (already) described problem with shutdown. If I add pools, they dont have a problem
and working properly like your's.

But I am not keeping installations, which have improperly behavior on stutdown (or startup).
For my ZFS-VMs (which are KVM/QEMU), I initiate a shutdown from inside and keep the
mouse-pointer (on the host) on the pause button, which I press at the moment, the red errorline appears.
On a new hardware, this is the same - but I cannot stop the display .... and they dont appear in logs,
and for my other cases, it is theit is the root-filesystem on unmount!

My older (and running) installations dont have errors or this behavior.
On my day-work machine (which ist Debian Bullseye, ZFS on root), no errors appear, wether
at startup or shutdown (and even my fileserver, staying on Debian Buster, ZFS on root, is error-free).

The 2.4 version (in backports), which I need due to the block-copy feature, is even crashing
hard at shutdown.

Usually, zfs-setup is easy (except for on root) and causes no errors - I am using it since
2012 (not on root at that time).

Regards,
Manfred

Thank you very much!
--br,
Manfred

Hello All!

Thanks, @fsmithred!
I followed this advice, event though it shows another theme!
My problem was not old/new naming convention, but changing interface names between boot - not daily though
and a quick reboot is not an answer. But I looked at this kernel commandline option and it seems not to have any effect!
But I found 70-persistent-net.rules, something, I've not regarded before.
Astroundingly, the mapping, applied in this file, does NOT fit the reality completely, there is an exception for one interface.
Then I changed the rules/names, but the problem persists. Then I enabled udev debug logging and saw, that the interface,
which hasnt followed the rule, was renamed two times: From eth0 to eth2, the from eth2 to eth3.
"Predictbale interface names" .....
Anyway, which kernel commandline applied.
Additionally, I found, that there COULD be "net.naming-scheme=v250", according to this thread:
udevd produce same ID_NET_NAME_SLOT for different NIC, so break rename #28929 :
https://github.com/systemd/systemd/issues/28929
But from this thread, I found a hint: "udevadm test-builtin" and I used it like this:

$ udevadm test-builtin net_id /sys/class/net/gif0 (where gif0 is now my 10GbE-IF)
calling: test-builtin
=== trie on-disk ===
tool version:          3
file size:         9709412 bytes
header size             80 bytes
strings            2419020 bytes
nodes              7290312 bytes
Load module index
ID_NET_NAME_MAC=enx001999c13f23
ID_OUI_FROM_DATABASE=Fujitsu Technology Solutions GmbH
ID_NET_NAME_PATH=enp4s0f0
Unload module index

This <enp4s0f0> (under: ID_NET_NAME_PATH) is probably the original IF-name and could explain, why
the "70-persistent-net.rules" cannot work:
ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth3" - because they trigger (not!) on interface
names, which do not exist?
After I enabled udev debug logging, I have to look deeper at systemstart in the next days.
So wether "net.naming-scheme=v250" nor "net.ifnames=1" made something!
To udev logging: The shown output ("=== trie on-disk ===") appears in LSPCI too:

08:00.0 Ethernet controller: Intel Corporation I211 Gigabit Network Connection (rev 03)
=== trie on-disk ===
tool version:          3
file size:         9709412 bytes
header size             80 bytes
strings            2419020 bytes
nodes              7290312 bytes

at the end of the list of network cards.

For the moment, I choosed a completely different set of names (eno0 for MoBo-IF, eif<N>
for the ethernet (better: 1Gbe) and gif<N> for the 10GbE interfaces. And these coming - at least
for the moment - up with exactly this names without any problem.

The drama will probably start, if I now start setting the "sriov_numvfs"
variable to get man VFs (asked a question in another part of this forum).