At UCLA-Mathnet we've standardized on SuSE 10.1 and we expect to get at least a year out of it, if not 18 months, before we have to visit each of our 125 Linux boxes and upgrade it. Thus we're not keen on installing 10.2 right now. We've been doing very well installing SuSE 10.1 across the net from our enterprise mirror -- until we received a new Dell Optiplex 745. This machine has the latest Broadcom 5754 NetXtreme Gigabit Ethernet NIC (PCI Express) (PCI ID 14e4:167a). Other new Dells such as the Dimension E510 and E520 have either the same NIC or a similar one. It wants the tg3 driver, which SuSE 10.1 does have.
Plan A: follow our standard procedure. This failed because the driver on the installer disc does not recognize the PCI ID, and if it's hacked to fake the ID it fails to send packets (because the new NIC requires actual different driver code).
Plan B: Obtain the latest sources for the tg3 driver from Broadcom, and
create a driver update disc
. Per instructions, we need to compile the
driver twice, once for the latest kernel and once for the kernel version that's
on the installation disc and which will be installed in the first phase.
This plan failed because we were not able to compile in the context of the
back-version kernel sources.
Plan C: Obtain a NIC that is supported. Install Linux, install tg3.ko for the current kernel, then change to the onboard NIC. Easier said than done: supported USB NICs get discontinued as soon as they're listed, and the case takes only half-height PCI cards which are hard to find. However I did use plan C successfully on a Dell Dimension E520, which takes full-size PCI cards.
Plan D: Use the SuSE 10.2 install disc (which does know about the NIC) to install SuSE 10.1. Yeah, sure. Update the driver by running the rescue system before the first reboot. This plan was actually successful. Here is the procedure I followed:
Preparation: Do the following on Sunset (master site).
Download the latest source for the tg3 driver from
Broadcom.
You get a zip file. cd /tmp
and unzip it (unzip whatever.zip
);
you get tg3-3.66d-1.src.rpm
(buried under various directories) (plus tarballs which you can ignore)
(the version may be higher in the future).
Install it: rpm -i tg3-3.66d-1.src.rpm
.
It appears in the normal place, sunset:/usr/src/packages/(various).
See .../SPECS/tg3.spec . Compile it with this command line:
rpmbuild -bb SPECS/tg3.spec >& /tmp/logfile
.
As Sunset is a SMP system, this will be a SMP version for the latest kernel,
which is what you want on a multi-core and/or hyperthread machine.
It compiles with no warning messages or errors, but there is a lot of
chatter from the rpmbuild process. The RPM is deposited in
.../RPMS/i586/tg3-3.66d-1.i586.rpm, but you won't be installing it; you
need to copy to your desktop machine .../BUILD/tg3-3.66d/tg3.ko
The following takes place on Hollyfs where the mirrored patches are, but you can do this on your desktop machine by changing to /u/hollyfs/s1/ftp/pub/SuSE/update/10.1 . Look at repodata/patch-kernel*.xml and view the latest patch. Hunt for \.rpm file extensions. Skip irrelevant kernel variants such as bigsmp or ppc64, and skip any delta RPMs. Also ignore the following packages entirely: kernel-default, kexec-tools, multipath-tools, open-iscsi; these would not be installed on a GX-745. At the rev level when this is being written you end up with these relative pathnames:
Now on the machine where you're installing Linux, insert CD #1 for SuSE
10.2. Do not use the DVD! It knows
that the x86_64
architecture belongs on an Intel Core 2 Duo processor, which can address over
4GB of memory, which we don't have. At Mathnet we install i586 on all machines
except those that can actually get some benefit from x86_64 software. The CDs
don't have room for x86_64 and install i586 on everything.
Booting from the CD is very slow. It turns out that there is a 30 second timeout on each of the three unused SATA channels, hiss, boo! Give it time to boot.
Go through the normal procedure but give it the 10.1 installation directory. The normal procedure would be:
It gets a DHCP address, downloads the 10.1 installer, and executes it. Likely you could give the magic boot parameters for a SSH installation, but I didn't want to complicate things.
Minor glitch: it failed to start the X-server and used the text console instead.
When you're shown the Gnome vs. KDE screen, it's recommended to select
Other
(minimal graphical system) and let post_jump install both Gnome
and KDE in the last step. However, the general public would generally pick
Gnome or KDE at this point. (post_jump is a script written at Mathnet that
handles local configuration issues. In particular, post_jump installs and/or
removes the software that Mathnet wants on the machine, and then does online
update from our enterprise mirror.)
Do all the normal steps. There is one detail: it wants to install the
booter (grub stage 1) in /dev/sda2 rather than the MBR of /dev/sda. This is
appropriate for a dual-boot system (e.g. with Windows), but that's not how we
do it at Mathnet. In the installation summary, expert
view, use the
booting
page to change to /dev/sda.
Let it install packages. It actually installs v10.1 packages. With the fast CPU this phase goes quickly.
Leave the CD in the drive. When it reboots, intercept it and change to boot the rescue system. Again, be patient while it loads drivers. Give the loginID of root (no password).
mkdir /tmp/root
mount /dev/sda2 /tmp/root #Substitute actual root device
mount /dev/sdb1 /mnt #Substitute actual USB device or CD (/dev/sr0)
Follow this procedure to install from the flash memory to the hard disc:
cp /mnt/*.rpm /tmp/root/tmp
cd /tmp/root/lib/modules
mkdir updates
cp /mnt/tg3.ko updates
cd /tmp
chroot /tmp/root
rpm -F -v --nodeps /tmp/*.rpm #Ignore errors about mtab
cd /lib/modules/2.6.16.27-0.6-smp #Give version du jour, use tab completion
mkdir weak-updates #It may already exist
cd weak-updates
ln -s ../../updates/tg3.ko .
depmod -a `get_kernel_version /boot/vmlinuz`
exit #(from chroot)
The RPM step puts the latest kernel on your machine. Without --nodeps, rpm will complain about various version skew and refuse to install the packages. The machine still works with the version skew, and as soon as you do online update it will be corrected. At Mathnet, post_jump handles the online update.
umount /mnt
and remove your USB device. Remove the installation
CD from the drive. reboot
.
Continue with phase 2 of the installation, beginning with network
configuration. It should proceed without problems. For Mathnet
installations, remember to switch to the machine's assigned static IP address,
and decline the network test
which involves online updates from their
overloaded server; let post_jump take care of updates. But the general
public is going to have to do online update promptly, and you might as
well do it in this step.
Finish by running post_jump (if at Mathnet).