Re: Before I start carving wheels....

Re: Before I start carving wheels....

[Jeff Moyer]

Vincent Liggio <vince@blueskystudios.com> writes:

> On Tue, 22 Feb 2011, Lee Damon wrote:
>
>> Has anyone done the work to get am-utils to compile on RHEL 6?  It seems the most recent autoconf tools don't like the contents of the 6.1.5 tarball.
>>

> I'm guessing it won't work even if you get it to compile. We've been
> trying to get it to work with the F14 latest kernel, and it just won't
> function (we were able to get it to work on F12, but autofs3 refuses
> to work on the F14 kernel).

The autofs maintainer (Ian Kent) tries to keep the v4 kernel module
compatible with v3.  However, if you don't report problems, they won't
get fixed (most testing these days is with autofs version 5).

> It performs horribly with nfs mode. Think it's time to move onto
> supported technology unfortunately (autofs5 is no great shakes, we're
> going to try autofs4).

autofs4 isn't exactly supported technology either.  You'd be moving from
one dead-end to another.  I've CC'd the autofs list.  If you have
suggestions and/or specific bugs, please let us know.

Cheers,
Jeff

Re: Before I start carving wheels....

[Vincent Liggio]

On 02/23/2011 09:19 AM, Jeff Moyer wrote:
> Vincent Liggio<vince@blueskystudios.com>  writes:
>
>> I'm guessing it won't work even if you get it to compile. We've been
>> trying to get it to work with the F14 latest kernel, and it just won't
>> function (we were able to get it to work on F12, but autofs3 refuses
>> to work on the F14 kernel).
>
> The autofs maintainer (Ian Kent) tries to keep the v4 kernel module
> compatible with v3.  However, if you don't report problems, they won't
> get fixed (most testing these days is with autofs version 5).

I reported on both kernel.org and on am-utils.org that autofs and amd do 
not work with F12's kernel in March/April of 2010 (kernel.org bug 15878 
and am-utils bug 639). No one has acknowledged or worked on the bug, as 
far as I can tell on the respective bugzillas.

We have discovered in the last couple of days that the amd compillation 
is bad on F14, as is the kernel support for autofs. Copying the amd from 
F12 (and the libgdbm library) and installing our custom compiled kernel 
from F12 (with autofs enabled) works. amd from 12 with the kernel from 
14 (2.6.35.10-74) does not work, nor does amd from 14 with the kernel 
from 12 (2.6.32.26-175). amd fails if autofs3 is not on, it does not 
recognize autofs4 as being usable.

NB: this is ONLY with amd in autofs mode. amd in nfs mode works, albeit 
sluggishly. We cannot use nfs mode because some of our tools don't like 
the whole /tmp_mnt structure.

>> It performs horribly with nfs mode. Think it's time to move onto
>> supported technology unfortunately (autofs5 is no great shakes, we're
>> going to try autofs4).
>
> autofs4 isn't exactly supported technology either.  You'd be moving from
> one dead-end to another.  I've CC'd the autofs list.  If you have
> suggestions and/or specific bugs, please let us know.

A very large installations (40,000+ servers) of linux that I know of 
refuses to use autofs5 because of issues with the mutli-threading. I 
know no more than that, but I trust their opinion and experience, and 
have heard rumblings of other groups having issues with autofs5.

Vince

Re: Before I start carving wheels....

[Ian Kent]

On Wed, 2011-02-23 at 10:03 -0500, Vincent Liggio wrote:
> On 02/23/2011 09:19 AM, Jeff Moyer wrote:
> > Vincent Liggio<vince@blueskystudios.com>  writes:
> >
> >> I'm guessing it won't work even if you get it to compile. We've been
> >> trying to get it to work with the F14 latest kernel, and it just won't
> >> function (we were able to get it to work on F12, but autofs3 refuses
> >> to work on the F14 kernel).
> >
> > The autofs maintainer (Ian Kent) tries to keep the v4 kernel module
> > compatible with v3.  However, if you don't report problems, they won't
> > get fixed (most testing these days is with autofs version 5).
> 
> I reported on both kernel.org and on am-utils.org that autofs and amd do 
> not work with F12's kernel in March/April of 2010 (kernel.org bug 15878 
> and am-utils bug 639). No one has acknowledged or worked on the bug, as 
> far as I can tell on the respective bugzillas.

I don't remember seeing any mail on that bug even though I'm on the cc
list for it.

In any case, it's asking for the autofs module to be built as default
which isn't likely to happen since, even at that time, the autofs module
was going to be removed from the kernel.

> 
> We have discovered in the last couple of days that the amd compillation 
> is bad on F14, as is the kernel support for autofs. Copying the amd from 
> F12 (and the libgdbm library) and installing our custom compiled kernel 
> from F12 (with autofs enabled) works. amd from 12 with the kernel from 
> 14 (2.6.35.10-74) does not work, nor does amd from 14 with the kernel 
> from 12 (2.6.32.26-175). amd fails if autofs3 is not on, it does not 
> recognize autofs4 as being usable.

But the autofs4 module should be able to be used for autofs kernel
protocol version 3. It may require some changes in user space and, since
the v3 protocol in autofs4 hasn't been tested for so long, there may be
some other bugs that need fixing.

> 
> NB: this is ONLY with amd in autofs mode. amd in nfs mode works, albeit 
> sluggishly. We cannot use nfs mode because some of our tools don't like 
> the whole /tmp_mnt structure.
> 
> >> It performs horribly with nfs mode. Think it's time to move onto
> >> supported technology unfortunately (autofs5 is no great shakes, we're
> >> going to try autofs4).
> >
> > autofs4 isn't exactly supported technology either.  You'd be moving from
> > one dead-end to another.  I've CC'd the autofs list.  If you have
> > suggestions and/or specific bugs, please let us know.
> 
> A very large installations (40,000+ servers) of linux that I know of 
> refuses to use autofs5 because of issues with the mutli-threading. I 
> know no more than that, but I trust their opinion and experience, and 
> have heard rumblings of other groups having issues with autofs5.
> 
> Vince
> 
> _______________________________________________
> autofs mailing list
> autofs@linux.kernel.org
> http://linux.kernel.org/mailman/listinfo/autofs

Re: Before I start carving wheels....

[Vincent Liggio]

On Thu, 24 Feb 2011, Ian Kent wrote:

>> I reported on both kernel.org and on am-utils.org that autofs and amd do
>> not work with F12's kernel in March/April of 2010 (kernel.org bug 15878
>> and am-utils bug 639). No one has acknowledged or worked on the bug, as
>> far as I can tell on the respective bugzillas.
>
> I don't remember seeing any mail on that bug even though I'm on the cc
> list for it.
>
> In any case, it's asking for the autofs module to be built as default
> which isn't likely to happen since, even at that time, the autofs module
> was going to be removed from the kernel.

It (autofs3) still exists as an option in F14 (if we build our own 
kernel), but doesn't seem to work either as a module or compiled into the 
kernel (it did work in F12). If there were a way for amd to work with 
autofs4, that'd be great, but it doesn't.

> But the autofs4 module should be able to be used for autofs kernel
> protocol version 3. It may require some changes in user space and, since
> the v3 protocol in autofs4 hasn't been tested for so long, there may be
> some other bugs that need fixing.

Problem is that amd I believe specifically looks for autofs3 (even though 
the code says minimum autofs version 3, it fails to work with autofs4). 
And since no one is responding to the bug I put in about that, and the 
last time code was released for amd was in 2005, amd using autofs on the 
current F14 kernel seems to dead.

Vince

Re: Before I start carving wheels....

[Ian Kent]

On Wed, 2011-02-23 at 23:35 -0500, Vincent Liggio wrote:
> On Thu, 24 Feb 2011, Ian Kent wrote:
> 
> >> I reported on both kernel.org and on am-utils.org that autofs and amd do
> >> not work with F12's kernel in March/April of 2010 (kernel.org bug 15878
> >> and am-utils bug 639). No one has acknowledged or worked on the bug, as
> >> far as I can tell on the respective bugzillas.
> >
> > I don't remember seeing any mail on that bug even though I'm on the cc
> > list for it.
> >
> > In any case, it's asking for the autofs module to be built as default
> > which isn't likely to happen since, even at that time, the autofs module
> > was going to be removed from the kernel.
> 
> It (autofs3) still exists as an option in F14 (if we build our own 
> kernel), but doesn't seem to work either as a module or compiled into the 
> kernel (it did work in F12). If there were a way for amd to work with 
> autofs4, that'd be great, but it doesn't.
> 
> > But the autofs4 module should be able to be used for autofs kernel
> > protocol version 3. It may require some changes in user space and, since
> > the v3 protocol in autofs4 hasn't been tested for so long, there may be
> > some other bugs that need fixing.
> 
> Problem is that amd I believe specifically looks for autofs3 (even though 
> the code says minimum autofs version 3, it fails to work with autofs4). 
> And since no one is responding to the bug I put in about that, and the 
> last time code was released for amd was in 2005, amd using autofs on the 
> current F14 kernel seems to dead.

I'll grab the amd source and have a quick look.
Where is the right place to get it?

What exactly are the error messages you get when trying to use autofs4?
When you have tried this have you added an alias to the modprobe config
so that autofs4 will be loaded instead of autofs (although compiling in
autofs4 only, not autofs, should also work)?

Ian

Re: Before I start carving wheels....

[Ian Kent]

On Thu, 2011-02-24 at 14:42 +0800, Ian Kent wrote:
> On Wed, 2011-02-23 at 23:35 -0500, Vincent Liggio wrote:
> > On Thu, 24 Feb 2011, Ian Kent wrote:
> > 
> > >> I reported on both kernel.org and on am-utils.org that autofs and amd do
> > >> not work with F12's kernel in March/April of 2010 (kernel.org bug 15878
> > >> and am-utils bug 639). No one has acknowledged or worked on the bug, as
> > >> far as I can tell on the respective bugzillas.
> > >
> > > I don't remember seeing any mail on that bug even though I'm on the cc
> > > list for it.
> > >
> > > In any case, it's asking for the autofs module to be built as default
> > > which isn't likely to happen since, even at that time, the autofs module
> > > was going to be removed from the kernel.
> > 
> > It (autofs3) still exists as an option in F14 (if we build our own 
> > kernel), but doesn't seem to work either as a module or compiled into the 
> > kernel (it did work in F12). If there were a way for amd to work with 
> > autofs4, that'd be great, but it doesn't.
> > 
> > > But the autofs4 module should be able to be used for autofs kernel
> > > protocol version 3. It may require some changes in user space and, since
> > > the v3 protocol in autofs4 hasn't been tested for so long, there may be
> > > some other bugs that need fixing.
> > 
> > Problem is that amd I believe specifically looks for autofs3 (even though 
> > the code says minimum autofs version 3, it fails to work with autofs4). 
> > And since no one is responding to the bug I put in about that, and the 
> > last time code was released for amd was in 2005, amd using autofs on the 
> > current F14 kernel seems to dead.
> 
> I'll grab the amd source and have a quick look.
> Where is the right place to get it?

It looks like amd should work with autofs protocol version v4.
You should also try "modprobe autofs4" before starting amd and see what
happens.

Ian

Re: Before I start carving wheels....

[Vincent Liggio]

On 02/24/2011 05:42 AM, Ian Kent wrote:
>
> It looks like amd should work with autofs protocol version v4.
> You should also try "modprobe autofs4" before starting amd and see what
> happens.

We tried that before, and this is what happens:

Feb 24 14:40:39 canton_64 amd[1504]: initializing amd.conf map amd.net 
of type nis
Feb 24 14:40:39 canton_64 amd[1504]: amd.net mounted fstype toplvl on /net
Feb 24 14:40:39 canton_64 amd[1504]: autofs: using protocol version 5
Feb 24 14:40:39 canton_64 amd[1504]: /net set to never timeout

Then we change to a directory and we get:

Feb 24 14:40:57 canton_64 amd[1504]: Unknown autofs packet type 3

lsmod
Module                  Size  Used by
autofs4                22687  13
ipv6                  278339  24
ppdev                   7925  0
parport_pc             21081  0
parport                31509  2 ppdev,parport_pc
e1000                  92062  0
i2c_piix4              11998  0
shpchp                 29568  0
i2c_core               26926  1 i2c_piix4
mptspi                 14609  3
mptscsih               28444  1 mptspi
mptbase                74728  2 mptspi,mptscsih
scsi_transport_spi     22211  1 mptspi

Re: Before I start carving wheels....

[Ian Kent]

On Thu, 2011-02-24 at 15:11 -0500, Vincent Liggio wrote:
> On 02/24/2011 05:42 AM, Ian Kent wrote:
> >
> > It looks like amd should work with autofs protocol version v4.
> > You should also try "modprobe autofs4" before starting amd and see what
> > happens.
> 
> We tried that before, and this is what happens:
> 
> Feb 24 14:40:39 canton_64 amd[1504]: initializing amd.conf map amd.net 
> of type nis
> Feb 24 14:40:39 canton_64 amd[1504]: amd.net mounted fstype toplvl on /net
> Feb 24 14:40:39 canton_64 amd[1504]: autofs: using protocol version 5

This is wrong, amd hasn't used the correct mount options or I'm not
parsing the options correctly. Not sure that I am parsing the options
incorrectly since autofs version 4 needs to use the version 4 protocol
and it seems to be able to request that OK.

> Feb 24 14:40:39 canton_64 amd[1504]: /net set to never timeout
> 
> Then we change to a directory and we get:
> 
> Feb 24 14:40:57 canton_64 amd[1504]: Unknown autofs packet type 3
> 
> lsmod
> Module                  Size  Used by
> autofs4                22687  13
> ipv6                  278339  24
> ppdev                   7925  0
> parport_pc             21081  0
> parport                31509  2 ppdev,parport_pc
> e1000                  92062  0
> i2c_piix4              11998  0
> shpchp                 29568  0
> i2c_core               26926  1 i2c_piix4
> mptspi                 14609  3
> mptscsih               28444  1 mptspi
> mptbase                74728  2 mptspi,mptscsih
> scsi_transport_spi     22211  1 mptspi
> 

Re: Before I start carving wheels....

[Ion Badulescu]

On Thu, 24 Feb 2011, Ian Kent wrote:

>>>> But the autofs4 module should be able to be used for autofs kernel
>>>> protocol version 3. It may require some changes in user space and, since
>>>> the v3 protocol in autofs4 hasn't been tested for so long, there may be
>>>> some other bugs that need fixing.
>>>
>>> Problem is that amd I believe specifically looks for autofs3 (even though
>>> the code says minimum autofs version 3, it fails to work with autofs4).
>>> And since no one is responding to the bug I put in about that, and the
>>> last time code was released for amd was in 2005, amd using autofs on the
>>> current F14 kernel seems to dead.
>>
>> I'll grab the amd source and have a quick look.
>> Where is the right place to get it?
>
> It looks like amd should work with autofs protocol version v4.
> You should also try "modprobe autofs4" before starting amd and see what
> happens.

No, amd will happily work with either autofs3 or autofs4.

The problem is that it (optimistically) tries to use the highest version 
that the kernel supports, which is autofs5 these days. But it itself 
doesn't have support for autofs5, so it fails miserably.

The patch (copy/pasted so it might not apply cleanly) fixes autofs:

commit 5cefcd3e1c7cb4943697e48996b8b1cbc7a9e7de
Author: Ion Badulescu <ionut@buggy.badula.org>
Date:   Tue Nov 30 07:14:23 2010 -0500

     max supported autofs version is 4

diff --git a/conf/autofs/autofs_linux.c b/conf/autofs/autofs_linux.c
index af61804..e901da7 100644
--- a/conf/autofs/autofs_linux.c
+++ b/conf/autofs/autofs_linux.c
@@ -59,7 +59,7 @@
   */

  #define AUTOFS_MIN_VERSION 3
-#define AUTOFS_MAX_VERSION AUTOFS_MAX_PROTO_VERSION
+#define AUTOFS_MAX_VERSION 4


  /*


-Ion

Re: Before I start carving wheels....

[Ian Kent]

On Fri, 2011-02-25 at 12:39 -0500, Ion Badulescu wrote:
> On Thu, 24 Feb 2011, Ian Kent wrote:
> 
> >>>> But the autofs4 module should be able to be used for autofs kernel
> >>>> protocol version 3. It may require some changes in user space and, since
> >>>> the v3 protocol in autofs4 hasn't been tested for so long, there may be
> >>>> some other bugs that need fixing.
> >>>
> >>> Problem is that amd I believe specifically looks for autofs3 (even though
> >>> the code says minimum autofs version 3, it fails to work with autofs4).
> >>> And since no one is responding to the bug I put in about that, and the
> >>> last time code was released for amd was in 2005, amd using autofs on the
> >>> current F14 kernel seems to dead.
> >>
> >> I'll grab the amd source and have a quick look.
> >> Where is the right place to get it?
> >
> > It looks like amd should work with autofs protocol version v4.
> > You should also try "modprobe autofs4" before starting amd and see what
> > happens.
> 
> No, amd will happily work with either autofs3 or autofs4.

My point above was that, in the past we've seen the wrong module loaded
or no module loaded because of name match failure. Pre-loading the
module uncovers those sorts of difficulties.

> 
> The problem is that it (optimistically) tries to use the highest version 
> that the kernel supports, which is autofs5 these days. But it itself 
> doesn't have support for autofs5, so it fails miserably.
> 
> The patch (copy/pasted so it might not apply cleanly) fixes autofs:
> 
> commit 5cefcd3e1c7cb4943697e48996b8b1cbc7a9e7de
> Author: Ion Badulescu <ionut@buggy.badula.org>
> Date:   Tue Nov 30 07:14:23 2010 -0500
> 
>      max supported autofs version is 4
> 
> diff --git a/conf/autofs/autofs_linux.c b/conf/autofs/autofs_linux.c
> index af61804..e901da7 100644
> --- a/conf/autofs/autofs_linux.c
> +++ b/conf/autofs/autofs_linux.c
> @@ -59,7 +59,7 @@
>    */
> 
>   #define AUTOFS_MIN_VERSION 3
> -#define AUTOFS_MAX_VERSION AUTOFS_MAX_PROTO_VERSION
> +#define AUTOFS_MAX_VERSION 4
> 
> 
>   /*
> 
> 
> -Ion

Re: Before I start carving wheels....

[Vincent Liggio]

Bug 680669 filed on bugzilla.redhat.com (crediting Ion's code).

Re: Before I start carving wheels....

[Vincent Liggio]

Ok, that works. I will put a bug report into redhat so they hopefully 
will integrate that into the latest code. Why they are releasing a -18 
for F15 I don't get, when it doesn't even have any code changes.

So to sum up, amd 6.1.5 patched as below works fine on F14 kernel's with 
autofs4.

The amd redhat supplies does NOT work, in fact, it doesn't even load 
properly with autofs enabled.

Vince

On 02/25/2011 12:39 PM, Ion Badulescu wrote:
> On Thu, 24 Feb 2011, Ian Kent wrote:
>
>>>>> But the autofs4 module should be able to be used for autofs kernel
>>>>> protocol version 3. It may require some changes in user space and,
>>>>> since
>>>>> the v3 protocol in autofs4 hasn't been tested for so long, there
>>>>> may be
>>>>> some other bugs that need fixing.
>>>>
>>>> Problem is that amd I believe specifically looks for autofs3 (even
>>>> though
>>>> the code says minimum autofs version 3, it fails to work with autofs4).
>>>> And since no one is responding to the bug I put in about that, and the
>>>> last time code was released for amd was in 2005, amd using autofs on
>>>> the
>>>> current F14 kernel seems to dead.
>>>
>>> I'll grab the amd source and have a quick look.
>>> Where is the right place to get it?
>>
>> It looks like amd should work with autofs protocol version v4.
>> You should also try "modprobe autofs4" before starting amd and see what
>> happens.
>
> No, amd will happily work with either autofs3 or autofs4.
>
> The problem is that it (optimistically) tries to use the highest version
> that the kernel supports, which is autofs5 these days. But it itself
> doesn't have support for autofs5, so it fails miserably.
>
> The patch (copy/pasted so it might not apply cleanly) fixes autofs:
>
> commit 5cefcd3e1c7cb4943697e48996b8b1cbc7a9e7de
> Author: Ion Badulescu <ionut@buggy.badula.org>
> Date: Tue Nov 30 07:14:23 2010 -0500
>
> max supported autofs version is 4
>
> diff --git a/conf/autofs/autofs_linux.c b/conf/autofs/autofs_linux.c
> index af61804..e901da7 100644
> --- a/conf/autofs/autofs_linux.c
> +++ b/conf/autofs/autofs_linux.c
> @@ -59,7 +59,7 @@
> */
>
> #define AUTOFS_MIN_VERSION 3
> -#define AUTOFS_MAX_VERSION AUTOFS_MAX_PROTO_VERSION
> +#define AUTOFS_MAX_VERSION 4
>
>
> /*
>
>
> -Ion

Re: Before I start carving wheels....

[Ion Badulescu]

On Sat, 26 Feb 2011, Vincent Liggio wrote:

> Ok, that works. I will put a bug report into redhat so they hopefully will 
> integrate that into the latest code. Why they are releasing a -18 for F15 I 
> don't get, when it doesn't even have any code changes.
>
> So to sum up, amd 6.1.5 patched as below works fine on F14 kernel's with 
> autofs4.
>
> The amd redhat supplies does NOT work, in fact, it doesn't even load properly 
> with autofs enabled.

Yeah, I know... it hasn't worked since f10. I've been using the f10 rpm 
on all newer fedora versions (when not running my locally compiled one)...

-Ion

Re: Before I start carving wheels....

[Ian Kent]

On Sat, 2011-02-26 at 15:24 -0500, Vincent Liggio wrote:
> Ok, that works. I will put a bug report into redhat so they hopefully 
> will integrate that into the latest code. Why they are releasing a -18 
> for F15 I don't get, when it doesn't even have any code changes.

You didn't look:
* Mon Feb 07 2011 Fedora Release Engineering
<rel-eng@lists.fedoraproject.org> - 5:6.1.5-18
- Rebuilt for https://fedoraproject.org/wiki/Fedora_15_Mass_Rebuild

Standard practice when branching a release, to ensure packages that may
not have been re-built don't have broken dependencies.

> 
> So to sum up, amd 6.1.5 patched as below works fine on F14 kernel's with 
> autofs4.
> 
> The amd redhat supplies does NOT work, in fact, it doesn't even load 
> properly with autofs enabled.

What are you saying?
If you add this patch to Fedora am-utils it then works?

If that's not the case then there is more work to do!

> 
> Vince
> 
> On 02/25/2011 12:39 PM, Ion Badulescu wrote:
> > On Thu, 24 Feb 2011, Ian Kent wrote:
> >
> >>>>> But the autofs4 module should be able to be used for autofs kernel
> >>>>> protocol version 3. It may require some changes in user space and,
> >>>>> since
> >>>>> the v3 protocol in autofs4 hasn't been tested for so long, there
> >>>>> may be
> >>>>> some other bugs that need fixing.
> >>>>
> >>>> Problem is that amd I believe specifically looks for autofs3 (even
> >>>> though
> >>>> the code says minimum autofs version 3, it fails to work with autofs4).
> >>>> And since no one is responding to the bug I put in about that, and the
> >>>> last time code was released for amd was in 2005, amd using autofs on
> >>>> the
> >>>> current F14 kernel seems to dead.
> >>>
> >>> I'll grab the amd source and have a quick look.
> >>> Where is the right place to get it?
> >>
> >> It looks like amd should work with autofs protocol version v4.
> >> You should also try "modprobe autofs4" before starting amd and see what
> >> happens.
> >
> > No, amd will happily work with either autofs3 or autofs4.
> >
> > The problem is that it (optimistically) tries to use the highest version
> > that the kernel supports, which is autofs5 these days. But it itself
> > doesn't have support for autofs5, so it fails miserably.
> >
> > The patch (copy/pasted so it might not apply cleanly) fixes autofs:
> >
> > commit 5cefcd3e1c7cb4943697e48996b8b1cbc7a9e7de
> > Author: Ion Badulescu <ionut@buggy.badula.org>
> > Date: Tue Nov 30 07:14:23 2010 -0500
> >
> > max supported autofs version is 4
> >
> > diff --git a/conf/autofs/autofs_linux.c b/conf/autofs/autofs_linux.c
> > index af61804..e901da7 100644
> > --- a/conf/autofs/autofs_linux.c
> > +++ b/conf/autofs/autofs_linux.c
> > @@ -59,7 +59,7 @@
> > */
> >
> > #define AUTOFS_MIN_VERSION 3
> > -#define AUTOFS_MAX_VERSION AUTOFS_MAX_PROTO_VERSION
> > +#define AUTOFS_MAX_VERSION 4
> >
> >
> > /*
> >
> >
> > -Ion

Re: Before I start carving wheels....

[Vincent Liggio]

On Sun, 27 Feb 2011, Ian Kent wrote:

> You didn't look:
> * Mon Feb 07 2011 Fedora Release Engineering
> <rel-eng@lists.fedoraproject.org> - 5:6.1.5-18
> - Rebuilt for https://fedoraproject.org/wiki/Fedora_15_Mass_Rebuild
>
> Standard practice when branching a release, to ensure packages that may
> not have been re-built don't have broken dependencies.

I did look and saw that. I guess I always considered those as code version 
numbers, not compilation version numbers, my bad. Good to know.

> What are you saying?
> If you add this patch to Fedora am-utils it then works?

Yes. I downloaded the F14 SRPM for am-utils, changed that one line, did 
an rpmbuild, and it works with the default F14 kernel.

The F14 supplied amd from am-utils-6.1.5-17 does NOT work at all with 
autofs - we compiled a kernel with autofs3 enabled, amd would not load. We 
tried our F12 kernel (which we compiled with autofs3 enabled and which 
worked on our F12 machines), along with the amd from F14 and amd wouldn't 
load. We copied over the F12 amd binaries, and the F12 amd loaded fine 
with both of our F14 and F12 kernels that we modified for autofs3.

Re: Before I start carving wheels....

[Ian Kent]

On Sun, 2011-02-27 at 00:01 -0500, Vincent Liggio wrote:
> On Sun, 27 Feb 2011, Ian Kent wrote:
> 
> > What are you saying?
> > If you add this patch to Fedora am-utils it then works?
> 
> Yes. I downloaded the F14 SRPM for am-utils, changed that one line, did 
> an rpmbuild, and it works with the default F14 kernel.

Great, then hopefully Karl will just add the patch and we'll be good.

> 
> The F14 supplied amd from am-utils-6.1.5-17 does NOT work at all with 
> autofs - we compiled a kernel with autofs3 enabled, amd would not load. We 
> tried our F12 kernel (which we compiled with autofs3 enabled and which 
> worked on our F12 machines), along with the amd from F14 and amd wouldn't 
> load. We copied over the F12 amd binaries, and the F12 amd loaded fine 
> with both of our F14 and F12 kernels that we modified for autofs3.
> 

To be honest I don't think trying to work out what VFS change broke this
is worth while (if in fact it was a VFS change, there have been a few
prior to 2.6.38). The fact is that autofs has been removed from 2.6.38
and we need to spend our time making sure the autofs4 module works with
products that use autofs the kernel communication protocols.

The final change needed is for autofs4 to be renamed to autofs to
finally remove that fork in development. I'm looking forward to the
breakage that will cause, ;)

Ian

Re: Before I start carving wheels....

[Vincent Liggio]

Oh, and many thanks Ian and Ion!