Run updatedb at install time?

It works fine here.
Could you attach a screenshot of the search window (with details open) to the
bug report (so we can test with the same configuration) ? Do you have an error
if you run it (gnome-search-tool) from a gnome-terminal ?

I'm seeing this behaviour too.

The search fails if "show more options" is disabled. It works if "show more
options" is enabled. See screenshots

Created an attachment (id=141)
Shows search for files when it doesn't work

Created an attachment (id=142)
Shows search for files when it is working.

Ok, I think I know where the problem is. When you don't display the options it
uses the "locate" command so you get a fast reply, when the options are
displayed it uses a find.
Could you run "updatedb" in a gnome-terminal and try again after the update ?

It it works I think we can close the bug.

Well, if that's it, I'm not sure the bug should be closed: it means that
updatedb should be run ASAP after an install.

Yes, that works. Thank you!

However when running sudo updatedb I got:

warning: updatedb: could not open database: /var/lib/slocate/slocate.db: No such
 file or directory

Then a slocate.db was created. There is a daily cronjob that runs updatedb. The
problem is that my box is a laptop so it isn't up 24/7 (it is usally up around
midnight when cronjobs traditionally get run). Still it seems that the updatedb
has not been run.

This results in behaviour that from a user perspective seems broken. In my
humble opinion this bug can be closed when:

A. Updatedb is certain to get run early on. Maybe with low nice post install?

or

B. The slower "show more options" search is run by default. Allthough it lists
files that contain the search string (instead of files that have the search
string in their name), it is intelligent enough to list the files that have the
search string in their name first. The user might think there is lots of "noise"
in the search but that is (again IMHO) better than not producing any results at
all.

I'm reassigning to base-config. What do you think about running updatedb once
after the installation ? So at least the database is created ...

Anacron would be useful for this too (there's a bug requesting anacron
inclusion: bug #7063)

My only hesitation about this (and other suggestions of this type) is that
running an I/O-bound process like this in the background causes the UI to be
less responsive, and so the user's first experience is that their system is "slow"

If we can find a way to resolve that issue, then I wouldn't mind running
updatedb (and scrollkeeper as well) in the background after install

A lot of desktop linux systems runs a task in the background on occasion, like
updatedb, or prelink after installing something, in my humble opinion this is
NOT a good way of doing things. I suppose if we could cook some kind of
"extreamly nice level" to check if the computer is in use at all (... maybe
simply check if load average is under 0.1 and check if dpms is on? Could be an
idea anyway), and then kill the task if the user comes back.

This is why I don't like the idea of running at the end of the installation:
this is one time when we are almost certain that the system will be actively in
use! :-)

This bug is not relevant anymore, gnome-search-tool now first does a locate then
do a find addtionnal files not in the locate database.
see http://bugzilla.gnome.org/show_bug.cgi?id=153563
and changelog entry 2004-10-26 Dennis Cranston <dennis_cranston at yahoo com>

hmm in fact, gnome-search-tool by default doesn't use find for searching in / if
the locate database exists (configurable in
/apps/gnome-search-tool/quick_search_second_scan_excluded_paths).
But it does use find if the locate database is not there which is the case in
this bug.

So it can be closed.

There are however some permission error when find is used on / but I think it
should be a separate bug.

(In reply to comment #13)
> This bug is not relevant anymore, gnome-search-tool now first does a locate then
> do a find addtionnal files not in the locate database.
> see http://bugzilla.gnome.org/show_bug.cgi?id=153563
> and changelog entry 2004-10-26 Dennis Cranston <dennis_cranston at yahoo com>
>
>

It would still be nice if the database were generated

Ubuntu now uses anacron, so only on the first day the slocate database might not
be there, shouldn't this bug be closed?

(In reply to comment #16)
> Ubuntu now uses anacron, so only on the first day the slocate database might not
> be there, shouldn't this bug be closed?

No, it shouldn't. It would still be nice for it to work on the first day; for
instance the first day is the *only* day that many reviewers are going to pay
attention to.

Crazy idea:

* Use a popup notification (libnotify) one or two mintes after the user logged
in to tell the user that update-db will be started with a suitable nice-level to
disturb as little as possible (in less technical wording of course)
* In the notification, provide a callback to cancel this and let anacron take
care of it (again in less technical wording)

Considering that the default desktop install for ubuntu doesn't allow you to select the packages, the database can be pregenerated and installed right along with all the other packages.

I'm not sure about the server installs, but for most of desktop users this would be sufficient for the first day.

Lakin: sorry, that would be too annoying to maintain. We've already had bad experiences with manually-updated lists of things that purport to describe the "current" desktop and in fact end up getting out of date very easily (readahead); and the locate database is very sensitive to small changes in packages and would require regular updates. Thanks for the suggestion, but I don't think we will be taking this approach.

Maybe silly, but what about running it before the installation is "ready". i.e. Install system, run updatedb and then tell the user that the installation is done.

so, how about just implementing this:

-add a hook in finish-install.d and run 'in-target updatedb' or similar. Would that be enough?

I think this bug is obsoleted by Ubiquity, since the locate database is pre-generated and copied to the installed system. It won't be 100% accurate due to the bits and pieces modified by the installation process, but it's plenty good enough to resolve this issue.

Matt: that means that it isn't a bug in ubiquity, certainly, but it's still a perfectly valid bug in the alternate/server CD. Indeed, I would say that this is relevant because I would expect considerably more server users to know about and care about locate than desktop users.

I think I'm going to go for doing this at the end of pkgsel rather than in finish-install. I know that will make it a bit less accurate, but another pause at the end of the already very long pkgsel step won't be quite so jarring as a long pause in the middle of finish-install which is currently quite short.

I'll add a preseedable pkgsel/updatedb parameter so that people who have trouble with the slowdown can turn it off.

Note, of course, that particularly with mlocate this means that the system will have less work to do on the first run of cron - bonus if you happened to do an installation in the dead of (UTC?) night shortly before the cron jobs fire!

This bug was fixed in the package pkgsel - 0.20ubuntu13

---------------
pkgsel (0.20ubuntu13) jaunty; urgency=low

  * Run updatedb at the end of pkgsel, unless pkgsel/updatedb is preseeded
    to false (LP: #8195).

 -- Colin Watson <email address hidden> Thu, 05 Mar 2009 23:52:57 +0000

This bug was fixed in the package installation-guide - 20081208ubuntu3

---------------
installation-guide (20081208ubuntu3) jaunty; urgency=low

  * Document pkgsel/updatedb (LP: #8195).
  * Document partman/default_filesystem.
  * Document controlling how partitions are mounted (LP: #347817).
  * Mention that Kickstart LVM configuration is now experimentally
    supported, and document the pieces currently known to be missing.
  * Update Canonical's copyright years.

 -- Colin Watson <email address hidden> Thu, 16 Apr 2009 21:56:50 +0100