I'm beginning to realize that Linux distributors and kernel hackers are not going to be cut a break when it comes to cheap Korean and Chinese hardware. The Pine Corporation, which makes digital audio players (the one I have is the SA-6400), is typical of the hardware manufacturers I mean - if you visit the Pine website, you get the distinct feeling that it's a fly-by-night operation. It offers no product support, no driver updates and no product-related FAQs.
The SA-6400 is a cute little player and recorder, with 64MB of built-in memory and an MMC card expansion slot. Unfortunately, there's no Linux driver for the player and no documentation from the manufacturer. Additionally, I bought a 256MB MMC card which, it turns out, was unformatted. Thus, I had to buy a card reader. I purchased an OmniFlash PCMCIA Active Adapter which (that's right) isn't supported under Linux. So I had to boot up under Windows XP to format the MMC card and to transfer files to and from the SA-6400. And guess what? There's some sort of buffer overflow bug in the SA-6400 manager software that prevents me from using the MMC card at all. It can detect it, but says the card has no available memory. The point is, don't buy the SA-6400 if you can help it.
So now I have an unsupported POS digital audio player, an unsupported PCMCIA card reader, and an MMC card that none of my devices use. Brilliant.
post a comment
| Date: | 2005-01-20 16:07 |
| Subject: | to do, etc. |
| Security: | Public |
Perhaps the biggest downside to my new laptop (which remains unnamed, though I'm quickly leaning towards naming it Temerity II) is the lack of a parallel port. It appears the time-honored parallel port is going the way of the dodo, replaced by faster and more powerful USB and firewire ports. I applaud progress, of course, but this leaves me in a bit of a pickle with my excellent parallel-based HP LaserJet 1100.
I purchased a parallel-to-USB adapter cable over the winter holiday, but it turned out to be the wrong kind of parallel plug - it was a 36-pin centronics, and my printer uses a 36-pin mini-centronics.
I can hear you saying, huh? Quick lesson on parallel port types:
DB25: 25 pins, and they usually look like actual pins.
centronics (IEEE 1284): 36 pins, and it actually looks more like a strip with a bunch of contact points on it.
mini-centronics (IEEE 1284C): also 36 pins, exactly like centronics but about half the size.
There are several other kinds, but these are the kinds I've had to familiarize myself with.
It turns out that the mini-centronics interface was made only for a short time, so finding a 1284C-to-USB adapter was a major pain. I finally found one, and my printer isn't recognized under either Linux or Windows XP. Hmmph. I ordered a mini-centronics-to-centronics adapter in hopes that this would fix the problem, but in the event it doesn't, I have a neater idea: wireless print server.
Now, I could shell out some dough and buy a wireless print server that connects my printer to the router, but remember: I have a new computer. A new computer means an old computer, and the old computer works great with the printer and has CUPS installed on it.
So, the plan is this:
1. Set up the old laptop to work securely and efficiently with the printer.
2. Set up the old laptop to accept incoming IPP connections.
3. Configure the new laptop to treat the remote printer as a network printer. The printer would be located at something like ipp://192.168.0.5:631/printers/LaserJet.
4. Configure my roommates' Macs to use the remote printer.
Voila! Or voila, I hope.
I'm looking at the following documentation/HOWTOs:
Centralized Printing Using CUPS
CUPS + KDE + Debian Testing
macosxhints - 10.3: Print to a remote CUPS server
As a secondary note, I can strip a lot of bulky software off the old computer, since it will be working solely as a server (I'll probably keep KDE because its CUPS interface kicks a lot of ass, though I could probably do most of that through a web browser). As a tertiary note, all that free disk space (getting rid of games, word processing, etc, should free up a couple gigabytes) might allow me to use the old computer as a LAN messaging server, or LAN Apache server, or streaming media server, or ... the possibilities are freakin' endless.
I'm so excited I think my glasses are going to crack. I better put some tape on those glasses.
Off to watch some Homestar Runner.
3 comments | post a comment
The migration of my slackware system to the new laptop is about 90% complete, though (I think) I'm going to be fixing things for months.
Here are the basic steps for migrating an old Linux system to a new computer, and setting that computer up to dual boot Linux and Windows XP:
1. Obviously, have your backup media handy. I used an external USB hard drive, which is much more reliable and compact than CDs (what happens if one of the forty CDs it takes to back up your system gets scratched?). Also, if you compiled your own kernel and your new machine has a different processor architecture than your old one (in my case, upgrading from a P-IIXn to a Pentium IV M), you'll need a kernel with generic x86 support built in.
2. You'll need a good Linux liveCD with qtparted installed. I recommend Knoppix.
3. Okay, first you need to clean up XP's messy data storage. With XP running, go to Start -> Run ... and type "chkdsk /f". XP will complain that it needs to do this without the disk mounted, so it will run the next time the computer boots. Restart the machine. After a clean boot, insert your liveCD, and restart the machine again.
4. Pay close attention to the Knoppix CD's different boot options. "knoppix26," booting a 2.6 kernel, worked best for me. Once booted, run qtparted from a console. This is all fairly straightforward - resize the XP partition to however much room you think XP will need, then create at least two new partitions - one for Linux, and one for swap.
5. Format your new partition: mke2fs -j /dev/hda3. Setup your backup media.
6. Mount your backup: mount -t ext3 /backup/device /mnt/backup. Also mount your new partition: mount -t ext3 /dev/hda3 /mnt/linux.
7. umask 000. This command is painfully important. It preserves the permissions of your backup data. If you don't do this, permissions will be hopelessly fucked and you'll spend months fixing little things here and there. (Yes, I'm embarrassed.)
8. cp -a /mnt/backup/* /mnt/linux/. Go watch a movie.
9. Change root to your new Linux partition: chroot /mnt/linux.
9a. At this point, if you really need to, you can recompile the kernel.
10. Edit the following:
fstab - needs to reflect your new partition setup
/etc/rc.d/* - get rid of custom commands for your old computer, and add commands for you new one (probably optional)
lilo - needs to reflect new partition setup
10a. It's not a bad idea to change your runlevel in /etc/inittab. Try booting to single-user mode or multi-user without X first.
11. Run lilo.
12. type "exit" and "shutdown -r now." Voila! You should boot to the lilo bootscreen.
Now, for the specific problems on my machine:
- My soundcard, it turns out, is actually just a chipset on a Conexant software modem. It works, but it's noisy as hell.
- The Intel 82852 graphics card is a total piece of horseshit. It's based on the i810 chipset, for which there's little support. Intel released its own driver set based on the DRI project, and though I got those drivers to work, I had to hack the source code and the whole mess is pretty shoddy. Initially, X would only boot into 800x600 display mode; I had to find yet another hack (855resolution) to get it to boot to 1024x768. How difficult is it to upgrade/replace a graphics card? I'd love to put an NVidia card in this machine, but I suspect it's more trouble than it's worth. Anyhow, the native xorg drivers don't support direct rendering; the Intel drivers are buggy as fuck, probably because they're designed for the 2.4 kernel and I'm running 2.6.9. Currently I'm compiling xorg from scratch, with the DRI project's drivers. We'll see how that works.
- The Broadcom wireless card doesn't work. Currently using my trusty Orinoco PC card.
- I'm not sure about the CD writer or DVD player yet. dmesg reported badness in some core module that (according to all the mailing lists) is associated with CD burning. We'll see.
- I desperately need more memory.
- None of these millions of multimedia keys work, of course.
BUT, there are some good points as well:
- Even without direct rendering, the i810 chipset is ten times faster than the ATI card in my old machine.
- This motherfucker can compile. It's fast, fast, fast.
- ACPI FINALLY works. I can actually use my computer without being plugged in.
- The machine is quiet and generally cool, even while compiling.
More later, post-DRI.
post a comment
| Date: | 2004-12-28 18:54 |
| Subject: | holla! |
| Security: | Public |
I received a new laptop for Christmas. It's an HP Pavilion ze4900, with some major good points:
- it's much faster than my old laptop, at 1.3 GHz.
- It has a 58 gigabyte hard drive, ten times bigger than my old box.
- The Altec Lansing sound system rocks.
- USB 2.0, kids.
- built in DVD/CD-RW.
- (Finally) fully ACPI-compliant.
The major bad points:
- The built in wifi is based on the Broadcom chipset, which apparently has sketchy Linux support.
- The Soft V94 modem is, well, soft.
- At the moment, it only has 256 GB of RAM, which crawls under Windows XP.
- Oh yes, Windows XP :(
Luckily, I backed up my old machine onto an external hard drive back at my apartment, and because I was hopeful that a pretty new laptop would enter my life, I actually recompiled the kernel for the backup so that it has generic x86 support.
Upon returning, I will:
1. Download and burn a decent Linux liveCD iso.
2. Boot to the CD and make sure it has the necessary drivers for the external drive.
3. Repartition the new laptop, with XP in the first partition, Linux in the third, and a swap partition between.
3a. Yes, I'm keeping XP. I have to run Photoshop and Dreamweaver.
4. Transfer the backup into the new partition.
5. chroot to the new partition.
6. Edit and run LILO.
7. ??
8. Reboot and see what happens.
I figure the worst thing that can happen (post-migration) is the kernel's all fucked up and I get a panic. If that happens, I may try rebooting to the liveCD and recompiling the kernel using the CD's compiler tools, or I may just say fuck it and burn iso's of Slackware 10 and start from there.
post a comment
| Date: | 2004-10-01 08:19 |
| Subject: | stuff |
| Security: | Public |
I've been irritated with Mozilla Thunderbird because its mail notification capabilities are so limited. No popups, no system tray icon, no indication of new mail on the task bar, and worst of all, there's a nasty popping noise when Thunderbird tries to play a sound file. So I came up with a fairly simple workaround using GKrellm and kdialog.
This script is called "newmail.sh":
#!/bin/bash
#check to see if script was called with "popup" option:
if [ "$1" = "popup" ]; then
#popup a passive notification box
kdialog --title "New Mail" --passivepopup "You have mail" ) &
#play a sound
play YourFavoriteSound.wav
else
#only play a sound
play YourFavoriteSound.wav
fi
In the GKrellm configuration menu, the mail plugin is located under "built-ins." It has the option to invoke a notification program, specifically a sound program; it turns out, though, that you can use any program you like. So in that box, you invoke "$HOME/newmail.sh popup." Now, whenever GKrellm detects new mail, a small popup notice appears for ten seconds.
The newest Xorg (6.8.x) supports true transparency using xcompmgr and transset. It will render any window transparent with lovely drop shadows, which is nice if you have a fast computer. Having spent a good deal of time last night upgrading X11 and glibc, and recompiling freetype with TrueType support, I can tell you that I do NOT have a fast computer. Transparent rendering brought everything to a crawl, though it was indeed pretty.
1 comment | post a comment
I recently used swaret to upgrade to Slackware 10. Everything is fine, with the exception of certain GTK applications (namely, GTK-Gnutella and Sylpheed-Claws). In these applications, odd blue lines show up between content in some windows - for example, the list of items being downloaded in GTK-Gnutella has lines separating each item, and the list of folders in Sylpheed has the same thing. I've uninstalled and reinstalled GTK+ and the like, checked dependencies, etc., but everything appears to be fine. What could be causing this?
post a comment
| Date: | 2004-08-28 16:52 |
| Subject: | stuff |
| Security: | Public |
I think I might expand this journal's purpose to include general computer/programmerish stuff in addition to journaling about my box.
Recent whatnots:
Temerity is pretty much completely upgraded to Slackware 10 (or more appropriately, Slackware current). This is always a difficult process for me, because many of the core scripts on this computer are highly customized. I wrestled a great deal with ALSA, but everything seems to be fine now. And KDE 3.3 is lovely (I downloaded it from kde.org, not from a Slackware mirror).
One strange problem I'm having after the upgrade has to do with X permissions. It used to be that if I wanted to open an X-based program (say Mozilla) as root, I could just type xhost +localhost and everything was fine. This no longer works, and now I have to su to root and type xauth merge ~current-user/.Xauthority. Still haven't quite figured out why this is the case.
I've written a really sweet wifi launching package complete with a setup script that auto-detects valid interfaces, a launch script that reads settings from a config file and even automatically assigns an access point, a safe shutdown script and an effective firewall. I have LILO set up with two different Slackware entries - Slackware and Slack-Wifi. The only difference is that Slack-Wifi passes a kernel parameter (wifi). The complete LILO entry is as such:
image="/boot/bzImage"
label="Slack-wifi"
read-only
append="rootflags=data=writeback idebus=66 psmouse.proto=imps elevator=as video=vesa:ywrap,mtrr noresume wifi"
Kernel parameters are stored at /proc/cmdline. So this line in rc.local launches the connection:
if [ "`cat /proc/cmdline | grep wifi`" ]; then
/usr/sbin/wifi-go
fi
Neat trick.
In PHP news, I've written a nifty function library that scrambles email addresses to prevent spambots from harvesting them off my website. It basically uses a Caesar cipher to generate what looks like gibberish. The main function is called grease(), and basically looks like this:
grease (email-address, number-of-letters-to-shift);
A javascript function called degrease() reverts the email address to a readable form and creates the mailto: link. I use it with a random number, thereby generating a new line of gibberish with each visit. Like so:
< ?
$num = random(0, 26);
$address = 'preston@suchandsuch.org';
$scrambled = degrease($address, $num);
?>
email me at <a href="javascript:degrease('< ? echo $scrambled; >?','< ? echo $num; ?>')">preston at suchandsuch.org< /a>.
It appears to be quite effective. I've seen a script similar to this one that uses RSA encryption to create scrambled addresses, but that seemed like overkill to me.
1 comment | post a comment
I've been thinking about an old argument between Andy Tanenbaum (the creator of Minix) and Linus regarding kernel design. Linux of course uses a monolithic kernel, which handles low-level processes, hardware and a few other things (lots of which can be converted into modules, of course). Minix is a microkernel; it handles only low-level processor-based issues and very little else. Andy's argument is for security; microkernel environments are inherently more secure, because they take far less user input (it's pretty much machine-to-machine input). Linus' argument is for speed and efficiency; the incorporation of so many modular elements results in a performance hit of 20% or greater. Minix uses a low-level kernel interface, which attempts to abstract basic service implementation from system operation policy; Linux uses a high-level kernel interface which attempts to integrate basic service implementation and system operation policy.
What I've been thinking about is a hybrid micro-mono-kernel. This isn't a new thing; there are plenty of kernel designs that put non-essential code into kernel space. But what about a kernel model that uses the microkernel philosophy of abstraction to create a modular dual-kernel environment?
This environment would consist of two parts: the core, which handles very low-level processes, and the mantle, which handles everything else. The core would consist of service implementation and would be exokernel-like - it would essentially be a tiny gatekeeper to memory and core processor function. It would contain a hook layer allowing it to interact with the mantle, and the mantle itself would handle system policy as a kind of bodyguard for the core. Any application could have access to a specific piece of memory, and certain applications could have direct access; it would be the mantle that would permit or deny this. Modules would plug into the mantle and not the core; therefore, if there's a serious problem with a module, it's possible to prevent that problem from reaching low-level hardware.
Major advantages:
Increased abstraction. It becomes possible to write modules and daemons that highly customize memory management and performance. I could, for example, design an additional abstraction layer that sits between the core and mantle and triages processes based on a neural network model.
Security. There's potentially an additional layer of protection against hardware-based exploits. It also becomes easier to develop security policies and trusted models based on kernel space designation.
Portability. It now becomes possible to patch and compile system policy components of the kernel without touching the hardware interface parts. It should greatly reduce compile time. It also becomes possible to do things like swap out the core for one designed for different hardware; imagine being able to take your entire kernel and port it, with the exact same policy setup, in under five minutes.
Major disadvantages:
Performance. The exokernel-like structure of the core might offset this somewhat.
Complexity. It would be a bitch to maintain, and bugs are bound to crop up.
post a comment
I'm compiling Xorg, and it's, um, BIG. I grabbed the CVS and it's been building for nearly two hours now.
Preliminary notes:
- You need to have bison installed to compile Xorg.
- If you have an up-to-date distro, you may very well have FreeType2 instead of FreeType. Xorg looks for FreeType in /usr/local/include/freetype/, FreeType2 is set up in /usr/local/include/freetype2/freetype. So you need to do this:
ln -s /usr/local/include/freetype2/freetype /usr/local/include/freetype
Sweet temerity is compiling her little heart out. She's currently pumping her way through X's video drivers, which (hopefully) means it won't be much longer now.
Update: All kinds of nastiness. Firstly, the newly compiled Xorg has a much slower startup than the binaries, and I notice no performance improvement. Secondly, the GATOS drivers for ATI failed to build against Xorg. Thirdly, The DRI/DRM drivers compiled and installed but won't initialize correctly. These projects don't play nice with Xorg yet, which is fine I guess, since I wasn't that impressed with their performance to begin with. I'm stepping back to the Xorg binaries.
post a comment
| Date: | 2004-06-04 12:41 |
| Subject: | currently |
| Security: | Public |
Currently: downloading Xorg from CVS. It turns out that the Slackware-current binary for Xorg was compiled against the 2.4.25 kernel; I think I might be able to squeeze a little more performance out of it by compiling it against 2.6. Also downloading the (apparently ancient) CVS for GATOS, which may or may not give me working 3d acceleration on my ATI 3D Rage Pro LT card. DRI is a much more active project, but Xorg recommends GATOS, so what the hell.
I'm also planning to work out AES loopback hard disk encryption, which I lost when my first hard drive died on me.
post a comment
Slackware has decided to make the switch from XFree86 to Xorg, which makes them one of the last major distros to do so. I made the switch myself today; after some minor difficulty (I screwed up syntax in the config file), Xorg started up like a charm. I immediately noticed much better memory management and a smaller hit on my processor. The ATI mach64 driver, however, still doesn't support OpenGL.
More details when there are more to report.
post a comment
I have a friend whom we shall call D. D. is a clever fellow, and likes to think of himself as computer literate, even savvy, and is quite comfortable in his knowledge of technology. One day, D. and I got into a conversation about passwords; it turns out that he's somewhat knowledgeable in this area, and his password consists of a string of unpronounceable characters. This provides a nice, secure password resistant to dictionary-style brute force attacks.
Later that day, I watched D. check his email, and I noticed that he only used his left hand to enter it. He told me he deliberately conceived of a one-handed password because it was easier to type. It occurred to me that the internet might be crowded with one-handed passwords (perhaps mostly left-handed, because the mouse is in your right hand).
It's important to note that I'm also an obsessive-compulsive counter, and having watched D. enter his password several times, I knew from the sound of the keystrokes that it was a six-character string.
So, a little math. Calculating password strength is a simple formula: Cn, where C is the number of characters in the character set, and n is the number of characters in the password. An ATM PIN number, for example, has 10 characters in its character set (0-9), and I'm willing to bet the average pin number is about 4 characters. So the total number of combinations for the average PIN becomes 104, or 10,000 possible combinations. A 400 MHz Sharp Zaurus should be able to perform a million guesses each second, so a brute force in this case would take very little time.
With passwords, you have 92 characters to deal with (93 if the space bar comes into play): 26 letters + 26 capital letters + 10 numbers + 30 puncuation marks. Therefore, D's password strength is 936, or 646,990,183,449. I have a slow machine, and the mdcrack hash cracking program performs about 1,145,000 attempts each second. That means brute forcing D.'s password should take me days. But then there's the one-handed thing. I can effectively eliminate all right-handed characters, and all left-handed caps (hard to hold down the shift key and type with the same hand). This eliminates all punctuation and reduces the character set to 22 characters. 226 = 113,279,904 combinations, eliminating 99.9% of combinations possible with the 93-character set. A little more observation, and I probably could have winnowed the character set down even further. At this point, a fast machine ought to be able to crack D.'s password in under ten minutes.
And so, for a good secure password, keep the following in mind:
- use the full range of characters - letters, capitals, numbers and punctuation.
- use a password that requires both hands to type.
- longer is better. mdcrack has a maximum password length of 12 characters; each character you add increases your password strength exponentially.
- never use a word you'd find in the dictionary. Most brute force crackers come with a dictionary file, some of them enormous (the one on my machine is 32 MB).
- don't use a password that has any association with your username (e.g., if your username is "spock," don't use "ncc-1701" as your password).
post a comment
My summer writing group is going to have to exist half in the ether; our schedules are simply too busy for regular meetings. Email is good for this kind of stuff, but having a correspondence archive would be nice. To whit: a PHP email archiving system.
Basically, the architecture is as such: there will be a special email address which forwards all correspondence to the correct addresses (e.g., workshop@blah.com forwards to writer1@hotmail.com, writer2@yahoo.com, etc). This email account will also retain copies of all correspondence. A PHP script will regularly access the email account, grab all email, reformat it as an HTML/PDF archive, and clear the account. This, of course, is basically a mailing list.
But here's the handy part: this PHP system will open attachments in plain text, RTF and a few other formats, convert them and include them inline. For formats it can't convert (e.g. PDF and DOC), it will Ip them up and place them in a download bin. The download bin will keep track of authorship, and a special naming system (my-new-poem.doc, my-new-poem-2.doc, my-new-poem-revised.doc) will allow the system to auto-generate a chronological list of drafts.
I should really do this in Perl, but fuck it. This should be a few days of programmery fun.
1 comment | post a comment
Let me first say, thank God for rdiff-backup. Either get rdiff-backup or RTFM for rsync. If you go the rdiff-backup route, the command you want to remember is this:
BACKUP=/your/backup/media
rdiff-backup --exclude /tmp --exclude /proc --exclude /sys --exclude /mnt --exclude /dev $BACKUP
You exclude proc,sys and dev because their contents are dynamically created at boot time. mnt is excluded to prevent backing up attached media, and potentially nasty loops (if your backup media is mounted on /mnt/backup, you'd end up trying to back it up, which could get ugly). tmp is excluded to save space, though for completeness I suppose you could back it up too.
In a nutshell: some time ago, I discovered that a former tenant of my apartment left behind a number of choice pieces of computer equipment, including an IBM Travelstar 20 gigabyte hard drive. My hard drive at the time was an older Hitachi drive with a 6 gigabyte capacity; since I was at a transitional point computationally speaking, I decided to switch to the larger drive. It worked great, and I came to rely on having all that space.
Recently, I learned why that former tenant abandoned this drive. There appears to be something fatally wrong with the head or reading arm or something. I noticed seek errors at boot time a few weeks ago, and as a precaution I decided to backup my system onto an external USB 60 gigabyte drive - this was a wise move, because the drive had only a short time to live. Tuesday night, while working feverishly on a poem, my computer locked up and the drive began making a steady clicking sound as the head either caught on something loose or broken (I can hear something rattling around inside the drive) or suffered a servo failure and couldn't read forward. I waited for some time, then shut the machine down. On reboot, the head appeared to be stuck in an unreadable position; the machine claimed that we had no readable media.
Disaster!
But as I said, luckily I backed up the system. I had another old Hitachi drive (long story how I came by it), so I knew I could get the machine up and running again. Worst case scenario, I could just install a CD backup I made a few months ago; the downside to that, though, was that the CD backup was for kernel 2.4.25, and my more recent configuration was on kernel 2.6. Important note for *nix geeks who like to tweak and customize: you can't reinstall your operating system. You have to rebuild it.
Also, thank God for rescue CDs. I booted the machine on an ISOLinux CD based on Gentoo, mounted my backup media at /mnt/backup and my clean new drive at /mnt/linux. In case you're wondering, this is how you prepare a new drive for Linuxy goodness:
mke2fs -j /dev/hda
e2fsck /dev/hda
mount -t ext3 /dev/hda /mnt/linux
The first major problem was this: the drive size was 6.0 GB, and the backup size was 6.2 GB. This means I couldn't simply do cp -a / /mnt/linux/, which would have been nice. In some cases (as with /usr), I had to go directory by directory to make sure I absolutely required the contents. Here are a few things you can ditch:
/usr/local/src/* (if you use this directory for downloads, packages and sources)
/usr/src/linux* (kernel sources)
/var/log/* (you'd be surprised how big these logs get)
/home/user-account/.kde/share/icons/icons-you-don't-need
I managed to get everything in place with about 20% of the disk left over. My second problem was that I couldn't get the disk to boot - BIOS would verify the DMI pool then hang for some reason. I figured it was a master boot record problem, so I booted again with the rescue disk and futzed around with LILO, which complained constantly about read-only directories and the like (of course they're read-only directories - I booted from a CD!). I tried this:
lilo -s /mnt/linux/boot/boot.0300 -M /dev/hda mbr
The -s option specifies where LILO should save a boot record backup; if you try to save it to the /boot directory on your CD, it will of course complain and abort. the -M option specifies the media to work with, and the "mbr" tells LILO to install a fresh master boot record. I include this here only for the sake of completeness, because it didn't work. The next boot ended with an error message complaining that the boot signature on the drive was missing or invalid.
Anyway, this is what you need to do:
- Boot with rescue media and mount your new (currently unbootable) hard drive.
- Use fdisk or cfdisk, and make sure the Linux partition has its boot flag turned on.
- See if your rescue CD uses MAKEDEV for devfs, and copy it into your hard drive's path:
which MAKEDEV
cp /path/to/MAKEDEV /mnt/linux/usr/bin/MAKEDEV
- Change the working root to your hard drive's mount directory:
chroot /mnt/linux
- At this point, you should have access to most of the console-based programs available on the drive. Take a look at lilo.conf and take note of which media it requires:
pico /etc/lilo.conf
You'll probably need /dev/hda or something to that effect. If your partition assignments have changed, edit lilo.conf accordingly.
- enter /dev, and run MAKEDEV for the devices lilo.conf requires:
cd /dev
MAKEDEV hda
LILO will fail unless it finds the required devices.
- Run LILO. If all goes well, there should now be a bootloader in your master boot record.
- Edit /etc/inittab and change your runlevel to single user, just to be safe. You can change your runlevel after you successfully boot into single user mode.
And you're all set. With any luck, that is. I had some important files missing (I couldn't get X to start because of missing libraries) - this was probably due to me skipping around inside /usr and trying to save space. Fortunately, my machine establishes a wireless connection at boot time, and I easily used swaret to reinstall things that were missing. Once I successfully booted into multi-user (non-graphical) mode, I ran pkgtool and got rid of things I didn't need. The hardest decisions to make, space-wise, were about window managers. Goodbye Enlightenment, goodbye Gnome. Sorry, kids, but I need the space. The final problem (so far) was swap. I have 256 MB of RAM, and I do a lot of compiling and programming, so swap space is important to me. On the big 20 GB drive, I had a 1 GB swap partition; since the backup data was sure to form a tight squeeze on the new drive, I couldn't really create a swap partition. My original plan was to reinstall the backup, take a look at how much space I had left over, then use parted to resize the primary partition and create a swap partition. It's important to note that parted has no idea to do with ext3 filesystems - a fact I was aware of, but had forgotten. Since I couldn't create a swap partition, I had to create a swap file - this is a bad idea, though I can't remember why. Anyway, this is how you do it:
SWAP_SIZE=`expr 1024 \* 256` (for 256 MB swap file; this saves you the trouble of a little math)
dd if=/dev/zero of=/swapfile bs=1024 count=$SWAP_SIZE
dd will create a swap file of a defined size. the "if" option tells dd which file to read from (/dev/zero is basically a null device), "of" defines the output file; "bs" defines the number of bytes to write at a time, and "count" is the size of the file. Next, turn the file into a proper swap file:
mkswap /swapfile
Then edit /etc/fstab to include this line:
/swapfile swap swap defaults 0 0
Finally, activate your swap file(s):
swapon -a
Voila! We're up and running. Currently the new drive is at 76% usage, with 1.3 GB free. I'm hugely relieved, though I don't want to get too attached to this configuration in the event I come across an affordable larger (and hopefully faster) drive. The moral of this story is: beware of abandoned hardware. It was almost certainly abandoned for a reason.
post a comment
Currently working on:
- Setting up a 60 GB external USB hard drive for backups (using rdiff-backup) and package storage
- Figuring out LS-120 disk stuff (bootability, for Zipslack or something similar?)
Ho hum. I also figured out that my hard drive won't do better than DMA2 or so because my ancient laptop doesn't have enough pins.
post a comment
These are just for my own sake.
Handy kernel parameters to pass at boot time:
psmouse.proto=imps -- forces kernel to treat touchpad as a PS/2 mouse. You can get fancier experimental Synaptics touchpad drivers somewhere, but my touchpad doesn't have any fancy features per se and I notice better overall performance with the kernel parameter. When I first used this parameter, the mouse would be unresponsive for a couple of seconds when X first started up. That has mysteriously gone away for some reason.
rootflags=data=writeback -- changes EXT3 journaling mode from its default "ordered" to "writeback," saving only metadata and increasing filesystem speed. I do notice a performance difference with writeback mode, though it's a tradeoff. The battery on my laptop is shot, which leads to the occasional power-loss situation. Recovery under writeback results in one or two wacky things.
idebus=66 -- the idebus speed otherwise seems to default to 33.
---
Little things to remember about kernel compilation:
Pretty much anything directly related to your processor should be compiled straight into the kernel. This includes flags such as the "PIIXn chipsets" flag in the ATA section.
DMA failed to work for me at first; hdparm -tT /dev/hda complained that the operation wasn't permitted. In order to get DMA working, you have to compile the following directly into the kernel (not as modules):
- ATA/ATAPI/API/MFM/RLL support
- PCI IDE chipset support
- Generic PCI bus-master DMA support
- Intel PIIXn chipset support (or whatever your chipset is)
- CMD640 (if you have a PII chipset, you'll probably need this one)
And, um, more later.
post a comment
The Netgear WG511T is the descendant of the WG511, the difference being WG511T's 802.11g support and its turbo mode (T for "turbo"). This card was a gift from my Windows-loving father, who, like many parents of Linux children (I came out of the closet a few years ago), chooses to ignore and deny the reality of my alternative computing life. Dad, therefore, did no compatibility or driver support research before purchasing this card.
( Thank goodness for Madwifi.Collapse )
post a comment
| Date: | 2004-04-23 10:30 |
| Subject: | fp |
| Security: | Public |
Temerity is my laptop. Relevant stats about the machine are in the info section of this journal.
Now, for everyone's enjoyment, a nice rambly introduction to my computing history. My first computer experience was with a Commodore VIC-20, when I was eight years old. For those of you who don't know or remember, the VIC-20 was a superb machine. Its graphics were superb, and its hardware support was astounding.
I'm joking, of course.
We used to tell this geeky Commodore joke:
Q: What do you call a Commodore 64 with half a brain?
A: A calculator.
Q: What do you call a Commodore 64 with no brain?
A: A VIC-20.
Anyway, like everyone else, I learned BASIC, wrote stupid text-based games, stored said text-based games on audio tape, and learned some painful lessons about storage media reliability when said tapes snapped like twigs in a storm after three or four plays. My next computer experience, much less programmery, was with an Apple IIGS, owned by my best friend Steve's parents. This thing really was impressive - it was the first computer I'd ever seen that could play MIDI files, which at the time seemed absolutely realistic. My favorite conversation regarding this machine:
Steve: My dad just upgraded the computer to a meg.
Me: Dude, what are you going to do with a meg? You'll never need that much space.
A few IBM PC clones aside, I eventually found my way to college and the world of Unix. The university ran primarily Windows 95 machines with an equal smattering of Unix machines (for the network, clusters and administration) and Macs (for artists and the like). This was just before the commercial advent of the World Wide Web; a few computers had Mosaic installed, but it was slow and unimpressive (especially if you knew how to use Lynx). Checking your email involved telnet and pine, which I loved, and usenet was a telnet/tin operation. Eventually I wrangled my way into the university's Unix research clusters, and I've been a *nix junkie ever since.
I've run one Linux distro or another over the years (mostly Mandrake, Slackware or Debian distros), but only in the last four or five years did I start treating Linux as a robust day-to-day system and stop dual-booting Windows. For a long time, Linux simply didn't meet my non-programming needs (I'm a writer; simple things like attractive readable fonts and non-buggy office software are extremely important to me). Now, I've settled on Slackware, which meets almost all of my needs. Arguments about which distro is better than which are totally pointless to me; Slackware is right for me. It suits my lifestyle, interests and concerns moreso than any other distro I've tried. Your mileage may vary.
Anyway, that's where I am with regard to computing. Future entries won't be quite this rambly and nostalgic - hopefully you'll find some information here that's useful to your own Linux journey.
post a comment
|
|
|
|
|
