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.

TechOpinionation - Linux

Figuring out why I can't resume any more

Real dependencies, not convenient dependencies