Thursday, August 20, 2009
Getting my data back out of NVBackup
I suppose I've never made this confession here yet, but I'm a Palm addict. It's been going on since the original Handspring Visor came out and my core Palm databases are the same ones that I created nearly nine years ago, brought from system to system.These days, I've been using Palm's disavowed LifeDrive, and mine just kicked the bucket. This is my second one; the first I got replaced through PalmCare (found an absolute steal on a packaged PalmCare plan.) As part of the LifeDrive lifestyle, I've been using Alexander Pruss' NVBackup to keep my data safe.
A hopefully brief history: traditionally, Palm handhelds have kept everything—programs, data, you name it—in battery-backed RAM. This works a lot better than it sounds, but it does have the disadvantage that it all goes pfft if you don't keep tabs on your Palm's battery. The early models actually ran on standard off-the-shelf batteries; my Visor used AAAs and it lasted a good while unless I was using it constantly. Backup was done by syncing your system to a PC.
Anyway, this battery run-down situation must have irked enough people, because in the last round of Palm handhelds they ever made, they introduced something called NVFS, non-volatile storage for the system's data. This wasn't the first time Palms could write to something other than RAM; over the previous several years they'd been adding storage (usually some form of Flash card) to some models. With those came backup applications, which did sadly have some problems with restoring the system to its original state, owing mostly, as I understand it, to the weird machinations that it took to serialize an in-RAM database to a
.pdb (Palm database) file.NVBackup, by comparison, was as simple as could be. It took these NVFS-based Palms and simply copied their databases straight out of NVFS, where they were already serialized, and dumped them straight to your Flash card. The advantage was that in almost all situations, restoring a backup brought your system back exactly the way it was before, which is great if you still have your system. My LifeDrive was dead, though, and I didn't have another to restore to—so I needed to do something to get these databases into
.pdb files so I could then stick them onto one of the other old Palms I have lying around, lest my life become tragically disorganized. Er, more than it is now.Alex Pruss has done some work on a tool called unbackup which reportedly does a passable job on some of the NVBackup dumps. I tried this tool. It did not do well on my LifeDrive's output at all, sadly. Crashed a lot, failed to make sense of other files... it just wasn't pretty. Facing the prospect of reverting to two-month-old data (my last PC sync), I started scraping together ideas for one last shot.
Palm developers (of which I am one, though I've never released a bit of anything) have access to the Palm Simulator tools, which emulate a Palm device on a (Windows, sigh and boot up the VirtualBox) PC. See where I'm going with this? Now I do have a spare LifeDrive that I can restore my NVBackup set to, and use the onboard tools to make
.pdb files out of my core databases. It wasn't quite that simple, but I did eventually get it working.First problem: getting NVBackup to restore to the simulated LifeDrive in the first place. Palm Simulator sets up an area on your disk to simulate external storage, so I copied the NVBackup set off my SD card and into that area, along with the NVBackup program itself. NVBackup got installed to the virtual LifeDrive and presented me with the backup set I copied. But then I tried to do the restore, and things started to get ugly.
I knew I only needed a small set of databases—
AddressDB, DatebookDB, MemoDB, and ToDoDB alongside those from my two key other Palm apps, Keys-Gtkr from Keyring and Months-HkDt from Eat Watch—so I started off trying a selective restore of just those databases. It looked like it was working, but then when it came time to restore the files, I kept getting "error opening" messages. I had no idea what was going on. I tried disabling the Simulator's write-protected storage option (honestly, I have no idea what this actually does) as well as PACE extended checks (I have a slightly better idea but this was last-ditch); neither gave me any joy.Eventually I even wrote to Alex Pruss, since I saw in one of many Google searches that he had originally started work on NVBackup in the Simulator; unfortunately, he had no idea how to solve my problem. One lead caught my eye, though: "error opening" could also show up if there was trouble dealing with an encrypted backup. Although I'd never had trouble with it on a real device, I wondered if perhaps NVBackup's default gzip compression might be at fault. So I ran gzip -d over the NVBackup set, hopped back into the Simulator, ran the restore, and—success!
Well, partial success, at least. The Simulator crashed irrevocably on reboot, possibly because the Simulator is compiled for x86 and my backup was full of ARM code. So I hard-reset my virtual LifeDrive and went back in again, this time only restoring the databases I needed (as well as their new PalmOS counterparts'—Contacts, Calendar et al.—since the old databases are really just there for compatibility purposes), then used FileZ to make
.pdbs out of them on the virtual SD card, and voilà!Okay, almost voilà.
DatebookDB was being stubborn, no matter how many times I tried to restore, convert, and copy it, pilot-xfer was refusing to copy it—likely corrupted somewhere along the line. I eventually ended up HotSyncing that one directly from the simulated LifeDrive over a "network" from within the VirtualBox VM to my host Linux netbook. And now it works. The old CLIÈ has all my important data and apps just as I left them before the last backup.It was a lot of work, but it was worth it, I think. And hopefully there's some clue in here that might help someone else in the same boat down the road.
Labels: nvbackup, palm, technotes
posted by zigg 11:17 PM
0 Comments
Sunday, June 21, 2009
Geek adventure: getting Ubuntu's console to stay in 132×60 mode
I'm sorry I haven't been "writing" writing here lately. I have been doing some writing over at N-Sider, though of course it's all games-related. Just been too busy, I suppose.Anyway, I wanted to drop a quick post to note the solution to a longstanding problem I've had with Ubuntu: getting the console to stay in 132×60 text mode (or, indeed, any other text mode). 80×25 may be just fine for installations or if I had my server connected to a 9" monitor, but I don't. I'm hooked up to a 19" monitor here, and 80×25 is a waste of space.
In the distant past, I used to just add
vga=0xa to the kernel parameters, which kicks in the VESA mode for 132×60. This still works in Ubuntu... but only temporarily. During the boot process, a new font is loaded which provides better character support than the old standby ASCII VGA font. The problem is that this font is 16 pixels high, and for 132×60 to keep working, the font needs to be 8 pixels high. So once this script runs, I'm left at 132×30—better than 80×25 but still not what I really wanted.I did some digging, and it seemed the secret to getting this to stay working lies with the
setupcon program, part of the console-setup package. setupcon reads /etc/default/console-setup to select its font, so I tried editing it to select an 8-pixel-high font from /usr/share/consolefonts. Which failed.It seems that
setupcon actually loads fonts from /etc/console-setup. In there, there's only Uni1-Fixed16.psf.gz by default—that's our default 16-pixel-high font. I figured there had to be some way of getting this to work in a standard fashion, so I tried a few more Google terms, waded through some more offhand mentions, and finally found my joy.It's actually just as simple as running
dpkg-reconfigure console-setup, accepting most of the current values, and then picking VGA at 8 pixels. I was somewhat amused; dpkg-reconfigure was always my go-to script for Debian, but I'd fallen out of running to it since I moved to Ubuntu a little under two years ago. But there it was. It reconfigured my current terminal for me; running setupcon in the other terminals fixed those up as well. A quick trip to /boot/grub/menu.lst to add vga=0xa (I'd been adding it manually) to the default boot paramters and a /usr/sbin/update-grub to regenerate the boot menu and I was in business for future boots as well.The only weird thing, and I think it's a bug, is that I get underlines on top of text. Not a big deal though.
Hope this helped someone. I'm off to Father's Day dinner!
posted by zigg 3:43 PM
1 Comments
Thursday, February 19, 2009
Sharing the wife's new iMac
For Valentine's Day, I surprised my wife with one of the latest iMac models; specifically, the 20" 2.4GHz. I'm parked in front of it right now, typing this post... and I must say, I'm getting rather enamored with it. We're not new to Mac in this house; this iMac replaces her aging iMac DV+, which we were running OS X 10.3.9 on (and rather well, I might add)—it wasn't a horrible performer by any stretch of the imagination, but it was beginning to show its limitations and it was cursed by horribly unreliable USB support.While I always sort of liked the old iMac, I am really taken with this one. It doesn't hurt that it's by far the most powerful computer in the house, but 10.5 (I always forget the cat names) is really a wonderfully engineered operating system. It's getting to the point that I'm finding myself wondering if, when it's time to replace the old Presario R3000, I might consider going Mac instead of wrestling with Linux support on a new piece of hardware until all the kinks are ironed out. I do wonder if I'll find myself running up against Apple walls, though. I like that I can go anywhere in my system and, if I care to, can dig right on down to the source code for pretty much everything.
So now that we have this machine of wonder in the house, which of course I have to let my wife use in the evenings since it is technically her computer and all, I got to wondering—is there any way we can share it? I know OS X doesn't run on X11, so I can't ssh -X OS X apps across to my wimpy little laptop, but as it turns out, there is actually a way to let multiple people simultaneously use the same Mac. I found out about it through some Googling, and it's really quite simple:
- Download Vine Server (a.k.a. OSXvnc).
- Turn on "Fast User Switching" at System Preferences > Accounts > Login Options. (This is a good idea anyway!)
- Log yourself in, start Vine Server up, and use the user switch menu in the upper-right corner of the screen to go back to the login window.
- Connect via your favorite VNC viewer.
I guess there's something to that whole Mac "just works" thing. I wonder if I might be the next full-fledged OS X convert down the road...
posted by zigg 6:27 PM
2 Comments
