Bug 487729 - root=dhcp netboot fails to write /etc/resolv.conf and set hostname
root=dhcp netboot fails to write /etc/resolv.conf and set hostname
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: initscripts (Show other bugs)
11
All Linux
low Severity medium
: ---
: ---
Assigned To: Bill Nottingham
Fedora Extras Quality Assurance
:
Depends On:
Blocks: K12LTSP THINCLIENT
  Show dependency treegraph
 
Reported: 2009-02-27 12:28 EST by Warren Togami
Modified: 2014-03-16 23:17 EDT (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-11-11 11:41:59 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Warren Togami 2009-02-27 12:28:01 EST
DHCP netboot fails to write /etc/resolv.conf based upon /dev/.dhclient-$dev.leases.  These types of boots do not use service network nor service NetworkManager because it can interfere with the network where.
It also fails to set a hostname when a hostname is given by the DHCP server.

I will write a patch for this.

initscripts-8.89-2
Comment 1 Warren Togami 2009-02-27 12:44:14 EST
(These types of boots do not use service network service nor NetworkManager because it can interfere with the network through which it reaches the root filesystem.)
Comment 2 Bill Nottingham 2009-02-27 16:37:43 EST
Sounds like the second issue needs fixed (that they don't work with network/NM), rather than the other issue. We don't need a third network infrastructure.
Comment 3 Bug Zapper 2009-06-09 07:42:01 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 4 Warren Togami 2009-07-20 15:49:19 EDT
Dan,

It seems we should have service network and NetworkManager read the files from dracut to set the hostname and /etc/resolv.conf from netboot.
Comment 5 Warren Togami 2009-07-22 10:22:09 EDT
dcbw came up with a new plan:

1) Do not copy ifcfg files written by dracut into the standard /etc/sysconfig/network-scripts/ location because we don't want ifup/ifdown to be able to control them.
2) initscripts (separate from service network or NetworkManager) writes out /etc/resolv.conf if it sees that dracut wrote out ifcfg files.
3) It is later up to service network or NetworkManager to decide if it wants to do anything with the ifcfg files in the dracut written location.  Such interfaces need to be treated differently since they must not be allowed to change during runtime, or the rootfs can be disrupted.
Comment 6 Bill Nottingham 2009-07-22 11:55:51 EDT
(In reply to comment #5)
> dcbw came up with a new plan:
> 
> 1) Do not copy ifcfg files written by dracut into the standard
> /etc/sysconfig/network-scripts/ location because we don't want ifup/ifdown to
> be able to control them.

... why not? If the user wants to screw themselves... :)

We already have code to prevent automatic unmounting of the backing device of hte root filesystem.

> 2) initscripts (separate from service network or NetworkManager) writes out
> /etc/resolv.conf if it sees that dracut wrote out ifcfg files.

If you're not using either service, where would it do this?

> 3) It is later up to service network or NetworkManager to decide if it wants to
> do anything with the ifcfg files in the dracut written location.  Such
> interfaces need to be treated differently since they must not be allowed to
> change during runtime, or the rootfs can be disrupted.  

initscripts is not going to look in another location - that doesn't make sense. (Neither should NM.)
Comment 7 Warren Togami 2009-07-22 13:19:26 EDT
dcbw and I came up with another new plan.

1) ifcfg files written by dracut contain NETBOOT=yes.

2) If rc.sysinit sees ifcfg files passed from the initrd (only in the netboot case), then do everything that ifup would have done.
    * copy ifcfg's into /etc/sysconfig/network-scripts/
    * copy dhclient lease file to /var/lib/dhclient/
    * write /etc/resolv.conf
    * Set hostname from reverse DNS if it works.

3) service network is modified to recognize NETBOOT=yes.  It knows not to DHCP again, and instead run dhclient taking over the existing lease.

4) NetworkManager  is modified to recognize NETBOOT=yes.  It knows not to DHCP again, and instead run dhclient taking over the existing lease.
Comment 8 Bill Nottingham 2009-07-22 13:23:21 EDT
(In reply to comment #7)
> dcbw and I came up with another new plan.
> 
> 1) ifcfg files written by dracut contain NETBOOT=yes.
> 
> 2) If rc.sysinit sees ifcfg files passed from the initrd (only in the netboot
> case), then do everything that ifup would have done.
>     * copy ifcfg's into /etc/sysconfig/network-scripts/

.. and readonly root does what here?

>     * copy dhclient lease file to /var/lib/dhclient/
>     * write /etc/resolv.conf
>     * Set hostname from reverse DNS if it works.

> 3) service network is modified to recognize NETBOOT=yes.  It knows not to DHCP
> again, and instead run dhclient taking over the existing lease.
> 
> 4) NetworkManager  is modified to recognize NETBOOT=yes.  It knows not to DHCP
> again, and instead run dhclient taking over the existing lease.  

Shouldn't these be the default state, if possible?
Comment 9 Warren Togami 2009-07-22 14:07:23 EDT
NETBOOT=yes for NetworkManager will do several things.

* Take over interface using existing lease.
* Ignore carrier, do not tear down interface if carrier disappears.
* Do not allow user to touch the interface.

Why?

* NetworkManager can keep renewing the DHCP lease, while protecting the interface, while making it possible for that client to launch VPN connections.

>> 2) If rc.sysinit sees ifcfg files passed from the initrd (only in the netboot
>> case), then do everything that ifup would have done.
>>     * copy ifcfg's into /etc/sysconfig/network-scripts/
>
> .. and readonly root does what here?

Good point, copying ifcfg at this point doesn't exactly work.  That is why the earlier proposal involved not copying it and instead reading it from the location passed from initrd.

I will re-examine exactly what cannot be safely detected from rootfs after switch_root.

I however am angry at the resistance here to simply use state passed from dracut.  The existing code in initscripts is no longer enough to do everything we need.
Comment 10 Bill Nottingham 2009-07-22 14:10:12 EDT
(In reply to comment #9)
> I however am angry at the resistance here to simply use state passed from
> dracut.  The existing code in initscripts is no longer enough to do everything
> we need.  

We *ALREADY HAVE CODE* that:

- copies the lease file
- makes resolv.conf
- etc.

I have yet to see any concrete reasons why you have to generate an entire new infrastructure and configuration paradigm to replace something that does exactly what you say you need.

If that makes you angry, I'm sorry, but I can't help that.

Note You need to log in before you can comment on or make changes to this bug.