Transferring the Crux ISO to USB

A day after I sidestep my way into a Crux installation to avoid USB CDROM issues, I find this brief set of notes reprinted to the Crux mailing list. If I understand it right, it’s a step-by-step conversion of the Crux ISO into a bootable USB, which I can only assume allows external sources for the installation process.

As a review and for my own notes, doing this on an Arch system basically required:

1. mkdir -p /mnt/{loop,usb}
2. yaourt -S dosfstools syslinux
3. fdisk /dev/sdb
1. o
2. n
3. p
4. 1
5. (enter)
6. (enter)
7. t
8. 0b
9. a
10. 1
11. w
4. dd if=/usr/lib/syslinux/mbr.bin of=/dev/sdb
5. /sbin/mkdosfs -F 32 /dev/sdb1
6. mount /dev/sdb1 /mnt/usb
7. mount -o loop,ro crux-2.6.iso /mnt/loop
8. rsync -aq /mnt/loop/ /mnt/usb/
9. umount /mnt/loop
10. mv /mnt/usb/boot/{iso,sys}linux
11. mv /mnt/usb/boot/syslinux/{iso,sys}linux.cfg
12. sed -i -e ‘s/isolinux/syslinux/g’ /mnt/usb/boot/syslinux/syslinux.cfg
13. wget -O /mnt/usb/crux.squashfs http://jaeger.morpheus.net/linux/crux/tmp/crux.squashfs
14. wget -O /mnt/usb/boot/initramfs http://jaeger.morpheus.net/linux/crux/tmp/initramfs
15. umount /mnt/usb
16. syslinux /dev/sdb1

In my case though, it wasn’t the magic bullet. I can boot the USB stick and the familiar Crux header spools past, but at the “module loading” step, both squashfs.ko and isofs.ko are spat back, with the message “device or resource busy” … and I get no farther than my previous attempts with the actual CD.

No harm done. I am learning slowly from these things. And it’s rather gratifying to build a USB stick that will boot. I shall have to experiment a little more and see if there are any other CD-based distros that I can convert to bootable USB. Some already have that — Arch for example has img files, which are wonderful — but some would be nice to change over.

But in the mean time, my scheme for installing Crux on the X60s remains the same. Now to put my evil plan to work. …

One short note: Compiling times

I forgot to mention two small but important things yesterday. Both of these were done with MAKEFLAGS="-j2" because otherwise I notice that the workload bounces between cores. …

• Time to compile a 2.6.30.7 kernel configured for a Pentium: 4 minutes, 17 seconds.
• Time to compile gcc 4.4.3 with -march=pentium: 42 minutes, 8 seconds.

That’s why I bought this machine.

Circumventing a lack of USB CD support

I don’t go looking for problems, I swear. It’s not in my character. All these little puzzles and conundrums that I document usually happen to me without active efforts to search them out. Trust me: The last things I need to do is to go looking for more problems to solve.

This time though, the issue is fairly easy to identify but requires a few steps to get around. It seems that the Crux 2.6 installation CD doesn’t carry support for USB CDROMs in its spinup sequence — which means the disc will boot, but it’s unable to reach the login prompt because it can’t find the source drive. I’m guessing the kernel lacks whatever module is necessary to find it, but of course I am probably wrong.

In this particular situation I was rebuilding the system for my Pentium. Since the X60s uses SATA drives instead of the old IDE connection, I have to use an external enclosure to connect to the machine anyway. However, just chrooting into the external drive causes Grub some confusion when I try to install it, so I went with another approach.

I installed a very very basic version of Crux within Qemu, booting from the ISO file and setting the disk image file size to something similar to the size of the target drive. In retrospect there was no need for that; just setting it to something smaller would save time later, and avoid discrepancies between the actual size of the drive and the size of the image. You know, that whole 40-gigabyte-but-not-really-because-companies-count-differently-from-normal-humans thing.

The problem with Qemu is that virtual systems (in my meager experience) don’t run at full speed, and I want this machine to compile without the need to manage X, the desktop, etc. So I passed the compiled kernel from the old system across the Internet to the virtual system, then installed Grub to get that chore out of the way.

From there I used dd to send the image to the actual drive, which even on USB2.0 was rather time-consuming. When it was done though, I could chroot into the system in the same manner as is suggested in the Crux handbook. With Grub no longer an obstacle, I could build a fresh kernel and continue installing at full speed.

And lucky me, when it was all said and done, it booted fine and worked just as well as the standing installation.

I suppose I should mention that all of this was done from within Arch, although that might have no bearing on the final results.

My plan at this point is to use a similar trick when I install Crux on the X60s itself, which was my original goal. I may take a shot at transferring the Crux ISO to a USB flash drive and seeing if that will boot through, but to be honest, I have my doubts. I’ll check on #crux to see if that behavior is planned in the first place, or to see if there should be a bug report somewhere. I don’t know anyone with a netbook that uses Crux, but it seems that computers like that would also need to be able to boot from a USB CDROM to install.

I won’t call this “solved” just yet, but it’s at least workable.

A bare minimum

This might sound odd in the wake of my purchase of a core duo machine last week, but even before that I was pondering exactly how slow a machine I could conceivably step down to, without inconveniencing myself to the point of affecting my work or leisure.

After all, I can comfortably handle around 90 percent of everything I do with computers with a measly 120Mhz Pentium, and the only things that are missing are CD access and DVD rip playback — both things that the hardware just isn’t prepared to handle in a 14-year-old computer.

At the same time the 550Mhz Celeron which has accompanied me through thick and thin over the past two years is decidedly strong enough to handle everything I do, and play movies and give me CD access (reading but not writing). So I could argue that a Pentium III-grade machine is actually overkill, if the burden of performing all those things doesn’t at least make it sweat a little.

If I had to put a number on it, I think I could get away with a 300Mhz Pentium II machine: Something with about 32Mb of memory in it although more is always better, proper framebuffer access (unlike some machines I have known), a decent audio card, as few fans as possible because there’s no need for the noise, perhaps a CD writer and some way of accessing a network through PCMCIA or USB. I don’t ask for much.

I am 99 percent sure that machine would cover all the essentials for me. The limiting factor is mplayer of course, and the limiting factor for mplayer would be whatever codec is the most difficult to handle. But removing that from the equation means an even slower machine is just as useful.

The irony of this is, about two years ago I had a machine of those exact specifications but handled most of those tasks graphically — to include video playback — instead of really taking advantage of the hardware and relying on the console. Hindsight is 20-20, but I have a feeling I could get a lot more out of that machine now, knowing what I know now and having a better grasp of things.

But no matter. It’s very unlikely that I will be liquidating my entire menagerie any time soon, and trading up for a single Pentium II. I have a feeling I could do it, but it’s not something I plan on.

Picking an external DVD drive

A long time ago I thought it was good to see the old printer ports phased out of laptops. Then the PS2 mouse plug started to fade away. When floppy drives disappeared I was a little concerned, but it hasn’t really affected me much. This X60s is the first machine I’ve ever bought that came without an optical drive though, and considering that was one of my reasons for needing a new computer I pondered it greatly before buying this one.

But that is a problem easily solved with about US$50 at my local electronic department store, on the way home from work. I have a bad habit of simply grabbing something off the shelf without double-checking its compatibility, but I do admit I check the label against what I know before I purchase.

This time though, I just yanked a Buffalo DVSM-PN58U2V off the shelf and walked to the counter. Careful Linux consumer be darned, I was going to go crazy and take my chances. I paid my money, came home and plugged it in.

And not only does it get its proper attention from Linux, but the BIOS in this X60s likes it too. I can boot off CDs (which was my main concern) and write ISOs out to disc too, so my adventures in restoring old hardware to full function can continue unabated.

My only caveat if you decide on the same one, is that the surface is that over-polished sheen that seems to be the rage on laptops these days. Personally I hate that, because it picks up fingerprints like crazy. So I leave the protective plastic cover on mine — much like I do with my cellphone. It’s a small layer of protection against dinks and scuffs, and doesn’t look like an entire primary school ate cookies and Kool-aid and then mauled your DVD burner.

And on that note. …

X60s + Arch Linux = Pure love

After double-checking all the minor details with Ubuntu, I decided it was time to regain a little speed again, and tinker with Arch Linux on my X60s.

Whoooeee. Now that’s fast. Ubuntu was a pleasant experience on a machine this quick, but Arch is like a caffiene buzz. If I hotwire the /etc/inittab to go straight to X using one of the methods here, I get from Grub to X in under 17 seconds. Memory use is only 44Mb with X, IceWM and a few other programs running, according to htop.

That’s pretty darned impressive. Not the best ever, but still quite nice considering the array of machines I have used in the past. I seem to remember the 1Ghz Inspiron bouncing to an Openbox desktop in only 16 seconds with Crux, but I might be conveniently misremembering that.

In any case, Crux is probably the last stop on this little distro-hop adventure. Between these two dustups with Ubuntu and Arch and the information at thinkwiki.org, I have enough information now about the underlying hardware to confidently put together a proper custom kernel, and see if the machine will start.

Beyond that … I don’t know. I hadn’t really thought that far into the future yet. …

Wubi does the job

One thing I forgot to mention in my description of the X60s was that I took my first swing at Wubi yesterday. I’ve never really had the occasion to use Wubi, because I haven’t had a Windows-based machine in the house in so long. I knew of the project and I knew of the principle, but this was an introduction.

And for me it actually worked — I say “actually” only out of surprise, not out of any disrespect for the application. The slowest part of the installation was the actual downloading of the ISO, which seemed to be getting rather weak connection speeds. I wanted to kickstart that process by dropping an ISO into the directory for Wubi (I keep a few backup ISOs on an external drive, just in case), but I couldn’t find the target location, so I just let it run.

After that it worked quite well. I like that I had the choice of operating systems at startup, but I disliked that I had to also tell Grub to boot (I know, that’s the default behavior for a dual-boot system in Ubuntu; there are ways around that). Aside from those miniscule startup points, there’s little difference between running a “classic” dual-boot system or one injected with Wubi. For my money, at least.

It may have been my imagination, but I could swear that running Ubuntu through the NTFS file system was a little “groggier” than usual. I don’t hold much love for Gnome Ubuntu anyway, but I have since cleaned out that Windows-grafted system and built a pure default ext4 system, and everything is a tiny bit snappier.

I should probably expect that though. I can be fairly certain that the tech staff at the store where I bought this didn’t install Windows XP with speed in mind, and that coupled with my own prejudices against Windows and its inability to satisfy, and I shouldn’t be surprised I sense a certain slowness in a split installation like that.

No matter. I doubt it will be often that I find myself in a situation where I will be running both operating systems on this machine. I had no issues using Wubi to half-step into a Ubuntu installation, and move me a little bit closer to a full, Linux-only arrangement. In that sense, I give it a thumbs-up.

Hello Thinkpad X60s

I finally set my mind to the task and came home with a new computer yesterday — and this time it’s not a 10-dollar wonder from the recycling shop.

Meet LV-A8280, a Thinkpad X60s with a Japanese keyboard.

This has the L2300 Yonah dual core processor, and I see wild unsubstantiated rumors on thinkwiki.org that its battery life will crest eight hours. I know, it’s crazy: I have a machine that runs faster than 1Ghz and has a working battery. Welcome to 2001.

Also included in the deal were a whopping 512Mb of memory, an 80Gb SATA hard drive, an Intel 82573 Gigabit connection and an Intel PRO/Wireless 3945ABG wireless connector, and with Intel’s 945GM graphics subsystem. I hope this doesn’t make me an Intel fanboy for buying one; I really didn’t have a choice in picking the guts.

Final price was just under US$400, which might be a little high but includes a 30-day guarantee, and judging by ebay it’s not too far off the mark. I had a chance to pick up a low-end X61 (no “s”) but I couldn’t see spending almost US$200 more for a machine that only had a small bump in processor power, a larger hard drive and twice as much memory. If those last two things become important, I’m fairly sure I can find substitutes for less than $200.

It also came with a straight installation of Windows XP, which I considered to be an improvement over the X61 I saw, which was cursed with Vista. Not that it would have mattered much; I came home and rigged up a USB key to run Clonezilla, and mirrored the entire XP installation to an external drive before doing so much as typing my e-mail address into Explorer. I take no chances.

So far I like what I got. I didn’t need anything super-fancy, but I’ve already gotten more than my money’s worth out of the USB2.0 ports and the SD card reader (welcome to 2003 … ). I also really like the fact that it has a very small footprint, and a 1024×768 screen is just fine for me. The graphics are strong enough to show Warzone 2100 with no slowdown whatsoever, so I can even amuse myself beyond Stone Soup again.

Yes, I think I got a good one. I am sure most people would say I got a good one knowing only that I picked out a Thinkpad, but not all Thinkpads were created equal. I like this one for a lot of little reasons, and I am certain it will prove very useful in the future.

And don’t worry, I may have a somewhat-modern machine now, but I am still typing this at 120Mhz. There’s only so much convenience that contemporary hardware can offer. Beyond that, a Pentium will work just as well, thank you.

A few more Crux ports

I have a few more ports that I think I should tack up here, rather than letting them collect dust in a folder somewhere in /usr/ports/local. As always, these are either home-grown or converted from AUR PKGBUILDs via Colin Zheng’s script. First up is the nameless network monitor from a few months ago.

# Description:	ncurses bandwidth monitor
# URL:		http://headhunter123.he.funpic.de/showtopic.php?forum=programme.for&index=1
# Maintainer:	headhunter at c-plusplus dot de
# Packager:	
# Depends on:	ncurses

name=net-monitor
version=1.0
release=1
source=(http://headhunter123.funpic.de/net.tar.gz)

build() {
	cd net
	make PREFIX=/usr
	mkdir -p $PKG/usr/bin/
	cp monitor $PKG/usr/bin/
}

Not much there, but it’s a straightforward little program. This is calcurse, which was a longtime favorite in this household.

# $Id: $
# Description: A text-based personal organizer
# URL: http://culot.org/calcurse/
# Maintainer: 
# Packager: 
# Depends on: ncurses

name=calcurse
version=2.7
release=1
source=(ftp://ftp2.culot.org/culot/$name-$version.tar.gz)

build () {
	cd $name-$version
	./configure --prefix=/usr \
		    --disable-nls

	make
	make prefix=$PKG/usr install

	chown -R root:root $PKG
}

A long time ago someone mentioned zile, and I dutifully compiled it, but it’s not to my liking. Either way it might be interesting to someone who needs a slimmed-down emacs.

# Description: 	Zile Is Lossy Emacs
# URL: 		http://zile.sf.net
# Maintainer: 
# Depends on:

name=zile
version=2.3.9
release=1
source=(http://ftp.gnu.org/gnu/$name/$name-$version.tar.gz)

build()
{
    cd $name-$version
    ./configure --prefix=/usr
    find -name Makefile | xargs -n1 sed -i 's|makeinfo|true|g'
    make
    make DESTDIR=$PKG install
}

I mentioned ncmatrix on the Software page but haven’t really shown it in action. That would be because it looks and behaves so much like cmatrix that it’s difficult to tell them apart sometimes.

# Description:	NCMatrix is a modified version of the CMatrix screen saver with added network traffic monitoring.
# URL:		http://webpages.charter.net/tux/ncmatrix/index.htm
# Maintainer:
# Depends on:	ncurses

name=ncmatrix
version=1.0
release=1
source=(http://webpages.charter.net/tux/$name/$name-$version.zip)

build() {
	cd $name-$version
	./configure --prefix=/usr
	make 
	make DESTDIR=$PKG install
}

Here’s task, which is one of many command-line task organizers.

# Description: A command-line todo list manager
# URL: http://taskwarrior.org/projects/show/taskwarrior/
# Maintainer: 
# Depends on: gcc ncurses 

name=task
version=1.8.3
release=1
source=(http://www.taskwarrior.org/download/$name-$version.tar.gz)
build () 
{ 
    	cd $name-$version
	./configure --prefix=/usr
	make 
    	make DESTDIR=$PKG install
}

And this is microdc2, which I put together one day a long time ago. I don’t know anything about it or how it works or what good it is, which begs the question of why I bothered in the first place.

# Description: Command-line based Direct Connect client that uses the GNU Readline library for user interaction.
# URL: http://corsair626.no-ip.org/microdc
# Maintainer: 
# Depends on: libxml2 readline

name=microdc2
version=0.15.6
release=3
source=(http://corsair626.no-ip.org/$name/$name-$version.tar.gz 
	logfile_segfault.patch 
	libxml2-configure.patch)
build () 
{ 
	cd $name-$version
	patch -p1 -i ../logfile_segfault.patch
	patch -p1 -i ../libxml2-configure.patch
	./configure --prefix=/usr
	make 
	make DESTDIR=$PKG install
	rm -rf $PKG/usr/share/locale
}

I think that’s about it for now; that will at least allow me to trim away some of the bulk in that folder.

Dual booting Debian and KolibriOS

KolibriOS is very impressive stuff, and after finding a brief set of instructions for installing it to a hard drive, I had a “dual-boot” system of both Debian and Kolibri running on the old Thinkpad 560e that’s still floating around the house.

It’s not as hard as it might sound; the instructions I found here from a few years ago still work fine with Debian stable as a host system. I can’t tell you why decided to use Debian, other than the fact that the CD was already in the drive.

And chances are I doubt it really matters which other Linux distribution you use as host, because the symbiont is tiny by comparison. If you give it a FAT32 partition of its own, you can save files to and fro and between the operating systems without having to rely on something like a floppy drive as an intermediary.

For my own purposes, this is what the partition array looked like on my test machine, with a slot specific to Kolibri.

/dev/hda1 64Mb /boot ext2
/dev/hda2 128Mb swap swap
/dev/hda3 1Gb /dos fat32
/dev/hda4 ~ / ext2

That last partition was whatever space happened to be lying around. It was more than enough to hold an entire Debian stable command-line installation, while the /dos partition was where all the Kolibri goodies sat — and a gigabyte was way too much space for that, too.

In any case, I had a place to read and write screenshots or text files or what have you, and move them between operating systems. Primitive, but on a machine with no CD, no floppy, no USB and network access only while in Debian, I am hoping you can forgive me.

Once Debian was installed, I got the machine online and added syslinux and p7zip-full. The former brings in the memdisk package, which will allow you to boot straightaway into Kolibri off the hard drive, and the latter makes unzipping the .7z format a little easier. If anyone on the Kolibri team is listening, it’s probably not necessary to compress a 5Mb ISO down to 3.5Mb, but do as you will. …

Download the floppy image with wget, expand it to the /dos partition and keep an eye on where the kolibri.img file lands. Then edit your /boot/grub/menu.lst file to add something like this.

title KolibriOS
root (hd0,2)
kernel /memdisk
initrd /kolibri.img

As always, pay close attention to the root designation if you changed the array from what I had, and to the location of the .img file, relative to the top level of the partition. In other words, don’t prefix the kernel or initrd lines with “/dos/”, because it won’t work.

After that it’s simply a matter of rebooting. If everything is set correctly, Kolibri should running in only a few moments, far faster than by floppy. At 166Mhz and with a horrid 2Gb 4200rpm drive, it’s up and running in less than 5 or 6 seconds.

The downside is that the video card in the 560e is officially certified VESA1.2 — no ifs, ands or buts. That explains why no Linux distro to date could push it beyond 640×480, and why even Kolibri can’t push it past 640x480x16. And that depth is utterly unattractive, with color smears and ruined visual effects everywhere.

No matter. I have other uses for that machine, and not all of them require a decent visual interface. …