Shallow Thoughts
Akkana's Musings on Open Source, Science, and Nature.
Tue, 29 Apr 2008
Since updating to Hardy, I've been getting mail from Anacron:
/etc/cron.weekly/slocate:
slocate: fatal error: load_file: Could not open file: /etc/updatedb.conf: No such file or directory
That's the script that updates the database for locate,
Linux's fast find system.
I figured I must have screwed something up when I moved
that slocate cron script from cron.daily
to cron.weekly (because I hate having my machine slow to a
crawl as soon as I boot it in the morning, and it doesn't bother me
if the database doesn't necessarily have files added in the
last day or two).
But after talking to some other folks and googling for Ubuntu bugs,
I discovered I wasn't the only one getting that mail, and there was
already a
bug covering it. Comparing my setup with another Hardy user's,
I found that the file slocate was failing to find, /etc/updatedb.conf,
belongs to a different package, mlocate. If mlocate is installed,
then slocate's cron script works; otherwise, it doesn't.
Sounds like slocate should have a dependency that pulls in mlocate,
no?
But wait, what do these two packages do? Let's try a little
aptitude search locate:
p dlocate - fast alternative to dpkg -L and dpkg -S
p kio-locate - kio-slave for the locate command
i locate - maintain and query an index of a directory
p mlocate - quickly find files on the filesystem based
i slocate - Secure replacement of findutil's locate
Okay, forget the first two, but we have locate, mlocate, and slocate.
How do they relate?
Worse, if I install mlocate (so slocate will work) and then look in my
cron directories, it turns out I now have, count 'em, five
different cron scripts that run updatedb. They are:
In cron.daily:
locate: 72 lines! but a lot of that is comments and pruning,
and a lot of fiddling to figure out what version of the kernel is
running to see whether it can pass any advanced flags when it tries
to renice the process. In the end it calls
updatedb.findutils (note no full path, though it
uses a full path when it checks for it earlier in the script).
slocate: A much simpler but unfortunately buggy 20 lines.
It checks for /etc/updatedb.conf, runs it if it exists, fiddles
with ionice, checks again for /etc/updatedb.conf, and based
on whether it finds it, runs either /usr/bin/slocate -u
or /usr/bin/slocate -u -f proc. The latter path is what
was failing and sending root mail every time the script was run.
mlocate: an even slimmer 12 line script, which checks for
/usr/bin/updatedb.mlocate and, if it exists, fiddles ionice then
runs /usr/bin/updatedb.mlocate.
In cron.weekly:
Two virtually identical scripts called find.notslocate and
find.notslocate.dpkg-new, which differ only in dpkg-new having
more elaborate ionice options. They both run updatedb.
And which updatedb would that be? Probably /usr/bin/updatedb, which
links to /etc/alternatives/updatedb, which probably links to either
updatedb.mlocate or updatedb.slocate, whichever you've installed
most recently. But in either case, it's hard to see why you'd need
this script running weekly if you're already running both flavors
of updatedb from other scripts cron.daily. And having two copies
of the script is just plain wrong (and there was already a
bug
filed on it). (As long as you're poking around
in cron.daily and cron.weekly, check and see if you have
any more of these extra dpkg-new or dpkg-old scripts -- they might be
slowing down your machine for no reason.)
Further research reveals that mlocate is a new(ish) package intended
to replace slocate. (There was a long discussion of that on
ubuntu-devel,
leading to the replacement of slocate with mlocate very late in
the Hardy development cycle. There was also lots of discussion of
"tracker", apparently a GUI fast find tool that can only search in
the user's home directory.)
What is this mlocate?
The m stands for "merge": the advantage of mlocate is
that it can merge new results into its existing database instead
of replacing the whole thing every time. Sounds good, right?
However, the down side is that mlocate apparently can't
to purge its database of old files that no longer
exist, and these files will clutter up your locate results.
Running locate -e will keep them from being printed --
but there seems
to be no way to set this permanently, via an environment variable
or .locaterc file, nor to tell updatedb.mlocate to clean up its database.
So you'll need to alias locate to locate -e
if you want sensible behavior. Or go back to slocate. Sigh.
Cleaning up
The important thing is to get rid of most of those spurious updatedb
cron scripts. You might choose to run updatedb daily, weekly, or only
when you choose to run it; but you probably don't want five different
scripts running two different versions of updatedb at different times.
The packages obviously aren't cleaning up after themselves, so let's
do a little manual cleanup.
That find.slocate script looks suspicious. In fact, if you run
dpkg -S find.notslocate, you find out that it doesn't
belong to any package -- not only should the .dpkg-old version not
be there, neither should the other one! So out they go.
As for slocate and mlocate,
it's important to know that the two packages can coexist:
installing mlocate doesn't remove slocate or vice versa.
A clean Hardy install should have only mlocate; upgrades from Gutsy
are more likely to have a broken slocate.
Having both packages probably isn't what you want. So pick one, and
remove or disable the other. If mlocate is what you want,
apt-get purge slocate and just make sure that
/etc/cron.*/slocate disappears. If you decide you want slocate,
it's a little trickier since the slocate package is broken;
but you can fix it by creating an empty /etc/updatedb.conf so
updatedb.slocate won't fail.
Tags: linux, boot, ubuntu, install
[
20:48 Apr 29, 2008
More linux/install |
permalink to this entry
]
Sun, 20 Apr 2008
I finally had a moment to upgrade my desktop to Ubuntu's "Hardy Heron".
I followed the same procedure as when I went from feisty to gutsy:
- cp -ax / /hardy
- cp -ax /dev/.static/dev/* /hardy/dev/
- Fix up files like /hardy/etc/fstab and /boot/grub/menu.lst
- Reboot into the newly copied gutsy
- do-release-upgrade -d
It took an hour or two to pull down all the files, followed by a long
interval of occasionally typing Y or N, and then I was ready to start
cleaning up some of the packages I'd noticed flying by that I didn't
want. Oops! I couldn't remove or install anything with apt-get,
because: dpkg --configure -a
But I couldn't dpkg --configure -a because several
packages were broken.
The first broken package was plucker,
which apparently had failed to install any files.
Its postinstall script was failing because it had no
files to operate on; and then I couldn't do anything further with it
because apt-get wouldn't do anything until I did a
dpkg --reconfigure -a
I finally got out of that by dpkg -P plucker; then after several
more dpkg --reconfigure -a rounds I was eventually able to apt-get
install plucker (which installed just fine the second time).
But apt still wasn't happy, because it wanted to run the trigger for
initramfs-tools, which wouldn't run because it wanted kernel modules
for some specific kernel version in /lib/modules. I didn't have any
kernel modules because I'm not running Ubuntu's kernel (I'm stuck on
2.6.23 because
bug 10118
makes all 2.6.24 variants unable to sync with USB Palm devices).
But I couldn't remove initramfs-tools because udev
(along with a bunch of other less important packages) depends on it.
I finally found my way out of that by removing
/var/lib/dpkg/triggers/initramfs-tools.
I reported it as
bug 220094.
Update: I forgot to mention one important thing I hit both on
this machine and earlier, on the laptop: /usr/bin/play (provided by
the "sox" package) no longer works because it now depends on a
zillion separate libraries. apt-get install libsox-fmt-all
to get all of them.
Tags: linux, ubuntu, debian, install
[
20:02 Apr 20, 2008
More linux/install |
permalink to this entry
]
Mon, 07 Apr 2008
On a lunchtime bird walk on Monday I saw one blue heron and at least
five green herons (very unusuual to see so many of those).
Maybe that helped prepare me for installing the latest
Ubuntu beta, "Hardy Heron", Monday afternoon.
I was trying the beta primarily in the hope that it would fix a
serious video out regression that appeared in Gutsy (the current
Ubuntu) in January.
My beloved old Vaio SR17 laptop can't switch video signals on the
fly like some laptops can; I've always needed to boot it with an
external monitor or projector connected. But as long as it saw a
monitor at boot time, it would remember that state through many
suspend cycles, so I could come out of suspend, plug in to a projector
and be ready to go. But beginning some time in late January, somehow
Gutsy started doing something that turned off the video signal when
suspending. To talk to a projector, I could reboot with the projector
connected (I hate making an audience watch that! and besides, it takes
away the magic). I also discovered that switching to one of
the alternate consoles, then back (ctl-alt-F2 ctl-alt-F7) got a signal
going out on the video port -- but I found out the hard way, in front
of an audience, that it was only a 640x480 signal, not the 1024x768
signal I expected. Not pretty! I could either go back to Feisty ...
or try upgrading to Hardy.
I've already written about the handy
debootstrap
lightweight install process I used.
(I did try the official Hardy "alternate installer" disk first, but
after finishing package installation it got into a spin lock
trying to configure kernel modules, so I had to pull the plug and
try another approach.)
This left me with a system that was very minimal indeed, so I spent
the next few hours installing packages, starting with
tcsh, vim (Ubuntu's minimal install has something called vim, but
it's not actually vim so you tend to get lots of errors about parsing
your .vimrc until you install the real vim),
acpi and acpi-support (for suspending),
and the window system: xorg and friends. To get xorg, I started with:
apt-get install xserver-xorg-video-savage xbase-clients openbox xloadimage xterm
Then there was the usual exercise of aptitude search font
and installing everything on that list that seemed relevant to
European languages (I don't really need to scroll through dozens of
Tamil, Thai, Devanagari and Bangla fonts every time I'm looking for a
fancy cursive in GIMP).
But I hit a problem with that pretty early on: turns out most of
the fonts I installed weren't actually showing up in xlsfonts,
xfontsel, gtkfontsel, or, most important, the little xlib program
I'm using for a talk I need to give in a couple weeks.
I filed it as bug
212669, but kept working on it, and when a clever person on
#ubuntu+1 ("redwhitewaldo") suggested I take a look at the
x-ttcidfont-conf README, that gave me enough clue to get me
the rest of the way. Turns out there's a Debian
bug with the solution, and the workaround is easy until the
Ubuntu folks pick up the update.
I hit a few other problems, like the
PCMCIA/udev
problem I've described elsewhere ... but mostly, my debootstrapped
Hardy Heron is working quite well.
And in case you're wondering whether Hardy fixed the video signal
problem, I'm happy to say it does. Video out is working just fine.
Tags: linux, ubuntu, install, fonts, vaio
[
18:31 Apr 07, 2008
More linux/install |
permalink to this entry
]
Sun, 06 Apr 2008
Some time ago, I wished for a simple Linux
"Tarball
installer", something that could install a minimal install of
a Linux distribution onto an existing partition or directory,
skipping all the flaky and error-prone hardware-guessing that
installers do.
It turns out Debian (and therefore also Ubuntu) has had this for
years, and it's totally cool. It's called debootstrap.
Some folks on the #ubuntu+1 channel told me about it, and I found
a nice clear
howto
article on how to use it for Debian. It works just the same
for Ubuntu.
First, get the .deb package for the debootstrap you want to use.
Here's
debootstrap
for Ubuntu Hardy Heron. Install it with dpkg -i.
Then run it, giving it the name of the system you want to install
and the directory (or mounted partition) where you want to install
it. Like this:
debootstrap hardy /mnt/hda3
That's all! It fetches the files it needs from the online
repositories. It takes no time at all -- this really is a minimal
system.
Then you need to do some fiddling to turn it into a bootable system.
That includes (all paths relative to the newly installed filesystem
unless otherwise stated):
- Set up etc/fstab to list the fileystems on the disk,
and to mount / from the filesystem you just installed
- Define the hostname in etc/hostname
- Set up a grub boot stanza in /boot/grub/menu.lst
(that's /boot on the current system, which should be the
same as /boot in the new fstab you just created).
Use whatever kernel you were using for your old system, for now.
Now you're read to reboot into the new system. Of course, since this is
a very minimal system, you have a lot more work to do.
Hardly anything is installed, and nothing has been configured for you.
Some things may be challenging (for example, as I write this, X is
installed but most of the fonts aren't showing up properly, which
may be a bug in Hardy).
Anyway, you can get a good start by mounting your old system's root
directory and copying some starter files from there, starting with these:
- Set up your important configuration files:
/etc/network/interfaces, /etc/hosts, /etc/resolv.conf,
/etc/passwd etc.
- edit /etc/apt/sources.list to include
restricted universe multiverse
- Install a kernel package if you're using distro kernels
- Install vim if you're a vim user -- remember, ubuntu comes with
something called vim that
isn't really vim.
- Create users and homedirs and such
- Install all the other stuff you want -- X, gimp/gtk, development
tools, editors, shells -- all that stuff that makes the system
feel like home. You're on your own there, so have fun!
Tags: linux, debian, installer
[
12:54 Apr 06, 2008
More linux/install |
permalink to this entry
]