Bug 51786 - Setting hostname at boot via dhcpcd on pcmcia-ethernet fails
Setting hostname at boot via dhcpcd on pcmcia-ethernet fails
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: initscripts (Show other bugs)
7.1
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Elliot Lee
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-08-15 03:15 EDT by jalar
Modified: 2007-04-18 12:35 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-03-02 17:57:13 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Suggested patch to ifup (646 bytes, patch)
2002-01-14 07:24 EST, jalar
no flags Details | Diff

  None (edit)
Description jalar 2001-08-15 03:15:15 EDT
From Bugzilla Helper:
User-Agent: Mozilla/4.77 [en] (X11; U; Linux 2.4.3 i586)

Description of problem:
I use a laptop with a pcmcia-ethernet card. Since I use the laptop in
several environments, I chose to keep localhost.localdomain as the standard
hostname. From what I gather, this would cause dhcpcd to set the hostname.
Unfortunately, this does not work at boot time (possibly because eth0 init
is delayed because the pcmcia services are not up at that moment). However,
if I simply issue '/etc/init.d/network restart' later the hostname is set
correctly. This requires me to restart X (xauth business), so it would be
nice to see this issue fixed. 

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. Boot, look at login prompt: "Localhost login:"
2. Login as root, do "/etc/init.d/network restart", logout
3. Login prompt now contains correct hostname.

Additional info:
Comment 1 jalar 2001-08-16 03:42:08 EDT
Performing "/sbin/ifdown eth0; /sbin/ifup eth0" does not set the hostname
correctly. Neither does removing the pcmcia card and reinserting it.
Comment 2 Pekka Savola 2001-08-20 03:43:49 EDT
This is initscripts' "fault": it only sets the hostname if ONBOOT=yes, and it's
run from 
init.d/network.

inserting the card basically just runs /sbin/ifup through /sbin/hotplug.

Changing component.

FWIW, this also exists in the "Roswell" beta.
Comment 3 Elliot Lee 2001-12-28 15:32:33 EST
This is pretty much the way it has to be:
1. The hostname cannot change during system uptime (because it breaks xauth,
ORBit, and other network services).
2. Of course 'network restart' sets the hostname because it is assuming you are
doing a bootup or screwing with your system at a basic level.

I understand the desire to have the hostname change to match the DHCP hostname,
but at the same time, there are these other constraints that prevent doing this.

I also seem to recall that if your hostname is 'localhost' it will do the
hostname change when you plug the PC card in... Worth a try, anyways.
Comment 4 jalar 2002-01-10 04:56:04 EST
Look,
1. Of course the hostname cannot change during system uptime. But I am talking
of what happens AT BOOT.
2. That 'network restart' fixes it was provided as info that it actually works
as expected in one instance. The whole point of this bug report is that I do not
want to "screw with the system at a basic level" once it is up. I want it to
work at bootup (and in fact, only then).

In short, I am not expecting dhcp to set the hostname at plugin time, just at
bootup. 

This works on a machine with a regular (ISA or PCI) network card, but not with a
PCMCIA card.

We have a number of dhcp-ed laptops here, and it would be nice if they worked
with a standard installation. If you decide not to fix this, set the resolution
to WONTFIX. Then I'll know I have to hack it myself.
Comment 5 Pekka Savola 2002-01-10 05:55:47 EST
do you have a particular fix in mind?

pcmcia+network startup has a *lot* dependencies that might break by "trivial"
changes :-(
Comment 6 jalar 2002-01-11 07:37:15 EST
I know. I was looking forward to an official fix. 

For now, the ugly hack I use is an additional "network restart" at the end of
the boot process (before X comes up, though). Time-consuming and badly behaved
if the cable isn't in, but for a 20s hack, it's something.  I'll need to fix
this properly at some time though.
Comment 7 jalar 2002-01-14 07:24:31 EST
Created attachment 42378 [details]
Suggested patch to ifup
Comment 8 jalar 2002-01-14 07:34:49 EST
When trying to understand the init of pcmcia-eth0, I noted that first 'ifup eth0
boot' is run and fails because pcmcia is not up. Then, when pcmcia comes up,
'ifup eth0' is run. That is, for a pcmcia ethernet card, the 'boot' part of ifup
is never run(!). 

The above patch fixes this by remembering that a 'boot' was tried and delayed,
and restarts 'ifup eth0' as 'ifup eth0 boot' the_first_time it is run (after
pcmcia comes up). Thus the hostname is changed at bootup only.

Comments? I don't think this patch breaks anything, but...

Also, the mechanism used to remember that 'boot' was tried may be less than
perfect; feel free to change it.
Comment 9 jalar 2002-01-15 03:29:15 EST
Come to think about it, timing must be an issue here, am I right? I don't have
problems myself, since I usually boot with the PCMCIA card in the slot and the
network plugged in. 

But when using the proposed fix, consider the following situation: boot without
the card in the slot, wait for the X prompt. THEN plug the PCMCIA card in with
the network plugged in. The hostname changes from under your feet, and xauth
will fail. Restarting X will help, I guess but this is no good anyway.

It seems a fix synced to the boot process is necessary.

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