Shdwdrgn

I am running Poweredge R620 servers. With Debian 10 I had no trouble, I could reliably set my network names using udev and they came up consistently even when moving from older hardware years ago. Knowing full well that upgrading to Debian 11 would break everything, I have resisted for years, but I finally gave up and started moving forward.

After fighting for the past day with a machine, I think the answer here is going to be that beginning with Debian 11 there is simply no way to reliably name the network interfaces now.

Starting with bullseye, udev is officially dead. There are still some remaining files buried on the system but /etc/udev/rules.d/70-persistent-net.rules no longer has any effect on the network interfaces.

/etc/default/grub -- "net.ifnames=0 biosdevname=0" have been removed and update-grub run

/etc/systemd/network/ -- I created the link files such as 10-eth0.link with the appropriate MAC addresses, but because the ethX names already exist, renaming is not possible:

[Match]
MACAddress=74:86:7a:ed:f6:a3

[Link]
NamePolicy=
Name=eth0

systemctl status systemd-networkd.service -- confirmed that this service is indeed active and running

Very early in dmesg I continue to see this:

[    2.193760] tg3 0000:01:00.0 eth0: attached PHY is 5720C (10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[1])
[    2.227087] tg3 0000:01:00.1 eth1: attached PHY is 5720C (10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[1])
[    2.247850] tg3 0000:02:00.0 eth2: attached PHY is 5720C (10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[1])
[    2.263753] tg3 0000:02:00.1 eth3: attached PHY is 5720C (10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[1])

The problem here is that the ethX names are being assigned backwards. The physical plugs have other brackets in the way so what I previously used as eth0 and eth1 is now being assigned to eth3 and eth2. And despite all of the above, debian and systemd refuse to ever assign "predictable" names to any of the interfaces (nothing shows up in dmesg). I ran across some info about a "BIOSdevname" setting in the actual BIOS, but can find no such setting in the last available BIOS rev for these servers. Because the system is assigning the ethX names, I am unable to reassign the correct names using the systemd link files.

The only solution I've found to work is to use the link files and assign the interface with names like dmz0, dmz1, etc. What's the deal here and what ever happened to the concept that I should be able to set up my computer the way I want to? The udev utility was 100% reliable for all the machines I've run since it was first introduced, and now we're stuck with a system that simply can't be given alternate information? Yeah I'm frustrated and annoyed.

I don't know if anyone else has run across other possible solutions, I fought with the last box for two weeks trying to name eight interfaces in the proper order and never could find anything that would work.

I built a new firewall under Debian 12. The machine has eight network ports, and during configuration I accidentally used the same name for a couple of the ports in the files under /etc/systemd/network/*.link. I ended up with two link files referencing two different MAC addresses but naming each of them as WAN0, and once systemd got that configuration it wouldn't let it go.

From what I could find online, normally I would just issue systemctl daemon-reload followed by a update-initramfs -u and after a reboot systemd should have had the updated information... but no dice this time. The way I finally discovered the problem was when I noticed under ifconfig that my wan0 port was pointing to the wrong MAC address (even though the link files had been corrected).

After several hours of fighting with it, I finally managed to get it to work by renumbering all of my link files, and now the information for each port matches up correctly. But my real question here is WHY did systemd refuse to read updated link files? Is there another step I should have taken which was mysteriously never mentioned in any of the dozens of web pages I looked at trying to fix this? I really need to understand the proper process for getting it to correctly use these files so I can maintain the machine in the future.

(God I miss the reliability of udev already)

I'm building a new rack server (Poweredge R620) and am using the option "consoleblank=600" in the GRUB_CMDLINE_LINUX setting. During the setup I used the wrong memory stick and installed Bullseye, and screen blanking was working correctly there. Since I had already finished nearly all the configuration this week, I thought it would be easier to just do a regular dist upgrade than reloading the whole system.

After upgrading to Bookworm and rebooting, I notice that now when the screen blanking is supposed to kick in (which normally just turns off the display), I am instead getting what looks like rolling static on the screen. I have several other R620 racks running Buster so I know the screen blanking should work with this hardware, but this appears to be an issue specific to Bookworm.

Note that even when I try something like setterm -blank 1 or setterm -powerdown 1 I get the same resulting static after 1 minute. To be clear, this is specifically for the command line, I do not run desktops on my servers.

A google search for the problem has been unsuccessful so I'm hoping someone can point me to a solution or help with the proper search terms.

I'm wondering if anyone has found (free) sources of data to use for live elections results, specifically the Presidential race? I've been building a map of poll results but would also like to put something together to watch the race tomorrow night.

A 1930s-era breakthrough is helping physicists understand how quantum threads could weave together into a holographic space-time fabric.

I would love to have them light up like a scoreboard as each representative takes the floor, showing all of the commandments they have broken. If people want so badly to bring religion into politics then lets just show them exactly who they've been voting for. Maybe we can get the news networks in on this too, displaying it on the side of the screen similar to a sporting event.

Marjorie Taylor Greene, the bastion of factual information, has once again shown the nature of her character by claiming that peaceful protestors at the Capitol are in fact an "insurrection of terrorists". Don't you see all the violence and mayhem being caused in this video clip? No, me either...

If you want to make such bold comparisons, lets start out by checking how many people are running for their lives or the number of deaths involved between these two events. Or maybe we should be asking why MTG thought it was an "honor" to meet with the people responsible for murder and the attempt to destroy our democracy?

I've seen the occasional blip here, but this is the first time I've seen a complete outage of this instance. Hoping @Salamander wanders through and gives us the scoop?

I have an annoying problem on my server and google has been of no help. I have two drives mirrored for the OS through mdadm, and I recently replaced them with larger versions through the normal process of replacing one at a time and letting the new drive re-sync, then growing the raids in place. Everything is working as expected, with the exception of systemd... It is filling my logs with messages of timing out while trying to locate both of the old drives that no longer exist. Mdadm itself is perfectly happy with the new storage space and has reported no issues, and since this is a server I can't just blindly reboot it to get systemd to shut the hell up.

So what's the solution here? What can I do to make this error message go away? Thanks.

[Update] Thanks to everyone who made suggestions below, it looks like I finally found the solution in systemctl daemon-reload however there is a lot of other great info provided to help with troubleshooting. I'm still trying to learn the systemd stuff so this has all been greatly appreciated!