Reposting this here, as it is was one of the pages in danger of being lost on my old demon webspace.

This is my (now rather old) write-up of installing Linux on one of the older Sony laptops at work. As I managed to install using the PCMCIA CD-ROM, and get the sound, pcmcia, floppy & software modem working, it may be of interest to someone. Food for TuxMobil & Google at least.

I don't have exact specs for the machine, as I wasn't involved in its purchase and was just given it to use, no manuals etc. I only know the model number from the sticker on the bottom :-).

Hardware

This model features an Intel PIII 800MHz, 256k cache and 256megs of RAM. The screen is ~12inch and does 1024x768, driven by an ATI Rage Mobility chipset. The hard drive in mine is a 20gig Toshiba MK2016GAP. The unit has built in ethernet supplied by an eepro100, standard Intel chipsets providing IDE and USB. lspci:

00:00.0 Host bridge: Intel Corporation 440BX/ZX - 82443BX/ZX Host bridge (rev 03)
00:01.0 PCI bridge: Intel Corporation 440BX/ZX - 82443BX/ZX AGP bridge (rev 03)
00:07.0 ISA bridge: Intel Corporation 82371AB PIIX4 ISA (rev 02)
00:07.1 IDE interface: Intel Corporation 82371AB PIIX4 IDE (rev 01)
00:07.2 USB Controller: Intel Corporation 82371AB PIIX4 USB (rev 01)
00:07.3 Bridge: Intel Corporation 82371AB PIIX4 ACPI (rev 03)
00:08.0 FireWire (IEEE 1394): Sony Corporation CXD3222 iLINK Controller (rev
02)00:09.0 Multimedia audio controller: Yamaha Corporation YMF-744B [DS-1S Audio Controller] (rev 02)
00:0a.0 Communication controller: CONEXANT: Unknown device 2443 (rev 01)
00:0b.0 Ethernet controller: Intel Corporation 82557 [Ethernet Pro 100] (rev
08)00:0c.0 CardBus bridge: Ricoh Co Ltd RL5c475 (rev 80)
01:00.0 VGA compatible controller: ATI Technologies Inc 3D Rage P/M Mobility AGP 2x (rev 64)
  

The laptop has no built-in floppy drive or CD-ROM; an external USB floppy is provided instead, and an external CD-ROM which connects via a PCMCIA card.

Installation

I have tried installing various distributions on here.

Redhat 7.3 went on very smoothly, and presumably so will newer versions. It boots from the PCMCIA CD-ROM drive, and reads from it once booted with no problems.

Mandrake 9.1 hung after booting.

Debian can be installed, but it takes a little more work. Specify this kernel parameter "ide2=0x180,0x386" so that it can read from the PCMCIA CD-ROM drive (as /dev/hde) once it is booted.

Configuration

Ethernet

The eepro100 driver in 2.2.x and 2.4.x worked for me, others I haven't tried.

Touchpad

No idea, a colleague with a grudge against touchpads disabled the one on mine using the machine's driver disk. Apparently it works just like a PS/2 mouse though.

Video

Using XFree86 3.3.6, I installed the Mach64 server, chose a high frequency SVGA monitor setting and faked some refresh rates, and it worked fine. Did I mention I know nothing about laptops?

It works fine with the XFree86 v4.1 ATI driver as well.

fbcon works using the vgacon driver, although the boot logo colours get messed up when at the end of the kernel startup. The vesafb driver also works, and with vga=791 gives a very nice text resolution. The mach64 framebuffer driver did not work straight off, the machine didn't crash, but nothing on the screen except a few lines criss-crossing. I didn't need fbcon for anything so I did not investigate further.

USB

There's a single USB port on the side of the machine. It works fine loading the usb-uhci driver.

If you plug in a USB mouse, you should only need to load the hid and mousedev modules, and set up gpm or X to read from /dev/input/mice with input type PS2.

Floppy Drive

The USB floppy drive works fine with the USB Mass Storage Devices (usb-storage) module (note: this option in the kernel config is dependent on SCSI support, which took me a while to figure out).

Once you have usb-storage loaded, the device will be automatically detected when it is inserted. It will be assigned a SCSI disk device; it seems to show up as /dev/sdb on my machine. Edit your /etc/fstab line for the floppy drive to point to /dev/sdb; it should look something like this:

/dev/sdb /floppy auto defaults,user,noauto 0 0

PCMCIA

The single socket on this laptop worked once I loaded the yenta_socket and ds kernel modules. With the pcmcia-cs package auto-loading of drivers for PCMCIA cards and setup of devices worked nicely.

On Debian I use the following in /etc/defaults/pcmcia:

PCMCIA='yes'
PCIC=yenta_socket
PCIC_OPTS=""
CORE_OPTS='unreset_limit=400'
CARDMGR_OPTS="-d"

(The unreset_limit I added to work around timeouts waiting the the CD-ROM to spin up.)

CDROM

The CDROM supplied with the laptop connects via a PCMCIA card, so you need the PCMCIA drivers and software above and the ide-cs module for the CD itself. It will show up as /dev/hde, unless you have an unusual setup; link it to /dev/cdrom.

APM

APM is disabled in the BIOS on mine (maybe win2k didn't like it, don't know), and I use apm=on to enable it for Linux. Alternatively you can load apm as a module. Battery status reads out OK. Suspend with "apm -s" works. And it automatically powers down on shutdown once apm is loaded/enabled.

Sound

The ymfpci driver supports the built in chipset.

Modem

Unlike some laptops in the Vaio range which come with PCMCIA modems, the Z600HEK has a built in modem. It is a software modem (with a Conexant chipset), so you will need a special driver, which can be obtained from http://www.mbsi.ca/cnxtlindrv/hsf/. Binary/RPM drivers are available. I went for the source .tar.gz, which contains the source to a number of kernel modules which make up the driver, and some utilities, primarily hsfconfig which compiles and installs the modules for the running kernel, and adds the /dev/ttySHS0 device with which the modem is accessed.

I just discovered ubp-build.py today. Given a package name, it downloads the source package, installs all the build dependencies, and compiles a version of the package for your version of Ubuntu. So you can set your deb-src line to dapper, and get Firefox 1.5 compiled and installed for breezy within half an hour. From Ubuntu Forums.

I am now a complete convert to Ubuntu for desktop systems. After 6 months of use, I am running it at home, on my laptop, and at work. For the laptop there is no contest, as I don't do Fedora or SuSE, and it is just too time-consuming to configure all the power management daemons, battery and wifi applets on Debian to get sensible enviroment (in particular, rt2500-based WLAN cards, in my case the Asus WL-107g, work out-of-the-box on Ubuntu 5.10, and with the help of Ubuntu's wiki worked fine in 5.4 too).

For work, having a current version of OpenOffice without hassle is a big win. And for home, having a supported AMD64 version gives it the edge; plus the UTF-8 locale support is much more complete. I even found myself on Friday forced (by time constraints) to use it on a machine doing server tasks at work, and found that it ran the software needed just as well as Debian, my usual choice (expect for one compile glitch, which was a real bug exposed by gcc 4). (I should qualify supported, though: only the Ubuntu core is supported, the universe and multiverse repositories, which just make available Debian's wider range of packages, are only unofficially offered by Ubuntu.)

My only complaint is the upgrading between releases. It seems poorly documented, and when run from within synaptic on my laptop at work, fell over spectacularly when it decided it could not operate in my locale nor use the gnome frontend to Debconf mid-way through the upgrade. Maybe that's my fault for running it in synaptic; but that's what the first page I found on the 'net suggested, and if they don't document the right proceedure, then it's still their problem.

The Ubuntu CDs that I ordered arrived at last on Friday. I installed it at the weekend and, so far, it seems quite good.

The install was cruder than I had expected — did I hit an expert install without noticing, or does it really ask "human beings" which kernel they want? Technically I was impressed though: it picked up both other distributions installed and added them to grub, and even accepted me going behind the installer's back ane remounting the install CD in another drive when the first gave errors reading some files.

While still clearly Debian under the hood, I liked the default setup. sudo only to root is a good idea. The only thing I really had to change was to add a smarthost to the mail server setup.

So I finally got around to completing the rebuild of the gateway machine at home. I went through a lot of hassle getting the Bewan ADSL card to work last time, so this time I decided to write up the process properly, in case it is of use to anyone else. Fortunately, with a 2.6 kernel the process at least only requires a lot of sysadmin skills (unlike with 2.4, where I ended up debugging the kernel driver).

First, build your own kernel. Don't waste any time trying to get it working without this — even getting the driver compiled is a nightmare without your own kernel source tree to hand, so it's worth taking the longer route. Build a 2.6 kernel (I used 2.6.11.11 with no problems). Enable "Asynchronus Transfer Mode (ATM)", "Classical IP over ATM", "PPP (point to point protocol) support", "PPP over ATM", and "ATM over TCP" (and don't forget iptables, NAT, and everything else you will need to actually use the connection).

Once you have build this kernel, make a synlink from /usr/src/linux to the kernel source tree. Now get the bast-0.9.0.tgz from Bewan's site & extract. To compile it, you will need, unusually, the g++ compiler. First go into the libm subdirectory and make. Then cd ../unicorn_pci and make.

You don't have to do the above kernel or unicorn module compile on the machine which will actually be the gateway and have the card. In my case, the gateway machine was a very old box without enough disk space to do this compile, so I built both kernel and module on another machine. If so, now is the time to install the finished kernel on the target machine, and copy ove rthe unicorn directory tree.

The install makefile rule for the unicorn driver seems to be broken (for 2.6 kernels, anyway). So just manually copy unicorn_pci_atm.ko, unicorn_pci_eth.ko to /lib/modules/version/extra/ (where version is the version of the new kernel) (and making that directory if it doesn't exist yet). Add pppoatm and unicorn_pci_atm to /etc/modules (or whatever equivalent your distribution has listing modules-to-load).

Reboot the target machine into the new kernel. The unicorn module should load okay — check dmesg and the output of lsmod to see that everything is in place as expected.

Next, we need the userspace supporting software set up. This is much easier these days, because most distributions should ship a new enough pppd that the ppp-over-atm support is already included. For Debian, for instance, it should be sufficient to apt-get install ppp libatm1. Crucially, you should end up with a file like /usr/lib/pppd/2.4.3/pppoatm.so.

Create a new /etc/ppp/peers/dsl file, containing something like this:

noipdefault
defaultroute
sync
user "whoami@lon1-aj2d.demonadsl.co.uk"
noauth
noaccomp
nopcomp
noccp
novj
holdoff 5
persist
maxfail 25
usepeerdns
plugin /usr/lib/pppd/2.4.3/pppoatm.so 0.38

The main things in there are the username (provided by your ISP), the usepeerdns (to add nameservers supplied when you connect to your resolv.conf) and defaultroute (to add a default route going over the DSL line). And of course the pppoatm plugin.

Now add a line to /etc/ppp/chap-secrets setting the password for the username set above:

# Secrets for authentication using CHAP
# client	server	secret			IP addresses
"whoami@lon1-aj2d.demonadsl.co.uk"	"*"	"mypass"	"*"

For Debian, you can now just add this ppp provider to /etc/network/interfaces:

auto ppp0
iface ppp0 inet ppp
	provider dsl

(obviously omitting the auto line if you don't want it to be started automatically; instead, you would use ifup ppp0)

For other distributions, you can use whatever method it favours, or instead use an init script to call ppp file /etc/ppp/peers/dsl.

Question: When is an operating system not an operating system?

Answer: when a "minimal installation" takes ~770MB, includes KDE and 150MB of locale data, and requires all 3 installation CDs.

I read with interest the extensive discussion surrounding Debian's future release plans. As I have been a user of Debian, both as a developer and as part of my work, I should have an opinion. So here it is.

It might be worth dwelling a moment on just how amazing Debian's package management is. The idea of supporting — what is it, 11 architectures? — across the whole range of many thousands of packages, is no small feat. Having buildds that automatically compile packages, providing build logs so developers can see the cause of build failures on obscure architectures, and activaly blocking packages until they are able to compile on enough platforms — this has put portability and compilability of the packages as a major project goal.

If Debian is to get used on servers, it has to make stable, supported releases. There are nearly 800,000 websites running Debian now; we are within shooting distance of being on the same scale as RedHat. A year ago Debian was the fastest growing; now the moment has passed, and with Fedora making regular releases, they have got the credibility now.

It is hard to advocate Debian for use in a live application when there is no viable stable release. Nobody wants to build a server today with a 3 year old OS (age by itself is not necessarily a problem, but age and the nearness of replacement and so obsolecence is). Woody should be unsupported in 6 months; conversely, sarge may not be supported for another 12 months, for all we know right now. So which one do people like me, who use Debian on servers at work, use? Right now, while I use Debian for development systems, I don't feel that I can advocate either release for new servers.

It is not easy, looking on, to see precisely what has gone wrong. I can see that basic software, like zsync, normally makes its way into testing without much fuss. It is unclear whether the problem is purely numbers (with so many platforms, at least one is sure to have problems?) or the small developer base of some of the platforms (few developers to clear problems, manage buildds?). But it clearly has gone very badly wrong, with not only no releases for years but apparently, until very recently, no clear sign that there was any definite timeframe for getting one.

Assuming Debian targets any live, production use, it has to make stable releases. Making these releases, for i386 as a minimum, is essential for new users starting with Debian, and necessary for Debian to continue to see use in stable environments. Frankly, it's not essential for these stable releases to cover every platform, as developers can always use testing on those other platforms (and so those other platforms will not be suitable for servers). Debian should drop as many architectures from the stable release target as is necessary to make annual stable releases. Having some stable architectures is better than none.

Well, that was fun. I was using cdparanoia to rescue the content off of some old audio CDs, and Linux completely died. It managed to corrupt the root partition so badly, that after an e2fsck the only files were in /lost+found. There must be a problem with DMA and CD-audio data on this SiS IDE chipset? It must be a while since I last ripped an audio CD, so perhaps I have really never tried it on this machine before.

Fortunately /home was unaffected, so I have reinstalled Debian and am already almost back to where I started. I am glad I had a backup rfom only a couple of weeks ago — and even more glad that I wasn't forced to test it :-).

Ah, finally figured out why rxvt-unicode was giving me so much trouble. Xlib doesn't seem to grok locale aliases, so it didn't understand LANG=en_GB.utf8 (which is what Debian's libc configuration suggests) but does understand LANG=en_GB.UTF-8. Cut and paste, and some other interactions with text and xlib, were quite broken before.

I must put in a good word for rsvg, which I used to generate the PNG versions of the bootcharts that I put up previously. I have been looking for a decent SVG viewer for ages, but this tool seems to do an excellent job of rendering them to PNG which is then easily viewed — even doing quite a good job with alpha and antialiasing. Another win for command line tools, IMO.

Which OS are You?

Dead right; although to be so easily seen through I am afraid is pitiful. Now, the real question — does the quiz really use your answers, or does it cheat and look at the User-Agent: string?

So I moved ntpdate to the multiuser part of startup, and hacked /etc/init.d/hwclockfirst.sh so it didn't query the timer to work out if setting the time had freakily failed (never happens on any machine I know!) (see previous post). Startup time is now 10s (graph). Zippy. (But of course, this is without starting XFree86.)

Someone pointed out this. Looks like the kernel will in future contain this hack to filter out UDP packets with broken checksum at select time for blocking sockets. So the various select-with-blocking-socket UDP vulnerabilities have returned to minor niggles now — although the software in question is still broken, of course, but the status quo ante is restored, so it will once again be hard to trigger.

So it is not of much interest now, but in case you want it, here is my patch to detect select(2)s on blocking sockets.

I came across the cool bootchart program today. This creates an extremely nice Gannt-chart-like graph of the processes running during bootup, CPU and disk utilisation and so on. So I set it up on my machine, to see how my parallel patch for file-rc fared.

Here's the chart. It looks like my parallel file-rc is doing quite well, with 21s bootup times and excellent CPU and disk utilisation in the main startup period. I should probably ditch ntpdate or background it, and look into why hwclock is so slow - without these 15s or better is easily within reach. Nor is my machine that lightly loaded, with squid, cups and apache in the startup list.

I was installing cups yesterday, as I found a rare occasion where I actually needed to use the printer. It immediately fell foul of my kernel patch to detected select(2) on blocking sockets. For the background to this, see this linux-kernel thread, where Linux's behaviour is discussed in depth: to cut a long story short, Linux doesn't guarantee that a read(2) or recvmsg(2) on a socket won't block even if select says there is data on that socket. This is because UDP, for instance, is a datagram protocol, and is allowed to discard packets at any time, even after they have been "seen" by a select(2).

So I filed Debian bug 284501 yesterday. I have already been responsible for the fixes for this issue to inetd and syslog. The list of applications bitten by this behaviour change just gets longer. I should put my kernel patch up here soon — it's an even more gross hack than my /tmp race detector, but it does the job well enough. But perhaps I should modify it to only report UDP sockets; while TCP sockets are theoretically vulnerable, in practice it's UDP which is easily DoSed using hping2.

Don't get me wrong: I, for one, welcome our new insect overlords... erm, that is, I like the new behaviour. If a program wants not to block on a socket, it should make it non-blocking. But surely introducing this change, which breaks so many applications, when the benefits are essentially a small micro-optimisation for VoIP and realmedia users — surely we are insane to make this tradeoff? How about fixing the applications first, next time? Surely the people who needed the speedup should have been responsible for doing the background work, so other users were not negatively affected by it?

Ever wished that Linux would boot faster? Ever been frustrated that Linux, so good at multitasking, should be forced to start up all the system daemons one after another?

filerc-parallel.diff — a patch to Debian's file-rc package, which makes the system rc script start several daemons in parallel. It parallelises the startup of any daemons which are at the same "level" in the runlevel.conf file (so utilising the existing knowledge about startup order as far as possible — although by hand-tuning the levels you can get further speedups). I have been using this on my home computer for 6 months, and it seems good enough. No warranty, though!