On Fri 01 Sep 2023 at 17:38:48 (-0400), Greg Wooledge wrote: > On Fri, Sep 01, 2023 at 03:18:47PM -0600, D. R. Evans wrote: > > [[ I speculate wildly that systemd or something doesn't complete configuring > > the network until after rc.local has finished processing (I know that > > rc.local executes late in the boot process, but I don't think that that > > means that everything else has *finished* executing when rc.local runs). I > > may easily be wrong, but really I don't think I care. ]] > > On Debian, there's an override file: > > unicorn:~$ cat /usr/lib/systemd/system/rc-local.service.d/debian.conf > [Unit] > # not specified by LSB, but has been behaving that way in Debian under SysV > # init and upstart > After=network-online.target > > # Often contains status messages which users expect to see on the console > # during boot > [Service] > StandardOutput=journal+console > StandardError=journal+console > > > The "After=network-online.target" line is supposed to ensure that > rc-local.service doesn't run until the network configuration has been > completed. However, the definition of "completed" here can be murky. > In particular, when using /etc/network/interfaces, only interfaces that > are marked as "auto" need to be up, to satisfy this criterion. An > interface that's only "allow-hotplug" isn't required to be up. > > Also, since the issue here involves network configuration, it would > seem counterintuitive to expect it to be done in a service that runs > *after* the network is supposed to be up.
I don't see that the OP is doing anything complicated that requires rc.local to run at all. They just need to distinguish between the two interfaces, and then configure them in a conventional manner. A .link file and the ifupdown package should be able to cope with that. (I haven't used the buster-onwards interface matching/renaming facility myself, which could replace using the .link file.) On Fri 01 Sep 2023 at 18:33:51 (-0400), Greg Wooledge wrote: > On Fri, Sep 01, 2023 at 04:16:46PM -0600, D. R. Evans wrote: > > Greg Wooledge wrote on 9/1/23 15:38: > > > > > In particular, when using /etc/network/interfaces, only interfaces that > > > are marked as "auto" need to be up, to satisfy this criterion. An > > > > I don't think that debian has used used /etc/network/interfaces for a while, > > at least not by default. Certainly there's nothing useful there on the > > machine that I just upgraded and whose networking is failing to configure > > itself correctly. > > > > Network Manager -- I think -- uses some completely different mechanism for > > managing networking (although I have no idea what that mechanism is.) > > Debian *absolutely* uses /etc/network/interfaces. By default, in a > Standard installation. But as you noted, it's optional. Debian *also* > allows the use of Network Manager, systemd-networkd, and probably several > other systems for configuring one's network(s). > > I haven't installed Debian 12 yet (upgraded to it, but haven't installed > it), but I did a Debian 11 install yesterday. And I can assure you, > that system uses /etc/network/interfaces just like every other Debian > system I've ever run. I used a Standard install, then booted it to > confirm that all the necessary firmware was present, and then installed > KDE (among other things). I don't know whether N-M is installed on > that system -- I didn't check -- but it doesn't matter, because the > machine's sole ethernet interface is configured in /e/n/i and therefore > N-M would skip it. Installing bookworm (standard packages, no DE) installed and configured ifupdown as per usual here. > Returning to the previous topic, I have no idea how > After=network-online.target interacts with N-M. I have experience with > network-online.target vs. /e/n/i and its absurd "allow-hotplug" default > setting, but I don't use N-M so I don't know how that works. I know you have a low opinion of allow-hotplug, but I can't see that auto/allow-auto is necessarily better for the naive user that doesn't install a DE for whatever reason. AIUI auto gives you a one-shot attempt to start the network at boot time, and if that fails for any reason (eg USB not yet plugged in/ not detected/hardblocked on/etc), you get a long timeout before the login prompt, and may have to reboot to get it to attempt again. OTOH allow-hotplug gets you to a login prompt as normal, without the network being up, and then rectifying the problem makes ifupdown/udev automatically have another go. Cheers, David.
