I am a Linux user, but I don’t really know how most things work, even after years of casual use on my Main, I just started getting into Devuan and wondered then, what exacly does systemd do that most distros have it? What even is init freedom? And why should I care?

    • Shdwdrgn@mander.xyz
      link
      fedilink
      English
      arrow-up
      4
      arrow-down
      2
      ·
      1 year ago

      After fighting with multiple network devices today, I feel like I have a right to be angry. Checking the info in dmesg what I see is that the system initially sets up all six NICs (two on the motherboard, four on a card) in the correct order with eth* names. Then something else comes along a couple seconds later (which I assume is systemd) and renames everything to enp* NIC names. If I move the card to a different slot or install a different card with the same model then all those enp* names change to something different, but dmesg still shows their initial eth* names in the expected order before being renamed.

      “Predictable” names are anything but, and now you can’t even use the standard udev naming or even put link files under /etc/network/interfaces.d/ because all that stuff has been changed again so now I have to move all the link files to /etc/systemd/network/. I don’t know how anyone considers this a good thing when the convention keeps changing every few years and I actually have to do extra work to put the names back to what linux originally called them at each boot. Where does the madness end?

      • Greyscale@lemmy.sdf.org
        link
        fedilink
        English
        arrow-up
        1
        arrow-down
        1
        ·
        1 year ago

        There is a grub argument to pass to the kernel that disables that renaming behaviour entirely.

        • Shdwdrgn@mander.xyz
          link
          fedilink
          English
          arrow-up
          3
          arrow-down
          1
          ·
          1 year ago

          Yep I’m aware of it. Seemed like it worked for a bit, then reverted back to the enp* names. And then all the pages I was finding for manually renaming the devices said to put the files under interfaces.d for deb11 but oddly it only seemed to read those link files for a few reboots, then it would revert back to the enp names. Found something about using OriginalName because the name changes were overlapping, that worked for a few boots and then reverted back to the enp names. So then I found something about a Path statement using the full pci device names, and THAT worked for a few boots and then reverted. So now I found out that the link files have moved to the systemd/network folder so I’m waiting to see how long that lasts…

          And I realize it sounds like I’m talking about a system I’ve been running for years… I actually just put together this machine last Thursday. I had to start with Debian 9 because I couldn’t get any newer memory stick images to boot (this machine doesn’t have EUFI support), upgraded to deb10 and everything was still working as expected with the grub lines to disable renaming. Upgraded to deb11 and it all went to hell. I’m having some serious thought of trashing the machine and switching to deuvian now even though I really want to support debian.

            • Shdwdrgn@mander.xyz
              link
              fedilink
              English
              arrow-up
              2
              ·
              1 year ago

              No the changes for “net.ifnames=0 biosdevname=0” were still in there. Those worked fine for debian 8, 9, and 10 (with adjustments made in udev rules to rename eth4 and eth5 to wan0 and wan1), but neither option seemed to have any effect after upgrading to deb11. When I went searching for renaming the devices in deb11, the first several articles all stated to create link files in interfaces.d, but after all the trouble I went looking further and finally found one that referenced putting the link files in the systemd folder. I just linked the files so they are available in both locations, and that change has continued working for several further reboots so I’m crossing my fingers.

              • Greyscale@lemmy.sdf.org
                link
                fedilink
                English
                arrow-up
                1
                ·
                1 year ago

                Ah, they might have killed that option in newer kernels. Vaguely remember something about it being a temporary fix, I guess its time has come.

            • Shdwdrgn@mander.xyz
              link
              fedilink
              English
              arrow-up
              2
              ·
              1 year ago

              Uh… there’s absolutely nothing wrong with the hardware, it all works exactly as it should. It’s just systemd’s insistence on rearranging things that aren’t broken, and then changing how you fix the problems it created.

                • Shdwdrgn@mander.xyz
                  link
                  fedilink
                  English
                  arrow-up
                  3
                  ·
                  1 year ago

                  I have actually. I saw the post for their latest release earlier today and had been seriously considering switching over. This new machine is to replace my existing firewall as the old one has gone through several upgrades since Squeeze, so I’m trying to get something set up to rebuild everything from a clean installation and then I can simply swap out the hardware (and swap it back real quick if something doesn’t work right away).

            • Greyscale@lemmy.sdf.org
              link
              fedilink
              English
              arrow-up
              1
              ·
              1 year ago

              Tell that to windows sysadmins. Windows would reaaaaally like to be treated like a pet. I feel for them.