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):
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.
Performing "/sbin/ifdown eth0; /sbin/ifup eth0" does not set the hostname
correctly. Neither does removing the pcmcia card and reinserting it.
This is initscripts' "fault": it only sets the hostname if ONBOOT=yes, and it's
inserting the card basically just runs /sbin/ifup through /sbin/hotplug.
FWIW, this also exists in the "Roswell" beta.
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.
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
This works on a machine with a regular (ISA or PCI) network card, but not with a
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.
do you have a particular fix in mind?
pcmcia+network startup has a *lot* dependencies that might break by "trivial"
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.
Created attachment 42378 [details]
Suggested patch to ifup
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.
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.