Yesterday I uploaded some packages, including base-installer and hw-detect.
Today during a test install from a local build this resulted in:

                     Failed to load installer component
       loading base-installer failed for unknown reasons. Aborting.

The syslog does not show much info, but this is interesting:
[...]
anna: DEBUG: retrieving base-installer 1.104
anna: DEBUG: retrieving base-installer 1.104
anna: DEBUG: retrieving bootstrap-base 1.104
[...]
anna: DEBUG: retrieving disk-detect 1.74
anna: DEBUG: retrieving disk-detect 1.74
[...]

So the error is probably the result of anna trying to install the same
package twice.

I ran anna a second time and that finished without errors and the rest of
the installation also completed without problems, so the impact is
limited.

The packages file on my local mirror shows the cause of the problem. It
contains two versions of both base-installer (1.103, 1.104) and
disk-detect (1.73, 1.74). Both are arch:all packages, so this is probably
the simple result of the recent changes in the archive and the packages
not yet being built for all arches.

We need to at least make sure anna does not try to process the same package
twice. It already seems to return the correct (highest) version.

The actual fix is probably in libd-i rather than anna itself.

This issue will only manifest for packages that have both arch:any and
arch:all udebs, and only while it has not been built for all arches.
So the problem will be fairly rare [1], but IMO it should still be fixed as
it looks extremely fatal.

The exit code of anna was 8, which matches an error during unpack or
configure.

I've run into this with a custom installer suite with udebs overriding
those in lenny's main/debian-installer.  My solution at the time was
just to filter the Packages file in net-retriever so that anna was only
given one version of any particular package.  (Ubuntu did something
similar, see [1].)  However, it should probably be fixed in anna or
libdebian-installer itself. :)

Specifically, what happens is that anna unpacks all the packages in one
batch, and then it configures all of them.  But while unpacking another
version of a package while another vesrion is in an
unpacked-but-not-configured state is ok, it's not ok to configure a
package that's already in the configured state.  So if a package is in
the list twice, it fails at the second configure for that package.

I'm trying to better understand anna and libd-i to come up with a
suitable patch...

 [1]: https://bugs.launchpad.net/ubuntu/+source/net-retriever/+bug/234486

reassign 562398 libdebian-installer4-udeb
found 562398 0.69
retitle 562398 libdebian-installer: strange behavior with more than one version of a package in a Packages file
affects 562398 + anna
tags 562398 + patch
thanks
with the same Package field as one it's previously seen,
di_packages_parser_read_name sets the data pointer the rest of the
parsing functions will use to the previously-used di_packages pointer.
At first glance, this would appear simply to prefer packages that appear
later in the Packages file, irrespective of version.  Unfortunately, it
appends the di_package to the package list
(&parser->data->packages->list) whether it's a newly allocated one or an
old one.  So while only one actual di_package exists for a particular
package name, it might appear multiple times in the list.

The simple way to fix the anna issue is to make sure we only append
newly allocated di_package objects to the list.  But it would be nice to
favor new versions rather than whatever shows up latest in the Packages
file (for example, to facilitate #389430 or LP#234486).

I've attached a quick reproducer to demonstrate the issue, and a patch.
I would prefer if the version comparison could happen during the
Packages file parsing, rather than after the fact (since this way
requires creating a temporary hash table and traversing the list a
couple of extra times), but that change would seem to be very invasive.
In any case, after pounding my head for a couple of hours, I couldn't
figure out how to do it any better with the current parsing
infrastructure. :)

Hi Gaudenz,

Just forwarding your mail to the bugreport for completeness (it seems you forgot
it).

Cheers,

OdyX

----------  Gaudenz's mail  ----------

Sujet : Re: Bug#562398: anna: fails if multiple versions of a udeb in Packages
file
Date : Monday 29 November 2010
De : Gaudenz Steinlin <gaudenz@debian.org>
À : "debian-boot" <debian-boot@lists.debian.org>

severity 562398 important
Thanks

Hi

It also seems quite risky to introduce this change now (see below for
my test results). As this bug is only triggered in very rare
circumstances and as far as I understand these circumstances can't
happen in a stable release, I don't think this issue is really release
critical. I'm therefore downgrading this bug. Feel free to upgrade it
again if you disagree.

Excerpts from John Wright's message of Mon Mai 03 10:15:06 +0200 2010:

I tested you patch during the BSP in Bern. The patch still applies
cleanly to the current libdebian-installer. It also still fixes your
test case. But when testing a d-i image with your patch (patched
libdebian-installer installed on the build host and in localudebs!)
anna fails to download (some) dependencies. The install then fails
during clock-setup because tzsetup-udeb is not installed. I'm pretty
sure this is related to the patch because it does not happen with the
daily images.

John did you test your patch in d-i? And did you install the patched
libdebian-installer on your build host? If you don't install it on the
build host, the first part of the installer will run with the
unpatched library.

Gaudenz