Closed RJVB closed 10 years ago
Could you just double check a different approach to your dkms.conf kludge?
(*)
if [ -e ${kernel_source_dir/%build/source} ]
then
echo ${kernel_source_dir/%build/source}
else
echo ${kernel_source_dir}
fi
;;
I still need to think about the correctness of this, but could you just revert to an original version of the file and then rewrite it like that instead and try again?
And is it necessary to include a PRE_BUILD statement when there's a configure to be called? I mean, dkms could detect there's a configure, and call it with an appropriate standard set of arguments...
First impression of your proposed mod looks good, final conclusion too (i.e., builds)
In fact, your mod seems to be very generic, and probably even makes it possible to avoid calling lsb_release altogether...
And is it necessary to include a PRE_BUILD statement when there's a configure to be called? I mean, dkms could detect there's a configure, and call it with an appropriate standard set of arguments...
Don't think it does. But either way, we need to use the with-linux parts to make sure we get the correct kernel. Otherwise it's a hit-and-miss if we get it built...
First impression of your proposed mod looks good.
Don't like that much either, but it's a little better. But I think I have some idea on how to get a really good one.
@dajhorn have any opinion here? I see that you're the one who wrote it with a case and using lsb_release..
Why not just use something like this:
PRE_BUILD="configure
--prefix=/usr
--with-config=kernel
--with-linux=$(if [ -e ${kernel_source_dir/%build/source} ]
then
echo ${kernel_source_dir/%build/source}
else
echo ${kernel_source_dir}
fi)
--with-linux-obj=${kernel_source_dir}
"
@RJVB Could you try my last version of this instead of my previous one? I really need to figure out the best way to do this...
Or this one. This one I'm almost proud of :)
PRE_BUILD="configure
--prefix=/usr
--with-config=kernel
--with-linux=$(moddir=`echo ${kernel_source_dir/%build/.}`;
if [ -e $moddir/source/include/linux/input ]; then
echo $moddir/source
elif [ -e $moddir/build/include/linux/input ]; then
echo $moddir/build
elif [ -e $moddir/include/linux/input ]; then
echo $moddir
fi)
--with-linux-obj=${kernel_source_dir}
"
Thing is, we can't just blindingly trust the existence of the source directory actually BEING the/a source directory. We need to make sure!
I do this here by looking for the include/linux/input
directory, that only exist in a directory containing the linux source.
We should really be doing that for the with-linux-obj option as well...
Oh, and the 'moddir' part is to make sure that we don't do the substitution (.../%build/something
) multiple times, only once.
That last part works on three different machines: My old (now deprecated) Lenny box with homemade kernel, my Wheezy development machine and my Wheezy ZFS root test machine (both with default Debian GNU/Linux kernel and header packages) as well as my Wheezy primary server (without any kernel/header installed).
@RJVB Does this work for you on your Mint machine?
Yep, works. On both set-ups described somewhere earlier in this thread.
Perfect, thanx. I'll use that instead then.
Any chance this will also work with the FreeBSD kernels I see in the repository? ;)
(answer: apparently not, and grub fails to detect or acknowledge the presence of a kfreebsd kernel anyway ... a zfs-grub specificity?)
Ehmmmm, what!? This is ZoL - ZFS On Linux. FreeBSD is a completely different animal...
Since this is now done, would you mind closing it as fixed in zfs/0.6.2-4~wheezy and spl/0.6.2-3~wheezy?
Heh, what defines Linux - the distribution? The kernel? The user? :)
The kernel. ALWAYS the kernel! Debian GNU/Linux, RedHat, Ubuntu (etc) is the distribution. The user... Well, my name is 'Turbo'.... :)
This is why the official name of Debian GNU/Linux contain both the distribution name (Debian), GNU (the userland) and Linux (the kernel). That's why I always use the full name. Not just 'Debian', because that's not the name of the distribution....
Just a thumbs-up: the latest updates (what's new?) went through without a glitch, even on my shiny new 3.10.5 custom-built kernel.
I have a "real silicon" Linux Mint Debian system running off a zfs root partition (with just /boot on an ext3 partition). I just tried to do an apt-get update && apt-get upgrade which told me about new zfs packages ... and got a configure error suggesting that spl-devel wasn't installed. The basic question is: is it even possible to use the usual upgrading procedures, or would you get a race condition where access to the zfs fs requires the very modules being updated? From what I saw, the "old" kmods were not removed, but I haven't yet tried to reboot ...
R.
FransUrbo commented 13 minutes ago @RJVB What was the exact error? What does the following tell you:
cat
find /etc/apt/sources.list* -type f
Also, what did the apt-get upgrade command output? Exactly!