Description of problem:
For the latest versions of "anaconda", network installs exit because
it fails to establish a working network connection. The system is an
"IBM ThinkPad T23", the network driver is "e100". An "HTTP" install
exits after entering server name and download directory.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Boot from current "boot.iso" image.
2. Select "HTTP" install.
3. Choose "DHCP" protocol.
4. Enter download repository and confirm.
Installer terminates and reports:
"install exited abnormally -- received signal 6"
Installer should proceed to downloading "stage2.img".
vt3 is filled with some relevant messages:
"ERROR: nic_configure: failed to configure resolver."
"ERROR: DHCPv4 interface configuration failed."
"INFO: result of setupInterface in DHCP configuration failed
-1 Operation not permitted."
It is of course possible to configure the network without "DHCP".
In this case, the installer simply sits there after entering the
repository parameters instead of reporting that it is retrieving
All of the above works again when a boot image of "FC5" is used
It is possible to boot from the rescue image, too. In this case,
network support with "DHCP" protocol is also chosen and the
repository parameters are entered. However, the following screen
appears instantaneously - too fast to have carried out the request.
Again there is an error message in a virtual console: "ERROR:
Error trying to start eth0 in rescue.py::startNetworking()".
A "ping" to some explicit IP number is rejected due to absence
of an active network connection.
The issue occurred more than about a week ago. Before, everything
Sorry, when booting from the rescue image, network activation and
"DHCP" are checked, of course, and that's all (no download server
name entered, etc.).
I'm seeing a similar crash while trying to do a FTP install on a VMWare virtual
machine. The installer crashes immediately after hitting "OK" on the screen for
selecting the FTP server and directory. I'll send screen captures of VT1, 3 and
4 with the error messages.
Created attachment 131102 [details]
Messages on virtual terminal 1
Created attachment 131103 [details]
Messages on virtual terminal 3
Created attachment 131104 [details]
Messages on virtual terminal 4
Yes, that's exactly what happens to me. I could reproduce this in "qemu"
until a few days ago myself, but since Thursday, unfortunately, the
kernel would hang when booting. Your "VMWare" screenshots are very
Happens for me as well on x86_64 using the forcedeth driver doing an HTTP install.
Just want to add a 'me too' if that matters. Crashes on x86_64 using both
forcedeth and skge drivers with both ftp and http install attempt.
Another 'me too'.
I have the same problem trying to do a network install. Essentially the same
errors as #3. Broadcom gigE nic.
Can people seeing this problem try booting with 'linux noipv6' and see if that
Also, please be sure to give *any* command line arguments you're passing, no
matter how inconsequential they may seem.
using 'linux noipv6' yields the same issue here although the dhcp probing seems
to take a lot shorter time it still does the amazing crash after givin anaconda
the mirror location.
Aha, finally reproduced by iterating through some DHCP options.
Is anyone actually getting back a DNS server in the DHCP server replies? When I
have a DNS server, I can't get things to fail -- when I don't, I can hit the
segfault. Debugging from ther enow.
I am hitting this with x232 IBM server (hadn't tried other machines yet). I
tried: "linux askmethod noipv6" and have the same hang.
In regards to the DNS server in the DHCP server replies, I think I do get it as
the HTTP site (redhat.download.fedoraproject.org hostmae gets resolved). The log
resjult of setupInterface is DHCP configuration failed - 1 Operation Not Permitted
reverse name lookup worked
starting to STEP_URL
Booting with "noipv6" behaves exactly as before. The error messages are
those posted in my initial report. The "DHCP" request is honored
succesfully but then this error ""ERROR: nic_configure: failed to
configure resolver." occurs which indeed points to a "DNS" problem. As
pointed out before, entering the download server address numerically
allows to avoid the termination, but then the system simpliy sits there.
Btw, the message "ERROR: DHCPv4 interface configuration failed." reported
earlier already shows that "IPV6" is not even used. I suppose that
explains why there is no difference when adding "noipv6".
Using "noipv6" makes no difference and the installer crashes at the same point
even if I define the IP information statically, so it's not DHCP related.
This is being moved to a FC6 blocker. We may be able to get out an updated
boot.iso after Test1 releases but this is not enough to hold up Test1.
I do agree. As long as installable media are provided for download,
which will of course be the case for FC6 test1, this is only a minor
loss of functionality. Thanks for inquiring.
The beginning of that signal 6 crash backtrace reads something like
*** glibc-detected *** /sbin/loader: corrupted double-linked-list...
As for wether the dhcp server replies correctly, the same server works fine for
fc network installs, DNS servers and all..
What might be particular here is that the install images are loaded via pxe and
there are two network adapters. Using the first (eth0, 3c59x) one.
Crashes exaclty as before for "anaconda-188.8.131.52-1".
These reports look exactly like all of the things I fixed today in rawhide.
But, there's still probably some cases where loader will sigsegv. I've fixed
HTTP installs in rawhide now (fixes the corrupted double-linked list, double
frees, etc that people are seeing). Next anaconda build will have this stuff
Closing this bug as RAWHIDE, but please feel free to reopen if the next anaconda
build is broken the same way.
For HTTP and FTP installs on an IPv4 network, there were two double free() calls
and one corrupted double linked list problem. These happened after you'd see
"enter STEP_URL" on tty3.
Still broken in "anaconda-184.108.40.206-1".
Still broken in "anaconda-220.127.116.11-1".
What about today's rawhide? I'm not able to reproduce this problem under
Tested "anaconda-18.104.22.168-1" on 2 systems: "Dell GX280SF" and "IBM ThinkPad T23".
1. Installer crashes on both systems unless option "noipv6" is added.
2. Installer crashes despite adding "noipv6" unless keyboard layout
"us" is left unaltered. Changing the keyboard layout to
"de-latin1-nodeadkeys" lets the installer crash at the same stage,
namely after setting up the network connection.
3. In all cases and regardless of any further option, the graphical
installer does not launch properly. After the initial message of
launching the "X" server, the screen turns black, and it is even
impossible to switch to a text console. However, the system still
responds to "ctrl-alt-del".
4. Honoring 1. and 2. plus "text" option allow to install the system
via the network, albeit in text mode only :(
PS: Even in text mode there is a lot of junk popping up in the background.
Looks like armenian or some other exotic charset. At least, it does
screw up the installation process.
Of course, I meant: "At least, it does *not* screw up the installation
The text installer stops working in "anaconda-22.214.171.124-1". After
scanning the disk for existing FC installations, the following error
message by "anaconda" is displayed:
line 68 in findRootParts
for (dev, fs, meta) in
ValueError: too many values to unpack'
The graphical installer still gets stuck when the "X" server is launched.
This happens on the 2 systems mentioned above ("S3" and "ATI" chip).
However: under "qemu", the graphical installer starts up nicely. IPv6
was not enabled, neither by adding the "noipv6" option nor by
unchecking the related networking option. The disk image was empty
without any partitions which might explain why the installer did
not crash in "upgrade.py". Choosing a German keyboard layout still
crashes the installer.
Too many bugs listed here. Please open new bugs as you find different problems.
Regarding the original problem, the loader2 network failures that prevent moving
to stage2 have been fixed in rawhide. They will be in the next build of
anaconda. The fixes won't appear until at least anaconda-126.96.36.199.
The log message "result of setupInterface is DHCP configuration failed - 1
Operation Not Permitted" was a problem in libdhcp and has been fixed as of
Ok, submitted new report for bug 199015. "anaconda-188.8.131.52-1" crashes
exactly as reported in my initial report producing the same screen
output as submitted in comment 3 (default language/keyboard "English/US").
However, no "DHCP" errors are reported anymore. It seems that the origin
of this issue needs to be looked for somewhere else.