Broken resolvconf setup in currenty daily ISOs #142
Labels
Comments
|
Alright, we set it up in grml-live's |
mika
added a commit
to grml/grml-live
that referenced
this issue
May 29, 2020
In commit acf12d4 we got rid of /etc/resolvconf/run, and while resolvconf >=1.80 no longer uses /etc/resolvconf/run, older versions of resolvconf still use it in their libc update hook script. :-/ So while it really works e.g. on Debian/buster (as documented in commit acf12d4) with resolvconf v1.79, there's an ugly: | /etc/resolvconf/update.d/libc: Warning: /etc/resolv.conf is not a symbolic link to /etc/resolvconf/run/resolv.conf" for resolvconf versions message when invoking "dhclient". Try to avoid this. Related to grml/grml#142
clexanis
pushed a commit
to clexanis/grml-build
that referenced
this issue
Dec 12, 2022
…f resolvconf workarounds resolvconf no longer supports usage of /etc/resolvconf/run as such, instead things are supposed to live in /run nowadays. Quoting from resolvconf's debian/changelog: | resolvconf (1.80) unstable; urgency=medium | | [...] | | [ Steve Langasek ] | * Eliminate all references to /etc/resolvconf/run. This should all be done | directly in /run, there is no reason to support making any of this | configurable with a symlink since we already have a versioned dependency | on the version of initscripts that introduces the /run transition. So /etc/resolv.conf being a symlink pointing to /etc/resolvconf/run/resolv.conf no longer works, instead it needs to point to /run/resolvconf/resolv.conf. Given that our resolvconf code dates back to 2007 (see commit 1d1565d), while at it get rid of the workarounds, which don't seem to be needed anymore. Tested this change with builds against Debian/stretch (resolvconf 1.79), Debian/buster (resolvconf 1.79) and Debian/bullseye (resolvconf 1.82). Closes: grml/grml#142
clexanis
pushed a commit
to clexanis/grml-build
that referenced
this issue
Dec 12, 2022
In commit acf12d4 we got rid of /etc/resolvconf/run, and while resolvconf >=1.80 no longer uses /etc/resolvconf/run, older versions of resolvconf still use it in their libc update hook script. :-/ So while it really works e.g. on Debian/buster (as documented in commit acf12d4) with resolvconf v1.79, there's an ugly: | /etc/resolvconf/update.d/libc: Warning: /etc/resolv.conf is not a symbolic link to /etc/resolvconf/run/resolv.conf" for resolvconf versions message when invoking "dhclient". Try to avoid this. Related to grml/grml#142
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The most current grml64-full_testing daily ISO (https://daily.grml.org/grml64-full_testing/2020-01-28_05-42-13/grml64-full_testing_build3010.iso) fails to set up
/etc/resolv.conf./etc/resolv.confis a symlink pointing to/etc/resolvconf/run/resolv.confand doesn't contain any actual configuration. When invokingifdown eth0; ifup eth0an update hook even complains about it:And indeed, inside
/run/resolv.conf/resolv.confis a valid configuration present.Unclear yet, who create this wrong symlink....
The text was updated successfully, but these errors were encountered: