Well, not so small. It doesn't work at all, and so d-i 2.6 installs
basically don't work at all.
Last week, I had images with the 2.6 kernel that worked fine, discover
worked, it saw all my hardware. Today I built an image with the 2.6
kernel, and discover fails, it sees none of my hardware. This is _after_
I fixed hw-detect, which has also been broken in the past week, in an
very lame way.
Anyway, it looks like my working 2.6 images have a package called
discover2-data-udeb on them, versioned 2.2003.12.30-1. They also have a
discover2-udeb version 2.0+20031223-2.1. My non-working new 2.6 images
have discover-udeb version 2.0.4-3 and discover-data-udeb
2.2004.04.09-2.
The discover2-data-udeb and discover2-udeb I used before were old udebs.
I used them by accident. discover2-udeb has since been removed from
unstable and testing. discover2-data-udeb is still available for some
reason.
I don't know if it's relevant, but the old discover2-data-udeb put its
data in /usr/share/discover in non-compressed xml files. The old one
puts it in /lib/discover, in gzipped xml files.
The discover command line in both cases is:
discover --data-path=linux/module/name --data-version=2.6 -d all -e ata \
-e pci -e pcmcia -e scsi bridge broadband fixeddisk humaninput modem \
network optical removabledisk
On the working images this produces a list of hardware, on the new
images it outputs nothing. The hardware that it does not see includes a
pcnet32 card in vmware, and an 8139too card, all very common stuff.
I tried combining discover-udeb with discover2-data-udeb, but that
doesn't work. Rather than drop 2.6 installs for beta4, or delay beta4,
I have switched us back to using discover1 udebs, which means d-i will
also install discover1 onto the installed system. No discover 2 will be
used. Not too happy with this, but it seems to be the most expedient way
out of this mess for now.