Bug 172111 - latest coreutils breaks autofs's /etc/auto.net
Summary: latest coreutils breaks autofs's /etc/auto.net
Alias: None
Product: Fedora
Classification: Fedora
Component: autofs
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Jeff Moyer
QA Contact: Brock Organ
: 172028 172239 174015 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2005-10-31 16:25 UTC by Alexandre Oliva
Modified: 2007-11-30 22:11 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2005-12-14 21:04:31 UTC
Type: ---

Attachments (Terms of Use)

Description Alexandre Oliva 2005-10-31 16:25:14 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.12) Gecko/20050922 Fedora/1.0.7-1.1.fc4 Firefox/1.0.7

Description of problem:
The latest coreutils update removes the long-deprecated `sort +N' syntax in favor of `sort -k n', where n = N + 1.  /etc/auto.net still used the old syntax, so it breaks, and /net doesn't work any more.  The fix follows:

-$SHOWMOUNT | LC_ALL=C sort -k 1 | \
+$SHOWMOUNT | LC_ALL=C sort +0 | \

Version-Release number of selected component (if applicable):
coreutils-5.92-1 autofs-4.1.4-11

How reproducible:

Steps to Reproduce:
1.Update to latest autofs and coreutils in the development tree
2.Enable /net mounting in autofs
3.Try to use it to mount anything from any server that exports filesystems over NFS to your box (or even yourself)

Actual Results:  It won't mount anything, even though showmount -e shows the exported directories correctly.  /var/log/messages says:

Oct 31 14:15:02 fri automount[3608]: >> sort: open failed: +0: No such file or directory
Oct 31 14:15:02 fri automount[3608]: lookup(program): lookup for fri failed
Oct 31 14:15:02 fri automount[3608]: failed to mount /net/fri

These messages are for self (bind) mounts, but it breaks for NFS as well.

Expected Results:  It should mount the directories exported from fri.

Additional info:

Comment 1 Jeff Moyer 2005-10-31 16:34:20 UTC

Is this a regression in coreutils, or is this a known interface breaker?

Comment 2 Alexandre Oliva 2005-10-31 16:39:39 UTC
*** Bug 172028 has been marked as a duplicate of this bug. ***

Comment 3 Jeff Moyer 2005-11-01 20:45:59 UTC
*** Bug 172239 has been marked as a duplicate of this bug. ***

Comment 4 Roland McGrath 2005-11-05 00:43:30 UTC
The change commited does "sort" instead of "sort -k 1", which is probably not
what you really want.  "sort -k 1" means the same as "sort +0" used to mean.

Comment 5 Tim Waugh 2005-11-07 09:37:06 UTC
This is indeed a change of interface -- but it happened a long long time ago and
we have been patching coreutils to accept the old syntax of +n for ages. 
Whatever packages still use the old syntax should be updated, regardless of
whether we eventually decide to patch sort again to still accept +n.

Comment 6 Jeff Moyer 2005-11-07 13:19:11 UTC
OK.  It's now changed to use -k 1.

Comment 7 Jeff Moyer 2005-11-23 18:00:43 UTC
*** Bug 174015 has been marked as a duplicate of this bug. ***

Comment 8 Jeff Moyer 2005-12-14 21:04:31 UTC
I'm closing this bug, as it should be addressed in rawhide.

Note You need to log in before you can comment on or make changes to this bug.