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
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.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=""
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.
-scottRe: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.