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. -- see shy jo
Attachment:
signature.asc
Description: Digital signature