This system has been removed and the fils all backed up for futurew use of a new install. Thanks for the support Rafael.
Stephen Corbin
<email address hidden>
-----Original Message-----
From: Rafael David Tinoco <email address hidden>
To: bigredsshop <email address hidden>
Sent: Tue, May 27, 2014 8:11 am
Subject: [Bug 1206387] Re: openafs-modules-dkms 1.6.1-1+ubuntu0.2: module FTBFS on 3.8.0
After this discussion (and some other customers/users requests on the
same bug), knowing that the 1.6.5 backport was not eligible for a SRU
(just like Steve pointed out) I started to cherry-pick code from openafs
1.6.5 to openafs 1.6.1, so the openafs dkms module was able to compile
on HWE kernels.
With that I could see that this approach would also not result in a
eligible RSU. There are too many changes from kernel 3.2 to kernel 3.11
and openafs has a huge amount of pre-defined code based on these changes
(Rightly pointed out by Anders).
After fixing some wrongly auto-generated includes, I could see that
there were 2 approaches for bringing 1.6.5 behavior to 1.6.1:
1) Remove "STRUCT_TASK_STRUCT_HAS_CRED" define. Autotools is correctly
checking for the existence of a "credentials" structure inside
task_struct (kernel). Since newer kernels (3.x) have this structure, the
code defines STRUCT_TASK_STRUCT_HAS_CRED variable and starts accessing
all credential variables directly from kernel defined structures
(includes). Removing this would make openafs behave like it used to in
the past (older kernels from 2.6.x) and would imply fixing all
"current_task"->cred structure (changing upstream code on that specific
version). Of course, after this, even more changes would be expected.
-> not a good approach
2) Cherry-pick code from 1.6.5 to 1.6.1. There are 398 commits between
this two versions and, taking in consideration only dkms module, this
could be a reasonable direction. The problem is that since there are a
huge amount of changes in the kernel structures for process, sched,
security (between v3.2 and v3.11) the changes wouldn't be acceptable on
SRU.
Some of needed changes would be: dentry_open new prototype, kmap_atomic
new prototype, vmtruncated deprecated, task_struct cred session_keyring
location, new proc_create function on module, and so on...
Title:
openafs-modules-dkms 1.6.1-1+ubuntu0.2: module FTBFS on 3.8.0
Status in “openafs” package in Ubuntu:
Invalid
Status in “openafs” source package in Precise:
In Progress
Bug description:
[Impact]
Since the backported Raring kernel 3.8 was released into Precise and is
installed by default, OpenAFS cannot be installed on Precise. The out-of-tree
OpenAFS kernel module needs to be upgraded to support kernel 3.8.
This happened before for the backported Quantal kernel 3.5 (bug
1015925), but this time so many patches are needed that it’s less
risky to take a new upstream stable release, which is already well-
tested, than to try to decide which patches to cherry-pick.
[Test Case]
apt-get install openafs-modules-dkms
(This should succeed on all supported Precise kernels, 3.2, 3.5, and 3.8.)
[Regression Potential]
OpenAFS 1.6.5 has been well-tested in the OpenAFS PPA https://launchpad.net/~openafs/+archive/stable,
which has many users at MIT. The 1.6.x series is focused on important bug fixes
and new kernel support (with main development happening on the master branch
that will become 1.8.x, and Windows development happening on 1.7.x).
This system has been removed and the fils all backed up for futurew use of a new install. Thanks for the support Rafael.
Stephen Corbin
<email address hidden>
-----Original Message----- modules- dkms 1.6.1-1+ubuntu0.2: module FTBFS on 3.8.0
From: Rafael David Tinoco <email address hidden>
To: bigredsshop <email address hidden>
Sent: Tue, May 27, 2014 8:11 am
Subject: [Bug 1206387] Re: openafs-
After this discussion (and some other customers/users requests on the
same bug), knowing that the 1.6.5 backport was not eligible for a SRU
(just like Steve pointed out) I started to cherry-pick code from openafs
1.6.5 to openafs 1.6.1, so the openafs dkms module was able to compile
on HWE kernels.
With that I could see that this approach would also not result in a
eligible RSU. There are too many changes from kernel 3.2 to kernel 3.11
and openafs has a huge amount of pre-defined code based on these changes
(Rightly pointed out by Anders).
After fixing some wrongly auto-generated includes, I could see that
there were 2 approaches for bringing 1.6.5 behavior to 1.6.1:
1) Remove "STRUCT_ TASK_STRUCT_ HAS_CRED" define. Autotools is correctly TASK_STRUCT_ HAS_CRED variable and starts accessing task"-> cred structure (changing upstream code on that specific
checking for the existence of a "credentials" structure inside
task_struct (kernel). Since newer kernels (3.x) have this structure, the
code defines STRUCT_
all credential variables directly from kernel defined structures
(includes). Removing this would make openafs behave like it used to in
the past (older kernels from 2.6.x) and would imply fixing all
"current_
version). Of course, after this, even more changes would be expected.
-> not a good approach
2) Cherry-pick code from 1.6.5 to 1.6.1. There are 398 commits between
this two versions and, taking in consideration only dkms module, this
could be a reasonable direction. The problem is that since there are a
huge amount of changes in the kernel structures for process, sched,
security (between v3.2 and v3.11) the changes wouldn't be acceptable on
SRU.
Some of needed changes would be: dentry_open new prototype, kmap_atomic
new prototype, vmtruncated deprecated, task_struct cred session_keyring
location, new proc_create function on module, and so on...
-> not a good approach also
* see next comment
-- /bugs.launchpad .net/bugs/ 1206387
You received this bug notification because you are subscribed to a
duplicate bug report (1249289).
https:/
Title: modules- dkms 1.6.1-1+ubuntu0.2: module FTBFS on 3.8.0
openafs-
Status in “openafs” package in Ubuntu:
Invalid
Status in “openafs” source package in Precise:
In Progress
Bug description:
[Impact]
Since the backported Raring kernel 3.8 was released into Precise and is
installed by default, OpenAFS cannot be installed on Precise. The out-of-tree
OpenAFS kernel module needs to be upgraded to support kernel 3.8.
This happened before for the backported Quantal kernel 3.5 (bug
1015925), but this time so many patches are needed that it’s less
risky to take a new upstream stable release, which is already well-
tested, than to try to decide which patches to cherry-pick.
[Test Case] modules- dkms
apt-get install openafs-
(This should succeed on all supported Precise kernels, 3.2, 3.5, and 3.8.)
[Regression Potential] /launchpad. net/~openafs/ +archive/ stable,
OpenAFS 1.6.5 has been well-tested in the OpenAFS PPA https:/
which has many users at MIT. The 1.6.x series is focused on important bug fixes
and new kernel support (with main development happening on the master branch
that will become 1.8.x, and Windows development happening on 1.7.x).
ProblemType: Package modules- dkms 1.6.1-1+ubuntu0.2 gnature: Ubuntu 3.5.0-37. 58~precise1- generic 3.5.7.16 Modules: openafs sion: 3.8.0-27-generic edia: Ubuntu 12.04.2 LTS "Precise Pangolin" - Release amd64 ecture: all modules- dkms 1.6.1-1+ubuntu0.2: openafs kernel module failed to
DistroRelease: Ubuntu 12.04
Package: openafs-
ProcVersionSi
Uname: Linux 3.5.0-37-generic x86_64
NonfreeKernel
ApportVersion: 2.0.1-0ubuntu17.3
Architecture: amd64
DKMSKernelVer
Date: Tue Jul 30 02:32:14 2013
InstallationM
(20130214)
MarkForUpload: True
PackageArchit
PackageVersion: 1.6.1-1+ubuntu0.2
SourcePackage: openafs
Title: openafs-
build
UpgradeStatus: No upgrade log present (probably fresh install)
To manage notifications about this bug go to: /bugs.launchpad .net/ubuntu/ +source/ openafs/ +bug/1206387/ +subscriptions
https:/