OpenAFS 1.4.11 module (from lenny-backports) in PVE kernel using DKMS

H

holrau73

New Member
Mar 12, 2010
4
0
1
Hi to everybody,

I want to be able to use OpenAFS 1.4.11 from lenny-backports on both the Proxmox VE 1.5 host (physical machine) and inside OpenVZ containers?

Is that possible? Where can I find the PVE kernel sources as .deb package? Unfortunately,

ftp://pve.proxmox.com/sources/

doesn't seem to be valid anymore.

When I try to get the OpenAFS 1.4.11 module compiled via DKMS inside an OpenVZ container, I get some error message telling me that the kernel header version doesn't match (seems like DKMS wants to use the headers for the 2.6.24-pve kernel).

Any help is greatly appreciated.

Thanks in advance & kind regards,

Holger
 
Sorry, replying to my own thread since I initially forgot to mention that I did

apt-get -t lenny-backports install openafs-krb5 openafs-client libpam-openafs-session openafs-modules-source openafs-doc

in order to obtain the desired packages and I had added this entry to /etc/apt/sources.list

deb http://www.backports.org/debian lenny-backports main

and had run "apt-get update/dselect update" prior to the "apt-get install" command.
 
Hi Tom,

thanks for your link to the new download URL. But I still got the following remaining questions:

1. Is OpenAFS supported in conjunction with the PVE kernel at all (especially when the OpenAFS client is not only supposed to be used on the physical machine but also in the OpenVZ containers)?
2. Why is there no deb-src archive with source debian packages, just the "plain" .tar.gz files?
3. According to "pveversion" and "uname -a" I still got

pve-manager/1.5/4627

and

Linux mia 2.6.24-8-pve #1 SMP PREEMPT Fri Oct 16 11:17:55 CEST 2009 x86_64 GNU/Linux

installed on my system. Do you recommend me to upgrade, so that I get a 2.6.32 kernel?

Thanks in advance for any hints and kind regards,

Holger
 
holrau73 said:
1. Is OpenAFS supported in conjunction with the PVE kernel at all (especially when the OpenAFS client is not only supposed to be used on the physical machine but also in the OpenVZ containers)?
Click to expand...

we do not support OpenAFS - never used that.

holrau73 said:
2. Why is there no deb-src archive with source debian packages, just the "plain" .tar.gz files?
Click to expand...

Why should we make one? Or, what do you miss in the tar?

holrau73 said:
Do you recommend me to upgrade, so that I get a 2.6.32 kernel?
Click to expand...

We recommended to use the 2.6.18 kernel.
 
Last edited by a moderator:
Hi Tom,

thanks again for replying.

> we do not support OpenAFS - never used that.

Sort of interesting since it's supported by standard Debian kernels (it compiles without any problems). Even though it's not officially supported by PVE, a PVE kernel should still work together nicely with standard Debian kernel module packages (such as openafs-modules-source).

Would you be willing to look into it if I copy&paste the error messages I get?

> Why should we make one? Or, what do you miss in the tar?

Because it's the standard way "plain" Debian handles things. Why did you decide to deviate from this course? No, I'm not missing something in the tar but simply apt-getting source packages is more convenient and more "the Debian way" in the sense that a Debian admin is used to it. So, at least to me, reasons for just offering the tarballs are not obvious. Could you please provide provide additional details?

> We recommended to use the 2.6.18 kernel.

Also sort of interesting, because my Proxmox system tells me

Linux mia 2.6.24-8-pve #1 SMP PREEMPT Fri Oct 16 11:17:55 CEST 2009 x86_64 GNU/Linux

when issuing "uname -a". Please note that this is a kernel officially distributed with PVE; I got it when upgrading to PVE 1.5 using "apt-get dist-upgrade".

Thanks again & kind regards,

Holger
 
holrau73 said:
Hi Tom,

thanks again for replying.

> we do not support OpenAFS - never used that.

Sort of interesting since it's supported by standard Debian kernels (it compiles without any problems). Even though it's not officially supported by PVE, a PVE kernel should still work together nicely with standard Debian kernel module packages (such as openafs-modules-source).

Would you be willing to look into it if I copy&paste the error messages I get?

> Why should we make one? Or, what do you miss in the tar?

Because it's the standard way "plain" Debian handles things. Why did you decide to deviate from this course? No, I'm not missing something in the tar but simply apt-getting source packages is more convenient and more "the Debian way" in the sense that a Debian admin is used to it. So, at least to me, reasons for just offering the tarballs are not obvious. Could you please provide provide additional details?
Click to expand...

we provide a header package, this is enough if you want to compile something (see ftp://download.proxmox.com/debian/dists/lenny/pve/binary-amd64/) or just aptitude it.

holrau73 said:
> We recommended to use the 2.6.18 kernel.

Also sort of interesting, because my Proxmox system tells me

Linux mia 2.6.24-8-pve #1 SMP PREEMPT Fri Oct 16 11:17:55 CEST 2009 x86_64 GNU/Linux

when issuing "uname -a". Please note that this is a kernel officially distributed with PVE; I got it when upgrading to PVE 1.5 using "apt-get dist-upgrade".

Thanks again & kind regards,

Holger
Click to expand...

See this wiki page, telling you all about the kernels.
http://pve.proxmox.com/wiki/Proxmox_VE_Kernel

it looks that you did not follow the upgrade instructions to 1.5,
see http://pve.proxmox.com/wiki/Downloads#Update_a_running_Proxmox_Virtual_Environment_1.x_to_1.5
 
holrau73 said:
> we do not support OpenAFS - never used that.

Sort of interesting since it's supported by standard Debian kernels (it compiles without any problems). Even though it's not officially supported by PVE, a PVE kernel should still work together nicely with standard Debian kernel module packages (such as openafs-modules-source).

Would you be willing to look into it if I copy&paste the error messages I get?
Click to expand...

We simply can't test and support 100 different filesystem. We do not have the resources to do that.

holrau73 said:
> Why should we make one? Or, what do you miss in the tar?

Because it's the standard way "plain" Debian handles things. Why did you decide to deviate from this course?
Click to expand...

Because it is easier for us.
 
You must log in or register to reply here.
Top Bottom