Since precise has reached end of life, this is 'wontfix' for that
release.
** Changed in: nfs-utils (Ubuntu Precise)
Status: Triaged => Won't Fix
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/6
** Tags added: precise
** Tags removed: glucid
** Tags added: lucid
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/643289
Title:
idmapd does not starts to work after system reboot
To manage notific
** Tags removed: precise
** Tags added: maverick
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/643289
Title:
idmapd does not starts to work after system reboot
To manage notifications about this bu
The precise-proposed package was superseded, so removing verification-
needed tag.
** Tags removed: lucid verification-needed
** Tags added: precise
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/64328
** Branch linked: lp:debian/mountall
** Branch linked: lp:~ubuntu-branches/ubuntu/precise/mountall/precise-
proposed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/643289
Title:
idmapd does not star
** Branch linked: lp:~ubuntu-branches/ubuntu/saucy/nfs-utils/saucy-
proposed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/643289
Title:
idmapd does not starts to work after system reboot
To manage
The mountall part of this is fixed. now we can update nfs-utils to
match.
** Changed in: mountall (Ubuntu Precise)
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.ne
I *think* this is fix-released in precise, right?
precise now has 2.36.3 and changelog reports it fixed in 2.36.2.
I'll test bug bug 1031065 tomomorrow.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/6
I had this crazy problem with NFS and not started idmapd after reboot on my
Ubuntu 12.10 x64.
I tested a lot of advices from the internet but found my crazy soltion. I don't
know why it works :)
I used to have in my fstab:
10.254.239.1:/usr/data/disk_1 /usr/data/disk_1 nfs4
_netdev,
Hello Alexander, or anyone else affected,
Accepted mountall into precise-proposed. The package will build now and
be available at http://launchpad.net/ubuntu/+source/mountall/2.36.2 in a
few hours, and then in the -proposed repository.
Please help us by testing this new package. See
https://wiki
marking verification-failed due to bug #1078926.
** Tags removed: verification-needed
** Tags added: verification-failed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/643289
Title:
idmapd does not
Hello Alexander, or anyone else affected,
Accepted mountall into precise-proposed. The package will build now and
be available at http://launchpad.net/ubuntu/+source/mountall/2.36.1 in a
few hours, and then in the -proposed repository.
Please help us by testing this new package. See
https://wiki
** Description changed:
+ [Impact]
+ Systems which make extensive use of NFS mounts have not been able to boot
reliably since the migration to mountall in Ubuntu 9.10. This is because of
race conditions in the handling of mounts vs. the startup of NFS client
daemons. A proper fix of the start
This bug was fixed in the package nfs-utils - 1:1.2.6-3ubuntu2
---
nfs-utils (1:1.2.6-3ubuntu2) quantal; urgency=low
[ Steve Langasek ]
* Adjust upstart jobs to treat TYPE=nfs and TYPE=nfs4 mounts identically,
since TYPE=nfs4 is considered deprecated.
* Fix various boot-time
This bug was fixed in the package mountall - 2.41
---
mountall (2.41) unstable; urgency=low
[ Alexander Achenbach ]
* Don't block other, unrelated mounts from being processed while one
mount is blocked on its mounting signal to process. LP: #643289.
[ Steve Langasek ]
*
Steve, I've got a mountall build a ppa at
https://launchpad.net/~smoser/+archive/ephermal-fixes and am testing it.
Generally it seems good for me. Is there anything I can do to help get
this tested to be uploaded?
--
You received this bug notification because you are a member of Ubuntu
Bugs, whi
** Branch linked: lp:ubuntu/nfs-utils
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/643289
Title:
idmapd does not starts to work after system reboot
To manage notifications about this bug go to:
ht
** Also affects: nfs-utils (Ubuntu Precise)
Importance: Undecided
Status: New
** Also affects: mountall (Ubuntu Precise)
Importance: Undecided
Status: New
** Changed in: mountall (Ubuntu Precise)
Status: New => Triaged
** Changed in: mountall (Ubuntu Precise)
Import
** Branch linked: lp:ubuntu/mountall
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/643289
Title:
idmapd does not starts to work after system reboot
To manage notifications about this bug go to:
htt
** Changed in: mountall (Ubuntu)
Assignee: James Hunt (jamesodhunt) => Steve Langasek (vorlon)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/643289
Title:
idmapd does not starts to work after s
I found this bug effect my systems today after installing LDAP. I hope
there will be update soon for Lucid. Working on solving the bug is out
of my reach. So big thanks great appreciation to all the developers.
Vang.
--
You received this bug notification because you are a member of Ubuntu
Bugs,
I've never had /usr on a separate partition, only /home/bronger, yet I
see this bug.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/643289
Title:
idmapd does not starts to work after system reboot
T
On Fri, Nov 04, 2011 at 11:35:04AM -, maxjos wrote:
> Is there any update on this? 11.04 with Kerberos, NFSv4, automount 5,
> idmapd does not start automatically.
The update is that bug #811823 already fixes the startup of idmapd to the
best of anyone's knowledge, and the remaining issue is on
Is there any update on this? 11.04 with Kerberos, NFSv4, automount 5,
idmapd does not start automatically.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/643289
Title:
idmapd does not starts to work
Steve, I tried out nfs-common 1:1.2.0-4ubuntu4.2 from lucid-proposed (as
referenced in bug 811823), and it works fine for me.
My problem was caused by a race condition with the rpc_pipefs dependency
(as verified by adding a sleep in rpc_pipefs.conf), so this will
obviously fix this problem.
--
Y
Hi Steve, I do not have a separate /usr partition
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/643289
Title:
idmapd does not starts to work after system reboot
To manage notifications about this b
maxjos, you don't mention in your comment whether you have /usr on a
separate partition or not, so I have no way to confirm whether yours is
the same issue as the one being fixed in bug #811823. Can you confirm
whether you have /usr mounted as a separate partition?
--
You received this bug notif
maxjos, this bug is not fixed in -proposed or even in a dev release of
Ubuntu. Please comment on bug 811823, and try the explicit "TEST CASE"
mentioned in the description of that bug, reporting your results.
Thanks!
--
You received this bug notification because you are a member of Ubuntu
Bugs, wh
I have enabled -proposed (ref bug 811823) and idmapd still not starting.
The setup is natty with -proposed, Automount, NFSv4, Kerberos and
NEED_IDMAPD=yes in /etc/default/nfs-common
After boot idmapd is (consistently) not running. Using 'service idmapd
start' after boot does not work and I need t
Hi Steve,
I will have a look at #811823 later on, but for a start:
We have /var mounted as a separate partition on all installations
on which we see the idmapd start-up problems. The same goes for
/usr and /tmp.
Cheers,
Alex
On 19/07/11 18:59, Steve Langasek wrote:
> iFred,
>
> I could not rep
Those who are experiencing problems with idmapd not starting reliably at
boot, please see bug #811823 and provide feedback there for the SRU
packages that have just been accepted into the -proposed pocket for
lucid, maverick, and natty. I've opened this as a separate bug because
there is still an
iFred,
I could not reproduce this problem even before I made that change to
/etc/init{idmapd,gssd}.conf in oneiric.
Something has just occurred to me, however, Could it be that the users
seeing this bug all had /var as a separate partition? In thas case, the
rpc_pipefs job would fail if /var is
Met same problem in natty.
@Steve Langasek
There is no way to reproduce open(/var/lib/nfs/rpc_pipefs/nfs) problem in
oneric because mount-related actions from /etc/init/rpc_pipefs.conf were moved
to /etc/init/idmapd.conf and /etc/init/gssd.conf.
I think, that best solution for this bug is to bac
I think this bug is in a somewhat confused state at the moment. I have
tried now to reproduce the problem using oneiric, which as of the latest
SRU had the same upstart job handling as in lucid. (Apparently we had
already SRUed for this issue, and I had subsequently forgotten!) The
only problem
I agree with Steve's analysis; the NEED_IDMAPD check here is redundant.
I have actually considered moving the rpc_pipefs job's contents directly
into the idmapd and gssd jobs since the current start condition of
rpc_pipefs makes it significantly less useful to have it as a separate
job, but haven't
I don't see the point of checking whether NEED_IDMAPD=yes is in
/etc/default/nfs-common. The "script" block is only going to run when
the pre-script determines that idmapd should be started. (Even if you
did need to check NEED_IDMAPD, you'd want to read it out of the
environment rather than grepp
Hi Guys,
I reproduced the issue using Steve Atwell's modification in
/etc/init/rpc_pipefs.conf and I am able to reproduce the same issue in a
stock Lucid install.
It looks like /etc/init/idmapd.conf needs also another if statement that
checks whether the client is using nfsv4 or not. I made a sma
Excerpts from Steve Atwell's message of Sat Jun 25 01:09:05 UTC 2011:
> In my configuration, /etc/fstab has only local filesystems. NFS
> filesystems are not mounted until later by autofs.
>
> This means that idmapd should be starting on the local-filesystems
> event.
>
> rpc_pipefs has "start o
Interestingly, I'm not able to reproduce my findings in the comment
above with a stock Lucid install (choosing just openssh in tasksel, then
installing nfs-common and turning on statd, gssd, and idmapd in
/etc/default/nfs-common).
However, I did verify that, on the systems I can reproduce this on,
In my configuration, /etc/fstab has only local filesystems. NFS
filesystems are not mounted until later by autofs.
This means that idmapd should be starting on the local-filesystems
event.
rpc_pipefs has "start on (starting gssd or starting idmapd)". My
understanding is that rpc_pipefs should r
Hi Steve,
I have an environment for testing purposes currently configured with Kerberos +
NFSv4 running on Lucid 10.04. I still could not replicate the issue since it
looks like it occurs randomly.
Please let me know if you have some ideas on how to create a testing scenario
for this issue. We
** Also affects: mountall (Ubuntu Lucid)
Importance: Undecided
Status: New
** Also affects: nfs-utils (Ubuntu Lucid)
Importance: Undecided
Status: New
** Changed in: mountall (Ubuntu Lucid)
Status: New => Triaged
** Changed in: mountall (Ubuntu Lucid)
Importance: Un
We appear to have solved this problem by modifying /etc/init/idmapd.conf
and changing:
start on (local-filesystems or mounting TYPE=nfs4)
to
start on (net-device-up or mounting TYPE=nfs4)
Comments?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscri
** Tags added: glucid lucid
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/643289
Title:
idmapd does not starts to work after system reboot
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
Thanks Alexander!
I've investigated your patches and find them very interesting, clearly
based on the same model of portmap/portmap-wait.
Still, I was looking for the less intrusive possible modification in the
time being (while this bug is being investigated thoughtfully, I hope,
by Canonical an
Hi Jean,
I can only (temporarily) offer the patched mountall packages we use
on our cluster for just over 400 machines:
http://fias.uni-frankfurt.de/~xela/mountall_2.20.1xela2_amd64.deb
http://fias.uni-frankfurt.de/~xela/mountall_2.20.1xela2_i386.deb
They should work ok on lucid.
For nfs-co
Hi guys!
First thanks for your analysis
I'm in the process to let deploy more than 400 computers using the
current LTS with NFSv4 (and autofs here too) and I'm stuck at randomly
facing exactly the same problem of idmapd failing to start, here because
of the late rpc_pipefs start:
Feb 28 22:20:4
@Steve - I've performed a code review of the 2 patches. Aside from a few
minor formatting suggestions for mountall.diff (#2), they look good:
mountall.c:162: indent of 'handler' element should align with 'mnt'.
mountall.c:1559: Suggest comment changed to, "All mounts have been attempted,
so wait
James, can you review Alexander's proposed patch to mountall here?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/643289
Title:
idmapd does not starts to work after system reboot
--
ubuntu-bugs mai
** Tags added: patch
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/643289
Title:
idmapd does not starts to work after system reboot
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https:/
Suitable for the mountall async patch set just provided, here is my set
of job configuration files for nfs-common:
gssd -- (triggered by portmap and local-filesystems)
gssd-mounting -- (triggered by mounting, triggers gssd)
idmapd -- (triggered by local-filesystems)
idmapd-mounting -- (triggered b
This is a secondary patch meant to prevent miscounting of mounts in
mountall.
The problem may actually already exist in mountall 2.20+nmu1 (the core
of the patch should work there, too).
With asynchronous event handling, this problem may show up severely,
which is why I post it here.
** Patch ad
I have invested some time into analysis of some of the problems the
introduction of upstart/mountall created.
Building on Steve Langasek's and Clint Byrum's ideas of introducing
fixes in the start-up procedure to make idmapd/gssd and even statd start
reliably again, I initially failed due to the l
Building on Clint Byrum's work on bug #525154, I'm much closer now to
understanding a possible solution for this issue, but it's going to
require some coordination. Details:
- the current idmapd job starts on 'local-filesystems or mounting TYPE=nfs4'
because it needs to start whenever an nfs4 fi
** Changed in: nfs-utils (Ubuntu)
Status: New => Triaged
** Changed in: nfs-utils (Ubuntu)
Importance: Undecided => High
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/643289
Title:
idmapd
55 matches
Mail list logo
