Comment 3 for bug 1167337

Where can I find this 2 upstart files?

I have also tested a sleep of 10 sec before starting rpc.gssd, which also
helps to solve the problem mostly.

The problem here was a started rpc.gssd with wrong or no credentials (missing
network connection at start of rpc.gssd).(mount was denied by server). I than
have no /tmp/krb5cc_machine_* credential.
In about 50% of boots the mounts work, in 50% not. This also depends on the
hardware of the machine, as the time for the network-start-up influences the
rpc.gssd startup.
On some machines there is no Problem at all (maybe one in 30 boots) but other
machines results in 50% boot failed.

In the boot failed situations only a manual restart of rpc.gssd solves the
mount denied situation. (here you have to press "S" very fast, as after some
time the machine ignores the "S"-key and the system hangs)

The problem may also arise in ignoring the _netdev option in the fstab file.
So mounting network filesystems without network connection is not a very good
idea at all, because it will never work.

On Tuesday 16 April 2013, Steve Langasek wrote:
> So while there have been updates to the gssd job in later releases,
> these updates were to change the job so that it does not depend on
> portmap *at all*. The rationale is that gssd is not actually supposed
> to need to talk to rpcbind... and this is true of the version in 12.04
> as well.
>
> And in any case, even when there was a dependency on portmap, this was
> only supposed to ever have been relevant for NFSv3, not for NFSv4.
>
> So I don't see how rpc.gssd starting before portmap was actually causing
> this problem for you. Could you try installing the /etc/init/gssd.conf
> and /etc/init/gssd-mounting.conf jobs from Ubuntu 12.10, to see if the
> problem persists?
>
> ** Changed in: nfs-utils (Ubuntu)
> Status: New => Incomplete