Re: bookworm and network connections
On Fri 01 Sep 2023 at 21:57:39 (-0400), Greg Wooledge wrote:
> On Fri, Sep 01, 2023 at 08:40:43PM -0500, David Wright wrote:
> > 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.
>
> It depends on the hardware, and how the system is going to be used.
> A built-in ethernet interface SHOULD NOT be configured as "allow-hotplug".
> It should be "auto". I'd argue that the same applies to a PCI card or
> other non-built-in but internal device. If you have to take the machine
> apart to remove the device, it's "auto".
>
> allow-hotplug is intended for things like USB ethernet interfaces, as
> you mention. They're literally hot-pluggable, and may not be present
> when the system is booted. If you're dealing with one of those, then
> by all means, use allow-hotplug for it. That's what it's for.
I think you have to include laptops, where the wifi might be built-in
but might not be switched on/unblocked at boot time. I have a laptop
with a (toggling) hard blocker. If the AC power has been disconnected
(the battery is flat), it boots up blocked, so I know to press the
toggle just /once/. If I can't remember whether it's been disconnected
or not, then I don't know whether to press the toggle. Having auto
specified in /e/n/i would make each boot a gamble.
> My gripe is that the installer has (traditionally?) used allow-hotplug for
> ALL ethernet interfaces, including the built-in interfaces on a server.
> This causes massive problems with the ordering of service initializations
> at boot. It took me a *long* time and a lot of digging to figure out why
> things were breaking, so I try to pass that knowledge along for others.
Fair enough, but I feel that setting a default that suits the naive
user with a simple one-machine setup might have weighted the choice
made by the d-i team. (I'm not sure how one divines an intent to set
up a "server" BTW.) Obviously I don't know what specific things broke
in your case, but I wouldn't call the OP's system a simple setup.
Cheers,
David.
Reply to: