Bug 755921
| Summary: | dhclient called with invalid hostname | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Ian Dall <ian> | ||||
| Component: | initscripts | Assignee: | Bill Nottingham <notting> | ||||
| Status: | CLOSED NOTABUG | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | unspecified | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 16 | CC: | iarlyy, jonathan, notting, plautrba, rvokal | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | All | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2011-11-23 10:57:40 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
Why do you have 'HOSTNAME=' in /etc/sysconfig/network? Umm. Legacy I think. I've had it that way since Fedora12 or so. The old pre-systemd rc.sysinit would do a:
HOSTNAME=$(/bin/hostname)
. /etc/sysconfig/network
then
if [ -z "$HOSTNAME" -o "$HOSTNAME" = "(none)" ]; then
HOSTNAME=localhost
fi
and then later
if [ "$HOSTNAME" = "localhost" ... # then set the real hostname.
so the case of a null HOSTNAME was deliberately being catered for. I found that the initial hostname (reported by /bin/hostname or in /proc/sys/kernel/hostname) was sometimes wrong and the easiest way was to override it in /etc/sysconfig/networking.
I have now discovered why the initial hostname is sometimes wrong. There is a bug in dracut where the domain part is omitted when setting the hostname from dhcp.
I'll try fixing dracut and removing the HOSTNAME= line. If that works I'll close this and open a dracut bug.
The real bug seems to be in dracut. See #756347 |
Created attachment 535007 [details] Patch handle null HOSTNAME properly. Description of problem: When using the network service (rather than NetworkManager), configured to get the hostname via dhcp, dhclient gets called with a hostname of "-1" which is not valid. Version-Release number of selected component (if applicable): initscripts-9.34-2.fc16 How reproducible: Always Steps to Reproduce: 1. Configure /etc/sysconfig/network: NETWORKING=yes HOSTNAME= keep_old_ip=yes and /etc/sysconfig/network-scripts/ifcfg-eth0: DEVICE=eth0 BOOTPROTO=dhcp 2. Boot 3. Examine server log file Actual results: Nov 22 21:18:13 fs info dhcpd: DHCPREQUEST for 10.0.0.151 from 00:14:22:d3:87:3f (-1) via bond0 Nov 22 21:18:13 fs info dhcpd: DHCPACK on 10.0.0.151 to 00:14:22:d3:87:3f (-1) via bond0 Nov 22 21:18:13 fs err dhcpd: Unable to add forward map from -1.example.domain to 10.0.0.151: REFUSED Expected results: Nov 22 21:45:20 fs info dhcpd: DHCPREQUEST for 10.0.0.151 (10.0.0.1) from 00:14:22:d3:87:3f via bond0 Nov 22 21:45:20 fs info dhcpd: DHCPACK on 10.0.0.151 to 00:14:22:d3:87:3f via bond0 Additional info: I am network booting using nfs root. I can't use NetworkManager because when NetworkManager starts I lose the NFS root connection. Dhcp from the initramfs works properly, it is only when the network service starts that the dhcp error occurs. I am using dynamic dns and this error results in the clients forward and reverse entries being deleted which stops nfs4 working. If I boot to "rescue.target" then everything is mounted correctly, but when attempting to go to "multi-user.target", the nfs4 mounted filesystems become inaccessible. I have tracked this down to a line in /etc/sysconfig/network-scripts/ifup-eth: DHCLIENTARGS="${DHCLIENTARGS} -H ${DHCP_HOSTNAME:-${HOSTNAME%%.*}} ${ONESHOT}... In this case, DHCP_HOSTNAME and HOSTNAME are both null and ONESHOT is -1, which results in arguments "-H -1" I reverted this to how it was in Fedora14: DHCLIENTARGS="${DHCLIENTARGS} ${DHCP_HOSTNAME:+-H $DHCP_HOSTNAME} ${ONESHOT}... which works for me, but presumably doesn't address whatever prompted the change. I've attached a tentative patch. Of course, fixing NetworkManager to handle nfs root configurations is an alternative approach.