Release Engineering

This project is intented for all release related issues (isos, installer, etc), under the umbrella of the ArchLinux Release Engineers
Tasklist

FS#49983 - dhcpcd stalls booting when NIC is not connected since 2016.07

Attached to Project: Release Engineering
Opened by Tom Yan (tom.ty89) - Thursday, 07 July 2016, 09:08 GMT
Task Type Bug Report
Category ArchISO
Status Unconfirmed
Assigned To No-one
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 1
Private No

Details

The title pretty much told it all. Also attached a screenshot.

It's probably due to an (un)intentional change in dhcpcd. The thing is, why are we STILL sticking to dhcpcd, instead of the more decent dhclient, or, systemd-networkd?
   Capture.PNG (103 KiB)
This task depends upon

Comment by Gerardo Exequiel Pozzi (djgera) - Thursday, 07 July 2016, 15:51 GMT
I do not remember any particular reason to keep dhcpcd, I will change to systemd-networkd for next archiso release. In any case if this is a regression should be reported to upstream. Thanks.
Comment by Gerardo Exequiel Pozzi (djgera) - Sunday, 10 July 2016, 20:29 GMT
Found it, it was because IPv6 not supported long time ago.

https://lists.archlinux.org/pipermail/arch-releng/2014-February/003365.html
Comment by Gerardo Exequiel Pozzi (djgera) - Monday, 18 July 2016, 20:26 GMT
Please test. Thanks. https://lists.archlinux.org/pipermail/arch-releng/2016-July/003739.html
Comment by Tom Yan (tom.ty89) - Tuesday, 19 July 2016, 11:15 GMT
resolved also needs to be enabled, and we need to remove /etc/resolv.conf (provided by the filesystem package) and create a symlink to /run/systemd/resolve/resolv.conf
Comment by Gerardo Exequiel Pozzi (djgera) - Tuesday, 19 July 2016, 17:31 GMT
Yes. The question here what behavior should be done with copy_resolvconf= (used in PXE boot). Current logic is:

elif [[ "${copy_resolvconf}" != "n" && -f /etc/resolv.conf ]]; then #if copytoram=n
cp /etc/resolv.conf /new_root/etc/resolv.conf
Comment by Tom Yan (tom.ty89) - Tuesday, 19 July 2016, 18:55 GMT
Hmm, simply change both /etc/resolv.conf to /run/systemd/resolve/resolv.conf? (I mean the check and source, not the target)
What was the point of this parameter anyway? Maybe it should be obsoleted and we will just always do the (rm and) symlink in this /newroot (i.e. /newroot/etc/resolv.conf -> /newroot/run/systemd/resolve/resolv.conf), and make sure resolved is (re?)started after "switiching root"?

P.S. Sorry I don't really know about PXE boot

Loading...