Adventures in installing *nix on a Toughbook R1

scrottie on 2004-12-04T22:47:22

As my old Sony Vaio has been on life support for some time now, barely limping along with a burnt out CPU fan, burnt out charging logic in the unit (requiring the base station), a burnt out touch pad (yes, I checked the ribbon cable), and a keyboard with litteraly holes worn through some of the keys, I got a new machine. Installing to the new machine would prove to be an adventure and the adventure continues. In this article: how NetBSD, FreeBSD, and Linux fair; Slackware install issues and how to work around them with Zipslack.

First a few words on how I got where I am and where (or what) I got. I was considering the Fujitsu P-1120 as its small and light and has excellent battery life - at 2.5 pounds with the extra life battery, it'll run Windows for 9 hours and Linux for significantly longer. It's also keyboard-shaped - the screen and the whole unit is the long and rectangular. Opening the unit reveals pure screen and keyboard - exactly as it should be. Most importantly, this machine is fanless. In my previous five or so laptops, one died a thermal death and two wore out their CPU fans, so I was eager to eliminate this mode of failure. Another problem was the laptop keyboards - apparently they weren't designed to actually be used. I saw someone with an old Toshiba Toughbook - one of the ultra-light but only semi-rugged varieties - at DEFCON and I fell in love. It was a little more square, tiny, adoreable, shiney, sexy, and if it's name was to be believed, tough. Conflicting reports online report the keyboard being semi-water resistant. And I hate if a laptop keyboard gets gummed up and you try to take a few keys off to get the built up hair, dust bunny-mass, etc out, you can't get the back on because the tiny, ultra-fragile little plastic dealies break like some kind of disposable seal. So I wanted a better keyboard.

I got the Toughbook CF-R1 from Expansys. Expansys is like the state-side CDW or any of these big places that deal primarily with companies, but they're big in England apparently but have a satellite office in the United States (where I'm presently located). This is a model that's a few years older, which I figured was all the better as far as *nix support goes. It has an 800mhz PIII (ultra low voltage - this chip would go on to become the Pentium M), 128 megs of RAM (kind of weak), and a 20 gig HD (also kind of weak), but considering the size of my bone pile and how often I have to go back to a 486 and how long I have to stay with a 486 due the frequent hardware failures of crappy machines, if this thing is tough, I don't care about the specs behind slightly behind the curve. Newer Toughbooks of course have better specs. By the way, I've seen reports of the W2 in coming with between a 713 and 900mhz CPU. Even without a fan and with an "ultra low voltage Pentium III", the thing beats the pants off the 650mhz Celeron in my Vaio (which also has 128 megs) by a factor of two using a few tests such as compiling things - the Celeron gets real hot real fast then it gets real throttled and it gets real slow. I'm sold. Give me the low voltage CPU any day and keep your f'n fan. I hereby declare laptops with fans to be stupid.

So how rugged is it? Well, I can take the key caps off and put them back on, but nothing about the keyboard seems water resistant or dust resistant to me, so it's certainly less crappy than other laptop keyboards, but I'm unconvinienced. Ports have little rubber seals around them and there aren't big gaping water (or cola, or kool aid) holes all over to rapidly conduct conductive fluid to the conductive circuits. This is a big plus. I can cringe about 100,000 fewer times in my life as big fat confused looking stragers fumble by wielding massive sugared beverages (and when friends stagger by looking confused with intoxicating beverages). Supposedly the HD is shock mounted, but I can't get the case open. Also supposedly it has a magnesium alloy case but as it turns out, the back of the LCD is most certainly plastic. And experimentally applying even gentle pressure to the back of it makes colors fly in the edges of the LCD itself indicating that the LCD isn't well protected from the pressure at all. The base of the unit easily bows and twists and the magnesium alloy is extremely thin. I'm starting to feel unimpressed and a little but abused about the whole "tough" thing. Panasonic makes a line of fully rugged notebooks which are universally regarded as nearly industructable - people run over them with Jeeps, lose them off the back of motorcycles, and sorts of things, use them in the pouring rain, and they just don't stop. But these weigh a lot.

So time for our next test: compatiability. I really want to run NetBSD on this thing because I'm used to it and I've been accumulating obscure software for almost a decade now and I don't want to have to recompile all of it - it'll take me another decade to do so ;) Well, NetBSD installs and runs fine, and APM actually fucking works. It's fucking amazing. The last time I saw APM work on a notebook was on a 486. NetBSD finds the USB, HD controller, keyboard, touchpad, sound card, and ethernet controller with no problems and all work. The cardbus controller however does not configure under NetBSD, but NetBSD lacks true ACPI support, even in NetBSD 2.0, so this was expected. A quick test and I'm online through my cell phone, GPRS, and the required USB cord - yay! startx fails. So I configure it. It still fails. I search online and steal a known working and plausible configuration. It fails. I tweak things. The best I can do is get the machine to stop responding as X goes into an endless loop trying to reset the Lynx3DM video chip. Googling for the error message, it turns out that Lynx support under NetBSD and OpenBSD has been broken for about 5 years now. Well, crud. I won't hold my breath then. I use the pre-break version of X, which is a pain to configure (but nothing I haven't done before), and it has the same problem. Crud! Both XFree86 and X.Org have the same problem and the same neglected bug report. I quickly figured out the machine wasn't really locking up, just failing to respond to keyboard input, so I'd run a sleep 60;reboot in another virtual console every time I tried to start X with a new configuration.

FreeBSD goes next, as it's still mostly what I'm used to. It installs, finds everything including the cardbus controller, but USB is hosed and I can't connect with the cell phone. This is after loading all of the right kernel modules. After chatgets the cell phone "dialed", pppd just sits there. Forever. If I try to kill it and run it again, chat sees all of the data the modem tried to send but pppd didn't get last time. Futzing with clocal and company doesn't help. Didn't try X - I need some comfort of success at this point so I'm trying Linux.

Slackware - X works. Thank god. At least I can use this thing for something even if I'm confined to the LAN. And it recognizes the cardbus controller. That's good. Maybe a Sierra wireless card will work. Anyway, I should go back try and FreeBSD again since Linux also won't talk to this phone either, having the same problems as FreeBSD. I have no great love of this Motorola v66 phone. However, installing Slackware was... interesting. *BSD's floppy boots recognize the USB floppy drive correctly and once they read in all of their disks, they're happy to install from CD, ftp, the web, NFS, a DOS partition, and any number of other things. Slackware has fewer install options and the floppies didn't understand the USB drive. Searching around, this is a common problem that most Linux distros suffer from. So I turned my swap partition into an MS-DOS filesystem and took a whack at Zipslack. Zipslack's install insructions were short and sweet: according to it, all I had to do was unzip the zipslack.zip file onto the MS-DOS paritiotion (off of the root) and then it would boot and could run Linux. Not so. The documentation entirely forgot to mention that DOS is required (it mentioned that Windows 95/98/etc should boot into DOS mode instead of Windows mode). There was a boot floppy, so I used that experimentally. When it came up, it found init and ran it, but it failed to find agetty. Crud. How come nothing ever seems to work for me to any degree adequate to be useful? Why? So I think, okay, maybe the unzip utility I have for NetBSD isn't doing the filenames right for UMSDOS and I download MS-DOS 8, boot that, and try to look at the C: drive - but there are no files. Turns out, not only did NetBSD not unzip the files correctly, it didn't even make the FAT32 partition correctly! I had to reformat it and use an old PKWARE MS-DOS unzip untility before the boot disk would actually be able to find the files correctly, using their long file names and the UMSDOS conventions. Suck. The PKZIP utility took *hours*, running without the benefit of disk cache. Before UNZIP'ing though, I used the SYS.EXE utility to make C: bootable (booting into MS-DOS 8), whereupon SYSLINUX takes control and hands it off to Linux. This works nicely. But the version of MS-DOS 8 I pirated apparently came from a Windows-95 boot disk. Booting into Zipslack first flashes the cloudy blue Windows 95 logo screen. The Zipslack instructions describe how to make a real Slackware system, with an ext2 filesystem, using the Zipslack install, and the instructions again were short and sweet. Make a few directories, do a few cp -a commands, run lilo, and you're done.

Well, lilo won't work. I can't get the online examples to work. I can't get the example in its docs to work. Yes, I know how Linux names the drives and partitions and my partitions are correct. It gives a vague error and exits. No where is this error defined. A quick look around at other bootloaders saddens me - I couldn't find a Linux bootloader with less than 7 stagers, other than SYSLINUX, so fuck them all, I'm booting into MS-DOS and using SYSLINUX to boot with the ext2 partition as root. Keep it simple, you god damn fucking morons. By the way, there's no good reason on god's green earth to have more than 3 stages in a bootloader, and the only reason there should be more than 1 stage is so that you may have a master boot record independent of all of the operating systems installed, boot records for each OS installed, and then a more involved boot routine that couldn't reasonably fit in the partition boot sector. Linux doesn't seem to get this. The 2nd stage boot loader should do nothing but examine the file system, find the file containing the 3rd stage boot loader, and run that. If logos need to be displayed and menus presented, do it in the 3rd stage. As it is, the 2nd stage boot loader can't even navigate the file system, so the whole boot process is fragile - you can't just copy the files, copy the boot sector and start the system. And with the 9 stage boot loaders and the 7 stage bootloaders (I wish to god I were making this crap up), they can't even figure out how to leave the OS-netural master boot record alone - they have to control that stage as well. Even though LILO claims it doesn't have to - it refuses to work with this vague error unless I let it have the master boot record. This isn't a graceful approach - it's nihilism - "all 9 stages or NO stages for you!".

But Zipslack morphed into Slackware very nicely. Slackware's package system is nice for the right reasons - it isn't fascist. It doesn't force you to uninstall all of your packages before installing any new package. It lets old libs and binaries lie around, just like Unix has always gracefully handled. It doesn't attempt so much control as to be error prone and fragile. In the event of an error, it'll be of the sort that's easily corrected by hand. But Slackware doesn't seem to want to mount a ffs (fast file system) partition, and all of my /home data is on a ffs paritition, meant to be shared between whatever OSes wind up cohabitating on this little bastard. So I guess I'll try FreeBSD again and if X doesn't work there, I'll have to move all of my /home data off, turn the filesystem into an ext2 filesystem, rsync the data back on, and reinstall Zipslack and then hop over to Slackware - and for however long this "tough" book lasts, suffer mild confusion in those rare cases where I have to reboot and am presented with the Windows 95 logo screen.

-scott


A few more oddities on the Panasonic...

scrottie on 2004-12-04T23:19:12

I tried to run the working Linux X.Org X server in NetBSD under Linux emulation, and with a symlink between /dev/console and /dev/tty5, it got as far as the mmap of video memory before it failed with a mysterious signal 11. Dang! Almost worked! Also, the keys on the Panasonic Toughbook are awkwardly small. I own an old Compaq Aero 4/25 which is an antique 486SX25 that's smaller than almost every other laptop I've seen. It's a little deeper, but it's just barely larger than a handbook format book, and it has tiny little keys. Well, the Toughbook is worse. I'm cocky about being able to type well on undersized keyboards, but this one is clearly meant for Japanese fingers. I fat-finger everything. By the way, I'm not typing on it now. This will take some serious adjustment - and I'm afraid that I'll continue to avoid using it. The Fujitsu P1120 has a normal sized laptop keyboard, with keys 0.7 times those of a standard keyboard; this thing is closer to 0.5.

-scott

SMI_GEReset flood on FreeBSD, still

scrottie on 2004-12-05T03:32:28

Nope. *sigh* FreeBSD has the same problem as NetBSD and OpenBSD - the Xorg.0.log in /var/tmp is just a flood of SMI_GEReset messages after the point where it should have started up.

NetBSD's lfs, the log structured file system, is 100% unusable, reliably crashing a machine daily, yet it's been listed as supported and available without any warnings for years and years. And there's a flood of bug reports, all of which get killed as duplicates. This is just another case where Free Software turns a blind eye to a flood of bug reports and instead of shitting or getting off the pot (fixing it or disabling the feature), they just leave it out there to fuck up poor suckers. In this case, the poor sucked popped $1000 for a laptop - and that's a hell of a lot of money for someone who is always behind on his college loans and works 14 hours a day trying to keep his head above water. If it would spite you, I'd install and run XP, but I know you fuckwads don't care that Linux+BSD only have about 1% share. And you're all liars anyway. You all say you run Linux but you don't. You sit on IRC channels, or shake my hand in real life, boast you run Linux, then you email me by way of an IP that only hours early registered hits from an XP box. If you toed the same line you preached this crap wouldn't go ignored for 5 years at a time.

-scott

Knoppix to HD

scrottie on 2004-12-05T21:17:03

I've used Knoppix before when I was otherwise doomed to borrow someones Wintel box as all my of my VGA-signal-producing or displaying hardware was down for the count. It's not as cozy as my little NetBSD install but I've come to get pretty good at getting my work done using it. While running NetBSD I'd steal large numbers of libs and binaries from it as it presents a whole running systems worth in an easy accessible location - not futzing with dependencies and brain dead package systems further aggrivated by running on a non-native system. And I've you've been following this discussion, you know I don't have a CD-ROM drive for this thing - sorry, ran out of money.

KNOPPIX will install itself to a HD - this isn't what I'm talking about because I couldn't boot KNOPPIX in the first place to do the install! Instead, I had to install KNOPPIX from outside of KNOPPIX. When KNOPPIX installs itself, it extracts the contents of its compressed file system to an ext2 filesystem. I just copied the compressed filesystem image itself over, leaving it read-only.

I found this page on installing Knoppix to a flash harddrive and said "close enough!". The instructions are good. However, I still had some trouble, which is why I'm posting. Hopefully this will further clarify. This should apply equally to any KNOPPIX-derived live boot CD (such as the one the above link is to).

Here are the five essential ingrediants to a Knoppix install: LILO (or some other bootloader), boot.img, the kernel, miniroot, and the huge KNOPPIX file. In different (later) versions of KNOPPIX, the exactly arrangement of these parts (which contains which others) varies but the parts always exist. I think. Later KNOPPIXes changed the early boot procedure and dropped boot.img I think.



boot.img contains the data from a 1.44 meg 3.5" floppy disk. This can be written to disk and used as a startup disk for systems that don't know how to boot from CD. More commonly, though, this is the CD boot file. The El Torito bootable CD specifications requires the CD to pick a 1.44 meg file of the same format as a floppy disk and use that to boot from (strictly speaking, it doesn't have to be 1.44 meg, but other sizes aren't handled well by various venders). On Knoppix 3.2, this contains SYSLINUX, the bootloader (in place of LILO) and the kernel. The floppy is of the UMSDOS format (MS-DOS extended with Unix permissions and long file names), and SYSLINUX is the DOS-mode Linux boot loader. This boot image also contains miniroot.gz, the next stage. When SYSLINUX boots the Linux kernel, vmlinuz, it passes it several parameters one of which is initrd=/boot/miniroot.gz or something close. This specifies that miniroot.gz should be used as an initial ram disk to run from. KNOPPIX 3.2 has this in the boot.img as part of the boot image; later versions of KNOPPIX can't fit vmlinuz and miniroot.gz both in 1.44 megs so miniroot.tgz is moved off the boot image.

miniroot.gz is a compressed ext2 filesystem. If this file is part of the boot floppy, it may be extracted from the boot floppy, uncompressed, and mounted with loopback like gunzip miniroot.gz;mount -o loop miniroot /mnt/miniroot because we're throwing away the boot floppy in this process and installing LILO.

When the system is finally loaded, this ram disk initialized by miniroot is still in place and it specifies the basic directory structure (all of those symlinks you see when you ls -l /). It contains a linuxrc file, a static/ directory containing very few executables, and a modules/ directory containing cloop.o and several SCSI card drivers. linuxrc is a shell script. It parses and handles most of the boot-time command arguments you give KNOPPIX. It tries to load to various SCSI modules and mounts various CD ROM devices looking for the KNOPPIX/KNOPPIX file which is the next and final stage in the boot process. When it finds KNOPPIX/KNOPPIX, it loads the cloop.o module and mounts KNOPPIX/KNOPPIX loop-back using it. KNOPPIX/KNOPPIX is a compressed filesystem image, and cloop is a special version of the loop filesytem layer that uncompresses on the fly. linuxrc hides errors and gags most output in general and my boot was failing, so this was my successful point of attack: I rewrote the file so it did little more than a few mount || echo "failed" operations:
mount -t ext2 -o ro /dev/hda1 /cdrom || echo "sdw - uh oh, mount of /dev/hda1 /cdrom failed"

if test -f /cdrom/KNOPPIX/KNOPPIX; then
echo "sdw - looks like we found it so we're trying to cloop it"
fi

insmod -f /modules/cloop.o file=/cdrom/KNOPPIX/KNOPPIX
mount -t iso9660 -o ro /dev/cloop /KNOPPIX || FOUND_KNOPPIX=""
There is more to my linuxrc than this but this is the interesting bit. All of the failure cases were removed as were the subroutines and variables. The bit that got me was the last line in the previous listing: the version of cloop I had taken from KNOPPIX 3.2 didn't like the KNOPPIX 3.4 KNOPPIX file - it found a very large block it couldn't allocate enough memory for ("out of memory allocating...") but this error wasn't reported by the stock linuxrc. The documentation for KNOPPIX documents a dozen different ways to tell KNOPPIX to boot from a HD using parameters such as BOOT_IMAGE fromhd fromfile and others. Looking at linuxrc, however, only one of these was actually implemented, so I suspect the documentation is accumulated cruft and indecision. Rather than guess which one applies, I found it easier to just hard-code it, but if you're stuck with booting from CD, you might consider just mounting boot.img and miniroot.gz under loopback and inspecting the file to learn which one it really is for your version of KNOPPIX.



KNOPPIX/KNOPPIX is a ISO9660 file system where individual files are individually compressed according to an optional ISO standard that mkisofs knows to create. As I write this, there is no other way to read this image than with cloop, but fear not, the source to this module may be downloaded and compiled, and some kind soul has explained how. You shouldn't need to do this if you're just copying the KNOPPIX file over to your HD.

Back to LILO. With a customized linuxrc, you need almost none of the extra= parameters. There, that was easy!

You'll want to use the instructions I linked to initially as your primary instructions for actually doing the KNOPPIX HD install - I haven't given the actual commands or specified what gets copied where or explained how to configure LILO. This was just some background on what the parts are, how to really get at them, and how they interact. Good luck!

-scott

Re:Knoppix to HD

scrottie on 2004-12-06T02:12:15

Changes for KNOPPIX 3.6: ISOLINUX is used instead of SYSLINUX. Apparently the isolinux.bin file, which was created with the configuration in isolinux.cfg, understands how to talk to the BIOS and get data from the CD-ROM in order to fetch the kernel and it's root disk. Per the isolinux.cfg, there are two kernels: linux24 and linux26 which use minirt24.gz and minirt26.gz respectively. These files are no longer bundled up inside of a boot.img file but are on the main CD filesystem in the boot/isolinux directory.

-scott

Re:Knoppix to HD

scrottie on 2005-01-03T12:49:44

Ahhh, a little more on the KNOPPIX system. There's a cloop module that a compressed filesystem can be mounted through (it's a filesystem layer, not a filesystem, apparently). But only one cloop device can be mounted at a time. http://www.lugatgt.org/articles/smallfootprint/ explains how to uncompress (and compress) this filesystem: the magic is in the extract_compressed_fs and create_compressed_fs commands.

Re:Knoppix to HD

scrottie on 2005-01-03T13:01:02

Based on the extract_compressed_fs and create_compressed_fs utilities, here's a script to modify the KNOPPIX-based LNX-BBC image. It uncompresses the compressed filesystem, mounts it lookback, copies in whatever, and then recompresses it.