16:13:06 
 protocol="application/pgp- 
 org 
 From: dxld@darkboxed.org 
  
 Hi Thorsten, 
  
 On Thu, Oct 23, 2025 at 08:48:34PM +0200, Thorsten Glaser wrote: 
 > >> I’ve never seen inet6 auto used anywhere, only inet6 static (and 
 > >> I’ve not personally encountered inet6 dhcp yet, and given rtadvd 
 > >> and rtsol work, I don’t quite see the use for most networks). 
 > > 
 > >Strange, given that this is what d-i will produce by default -- if the 
 > >installation network has IPv6 RAs at least. 
 > 
 > As of which release? ;-) 
  
 Quite a while ago: 2002 AFAICT from a quick look at d-i/netcfg git logs. 
  
 Happy to be proven wrong, but for now I'm going to continue assuming inet6 
 auto lines should be the norm in typical Debian installations. 
  
 > [...] I’ve since switched away from d-i to just debootstrap plus a small 
 > shell script that does what d-i does to the installed system (except it 
 > doesn’t copy the live CD’s network config), as has been a growing trend 
 > among (at least) Grml enthusiasts for years. 
  
 It falls on you to keep up with system changes then. Hope you're an avid 
 NEWS reader :-). 
  
 > >IMO if you need to make changes that deep it's alright to have to go to 
 the 
 > >dhcp client config files to do it honestly, unless you disagree? 
 > 
 > I find “hands off my resolv.conf” (the standard config tends to not 
 > change the system hostname, domain and timezone, but since I saw this 
 > in the manpage I added it) is the one single change to DHCP client 
 > configuration I need in most places where I need any. This could also 
 > be handled by the hooks or something, but if there isn’t any mechanism 
 > for this at the moment, don’t lose any time for this, the other issues 
 > are more important. 
 > 
 > Just I don’t consider “hands off my hostname, domain and timezone” 
 > something I should even *have* to specify, and “hands off my resolv. 
 conf” 
 > the one useful high-level toggle here (defaulting to write it is okay, 
 > but perhaps I run a recursive resolver myself and have that in the conf). 
  
 I think all of these we could pass overrides down to dhcpcd from ifupdown 
 if we needed to (--nohook/--nooption), but AFAIK the system defaults are 
 alright currently. Testing welcome. 
  
 > >> Note that it could also be started from /etc/init.d/dhcpcd, so 
 > >> ordering there also needs to be correct. 
 > > 
 > >Naturally, but I do think that should also be possible. I'm just not 
 > >familliar with sysvinit's ways. 
 > 
 > Yes, I was just pointing out that not everyone uses systemd. 
 > An X-Start-Before: in the LSB pseudoheader should suffice, but 
 > the debian-init-diversity mailing list is available to help, 
 > once you have a concrete setup. 
  
 Thanks for the hint on which pseudoheader to use! I'll see to it Martin 
 makes that change along with the systemd service fix if we end up going 
 that route. 
  
 > >> Likely not going to happen, as it has no security support. 
 > > 
 > >Well given that we've shipped isc-dhcp-client in Trixie already without 
 > >properly moving all users over that ship has kinda already sailed. Now we 
 > >have to support it. See #1106121. 
 > 
 > It’s not the first package we ship in a stable release for users’ 
 > convenience that has no support. (And it allows people to decouple 
 > “upgrade to trixie” from “switch to kea”, as kea in bookworm was… 
 > not quite ready.) 
  
 Right. I do think switching to dhcpcd is the right long term solution 
 anyhow. My preferred solution is porting the fixes to Trixie too, I'm just 
 not sure whether the needed changes are "small" enough for a stable update 
 at this point :D. 
  
 > >If we remove the release-notes notice at least fewer users might try to 
 > >switch and consequently run into problems. Idk. if that'd really be a 
 > >good idea its just a thought. 
 > 
 > If the SRM agree and you manage to get this fixed in sid, I’d like 
 > for the fixes to end up in trixie, so less people run the unsupported 
 > software (and it’d look bad for Debian if we recommended people to 
 > stay on it for one more release, when the client is already… four? 
 > years dead upstream). 
  
 Its looking plenty bad already :-(. 
  
 > >Eeeeerm. Well. I've seen dhclient crash mysteriously after long runtime 
 > >leaving systems without IPs somehow. So that's not a sure bet 
 > 
 > How? If it crashes it won’t remove the currently working IPs. 
  
 You (and me) would think so! Somehow that's what the systems ended up 
 looking like. I didn't check logs at the time unfortunately and switched to 
 dhcpcd since, so I have no clue if it's still happening. I'm watching bugs 
 on isc-dhcp so we'll see if anything crops up. 
  
 My theory is the crash happened just after a lease expired which would take 
 the IPs/routes with it. Perhaps the ISP took a (long) while to do 
 maintainance on their DHCP server. If dhclient crashes as it's trying for a 
 new lease you'll be left with a system without IPs and no DHCP client 
 running and no mechanism that would restart it. Sad face. 
  
 > But at least IPv6 will still work in that case, as it’s kernel- 
 > managed ;) (see above…), so it’s recoverable. 
  
 IPv6 win, nice. 
  
 > >Thinking about this some more I may consider requiring `inet6 auto` in the 
 > >future for this configuration, but not without a proper transition and 
 > >ample notice. 
 > 
 > That directly contradicts what you wrote above. That would mean 
 > ifupdown would break kernel defaults without the user explicitly 
 > asking for it, by merely the user specifying IPv4 configuration. 
 > 
 > This will be a net loss because at the moment, IPv6 “just works” 
 > with no configuration for many people because of the kernel default, 
 > and this should not change to the worse. 
  
 Let me expand on this a bit then since it doesn't seem to be clear. 
  
  
 [continued in next message] 
  
 --- SoupGate-Win32 v1.05 
  * Origin: you cannot sedate... all the things you hate (1:229/2)