debirf fails on kernel install on non-standard archs

[jrollins]

A user 'qq' reported that debirf was failing to build on a "bigmem" system, because the install-kernel module was failing to correctly determine the arch of the running kernel. Clearly we need a better more robust way of determining what kernel arch to install.

Here are a couple of suggestions:

linux-image-$(ls -1 /lib/modules/ | sort -n | tail -1)
linux-image-$(ls -1 -t /lib/modules/ | head -1)

I think we may have had issues with the above methods in the past when trying to build a lenny system on an etch machine, or vice versa. I think this might be the best I have:

linux-image-2.6-$(uname -r | cut -d- -f3-)

That cuts out the kernel-debian version, and leaves the rest. I'm going to implement this, but leave the bug open just in case a better idea comes along.

[dkg]

$(uname -r | cut -d- -f3-) seems like a reasonable simple default to me. It might be nice to be able to specify it with an environment variable, too, though. If you're running on, say, xen-686, but you want to build a debirf rescue image with a plain ol' 686 kernel, it'd be nice to be able to say something like:

DEBIRF_KARCH=686 debirf make rescue

[jrollins]

This method is now being used in 0.21. I would like to close this bug, but I don't have any alt archs to test this on, though.

[dkg]

I've tested this with -vserver-686 and it worked out fine.