TechOpinionation - Operating Systems

Figuring out why I can't resume any more

nospam@example.com (Joshua Kugler) — Sun, 17 May 2009 11:54:05 +0000

I recently installed the Jaunty/KDE3.5 remix. I had some interesting issues in that I was trying to install on an existing LUKS/LVM setup. Whole-disk encryption on LVM rocks, but if the installer doesn't support it, you'll have to fiddle to get things working right.

It was up and working, but of course I was still fiddling around. At some point I ran mkswap on my swap partition. After this, I noticed I could no longer suspend to disk (hibernate), but I did not yet corelate the two events, as I had changed /etc/fstab to use the new UUID of the swap partition.

I then noticed that upon boot I now had two swap partitions active: my swap partition, and another one mounted on /dev/ramzswap0. I turned off that swap device, and behold, I could suspend to disk! BUT, when I resumed, it went through normal boot...but not resume.

So, I began looking through the files under /etc/initramfs-tools. I came across one in conf.d called "resume" which contained this line:

RESUME=UUID=some-uuid-that-wasn't-correct-anymore

AHA! I replaced the UUID with the correct one, ran

update-initramfs -k all -c

and now I can suspend to disk and resume.

Real dependencies, not convenient dependencies

nospam@example.com (Joshua Kugler) — Tue, 28 Apr 2009 07:19:57 +0000

Over on his blog, Raphael Pinson has a post about creating a package with "minimal dependencies." In short, make the dependencies of the package the "real" dependencies, not just the latest and greatest version of the package you rely on.

I have been waiting way too long for someone to say this. This has especially bitten me when trying to back port things like Python modules. Both debhelper and python-central versions are automatically bumped to the latest, when they will compile and install just fine with versions that are one or two distro releases old.

Then, a request for backports is bounced with the message "too many dependencies" when in reality there wouldn't be "too many" if the dependencies were really set to what they need to be and not just whatever version is in the latest release.

In the case of Ubuntu, I personally would like to see all packages test-compiled with the versions of software that comes with the current LTS releases. Then, if it truly cannot be compiled with those versions, but the dependency to what it needs to be, but not any higher.

Related gripe: I have seen bugs in Ubuntu closed when a fix is released for the latest version, but the LTS version of the package was ignored. Maintainers: LTS means "Long Term Support," and as long as the support window is open for that release, the package should be supported and all bug fixes backported to the package (without having to enable backports, incedentally).

Thank you Raphael for bringing this up! Hopefully this will spark discussion and make it easier in the future to backport the "latest and greatest" to the current LTS release.

Relative Difficulty

nospam@example.com (Joshua Kugler) — Sun, 10 Aug 2008 20:47:00 +0000

The other day, at work, we were working on setting up an automated qurk-and-dirty back up for some files from one Linux box to another. The link was a long distance one (from a data center in Dallas to our office in Anchorage). The solution was simple and elegant:

On the host being backed up:

tar -cv /etc|bzip2 -9 -c | ssh -i /path/to/id_rsa user@backuphost.com \
"(cat > /path/to/backup.tar.bz2)"

Tar up the files, pipe it through bzip2, pipe the output of bzip2 through SSH, which connects to the remote host via a keyed login, and output the result of that stream to a file on the other side.

Any idea how much contortion you'd have to go through to do the same thing on Windows? Difficulty: assume no use of SSH, and no interactive login (i.e. must be able to run completely unattended).

I asked my programming lead that question, and he said, "An order of a magnitude more."

"Only one order?"

"I said OR MORE. OR MORE with windows always means MORE."

Edit: Yes, run unattended, not unintended. Although I like cubiculum's comment on reddit: "Windows does that sort of thing all the time."