From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.18 i686; en-US; Galeon) Gecko/20010216 Using the bootnet.img from the Wolverine distro does not allow me to perform an FTP install. When selecting FTP from the menu then selecting my NIC from the list (3Com type), the installer loops back to prompting for the type of install (FTP, NFS, HTTP). If I select FTP again, the 3Com option is no longer listed in the NIC list. I have tried the graphical, text, lowres, nofb, and expert installs, all have the same result. Reproducible: Always Steps to Reproduce: 1. Create network boot disk with the bootnet.img file on the Wolverine distribution 2. Boot with it, select any install method except driver disk or rescue 3. Try an FTP install Actual Results: The installer loops back to prompting for an installation type. Expected Results: Should proceed and ask for ftp address I checked the consoles, there is no additional output when this occurs.
not a bug in pax, a bug in the installer if anything.
What is the exact model of your 3com NIC?
Sorry about the incorrect component. The NIC is a 3Com Etherlink III ISA (3c509B-TPO).
This is solved by using the driver disk (drivers.img). The 3Com Etherlink II/III is not supported by the 59x driver. I bumped into this one doing an FTP upgrade on a friend's machine. You also need to boot with ramdisk_size set to greater than the size of the /usr ramdisk image, e.g. set to 8192 (i.e. 8M) as the default maximum size is 4M.
Matt will you please make sure we have any required changes reflected in our internal tree?
the kernel has a compiled-in default of 8M for the BOOT kernel. The real issue here was the card needing the driver disk
Could I suggest you try to fit the 3c509 driver on the boot floppy? It is a *very* common card in older machines, and most people (myself included) expect it to work "out of the box" ... and it's easy to misread the 59x entry on the menu that appears. In particular, the EtherLink cards are ones that we tend to hunt down and scavenge for use on older boxes.
And, uh, no, I had to specify the ramdisk_size parameter too. Otherwise it didn't work. I only realised this after watching it fail to load the /usr image several times. I've done this on two machines, one of which had a 3c905B in and so worked immediately ... until it came time to fetch the images. This was in Wolverine, the Raw Hide version may be fixed now.
I've forgotten, are those ISA cards?
The one I have in my desktop box is a PCI (3c905B). The one in the older box is an ISA card (3c509something, EtherLinkIII). Point being that older boxes which still have ISA slots, and are being used by technical folks, may well have these older cards in ... they're still fairly common ... the driver is 11k, so it shouldn't be too hard to squeeze in? Every box we have here over a year old has either one of these or a newer 3com card in.
Can you confirm whether the ramdisk_size issue has been resolved? There is at least one other known case of the problem, on the Wolverine mailing list, which was fixed by booting with this parameter at the syslinux prompt.
if you are using the wolverine bootnet.img, you should *not* need to pass in ramdisk_size
I definitely used bootnet.img from Wolverine, because I'd downloaded the CD images, then had to copy all the files off the images into a tree to make a network install work. I *did* have to use the ramdisk_size parameter, and two people in the last two days have "me-too"ed on Wolverine-list that it fixed an install failure for them. I only twigged because I looked at the messages on one of the VTs and saw something about a write failure to the ramdisk.