Recently in Parted Magic Category

In my ongoing quest to bring the latest news about Xorg and its hatred of the Intel 830m chipset that I have on three laptops, today I'm running a long filesystem check in gParted on the Parted Magic 4.9 live CD.

Don't get me wrong: I love Parted Magic. It's my preferred tool for partitioning drives with gParted and doing all sorts of other things. I generally don't burn new Parted Magic discs. I just keep using the same ones. The last time I made one, it was version 4.6.

But since my Toshiba 1100-S101 hates CD-R discs and likes DVD+R, I needed to burn the CD image onto a DVD. (Recently the Toshiba hasn't even been reading commercially created CD-ROM discs, so it looks like DVD-only from here on out.)

Parted Magic 4.9 is doing everything I need it to do. But I'm noticing in the helpful Conky output that Xorg is consuming 50 percent to 60 percent of the CPU at any given time. Hey, that's the same problem I had in Debian Squeeze ....

Whether this is something that can be addressed in xorg.conf, I don't know, but it is disturbing.

In other Parted Magic 4.9 news, I'm using the Chromium browser for the first time. It appears to work great. I'm no fan of Google Chrome on my Windows XP machine, but in Linux the Google-derived Web browser is performing exceptionally well.

I'm getting ready to install either Debian or Ubuntu again, and I'm undecided about whether or not to use encrypted LVM this time. I didn't have any performance issues with the encrypted drive, but my lack of knowledge regarding modifying LVM worries me. Specifically, Debian Squeeze appears to be larger than Lenny, and I'm worried that my root partition will be too small, and I won't know how to grow it and shrink /home — operations I'm very comfortable doing with non-LVM partitions in gParted.

I've been using Parted Magic to work on my disks, and after recently replacing my old 1.x live Parted Magic CD with 4.6, I'm enjoying the little things that PM brings to the project.

For instance, when you turn networking on with DHCP and the DHCP server to which you're connecting doesn't transmit nameserver info, Parted Magic uses OpenDNS to supply you with DNS lookup so you can actually use the Internet while in the live environment.

And since Parted Magic can generally run totally in RAM, once it loads the CD drawer opens and you can remove the optical disc. With the drive free, you can then can burn data onto a CD

The gFTP software is included, as is rsync and the graphical front-end Grsync.

There are utilities to see what hardware you have in the box, ways to test it, and generally a lot of useful stuff, and not just for Linux users.

One problem: I used Parted Magic to create HFS+ partitions, but the Mac on which I tried them did not recognize them. I guess there's some magic I don't possess (or which makes Parted Magic a little less magical).

I had intended to keep some Mac backups in HFS+ format on this drive, but I guess I'll have to do them either in ext3, FAT32 ... or on another drive.

While a powered USB hub will run this 500 GB Toshiba portable hard drive with my Toshiba Satellite 1100-S101 laptop, the "two regular USB plugs to one small USB plug" cable, if you can find one, will also do the job.

I have a portable USB drive that has an ext3 Linux partition and a FAT Windows partition.

The drive is a bit flaky due, I'm pretty sure, inadequate power from the USB connection. My solution in the next few paragraphs is less than ideal, and I've since found a better way to make my drive work.

I have a powered USB hub which solved the problem, but it turns out I have to have the drive plugged into a certain one of my four USB outputs from the hub. I assume the other ports just don't deliver enough power.

I plugged it into the "wrong" one (and didn't know until now that there IS a "wrong" one) and had a lot of trouble with the drive.

Now it's plugged into the "right" USB port on the hub. I want to fsck the drive to see how the filesystems are doing.

When I tried to check the FAT partition:

$ sudo fsck /dev/sda1

I got this error:

fsck: fsck.vfat: not found
fsck: Error 2 while executing fsck.vfat for /dev/sda1

A little Googling provided the answer:

To fsck a FAT partition/drive, you need the dosfstools package.

I used Synaptic to install dosfstools, and then I was able to fsck my FAT partition.

Moral of this story: Portable hard drives don't always work. Some PCs just don't supply enough juice through USB to spin 'em properly. The el-cheapo Toshiba portable drive I'm using, model No. HDDR500E04X, doesn't have the provision for connecting an external power supply. Other portable drives, including those sold by Iomega, do include a power plug in case USB isn't making it happen.

If I had known this, I wouldn't have purchased the Toshiba in the first place. In my opinion, better choices include a drive designed for "desktop" use that comes with its own power supply, or a portable drive that can be powered via a traditional power adapter (and not just the USB) if needed.

Using a powered USB hub is not the best solution, especially now that I've learned the Toshiba "likes" one of the USB ports on the hub better than another (i.e. it won't work on port 3 but will on port 4).

One way to make USB-powered drives work if you have "weak" USB power:

Daily News photo guru Shane Kidder showed me an interesting cable — one that combines two USB inputs into one — so a device powered by USB can presumably get more juice.

I borrowed the cable from Shane and plugged it into two of my three USB ports on the Toshiba Satellite 1100-S101. Believe it or not, it works.

I successfully rsynced my laptop to the Toshiba USB drive, and it performs perfectly ... all I need to do it devote two USB ports to it.

But a working hack, I'll accept any day. Now all I have to do is find one of these franken-USB cables.

As an experiment, I decided to bring my Evolutionary Computing presentation on making the journey into free, open-source software — a slide show originally created in OpenOffice Impress 2.4 — into Google Docs, which happens to have a presentation app in addition to the better-known Docs and Spreadsheets components.

I revised the presentation — taking some things out, adding others and providing some updates on what I'm doing — and output it as a PDF.

Download that PDF for your reading pleasure by clicking on the image above or the link below:

Evolutionary Computing (revised July 2009)

Interesting note: I believe that no previous entry on this blog has been filed under so many categories. (And I've been considering dumping Categories entirely and just using tags ...)

When I installed OpenBSD 4.4 on my Toshiba Satellite 1100-S101 laptop, I purposefully left Windows XP on the drive. I used the free Linux-based Parted Magic live CD to shrink the Windows partition and leave room for OpenBSD on the hard drive.

The reason I'm so comfortable partitioning a hard drive is because I've done it between 50 and 100 times. For my first three or so OpenBSD installs, however, I gave the whole drive over to OpenBSD since I didn't feel confident setting up a dual- or triple-booting system with it.

So if you ARE comfortable dual-booting lots of Linuxes, Linux and Windows, or what have you, and you have managed to install OpenBSD without killing out your other operating systems, you might want to actually run those other systems, right?

On my most recent OpenBSD install on the Toshiba, I wanted to leave Windows XP on the drive and eventually dual-boot it.

I followed the instructions on the FAQ for installing OpenBSD on a PC with Windows already installed, and I intended NOT to install the OpenBSD bootloader. Well, I didn't do that, but I also managed somehow to kill out the Windows bootloader on the drive's master boot record. That meant I couldn't boot anything.

Luckily the OpenBSD FAQ show me how to boot from the floppy I used for the install (I booted from the floppy because the CD drive isn't working), drop to a shell and install the OpenBSD bootloader. That was easy enough, but I still couldn't dual-boot.

You theoretically can use the Windows bootloader to dual-boot with OpenBSD, but since I had already killed it out and don't have a Windows XP disc to restore it, I turned to GRUB, the bootloader I always use with Linux. It's a package for OpenBSD, and if your system is set up to install packages (with your PKG_PATH in your .profile if you're going to sudo, or in root's .profile if you su to root), you can easily install it.

Since I already added my user account to the sudoers list with visudo, I used sudo at my own shell to install the package. If you su to root instead, use the line with the # prompt:

$ sudo pkg_add -i grub
or
# pkg_add -i grub

After you install grub, you are presented with a path to the Instructions for setting up grub. Those instructions say to do this:

# grub-install --no-floppy hd0

That didn't work for me. The reason is that pkg_add puts all the grub packages in /usr/local/sbin, and either by accident or design, that isn't in my path.

So I instead ran:

# /usr/local/sbin/grub-install --no-floppy hd0

That did work. It installed GRUB in the master boot record as my bootloader.

But unlike in Linux, this GRUB installation didn't create the menu.lst file that GRUB uses to select and boot the various operating systems.

A look through the man and info pages for GRUB plus a little searching on the Web helped me create a menu.lst.

Before I go into that, it's worth pointing out that while most Linux systems store that file as /boot/grub/menu.lst, in OpenBSD it's just /grub/menu.lst. There's no /boot directory. (Instead, boot is an executable in the root directory, the reasons for which both elude me and seem unimportant at this stage.)

Use any text editor you have installed (vi in the base OpenBSD system; or nano or Geany in my system, both of which I've previously added with pkg_add) to create /grub/menu.lst.

Once again, since I have sudo set up, I used it and the nano editor in my shell to create the file. As far as partitions go, on my drive, Windows XP is installed first, followed by OpenBSD. To dual-boot with GRUB, here's how I created menu.lst:

$ sudo nano /grub/menu.lst

That creates the menu.lst file, into which I typed the following:

default 0 timeout 5

title Windows XP
root (hd0,0)
chainloader +1

title OpenBSD
root (hd0,1)
chainloader +1

I saved and closed the file (F3 and then ctrl-X in nano) and then rebooted the PC. As yet another aside, here's how I reboot in OpenBSD:

$ sudo shutdown -r now

Upon reboot, GRUB ran and allowed me to choose between Windows and OpenBSD.

I tested both OSes, and both successfully booted.

I'll probably reverse the order so OpenBSD is in the top spot and will boot automatically if I don't purposefully select it. I could also increase the timeout time to have more of a chance to pick one OS or the other, but right now that doesn't seem necessary.

Observations: While documentation in OpenBSD tends to be extremely detailed, it's not always 100 percent correct. The man pages and info pages didn't tell me, for instance, that the grub executables, including grub-install, couldn't be run from the / directory and that the full path to them was needed. I only found that path by poking around in a file manager. Once I did have the path, I was able to use grub-install successfully with the directions as given. Adding the path to the instructions would certainly help others get GRUB working in OpenBSD.

Since both of the OSes on my laptop — Windows XP and OpenBSD have their own bootloaders on their respective root partitions, all GRUB has to do is chainload to the proper partition, after which time the respective systems' bootloaders take over. After using GRUB to dual- and triple-boot GNU/Linux distributions for more than a year, I've discovered that chainloading as much as possible is a very good thing, especially when dual-booting two Linux distros. That way, "automagic" updates to each distro's menu.lst are just about guaranteed to go smoothly.

This technique made things much easier when dual-booting Debian and Ubuntu. When I didn't chainload to one or the other, one of the two OSes never did get the proper menu.lst updates when a new kernel was installed. But by chainloading to all but one of the distros on the hard drive and installing GRUB in all but one of the distros' root partitions, I've avoided countless problems.