[SOLVED] slackware64-current (aug. 9th 2015) dhcpcd No such file or directory

lemurian · 08-09-2015, 06:50 AM

Hi all,

After an update of slackware64-current I'm having an issue with dhcpcd.

During boot i get this message:

Code:

cat: /run/dhcpcd/dhcpcd/resolv.conf.wlan0.ipv4ll no such file or directory

The network connection is wlan0 wifi with wpa.
I do have network access but, as can be expected with resolv.conf issues, no DNS.

Running dhcpcd --rebind "fixes" the issue.

I have no idea where to start looking for this.
Although looking at the strange file name in the error, I would guess some script variable getting messed up.
I've had a look at dhcpcd.conf, rc.inet1, rc.inet1.conf but I failed to find anything querrying /run/dhcpcd/dhcpcd/

Kind regards.

lemurian · 08-09-2015, 09:15 AM

Issue mentioned here too:
https://www.linuxquestions.org/quest...as-4175550242/

I've build a package from the dhcpcd-6.8.2 source and the issue is gone.

Forgot to mention I'm using neither NetworkManager nor wicd.

dr.s · 08-09-2015, 02:12 PM

Same issue here, same fix.

Alien Bob · 08-09-2015, 04:39 PM

Should be fixed in the latest update:

Code:

n/dhcpcd-6.9.1-x86_64-2.txz: Rebuilt.
       Recompiled with --rundir=/run.

hotchili · 08-09-2015, 06:57 PM

Quote:

Originally Posted by Alien Bob

Should be fixed in the latest update:

Code:

n/dhcpcd-6.9.1-x86_64-2.txz: Rebuilt.
       Recompiled with --rundir=/run.

Something is still wrong with this one imho.
I just tried it in a virtualbox vm and often end up with empty /etc/resolv.conf after boot (but not always which is the weird part)
Config dhcp via rc.inet1.conf, no networkmanager or wicd.

I try a few more reboots to see what happens ... 10 reboots later:

Code:

 1 ok
 2 fail
 3 fail
 4 fail, but resolv.conf is not empty, contains one line:
   # /etc/resolv.conf.tail can replace this line
 5 fail
 6 fail
 7 ok
 8 fail
 9 fail
10 fail

Some more shitty testing calling /etc/rc.d/rc.inet1 stop & start 30 times:

Code:

# for count in $(seq 30); do (/etc/rc.d/rc.inet1 stop && sleep 10 && /etc/rc.d/rc.inet1 start) >/dev/null; grep "nameserver 192.168.2.1" /etc/resolv.conf >/dev/null && echo "resolv.conf: OK" || echo "resolv.conf: FAIL"; done
resolv.conf: OK
resolv.conf: FAIL
cat: /run/dhcpcd/resolv.conf.eth0.ipv4ll: No such file or directory
resolv.conf: FAIL
cat: /run/dhcpcd/resolv.conf.eth0.ipv4ll: No such file or directory
resolv.conf: FAIL
cat: /run/dhcpcd/ntp.conf.eth0.ipv4ll: No such file or directory
resolv.conf: OK
resolv.conf: OK
resolv.conf: OK
resolv.conf: OK
resolv.conf: OK
resolv.conf: OK
cat: /run/dhcpcd/resolv.conf.eth0.ipv4ll: No such file or directory
resolv.conf: FAIL
resolv.conf: OK
resolv.conf: OK
resolv.conf: OK
resolv.conf: OK
resolv.conf: OK
resolv.conf: OK
resolv.conf: OK
resolv.conf: OK
cat: /run/dhcpcd/resolv.conf.eth0.ipv4ll: No such file or directory
resolv.conf: FAIL
resolv.conf: FAIL
resolv.conf: OK
resolv.conf: FAIL
resolv.conf: OK
cat: /run/dhcpcd/resolv.conf.eth0.ipv4ll: No such file or directory
resolv.conf: FAIL
cat: /run/dhcpcd/ntp.conf.eth0.ipv4ll: No such file or directory
resolv.conf: OK
resolv.conf: OK
cat: /run/dhcpcd/resolv.conf.eth0.ipv4ll: No such file or directory
resolv.conf: FAIL
resolv.conf: OK
resolv.conf: OK

Seems that works more often but still fails sometimes.

I downgraded my main system to dhcpcd 6.8.1 and problem is completely gone there.

gordydawg · 08-09-2015, 10:20 PM

Had similiar issues with dhcpcd in slackware64-current (08/07/2015)

Tried different things, dhcpcd --bind didn't work across reboots. And in the end, I downgraded dhcpcd to 6.8.2 using the same source build in current.

As in many things, sometimes the latest software version tends to break things.

I seem to recall a similar issue with dhcpcd popped up in slackware 14.1 release candidates. And in the end, patching had to be done in dhcpcd before release.

lemurian · 08-10-2015, 04:35 AM

Hi Alien,
Thanks for the quick reply.

The new package dhcpcd-6.9.1-x86_64-2 actually made it worse. :-)
Now dhcpcd gives a "timed out" notice during boot plus the "dhcpcd --rebind" workaround results in:

Code:

cat: /run/dhcpcd/dhcpcd/resolv.conf.wlan0.ipv4ll no such file or directory

kind regards.

lemurian · 08-10-2015, 04:53 AM

[Duplicate post, sorry]

rdsherman · 08-11-2015, 12:58 PM

More problems with dhcpcd v6.9.1 build 1 or 2 and never seen in prior releases.

If rc.inet1 is launched from rc.M, as is standard, there is, after login, NO connection to the internet via eth0 nor wlan0. All the logs to stdout and messages appear correct, except the spurious absence of /run/../resolv.conf.eth0(wlan0).ipv4ll (which should not be there since NOIPV4LL[0...] is set) and top or htop shows 2 running instances of dhcpcd. ifconfig output looks ok, too.

This situation repeats identically with every boot or reboot.

If rc.inet1 is NOT launched inside rc.M, there is after a quick boot (dhcpcd process is slow), of course, no running network. If rc.inet1 is manually started at this point, everything works exactly as it should and there are no error messages at all. Logging messages in both cases are essentially identical.

dhcpcd --rebind, inserted into rc.M after rc.inet1 will make the system work, but, that is NOT the way to go. I note, in addition, here that this method adds a curious terse line to logging output, "/dev udev". Is there a problem with a device node being inactive.

Anyway, something needs fixing.

drmozes · 08-11-2015, 05:13 PM

Quote:

Originally Posted by rdsherman

More problems with dhcpcd v6.9.1 build 1 or 2 and never seen in prior releases.

If rc.inet1 is NOT launched inside rc.M, there is after a quick boot (dhcpcd process is slow), of course, no running network. If rc.inet1 is manually started at this point, everything works exactly as it should and there are no error messages at all. Logging messages in both cases are essentially identical.

Slackware ARM upgraded to the newer 6.9.x release a while ago and I experienced similar issues.
I didn't find out what was going on with regards to dhcpcd being launched from the rc or manually. I found that instead if I simply increased the default timeout from 10 seconds to 12, and switched off zeroconf, it fixed the issues on a couple of the ARM build systems upon reboot.

I made this changelog entry for the initial dhcpcd upgrade:

Code:

n/network-scripts-14.1-noarch-4.txz:  Rebuilt.
 /etc/rc.d/rc.inet1: Make dhcpcd use the -L option (don't use IPv4LL-aka APIPA,
 aka Bonjour, aka ZeroConf).  On SheevaPlugs dhcpcd would more often than not
 obtain an IP in the 169.254 range rather than waiting for an IP from the DHCP
 server.  Even supplying the --waitip option, dhcpcd considered the IP within
 the 169.254 range 'received'; so I cannot find any other option apart from
 disabling ZeroConf.

You can try this by editing rc.inet1:

Code:

# Switch off zeroconf:
sed -i 's?/sbin/dhcpcd -t ?/sbin/dhcpcd -Lt ?g' /etc/rc.d/rc.inet1
# Change from 10 seconds to 15 for the DHCP offer timeout:
sed -i -e 's?10 seconds?15 seconds?g' -e 's?\${DHCP_TIMEOUT\[\$i\]:-10\}?\$\{DHCP_TIMEOUT\[\$i\]:-12\}?g' /etc/rc.d/rc.inet1

Does this help?
I can't see the point in Zeroconf at all - my mind is boggled by the purpose of having an IP range assigned that doesn't get you out to the world and never will.
Surely it only makes sense to fail and for the user to know that their network settings will need attention.
Or maybe I don't really understand Zeroconf.

dr.s · 08-11-2015, 06:12 PM

Quote:

Originally Posted by lemurian

Hi Alien,
Thanks for the quick reply.

The new package dhcpcd-6.9.1-x86_64-2 actually made it worse. :-)
Now dhcpcd gives a "timed out" notice during boot plus the "dhcpcd --rebind" workaround results in:

Code:

cat: /run/dhcpcd/dhcpcd/resolv.conf.wlan0.ipv4ll no such file or directory

kind regards.

Same here, dhcpcd-6.9.1-x86_64-2 didn't fix the original issue, I get the message below at boot:

Code:

cat: /run/dhcpcd/dhcpcd/resolv.conf.eth0.ipv4ll no such file or directory

Same workaround, "dhcpcd --rebind".

When I run Slackware-current in a VM however, I don't get this error.

rdsherman · 08-11-2015, 08:17 PM

I tried, directly inside rc.M,

dhcpcd -L -t 30 eth0

instead of rc.inet1, thus directly invoking what I need. It, again, does NOT work.

As a correction to my first post, upon running dhcpcd --rebind, the first logged line reads

dev: loaded udev.

That line does not appear when rc.inet1 runs initially.

Still a mystery.

ReaperX7 · 08-11-2015, 08:42 PM

I'm about to test this with OpenRC, which doesn't use inetd, so I'll report back here too if there's any issues using the native network script of OpenRC and dhcpcd.

Rebooted and works fine here, but OpenRC says it crashed, but I still have networking under the main networking agent. I did however switch out the network daemon to NetworkManager using it's internal agent. Dhclient works too.

rdsherman · 08-11-2015, 10:32 PM

There are other ways to get a connection, eg, dhclient, or a previous version of dhcpcd. And I also have on a USB flash drive a systemd + dhclient + NetworkManager (F22) which works, too.

But, I have used dhcpcd since inception (> 20yrs?), launched in rc.inet1 without a hitch ever until now. I can patch it to do the job as I have now, but, it's an ugly one.

We need to get it working reliably before the next official release of 14.?.

I like dhcpcd!

rdsherman · 08-11-2015, 11:06 PM

I found this quote in LFS 2015 July 15

"add udev support for interface arrival and departure; this is because udev likes to rename the interface, which it can't do if dhcpcd grabs it first."

Could this be the issue of starting dhcpcd shortly after udev runs in rc.S?