Bringing up loopback interface
 

I have just completed an install of Redhat 8.0. The install goes through without a hitch. However, on rebooting, the startup routine always hangs at the point where it says:

"Bringing up loopback interface"

My setup involves a Intel Express Pro 100 ethernet card (using eepro100 module) and DHCP broadband access. Other Linux distributions have no problems detecting my setup and automatically configuring it. Also, I experience no problems with Redhat 7.3.

I can get into the Redhat 8.0 install by entering interactive startup and not allowing it to "bring up network". Once inside, I have tried the following:

- lsmod

And this does not show the ethernet card loaded (because I didn't allow startup to process "network"?)

- modprob eepro100

Nothing happens

- insmod eepro100

I get a message saying /usr/src/linux.../eepro100.c but then nothing happens.

- ifconfig -a

Nothing happens

My questions:

- Can anyone give advice on what I could try next? (And, as you can see, I am very much a "newbie")

- I have a working Redhat 7.3 installation alongside this Redhat 8.0 installation, so are there any files I can compare between the two and copy over from 7.3 to 8.0?

Many thanks in advance for your help!

well firstly, your loopback interface has nothing to do with any NIC on your system, it's an internal network, 127.0.0.1. It's possible you do not have your host name configured correctly i guess. boot to single user mode, and look at /etc/hosts

I experienced the same problem when I tried to install RedHat8.0 on my SONY Vaio laptop PCG-GR170K, while the same laptop had no problem with RH7.3. Plus, I experience no problem when I installed RH8.0 on the desktop I built. I tried to set a hostname under the rescue mode, and then reboot. But it didn't help. Could someone shed more light on this? Your help is greatly appreciated

possible solution
 

thanks for your replies...

I have worked out one possible solution...

I found that if I entered interactive startup (pressing "i" during startup), I could get the machine to boot correctly if I didn't allow the following to run:

kudzu

So, after booting up successfully in this way, I simply went to /etc/rc.d/rc5.d and deleted the item Sxxkudzu (xx= numbers). Now, when I boot up, kudzu doesn't try to start and my machine boots normally. I don't know if this is a correct solution but it is working for me so far!

I have exactly the same problem
 

Did you get any suggestions on how to fix this? I have exactly the same problem, and resorted to downgrading to RH7.3, which fixed the problem. I forget, were you trying to use DHCP? Or a fixed IP address?

My guess is either the eepro100 driver is shagged in 8.0, or something is wrong with DHCP.....

Hope to hear back from you....

Cheers

Re: possible solution
 

Removing kudzu (new/changed hardware probe) worked on Sony GRX570 as well, but then it never finds the mouse or other required hardware. Tried some options w/o results. No mention on RH site. Sound, although found during install, is broken as well. (7.3 doesn't support this P4 laptop at all)

how do we inform redhat to get a fix?
 

I guess disabling h/w autodetection on a laptop is not such a
biggie - but on a desktop it would be a complete pain the arse.

So how do we go about reporting the bug?

what kudzu does...
 

OK - so disabling kudzu worked for me too - but at what cost?

I removed the link /etc/rc5.d/S05kudzu which then disables
automatic hardware detection at boot time, however, a linux
expert at my workplace informed me that this might not be such
a great idea since it will affect the automounting of CDs and
floppies, which apparently is done by, you guess it, kudzu.

I haven't put his words to the test yet. It seems like this problem
seems to preferentially affect SONY laptops, which makes me
think that the common link could be the IEEE1394 (firewire) port.

Just before my machine hung at the testing loopback interface
stage, I saw a whole load of error messages refering to the
firewire port (I think).


There isn't a means of disabling firewire in the BIOS, so I
wondered whether it was possible to stop this being detected by
either kudzu, or by disabling it in the linux kernel??

Any ideas?

Same issue, Toshiba Satellite 5000. Haven't tried RH7.3. I removed my WiFi card thinking there was a conflict as in Interactive mode it locks just past the loopback thing at PCMCIA. I'll stay tuned to this thread, but in the meantime it's looking like 7.3 for me.

Re: what kudzu does...
 

I have a Dell Inspiron laptop with a firewire port and have no problems at all running RH7.3, I just installed 8.0 a few days ago and so far have not found any errors regarding this, however, I have not connected 8.0 to the network yet either. I would venture to guess that if it is a problem with the firewire port, it is specific to certain brands or implementations.

In terms of bugs with 8.0, this is to be expected. A good rule of thumb is don't waste time or money on _even_ (*.0, *.2, etc...) revisions of software as they are usually the first releases of new features, always wait for an _odd_ release (*.1, *.3). Just my .02 USD

Jeremiah

OK so I was wrong
 

Apparently disabling kudzu at startup doesn't seem to have
as big an effect as I suspected. CDs still automount, don't have
a floppy so can't test that.

So it seems like SONY's implementation of firewire is suss -
in another thread (hardware) someone suggested that I
run lsmod, apparently this should show a device driver (module)
loaded for firewire - called ohci1394.

It wasn't there, so I was asked to try running modprobe ohci1394
which produced a segmentation fault.

So I guess I am at the mercy of whoever writes the modules to see if they can fix it.

I don't know of a way of bringing this to RH's attention ???

Cheers,
Jon.

Try running the kudzu startup script by hand once you have booted
successfully. Maybe even try running each portion of the script by
hand so you know exactly where it fails. . .
You may have to recompile your kernel so that it only has what you
need compiled in, and other things that aren't used as often can be
compiled as modules. This way you can be more sure of what hardware
your kernel thinks your machine has. If there are conflicts between
different drivers and they both try to load, you can get this sort of hang.

OT:
<flame bait>
You're getting segfaults on a "clean" installation of RH?! That just
astounds me. Four years after I last tried Redhat, they still seem to be
the "Microsoft of Linux".
</flame bait>

Bringup up loopback interface
 

I'm running a Sony Vaio PCG-GRX570 and I have the same problem running RedHat 8.0.

I've come to the same conclusion - what's wrong with this? Other distros worked fine...

basically Redhat 8 sucks
 

Hi,

My guess is that RH8 is using a fairly recent kernel with acpi
support and firewire built in - when kudzu finds the hardware
however, the whole thing falls over. I tried getting acpi to
work in a home-compiled 2.4.19 kernel and failed miserably.
And that was under 7.3 - other people have achieved this
and got firewire/USB/modem/jogdial working successfully, but
not for me :(

Never mind eh.

Jon.

I am finding this problem posted on several different websites, all with few solutions. It seems to be unique to RH 8.0 and laptops. I have a Sony Vaio 650 and am getting very frustrated. If anyone gets any solid answers, please post. I appreciate all the information that has been posted thus far. I am a newbie to Linux. Nothing is ever easy:)