I had an nfs server which stopped working when I updated to MGA5 from mga3. rpcinfo showed that no ipv4 tcp/udp service for nfs was listed. No client would mount the files which had always worked before. After a week of bashing my head trying to figure out what could be wrong, I discovered that unfs3 was installed on the non-working server, and I guess was being loaded at boot. This completely blocked nfs from working on that system as a server (It did work as an nfs client). Once I removed unfs3, nfs began to work again. There were no errors listed anywhere in any log files. The only hint was rpc.nfsd: unable to bind inet TCP socket: errno 98 (Address already in use) which was pretty useless as it did not say what was using it. unfs3 is a trap which should come with huge warnings that it will destroy nfs service and leave not a clue behind that it is doing so. (I have no idea how it got installed on a new installation of mga5 on that server).
Severity: normal => major
Given what unfs3 is, I would expect this conflict. unfs3 is not required by any packages, nor is it listed in rpmsrate, so the only way it should get installed is if you install it. I did notice that unfs3 has a virtual provides of nfs-server. That's not listed in rpmsrate, and nothing requires it either, but I suppose it's possible that it is somehow responsible for that package getting pulled in on your system (not sure how though). It would be nice to know what is pulling that in (maybe your installation logs have a hint, look in /root/drakx). rpc.nfsd comes from the nfs-utils package, which should probably also have this virtual provide of nfs-server, as well as being listed in urpmi's prefer.vendor.list file, to make sure that it gets favored by default over unfs3. In fact, it already is listed in prefer.vendor.list as such, so the bug is that nfs-utils is missing the virtual provides of nfs-server. Assigning to the nfs-utils maintainer.
Assignee: bugsquad => guillomovitch
Yes, I can no longer remember at all how it got there, whether it was automatically drawn in or whether it was something I did. I do have at least 3 other machines onto which I installed mga3, and none of them have unfs3 installed, so if it was drawn in it was in some obscure manner. There is nothing in root/drakx, but I did "update" the system by listing all of the packages in my MGA3 and installing them into MGA5 with urpmi, and whether one of those hauled in unfs3 I cannot remember. Sorry. I guess one of the requests for this is to have some better error messages somewhere so that this could be debugged more easily if it happens. It took me a long time of wasted effort to discover the problem. And unfs3 and nfs-server (not sure which package that is nfs-utils?) should have "Conflicts with" included in the rpm since they sure do conflict.
unfs3 hasn't evolved since 2009, does not support current NFS specification (v4), and has no mageia maintainer. I just dropped it from the distribution, and asked for its removal from the mirror. I'm not sure providing an update for mga5 just for adding an explicit conflict would be really helpful for anyone. In any case, I won't take care of it myself.
Status: NEW => RESOLVEDResolution: (none) => FIXED
I have no objection to its being dropped, presumably from Mageia 6. However that does not address the problem for Mga5 users (or earlier) who accidentally or purposely install both. It would of course have been better if I knew how it got installed on my system, but I cannot remember doing so.
Given than you're the first one to report the issue, despite the package being available since mageia 1, I really doubt anyone is concerned. Anyway, feel free to apply to a contributer account if you're willing to do it yourself.