"info: unrecognized option '--convert-db'" on upgrade

I'm having trouble making sense of this; that option is definitely supported by 'udevadm info' from udev 166-0ubuntu6. Is it possible that you have a different udevadm somewhere else on $PATH?

Only if some Ubuntu package put it there. I've never installed one by hand.

Could you check with 'which -a udevadm'?

/sbin/udevadm

http://people.canonical.com/~mvo/automatic-upgrade-testing/current/mythbuntu/ shows the same symptoms.

I tried reproducing the mythbuntu one above by doing:
1) Clean install of Mythbuntu 10.10 (amd64)
2) Dist-upgrade to be up to date
3) do-release-upgrade -d

Everything went fine without any error message.

After I did that I noticed that the automated upgrade was on 32bit, so I'll download the i386 image and do the same thing.
Also I couldn't find any reference to the "--convert-db" string in the automatic-upgrade logs or in the .crash file (once unpacked).
The upgrade issue seems to be caused by the udev daemon crashing on restart.

I should have more soon.

Found the issue.
Apparently on upgrade udevadm isn't actually updated (as in, we still have the old binary).

On my laptop, with a clean Natty 64bit install:
root@castiana:~# debsums -sa udev
root@castiana:~#

root@castiana:~# md5sum /sbin/udevadm
848c4c6c4368d5a0ca84b7b763d7ddfb /sbin/udevadm
root@castiana:~#

In a VM running an upgraded mythbuntu 64bit:

root@stgraber-upgrade:~# debsums -sa udev
debsums: changed file /sbin/udevadm (from udev package)
root@stgraber-upgrade:~#

root@stgraber-upgrade:~# md5sum /sbin/udevadm
1720f799a4a2dd4061b995fed74841c3 /sbin/udevadm
root@stgraber-upgrade:~#

My guess is that the diversion is causing this problem. I'll have a look at fixing that tomorrow if nobody else proposed a fix by then.

Ok, so quickly going through the postrm, preinst and postinst script, assuming a working scenario (the upgrade doesn't get cancelled):

postrm: Nothing happens
preinst: disable_udevadm (diverts the OLD udevadm to /sbin/udevadm.upgrade, then puts a shell script to replace udevadm)
postinst: remove the "fake" udevadm and remove the diversion

Now, I don't see any manual moving of udevadm done in any of these scripts and my understanding of dpkg diversions is that when updating the files in the udevadm package, udevadm.upgrade should have been updated with the new content, then moved back to /sbin/udevadm when the diversion got removed.
For some reason this didn't happen ...

I'll do some more tests to reproduce tomorrow with a non-critical package, to check if that's a udev-specific issue or something wrong with dpkg-divert (or me understanding it).

I reproduced udev's postrm,preinst,postinst scripts in a test package and found nothing weird in dpkg-divert's behaviour there.

I also tried reinstalling the udev package with a --reinstall --purge but that doesn't help:

root@stgraber-upgrade:~# apt-get install --reinstall --purge udev
Reading package lists... Done
Building dependency tree
Reading state information... Done
0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 1 not upgraded.
Need to get 0 B/416 kB of archives.
After this operation, 0 B of additional disk space will be used.
(Reading database ... 107070 files and directories currently installed.)
Preparing to replace udev 166-0ubuntu6 (using .../udev_166-0ubuntu6_amd64.deb) ...
Adding 'diversion of /sbin/udevadm to /sbin/udevadm.upgrade by udev'
Unpacking replacement udev ...
Processing triggers for ureadahead ...
Processing triggers for man-db ...
Setting up udev (166-0ubuntu6) ...
udev start/running, process 9218
Removing 'diversion of /sbin/udevadm to /sbin/udevadm.upgrade by udev'
update-initramfs: deferring update (trigger activated)
Processing triggers for initramfs-tools ...
update-initramfs: Generating /boot/initrd.img-2.6.38-7-generic
root@stgraber-upgrade:~# debsums -sa udev
debsums: changed file /sbin/udevadm (from udev package)

Stracing apt-get shows the following:
 - /sbin/udevadm gets diverted to /sbin/udevadm.upgrade
 - /sbin/udevadm gets created (shell script)
 - /sbin/udevadm gets updated with the new file (and not udevadm.upgrade)
 - /sbin/udevadm.upgrade gets undiverted to /sbin/udevadm (thereby restoring the old binary)

Strace attached (look for udevadm.upgrade)

Here is what I found out so far in a maverick chroot:

# dpkg --version
Debian `dpkg' package management program version 1.15.8.4ubuntu1 (amd64).
# dpkg --unpack /var/cache/apt/archives/udev_167-0ubuntu1_amd64.deb
(Reading database ... 13758 files and directories currently installed.)
Preparing to replace udev 162-2 (using .../udev_167-0ubuntu1_amd64.deb) ...
Adding 'diversion of /sbin/udevadm to /sbin/udevadm.upgrade by udev'
Unpacking replacement udev ...
Processing triggers for ureadahead ...
# md5sum /sbin/udevadm.upgrade
0069a25805ff3174a4a6dfe1a6752a5b /sbin/udevadm.upgrade
# dpkg --configure -a
Setting up udev (167-0ubuntu1) ...
restart: Unknown job: udev
Removing 'diversion of /sbin/udevadm to /sbin/udevadm.upgrade by udev'
info: unrecognized option '--convert-db'
update-initramfs: deferring update (trigger activated)
Processing triggers for initramfs-tools ...
# md5sum /sbin/udevadm
0069a25805ff3174a4a6dfe1a6752a5b /sbin/udevadm
# grep sbin\/udevadm /var/lib/dpkg/info/udev.md5sums
4bad6bfa5d6ea9829b77d61bc3b0652e sbin/udevadm

So its easy to reproduce.

I looked at older version of this and its only a problem for maverick (and later). It seems like dpkg-divert has a bug now, older versions work as expected. Probably releated to the rewrite in C that 1.15.8 features.

Based on previous comment, adding a dpkg task to the bug.

Here is another strace, this time only with the --unpack operation.

The strace looks like the divert database is correctly written (including the new udev entry) and also correctly (re)read by dpkg. But for some reason not used. That is my reading of the strace so far at least.

This is a bug in udev only... if udev wants to diverts its own file it must not use "--package udev" otherwise it instructs dpkg to divert the file EXCEPT when it's provided by udev (which it does). So in reality the replacement /sbin/udevadm is only there for a short time and overwritten by the new udevadm.

And then the postinst reinstalls the old udevadm which has been copied into /sbin/udevadm.upgrade (from the previous version) which supposedly does not support the --convert-db option.

I suggest to use "--package fake-udev" or "--local" instead (but --local is meant to be used by the admin in theory and might generate a lintian warning).

Running dpkg in debug mode, I see:
root@stgraber-upgrade:/var/cache/apt/archives# dpkg -D10 -i udev_167-0ubuntu1_amd64.deb 2>&1 | grep udevadm
Adding 'diversion of /sbin/udevadm to /sbin/udevadm.upgrade by udev'
D000010: tarobject ti->name='./sbin/udevadm' mode=100755 owner=0.0 type=48(-) ti->linkname='' namenode='/sbin/udevadm' flags=2 instead='/sbin/udevadm.upgrade'
D000010: namenodetouse namenode=`/sbin/udevadm' pkg=udev
D000010: namenodetouse ... useinstead=/sbin/udevadm.upgrade camefrom=<none> pkg=udev return /sbin/udevadm
D000010: ensure_pathname_nonexisting `/sbin/udevadm.dpkg-tmp'
D000010: ensure_pathname_nonexisting `/sbin/udevadm.dpkg-new'
D000010: tarobject ti->name='./usr/share/man/man8/udevadm.8.gz' mode=100644 owner=0.0 type=48(-) ti->linkname='' namenode='/usr/share/man/man8/udevadm.8.gz' flags=2 instead='<none>'
D000010: ensure_pathname_nonexisting `/usr/share/man/man8/udevadm.8.gz.dpkg-tmp'
D000010: ensure_pathname_nonexisting `/usr/share/man/man8/udevadm.8.gz.dpkg-new'
D000010: namenodetouse namenode=`/sbin/udevadm' pkg=udev
D000010: namenodetouse ... useinstead=/sbin/udevadm.upgrade camefrom=<none> pkg=udev return /sbin/udevadm
D000010: deferred extract of '/sbin/udevadm'
D000010: namenodetouse namenode=`/sbin/udevadm' pkg=udev
D000010: namenodetouse ... useinstead=/sbin/udevadm.upgrade camefrom=<none> pkg=udev return /sbin/udevadm
D000010: deferred extract of '/usr/share/man/man8/udevadm.8.gz'
D000010: process_archive not overwriting any `/sbin/udevadm' (overriding, `/sbin/udevadm.upgrade')
D000010: process_archive looking for overwriting `/usr/share/man/man8/udevadm.8.gz'
D000010: namenodetouse namenode=`/sbin/udevadm' pkg=udev
D000010: namenodetouse ... useinstead=/sbin/udevadm.upgrade camefrom=<none> pkg=udev return /sbin/udevadm
D000010: namenodetouse namenode=`/sbin/udevadm' pkg=udev
D000010: namenodetouse ... useinstead=/sbin/udevadm.upgrade camefrom=<none> pkg=udev return /sbin/udevadm
D000010: ensure_pathname_nonexisting `//sbin/udevadm.dpkg-tmp'
D000010: ensure_pathname_nonexisting `//usr/share/man/man8/udevadm.8.gz.dpkg-tmp'
Removing 'diversion of /sbin/udevadm to /sbin/udevadm.upgrade by udev'

The above shows that the diversion is indeed probably registered but that for some reason it still returns the old path instead of "useinstead".

The condition that's producing this result is:

  r=
    (namenode->divert->useinstead && namenode->divert->pkgset != pkg->set)
      ? namenode->divert->useinstead : namenode;

I tried adding the following to the namenodetouse() function in help.c:
printf("divert_useinstead=%s, divert_pkgset=%s, pkgset=%s, namenode=%s, using=%s\n",namenode->divert->useinstead,namenode->divert->pkgset,pkg->set,namenode,r);

That would have given me more details on exactly what's going on but dpkg doesn't seem to build today because of another unrelated issue: https://launchpad.net/~stgraber/+archive/foundation-build/+buildjob/2427483

From the debug output we get, the "useinstead" is set properly, so the issue is with the pkgset part of that check.

Thanks Raphaël, that explains it.
I'll upload a udev using the fake-udev --package as suggested.

This bug was fixed in the package udev - 167-0ubuntu2

---------------
udev (167-0ubuntu2) natty; urgency=low

  * debian/udev.{postinst,postrm,preinst}: Update diversions to use fake-udev
    instead of udev as the package. Otherwise the diversion will be ignored.
    (LP: #745011)
 -- Stephane Graber <email address hidden> Mon, 04 Apr 2011 17:50:13 -0400

I just got this error when upgrading from Lucid.
It might have been fixed for Natty, but how about when upgrading from Lucid?

I want to add to this in case somebody runs into the same problem.

I just got this exact same issue going from 10.10 to 11.10. In the end I solved it by doing this:

touch /sbin/udevadm.upgrade
apt-get install udev # gave me an error
rm /sbin/udevadm.upgrade
apt-get install udev # worked fine this time

> I just got this exact same issue going from 10.10 to 11.10. In the end I
> solved it by doing this:

Upgrading directly to 11.10 from 10.10 isn't supported. If you'd followed the
supported upgrade path and upgraded through 11.04, it would have been fine.

If I may Scott, this is an answer one might except from microsoft telling you you can't upgrade from XP to W7 without going through Vista. Obviously you know of ubuntu bug #1.
I could understand "sorry, we don't have the resources to test upgrades from any release to any release, but let me see how I can fix this bug", but not "eh, you upgraded wrong, now udev and therefore your entire system won't work, sorry"

I realize writing upgrades so that they work from older versions of the package takes more time, but debian has been doing it for 15 years and been doing a pretty good job of it. May I recommend trying to emulate them a bit more here?

Back to this issue, if others get bitten by it, the workaround of udevadm.upgrade did not work for me. I had to edit the postinst script and comment out the udevadm info --convertdb line for things to continue.
Obviously this means whatever udev DB that might be important to my system will not have been upgraded, but at least I get a better chance of still having a usable system after I reboot it than leaving things as is :-/

Nonsense. Ubuntu has limited resources and can't develop for and test every possible method for doing things.

Debian does not support upgrades from oldstable to testing, so you can't skip versions their either. The only difference is that since Debian has so many fewer versions the situation is less likely to come up.

People are certainly welcome to work on supporting alternate upgrade paths. The Kubuntu team did this for upgrades from 8.04 direct to 9.04/9.10 since the early KDE4 versions were spotty. That doesn't make it a general problem for all Ubuntu developers to worry about such corner cases.

If you want an unsupported use case to work, feel free to work on it, but you've no right to whine about others not doing it.

I had also tried the 'touch /sbin/udevadm.upgrade' workaround, and it failed to work. However, instead of deleting the '--convert-db' line in /var/lib/dpkg/info/udev.postinst, I changed it from:

    udevadm info --convert-db

to:

    udevadm.upgrade info --convert-db

This let the install finish correctly, and the next time I edited the udev.postinst file, dpkg had changed it back to the original. Now back to fixing dependencies and then finishing my upgrade.