Comments

19 Comments

what failed?

To make it a 1.3.4 I would have to make a new release... 1.3.4.rc3 means 1.3.4 is not released... aka the rc2...

Updated to the latest upstream RC release: libtirpc-1-3-4-rc2 mean I update to latest upstream RC (aka upstream tag)

The NVR is 1.3.3-1.rc2 increased from 1.3.3-1.rc1 which is fine

This update has been unpushed.

This update has been unpushed.

rpc-gssd.service now starts successfully

Since f27 was already released I felt it very important to put things back exactly as they were. With f28, I was working with the NIS maintainer on how to proceed forward.

This update has been unpushed.

What does it mean "Doesn't work."? What is the problem???

I bet those 3 positive karma didn't selinux enabled.

I wonder why I didn't see it in my testing... I do have selinux enabled...

Bug 1402083 is a SELinux big not an rpcbind bug. Here is the workaround

http://koji.fedoraproject.org/koji/buildinfo?buildID=823463

Fair enough... Here is what I have for the in the spec file... What do I have to change:

%post %systemd_post rpcbind.service rpcbind.socket

%preun %systemd_preun rpcbind.service rpcbind.socket

%postun %systemd_postun_with_restart rpcbind.service rpcbind.socket

freddyw, If there is a hostname file under /var/lib/nfs/statd/sm* and boot does not hang then bug 1181708 is fixed

"System fails to boot" what exactly does this mean? Did the system hang, if so where? Did the system panic, if so where. Are you sure nfs-utils was causing the problem?

This is main: open(/var/lib/nfs/rpc_pipefs//nfs): No such file or directory is happening because the sunrpc kernel module is not loaded which means /var/lib/nfs/rpc_pipefs is not mounted. So the question is why is rpc.idmapd even being started if you not running the NFS server. I'm guess this is a problem with the upgrade not so much a bug in the code.

Please Note: To stop this DOS the libtirpc-0.2.5-1.0.fc21 has to be installed which is currently in testing