Description of problem: After a fresh install (Fedora 7 PPC, pp64, PLAYSTATION 3), running the updatedb command (with root priviledges either logging in the shell as root or using the su -c '' command) to create the database read by the locate command will fail unless the /sys directory is pruned from the search with the following command: # updatedb --add-prunepaths /sys Version-Release number of selected component (if applicable): # updatedb --version updatedb (mlocate) 0.16 findutils.ppc 1:4.2.29-2 How reproducible: Simply update the mlocate database running the updatedb command as root. Steps to Reproduce: 1. updatedb 2. 3. Actual results: # updatedb updatedb: src/updatedb.c:721: scan_cwd: Assertion `name_size > 1' failed. Aborted Expected results: the command should return cleanly. Additional info:
I'm seeing the same thing on F7 PPC 32-bit on a PowerBook G4 [root@hockey ~]# updatedb updatedb: src/updatedb.c:721: scan_cwd: Assertion `name_size > 1' failed. Aborted [root@hockey ~]# updatedb --add-prunepaths /sys [root@hockey ~]# uname -a Linux hockey.jaredsmith.net 2.6.21-1.3194.fc7 #1 Wed May 23 22:12:25 EDT 2007 ppc ppc ppc GNU/Linux [root@hockey ~]# rpm -qf `which updatedb` mlocate-0.16-1
Thanks for your report. Can you run (strace -v -o log updatedb) and attach the generated log file, or at least the last 1000 lines of the log file, please?
Created attachment 156375 [details] the last thousand lines of (strace -v -o log updated) Ask and ye shall receive...
Created attachment 156404 [details] Here is the entire log file for the given strace command :)
Created attachment 156406 [details] I apologize, the log was enormous, non compressed, and put up as octet/stream...
Thanks. The kernel is returning invalid data from getdents() on /sys/module/nousb/parameters: getdents64(9, {{d_ino=174, d_off=1, d_type=DT_DIR, d_reclen=24, d_name="."} {d_ino=173, d_off=2, d_type=DT_DIR, d_reclen=24, d_name=".."} {d_ino=175, d_off=3, d_type=DT_REG, d_reclen=24, d_name=""}}, 4096) = 72 Note the d_name="". nousb comes from __module_param_call("", nousb, param_set_bool, param_get_bool, &nousb, 0444); in drivers/usb/core/usb.c. It seems the empty module name confuses something.
*** Bug 247381 has been marked as a duplicate of this bug. ***
Created attachment 159750 [details] strace -v -o log updated compressed
(In reply to comment #8) > Created an attachment (id=159750) [edit] > strace -v -o log updated compressed > As this error is present with the latest kernel.x86_64 2.6.22.1-27.fc7 kernel. > It does not occur in the previous 2 F7 kernels
*** Bug 249215 has been marked as a duplicate of this bug. ***
"nousb" isn't a module parameter at all -- it's a boot-time option only. And drivers/usb/core/usb.c is the only place using __module_param_call directly. What happens is this: $ pwd /sys/module/nousb/parameters $ ll -Q total 0 ?--------- ? ? ? ? ? "" $ stat "" stat: cannot stat `': No such file or directory
*** Bug 249561 has been marked as a duplicate of this bug. ***
Wouldn't the prooper fix be to add /sys to the PRUNEPATH lint in /etc/updatedb.conf?
> Wouldn't the prooper fix be to add /sys to the PRUNEPATH lint in /etc/updatedb.conf? No, 1) The kernel is returning invalid data. It shouldn't. (the assertion failure happens because the code in updatedb protects itself against invalid data, assuming they are caused by a but in updatedb.) 2) The daily updatedb run automatically excludes all "nodev" file systems, including /sys.
If you want to run updatedb manually, you can run /etc/cron.daily/mlocate.cron instead.
*** Bug 250890 has been marked as a duplicate of this bug. ***
Two questions: A. Why should updatedb even touch /proc and /sys? I doubt that anyone will be using updatedb to watch the cmdline under process XXXXX or follow the USB bus under /sys? B. In the existing prune list under updatedb.conf, I see /sfs... /sfs? (/sys maybe?) - Gilboa
(In reply to comment #17) > Two questions: > A. Why should updatedb even touch /proc and /sys? I doubt that anyone will be > using updatedb to watch the cmdline under process XXXXX or follow the USB bus > under /sys? > B. In the existing prune list under updatedb.conf, I see /sfs... /sfs? (/sys maybe?) I think we should be pruning sys and proc filesystems types. No idea why we don't...
This seems like a pretty big show stopper to me. I just removed beagle, because it was causing Firefox to pop-up warning on websites repeatedly. Now updatedb doesn't work. What is next? Bill
confirming problem on F7 x86_64 fully updated until today.
(In reply to comment #17) > A. Why should updatedb even touch /proc and /sys? I doubt that anyone will be > using updatedb to watch the cmdline under process XXXXX or follow the USB bus > under /sys? _Only_ manually-run updatedb touches /proc and /sys. It does so because mlocate is supposed to be portable, leaving the platform-specific file system knowledge to the distribution scripts - /etc/cron.daily/mlocate.cron in this case. (BTW, I consider (locate cmdline) a perfectly legitimate use case, although one that is not supported in Fedora by default.) > B. In the existing prune list under updatedb.conf, I see /sfs... /sfs? (/sys maybe?) No, sfs is from #54864. I have never tested it - if it is a "nodev" filesystem, it should be removed from PRUNEFS.
*** Bug 252265 has been marked as a duplicate of this bug. ***
*** Bug 253136 has been marked as a duplicate of this bug. ***
*** Bug 253795 has been marked as a duplicate of this bug. ***
Actually, my prunepath contained a "/sfs" -- I wonder if that's a typo, and was actually supposed to mean "/sys". Can anybody verify if that's the case, and an older updatedb.conf has /sys instead of /sfs ? BTW: Fedora 7, x86_64, fresh install with all updates installed, on a Thinkpad T61.
Ingo, See post https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=242715#c21 - Gilboa
This also affects other applications too. I found this page when trying to find out what causes the the Baobab disk usage analyzer (Fedora 7 gnome-utils package) to lock up and explode. It looks like the corrupted information from the parameters directory causes Baobab to sink into a recursive loop. /sys /sys/module /sys/module/nousb /sys/module/nousb/parameters /sys/module/nousb/parameters/parameters /sys/module/nousb/parameters/parameters/parameters ....
*** Bug 296211 has been marked as a duplicate of this bug. ***
*** Bug 302201 has been marked as a duplicate of this bug. ***
I reported this upstream and nobody seemed to even care.
Bad day to say that :(... I was just reading the reports from the '07 Kernel Summit and the saddening report of more and more bugs which are simply left out in some bugzilla system somewhere to die. :(.
Confirm that this is a problem with Fedora Core 6 with latest kernel 2.6.22.9- 61.fc6
This is still an issue for current "rawhide" on x86_64: kernel-2.6.23.1-18.fc8.x86_64 glibc-2.7-1.x86_64 mlocate-0.18-1.x86_64 $ updatedb updatedb: src/updatedb.c:730: scan_cwd: Assertion `name_size > 1' failed. Abort
Fix in CVS
*** Bug 357061 has been marked as a duplicate of this bug. ***
*** Bug 369291 has been marked as a duplicate of this bug. ***
*** Bug 374421 has been marked as a duplicate of this bug. ***
/etc/updatedb.conf from fedora 8 has "/sfs" in PRUNEPATHS. If it hasn't already been fixed, that should probably be changed to "/sys"
(In reply to comment #38) > /etc/updatedb.conf from fedora 8 has "/sfs" in PRUNEPATHS. If it hasn't already > been fixed, that should probably be changed to "/sys" See comment #21.
*** Bug 372031 has been marked as a duplicate of this bug. ***