[ via TOR :: whatsnew :: archive :: hupmeme/24h/7d :: hardware :: pinouts :: hoarding :: download :: rss ]
projects: [ ax.25 :: aquaponics :: job wanted ]

:: 2019-10-06 21:24:52

The world's most crippled, slowest Linux machine

It's actually possible to netboot a Linux via PLIP (f.l.: parallel port). There's hardly any reason to do it (be it good or bad), but PLIP is sexy so here goes. Grab a 2.0.36 kernel, and modify it like so:

--- fs/nfs/nfsroot.c.orig       2019-10-06 13:17:12.508386875 +0200
+++ fs/nfs/nfsroot.c    2019-10-06 14:50:03.945897455 +0200
@@ -175,7 +175,7 @@
        for (dev = dev_base; dev != NULL; dev = dev->next) {
                if (dev->type < ARPHRD_SLIP &&
                    dev->family == AF_INET &&
-                   !(dev->flags & (IFF_LOOPBACK | IFF_POINTOPOINT)) &&
+                   !(dev->flags & (IFF_LOOPBACK)) &&
                    (0 != strncmp(dev->name, "dummy", 5)) &&
                    (!user_dev_name[0] || !strcmp(dev->name, user_dev_name))) {
                        /* First up the interface */

If a host runs 2.4, then 2.0 kernels (and maybe 2.2 as well) must be compiled in a historically fitting chroot (or at least make dep), due to this bug.

First I thought I'll need to add code in order to bring up a point-to-point link, but turns out it works fine configured as Ethernet. The kernel command line looks like this: root=/dev/nfs nfsaddrs=10.0.3.15:10.0.0.198:10.0.3.1:255.255.255.0:plipclient:plip1:none nfsroot=10.0.0.198:/data/nfs/linux-redhat42 init=/bin/ash . The PLIP-to-Ethernet routing commands you can type in yourself.

A slight explanation on this fuckery: IP addresses are hardcoded since there's no need for a BOOTP or RARP server on the other end (I've actually tried with ISC DHCP v2.0, but it failed to send a reply packet on the PLIP link). The parameters are well documented in the kernel dox. Netmask can not be 255.255.255.255 if the NFS server is not the same as the other PLIP node. The shell is going to be ash, because isa, por es homou vogymuk the 386SX/2MB laptop which I volunteered as client could never execute bash. The kernel just kept on retrieving substantial NFS traffic forever. Due to the 2MB RAM limitation, a GRUB boot is needed (LOADLIN.EXE has a 4MB minimum requirement). 2MB is of course quite unusable even on an Ethernet link, due to the obvious fact that even a greatly size-reduced kernel still leaves only about 800k RAM available, and that's not a real lot for a modern, bloated libc5 Linux distro like Red Hat 4.2. So there's ash, and it runs. The first echo * command takes 4 (four) seconds to run on this machine... and that's about as far as it really gets. Or one can go get a glass of water (and drink it patiently) in the time a telnet exe connects to a server's chargen port (15kB/sec).

Booting from a 4MB 386SX is a lot better (the increased cache size is very welcome), but ls / still takes about 20 seconds to run. PLIP is a great system resource hog, and even then its top speed under normal circumstances is 50kB/sec, which I alas could not achieve here. It's sad, isn't it? It is.

Maybe I'll try a 2.2 kernel next time. And someone should put slattach functionality into the kernel where it belongs. At this point 115200 baud SLIP would not be a slowdown, and more importantly the CPU would be freed from the constant nibbling.

[ archived posts ]

[ e-mail ]
sidripalliance kq5
digital
apple india uboot bombagyar