Bug 195749

I got the same results for http and ftp install for boot.iso June 17th.

I noticed that the updates had an anaconda comment in libdhcp.
I noted that my current FC6 install did not have this package lib dhcp.
I yum installed it and it also installed dhcp4client and dhcp6client.

Q1. What was the system using for dhcpclient w/o these (as it works)?

Q2. Anaconda net install fails right after the enter of wensite and path.
Before this is the dhcp ip address get.
I do not notice and net activity on the dhcp server side.
Could the linkage between dhcplib and clients be missing in anaconda?

Just a thoht for debugging I don't need an answer.

FYI: The mail for this bug was never recieved.

Darwin

Seeing this glibc detected double free or corruption error on both USB diskimage
and boot.iso. Using the FC5 installer images avoids it.

This looks a bit like bug #196304 ...

*** Bug 196898 has been marked as a duplicate of this bug. ***

*** Bug 196304 has been marked as a duplicate of this bug. ***

This has been fixed in rawhide and will be in the next anaconda build.

Thanks a lot.
Unfortunately, the joys of Rawhide are preventing me from testing the fix as the
installer fails to load the ne2k-pci module today *sigh* ;-)

(In reply to comment #6)
> This has been fixed in rawhide and will be in the next anaconda build.

But that build did make it out to mirrors in the nightly push of Tuesday night
to Wednesday morning, June 27 to 28.  The "rawhide report: 20060628 changes"
shows none for anaconda, and none for the kernel.

The FC-development-ppc-rescuecd.iso pushed last night with md5sum
c9af809d83482b1bccf3f02ee0c81839 still gets "No driver found" for HTTP install
on Apple Macintosh PowerPC Power Mac G4.

We haven't had a new build of anaconda since June 23rd.  Remember that a new
rawhide tree != new anaconda build.  The rawhide report shows the results of a
new tree composition, which is a diff against previous RPM changelogs.  So you
get to see in the report is new RPMs that have shown up in the tree.  If you see
nothing for anaconda, that means we did not rebuild the anaconda RPM.

The sentence "this problem has been fixed in rawhide and will be in the next
anaconda build" probably makes absolutely no sense to anyone outside of Red Hat.
 I'll try to do better with explanations in the future.  But, as far as anaconda
goes, we say "closed rawhide" when we mean we have fixed the problem in the HEAD
CVS branch of the anaconda tree.  I say "will be in the next anaconda build" as
a reminder that even though the code fixes are there, users won't see any
changes until we rebuild the RPM.  We don't build new anaconda RPMs each day and
usually try to get the HEAD branch somewhat stable before a new RPM is built. 
Hope that makes a little more sense.  Sorry for the confusion.

And, as noted in comment #7, kernel modules can't load with rawhide's current
kernel (known problem).

The bug is back.  Please Re-open; bugzilla won't let me change Status.

"rawhide report: 20060629 changes" claims that anaconda-11.1.0.49-1 has fixed
this bug #195749.  However, using last night's FC-development-ppc-rescuecd.iso
with md5sum 26fa172e209467ca1268792fe9e4dd39, I still get "*** glibc detected
*** /sbin/loader: corrupted double-linked list" and traceback.  The good news is
that the rescue CD apparently did find the driver for the builtin ethernet on
Apple Macintosh PowerPC Power Mac G4, because it got beyond entering the server
and path, and got beyond the DHCP dialog.

Then it's maybe ppc specific or only happening for the rescue CD because the
i386 boot.iso image dated 20060629 did fix the problem for me.

Reopened and investigating the PPC rescue CD problem.

This time no BSOD, but "install terminated abnormally".
sha1sum=830546309ea5a031aaf0a64b74df1a4e71a3b331 
FC-development-ppc-rescuecd.iso of 2006-06-30.

The attached screen shot [.jpg ;-)] of VT3 shows a couple of interesting items.
 First, DHCPv4 was obtained in less than one second at 13:10:07, while DHCPv6
timeout took 47 seconds from 13:10:07 to :54.  That's too long, so there should
be an option to disable DHCPv6.  Second, "13:10:56 ERROR: nic_configure: failed
to configure resolver." and "DHCPv4 interface configuration failed." even though
this network has a healthy DHCPv4 server (Netgear RP614v2; no hostname tracking)
which does provide resolver addresses.

Created attachment 131808 [details]
screen photograph of VT3 showing DHCP failure

830546309ea5a031aaf0a64b74df1a4e71a3b331  FC-development-ppc-rescuecd.iso
"boot: linux askmethod" HTTP  "install terminated abnormally"

I also get "install terminated abnormally" with 20060630 i386 boot.iso trying an
ftp install, but DHCP worked (no IPv6 here either, so I agree about the nearly 1
minute timemout being quite annoying). I got that message right after it
transferred the stage2 image, and the last message on tty2 was "Running anaconda
script /usb/bin/anaconda".

Different problem than initially, but still some anaconda problem that prevents
the installation :-)

OK, too many bug reports in this one BZ entry.  I already know about install
terminated abnormally.  I uncovered that yesterday.  Working on tracking that
down.  It's happening in a few scenarios, but the easy way to recreate it is to
do a static IP configuration and proceed with an NFS install.  You will see that
message.  DHCP net installs work fine.

You can disable ipv6 by passing 'noipv6' as a boot parameter.  If you think the
UI in loader2 should have a check box for that or something, please file an RFE
for that.

Since this bug was originally for HTTP installs crashing and that is working
now, I'm closing the bug.  Other networking issues are present, but are
unrelated to the topic of this one.  Please open new bugs for new issues. 
Marking this one as closed.

This doesn't work for me in current rawhide -- have the fixes flowed down yet?

I just tested eight different permutations:

- Rawhide version local mirror, July 2
- Two systems: old 400 MHz AMD with RTL3139 networking, and Dell Inspiron 3GHz
P4 laptop (5150) with B44 networking.
- Two protocols: HTTP and NFS
- Two IP assignment schemes: DHCP and static

*None* of the installations worked -- they all aborted at the "Starting
Anaconda" point (all static assignment attempts aborted one screen earlier,
right after the static IP information was entered).

(I've been trying the network installation daily but it hasn't worked for at
least a couple of weeks).

The traceback on VT8 shows:

  ...
  File "/usr/lib/anaconda/fsset.py" line 552, in __init__
  self.partedFileSystemType = parted.file_system_type_get("gfs")
  parted.error: unknown file system type