Using dd to blank a drive

A lot of well-meaning people dumped their leftovers on me when I mentioned I was using a machine with a floppy drive, and had use for some spares. The things are like coat hangers now though — I have about twice as many as I wanted, and 10 times more than I need.

I also don’t really want to know what was on the floppy before it became mine, so I scrounged around a bit and found this as a command to overwrite the disk, until I find time to actually use it. As an alternative to the shred command. …

dd if=/dev/urandom of=/dev/fd0

The drive assignment is for Debian there, so it might be different for your distro. And changing the destination assignment will work for a USB drive or something else too. My primary school maths teacher taught us that we should always check our work, so …

dd if=/dev/fd0 count=1 | hexdump -C

That gives you a quick look at the earliest part of the floppy, so you can check and make sure what’s there is more or less unreadable. I don’t know if it’s a terrifically secure method or proof against forensics efforts, but neither of those is really a concern for me.

A simple batch encryption loop

Since I nailed down a way to encrypt files before transferring them over the Internet to a family member, I have been considering locking up a lot of the personal files I have on hand, in case they are lost or stolen. There are quite a few though, and the time it takes to step through the encryption process makes it inconvenient, to say the least.

gpg has a batch mode though, and splicing together the loop from this command and the encryption sequence from this command, plus a little help from gpg man page and elsewhere, I cobbled this together as a one-liner that appears to do the trick.

for nam in *.doc ; do echo MyPassword | gpg --batch -c --force-mdc --passphrase-fd 0 $nam ; done

The -c flag is the same as the --symmetric option, and the --passphrase-fd 0 flag accepts the password from whatever I type after entering the command … except that the echo fills that in for me. The --force-mdc option is only to avoid a warning message on the receiving end when it is decrypted, so you can omit that if you like.

I suppose it’s worth mentioning that I used detox to clean the file names a little bit beforehand; otherwise, spaces or oddball characters can interfere with the encryption command and cause the loop to halt. If you can improve upon this, by all means please let me know. I am well aware of my limitations as a script writer.

Debating a machine with few merits

My “newfound” philosophy regarding leftover parts is taking a sideways step these days, and making me reassess the less-than-a-month-old-to-me 560e I tinker with. I’m starting to feel like maybe this is one that’s worth releasing back into the wild, to find its own way.

Truth is, after a month of working with it, I can’t help but feel like it has shortcomings — a lot of shortcomings. Probably the biggest and most encumbering is simply the lack of any way to get a system on to it, without yanking out the hard drive or relying on a network connection (which of course, would require an installed system). No CD drive, no floppy that works (I’ve tried four that will connect, but none will read a disk) and short of hunting down a PCMCIA-driven CDROM (there’s an expression about “hen’s teeth” I think I could use here) and then still wondering if it would be compatible, it seems I have only one option for installing or handling hardware.

And this particular machine isn’t exactly flexible in that department either. Getting to the hard drive requires removing 14 screws, or at least about nine of those 14 and peeling back the upper plastic tray. I used to be annoyed to have to pull out a drive, plop it into a modular tray and jack it into my old Inspiron, but that was a dream compared to pulling the hard drive out of this.

I have other complaints besides just technical-unfriendliness and limited inroads for installation. Thus far, I’ve tried three different releases of Debian, one of Ubuntu, one of Slitaz and even put Windows 2000 on the machine (a lot of good that did me … Win2K wouldn’t even start), and not a single operating system has been able to show me a graphical environment. Even the framebuffer, which is usually something that I can handle myself without needing help from well-orchestrated distros like Ubuntu or Debian, or magical ones like Slitaz, can’t get past 80×60, and most crash and burn violently under X.

It’s not only frustrating, it leads me to wonder if there is some sort of minor fault in the hardware, if nobody can get something working. If something works in one distro but not another, I usually put that on my to-do list as a future challenge. But this is something no one can handle, and that has me eyeing the computer itself suspiciously. And honestly this wouldn’t be the first time something didn’t work quite “right” in it.

This isn’t an issue of function — I have a long list of things to do with a computer like this, first choice being to park it near the router, drop in a 120Gb hard drive and a halfway-decent network card, and let it seed distros throughout its remaining life. But again, I feel like a somewhat-useful 12-year-old semi-inconvenient computer isn’t much better than a somewhat-useful 8-year-old semiworking network card.

Especially because there are more options of its calibre on hand. Today at the recycling shop I saw another ten-dollar-wonder … a 133Mhz NEC Pentium, and that one with 32Mb in it and a CDROM as well. What a luxury. I didn’t ask about the model number, but I at that price I can take a chance and maybe pluck a winner from the display case. …

No, really: The initrd is too big

A while back I remember seeing news around the ‘net about Linus Torvalds voicing concern over the growing size of the kernel. Things like that are usually non-issues for me and I think they are for most end-users, but it’s the first thing I thought of when I put Ubuntu onto a 2Gb 4200rpm drive and dropped it into a Pentium with 32Mb of memory in it.

For the longest time now, my mental limbo-pole for Ubuntu on any computer has been 32Mb: Without 32Mb in the machine, the installer program twitched and flailed uncontrollably until you finally took it off life support and cut the power. You could, conceivably run Ubuntu on a machine with less memory than that, although dipping much lower — even by just 8Mb or so — left you in dangerous territory.

Or so I thought. I was pleased to find the random 16Mb stick of PC66 at the bottom of a box in my local recycling shop last week, and after a 12-hour marathon of memtest, it’s showing no defects whatsoever. But the aforementioned 2Gb hard drive with a clean installation of Ubuntu on it refused to start all the same. “The initrd is too big,” it said, quite politely.

I see elsewhere on the Internet where BIOS settings can come into play, but this time it might be that the initrd is just too big. How big can it be? I thought, and transplanted the drive (again … swapping drives is the story of my life) in an effort to find out. And the answer was 40Mb.

Good grief. I must be looking at that wrong. Discrepancies like that can only be explained as some mistake of mine. In any case, the error message was telling the truth. That is too big.

Now the size of a stock Linux kernel and the size of the initrd in a vanilla installation of Ubuntu 9.10 are not necessarily related, but I could swear this was never a problem before now. I am more-or-less certain that I have installed minimal Ubuntu systems on computers with only 32Mb of memory — some within the past couple of years — and they started up fine. And Debian runs without complaint on the machine, although I haven’t needed to check the size of the initrd in Debian, so it might be different. (It appears to be less than 8Mb for initrd.img-2.6.32-trunk-486.)

I suppose weight gain is the only excuse. Forty megabytes is considerable when your world is topped off by a 550Mhz Celeron, and no machine has more than 192Mb. But this world never has a need for more than about 24 of those 192Mb at any given time … unless of course, you’re trying to start up Ubuntu.

I’ll have to scrape around a little more and see if there is any way to carve down that 40Mb number, and maybe actually get the system working without having to swap memory chips as well as hard drives. I don’t hold out much hope though … 40Mb might be a stumbling block for a beat-up leftover 166Mhz Thinkpad, but to anyone else who’s not living in 1998, 40Mb here or there is nothing to voice concern over. Unless you are Linus.

Another console download manager

I mentioned a script yesterday, so I’ll mention another one today — another sort of “download manager” for the console. This isn’t nearly as feature-ful as fttps, but since it approaches the issue in a concise and straightforward way, I thought it worth bringing to attention.

wget-queue.pl claims to be an offshoot of a bash script called wget-queue.sh, but I haven’t had much luck in tracking that down, unless this is what it means. It works in much the same way as I originally envisioned when I thought I was coming up with an original idea, and probably if I had enough skill to put together a program (which I don’t) it would look and behave in the same way as wget-queue.pl.

I’ll let you dig around and see how it works; if it were me I would plant this in a directory somewhere, set up cron to execute it once an hour or so, and keep the list of programs to download somewhere in your home directory. I adjusted it slightly for my system, so that it keeps a “session” directory where the logs and settings are stored, and a “watch” directory where I can manage the list of files to download. I wanted the style to mimic rtorrent, if you must know. I also added an -nv flag to the actual download command, because I foresaw the log file getting rather big.

If I must be terrifically honest, I think blice’s fttps is still a step above this even if it never fully matured. Even in its unfulfilled state fttps has a few more controls and features than wget-queue.pl (and wget-queue.sh, if we can count that one) and while it is worthy of some refinements, I’ll probably stick with it on my machines. The perl script is worth investigating though, if you are curious and capable of tuning it.

Module configuration script

I only have a minute or two today, so I’ll just mention that I found this perl script that supposedly presets the used modules in a kernel configuration, which I hope will be useful in arranging custom kernels between Debian and Crux.

I still have it in my mind that I want to convert this entire system to a Crux analogue, mostly because my settings and configurations are sometimes intended for still-fresher versions than what Debian testing offers. Part of that would include getting a kernel adjusted to this machine, and considering that Debian has had better luck than I with regard to some things (like the framebuffer), I am willing to take a cue.

A script that scans through the modules you have on board, then tweaks a configuration file for you, would be useful. I think that’s what this does, although as always, I might misunderstand. I promise a report, either way.