Red Hat Bugzilla – Bug 198865
smart chokes on autofs5's +map syntax
Last modified: 2007-11-30 17:11:37 EST
Description of problem:
smart crashes when trying a smart update / upgrde
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. smart upgrade or update
[root@macbook ~]# smart update
Traceback (most recent call last):
File "/usr/bin/smart", line 194, in ?
File "/usr/bin/smart", line 161, in main
File "/usr/lib/python2.4/site-packages/smart/__init__.py", line 115, in init
ctrl = Control(configfile, forcelocks)
File "/usr/lib/python2.4/site-packages/smart/control.py", line 53, in __init__
self._fetcher = Fetcher()
File "/usr/lib/python2.4/site-packages/smart/fetcher.py", line 53, in __init__
self._mediaset = MediaSet()
File "/usr/lib/python2.4/site-packages/smart/media.py", line 34, in __init__
File "/usr/lib/python2.4/site-packages/smart/media.py", line 41, in discover
for lst in hooks.call("discover-medias"):
File "/usr/lib/python2.4/site-packages/smart/hook.py", line 64, in call
val = hook(*hookparam, **hookkwparam)
File "/usr/lib/python2.4/site-packages/smart/media.py", line 329, in
prefix, mapfile = line.split()[:2]
ValueError: need more than 1 value to unpack
working smart ;)
this is on a fully updated FC6 devel
smart needs a rebuild on rawhide, but currently it breaks:
smart/util/celementtree/expat/xmlparse.c:75:2: error: #error memmove does not
exist on this platform, nor is a substitute available
When I opened bug #201435 I didn't realize that it was a duoplicate of this one,
sorry. Since the resolution is in the other bug I'm closing this as a duplicate
of the other.
In case it's not the same issue please reopen, thanks!
*** This bug has been marked as a duplicate of 201435 ***
I should better read the description not my own comment. While smart didn't
build until now for FC6, it doesn't really explain the error you see.
Can you please try again with the latest smart package? If it still fails (I
assume it will), please post the contents of auto.master. Thanks!
I've just updated to the latest smart package (smart-0.42-35.fc6), and it failed
to start giving the same traceback as in the initial bug report. If it matters,
this is a x86_64 system.
That was expected, what about the contents of /etc/auto.master?
Sorry, it seems I didn't read comment #3 ver well earlier. Below is the entire
content of /etc/auto.master
# $Id: auto.master,v 1.4 2005/01/04 14:36:54 raven Exp $
# Sample auto.master file
# This is an automounter map and it has the following format
# key [ -mount-options-separated-by-comma ] location
# For details of the format look at autofs(5).
# Include central master map if it can be found using
# nsswitch sources.
# Note that if there are entries for /net or /misc (as
# above) in the included master map any keys that are the
# same will not be seen as the first read key seen takes
The last line is what causes the breakage. smart assumes that all non-commented
entries in this file have at least two words.
If you comment that line smart will work again. See als bug #193831.
(In reply to comment #7)
> The last line is what causes the breakage. smart assumes that all non-commented
> entries in this file have at least two words.
> If you comment that line smart will work again. See als bug #193831.
Yes you're right, it did work with the last line commented.
I can confirm that commenting the last line of /etc/auto.master makes smart work
Upcoming package (-37) will have a check to skip +<map> entries in auto.master.
This is a short term fix, long term smart should query autofs directly instead
of replicating its parsing. Upstream has been notified and will fix it in a next
The patch is bogus: it applies the fix a couple lines too high. :(
*** Bug 208647 has been marked as a duplicate of this bug. ***
Fixed the fixing patch.