On Sunday 22 June 2008, root wrote:
> Comments/Problems:
> /etc/fstab ended up with an /media/floppy mountpoint for /dev/sda.
> Which was weird, because /dev/sda is a (very cheap) USB ide laptop disk
> enclosure; /dev/sda1 is the root filesystem. Seems to happen because
> ID_TYPE is reported as floppy:
>
> root@slug:/etc/ssl/certs>udevinfo -q env -p /block/sda
> ID_VENDOR=Myson_Century,_Inc.
> ID_MODEL=USB_Mass_Storage_Device
> ID_REVISION=b008
> ID_SERIAL=Myson_Century,_Inc._USB_Mass_Storage_Dev ice_100
> ID_SERIAL_SHORT=100
> ID_TYPE=floppy
> ID_BUS=usb
> ID_PATH=pci-0000:00:01.2-usb-0:1:1.0-scsi-0:0:0:0
>
> I don't know if this is a kernel or a hardware bug. I do wonder if d-i
> should trust the ID_TYPE at all.

We don't, at least not entirely. See list-devices which has a few
exceptions. Maybe another one should be added?



--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Monday 23 June 2008, Frans Pop wrote:
> > I don't know if this is a kernel or a hardware bug. I do wonder if
> > d-i should trust the ID_TYPE at all.
>
> We don't, at least not entirely. See list-devices which has a few
> exceptions. Maybe another one should be added?

OTOH, it should probably only be a minor fix to get the type reported
correctly. The first thing to check is extras/usb_id/usb_id.c in udev
which seems to be what determines the output based on sysfs info.

The type looks to be determined by bInterfaceClass and bInterfaceSubClass
in /sys/bus/usb/devices/x-y:1.0/. The SubClass seems to be 5 instead of 8
in your case.
The output of 'lsusb -v' (as root) will give you those values as well.

If so, the classification error looks to be in the kernel and should be
traceable with full lsusb output for the device.



--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

* root [2008-06-21 19:15]:
> I always forget to select the usb-storage and ext3 modules when
> installing a slug, and this time was no exception;

Yep, it's annoying. IMHO it would be nice if we could specify a list
of modules for specific subarches that would be loaded even when
you're in lowmem level2.
--
Martin Michlmayr
http://www.cyrius.com/



--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Monday 23 June 2008, Martin Michlmayr wrote:
> * root [2008-06-21 19:15]:
> > I always forget to select the usb-storage and ext3 modules when
> > installing a slug, and this time was no exception;
>
> Yep, it's annoying. IMHO it would be nice if we could specify a list
> of modules for specific subarches that would be loaded even when
> you're in lowmem level2.

Assuming s/modules/udebs/: add them in /var/cache/anna/include.
When/how to best do that is up to you.



--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Frans Pop wrote:
> On Monday 23 June 2008, Frans Pop wrote:
> > > I don't know if this is a kernel or a hardware bug. I do wonder if
> > > d-i should trust the ID_TYPE at all.
> >
> > We don't, at least not entirely. See list-devices which has a few
> > exceptions. Maybe another one should be added?

I have a feeling there are a near-infinite supply of differenct cheap
usb enclosures. Though I definitly picked the very cheap end in this one. :-)

There might also be reasons for these devices to pretend to be USB
floppy drives, to work around BIOS issues or something.

> OTOH, it should probably only be a minor fix to get the type reported
> correctly. The first thing to check is extras/usb_id/usb_id.c in udev
> which seems to be what determines the output based on sysfs info.
>
> The type looks to be determined by bInterfaceClass and bInterfaceSubClass
> in /sys/bus/usb/devices/x-y:1.0/. The SubClass seems to be 5 instead of 8
> in your case.
> The output of 'lsusb -v' (as root) will give you those values as well.
>
> If so, the classification error looks to be in the kernel and should be
> traceable with full lsusb output for the device.

Bus 001 Device 002: ID 04cf:8818 Myson Century, Inc. USB2.0 to ATAPI BridgeController
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x04cf Myson Century, Inc.
idProduct 0x8818 USB2.0 to ATAPI Bridge Controller
bcdDevice b0.08
iManufacturer 1 Myson Century, Inc.
iProduct 2 USB Mass Storage Device
iSerial 3 100
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 32
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 4 USB Mass Storage
bmAttributes 0xc0
Self Powered
MaxPower 10mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 8 Mass Storage
bInterfaceSubClass 5 SFF-8070i
bInterfaceProtocol 80
iInterface 5 Mass Storage Class
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x03 EP 3 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x84 EP 4 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Device Qualifier (for other device speed):
bLength 10
bDescriptorType 6
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
bNumConfigurations 1
Device Status: 0x0001
Self Powered

--
see shy jo

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iD8DBQFIX9E/d8HHehbQuO8RArIYAJwL/2SZjEBnPtqLXJJ3yxrD1DpWJgCdF5p2
S3Bt/XkMUvTJ2nwDFS9xS18=
=lzqE
-----END PGP SIGNATURE-----

* Martin Michlmayr [2008-09-13 16:21]:
> The only thing I don't like is that the modules installed via
> anna-install won't show up in the list of modules that users get to
> select from (iirc this is not the case when using
> /var/cache/anna/include)

Actually, I just checked and you get the same with
/var/cache/anna/include. So let's use anna-install.
--
Martin Michlmayr
http://www.cyrius.com/



--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

* Frans Pop [2008-06-23 16:29]:
> > Yep, it's annoying. IMHO it would be nice if we could specify a list
> > of modules for specific subarches that would be loaded even when
> > you're in lowmem level2.
>
> Assuming s/modules/udebs/: add them in /var/cache/anna/include.
> When/how to best do that is up to you.

That's a great idea, Frans! Actually, /var/cache/anna/include won't
work in this case because on lowmem systems some things from
/var/cache/anna/include are ignored, so you cannot queue up
partman-auto and partman-ext3 this way. However, anna-install works.

I came up with the patch below which I tested on a QNAP device in
(faked) lowmem level 2.

Gordon, can you test this on a NSLU2?

Frans, any comments on the patch?

The only thing I don't like is that the modules installed via
anna-install won't show up in the list of modules that users get to
select from (iirc this is not the case when using
/var/cache/anna/include). I fear this might confuse some users who
are known to the etch installer, but I still think it makes sense to
load them automatically and to document this change in the release
notes.

The alternative would be to modify anna.c and to move the
take_includes/drop_excludes calls right after the if (lowmem_mode)...
and then use /var/cache/anna/include. I don't think this would have
any negative effects, but I'm not sure. Colin/Frans?

Index: src/lib/debian-installer-startup.d/S80anna-install
================================================== =================
--- src/lib/debian-installer-startup.d/S80anna-install (revision 0)
+++ src/lib/debian-installer-startup.d/S80anna-install (revision 0)
@@ -0,0 +1,21 @@
+## Make sure some udebs are loaded automatically, even in lowmem level 2
+
+kver=$(uname -r)
+machine=$(grep "^Hardware" /proc/cpuinfo | sed 's/Hardware\s*:\s*//')
+case "`archdetect`" in
+ arm*/ixp4xx)
+ case "$machine" in
+ "Linksys NSLU2")
+ anna-install partman-auto
+ anna-install partman-ext3
+ anna-install usb-storage-modules-$kver-di
+ ;;
+ esac
+ ;;
+ mipsel/cobalt)
+ anna-install partman-auto
+ anna-install partman-ext2r0
+ anna-install partman-ext3
+ ;;
+esac
+
Index: src/lib/debian-installer-startup.d/Makefile
================================================== =================
--- src/lib/debian-installer-startup.d/Makefile (revision 55567)
+++ src/lib/debian-installer-startup.d/Makefile (working copy)
@@ -20,7 +20,8 @@
S10syslog \
S20templates \
S35term \
- S37speakup
+ S37speakup \
+ S80anna-install

ifeq ($(DEB_HOST_ARCH_OS),linux)
ifneq (,$(filter i386 amd64,$(DEB_HOST_ARCH_CPU)))

--
Martin Michlmayr
http://www.cyrius.com/



--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

* Joey Hess [2008-06-23 12:37]:
> > OTOH, it should probably only be a minor fix to get the type reported
> > correctly. The first thing to check is extras/usb_id/usb_id.c in udev
> > which seems to be what determines the output based on sysfs info.
> >
> > The type looks to be determined by bInterfaceClass and bInterfaceSubClass
> > in /sys/bus/usb/devices/x-y:1.0/. The SubClass seems to be 5 instead of 8
> > in your case.
> > The output of 'lsusb -v' (as root) will give you those values as well.
> >
> > If so, the classification error looks to be in the kernel and should be
> > traceable with full lsusb output for the device.

Frans/Joey, should this be reassigned to the kernel or udev or
something?

> Bus 001 Device 002: ID 04cf:8818 Myson Century, Inc. USB2.0 to ATAPI Bridge Controller
> Device Descriptor:
> bLength 18
> bDescriptorType 1
> bcdUSB 2.00
> bDeviceClass 0 (Defined at Interface level)
> bDeviceSubClass 0
> bDeviceProtocol 0
> bMaxPacketSize0 64
> idVendor 0x04cf Myson Century, Inc.
> idProduct 0x8818 USB2.0 to ATAPI Bridge Controller
> bcdDevice b0.08
> iManufacturer 1 Myson Century, Inc.
> iProduct 2 USB Mass Storage Device
> iSerial 3 100
> bNumConfigurations 1
> Configuration Descriptor:
> bLength 9
> bDescriptorType 2
> wTotalLength 32
> bNumInterfaces 1
> bConfigurationValue 1
> iConfiguration 4 USB Mass Storage
> bmAttributes 0xc0
> Self Powered
> MaxPower 10mA
> Interface Descriptor:
> bLength 9
> bDescriptorType 4
> bInterfaceNumber 0
> bAlternateSetting 0
> bNumEndpoints 2
> bInterfaceClass 8 Mass Storage
> bInterfaceSubClass 5 SFF-8070i
> bInterfaceProtocol 80
> iInterface 5 Mass Storage Class
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x03 EP 3 OUT
> bmAttributes 2
> Transfer Type Bulk
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0200 1x 512 bytes
> bInterval 0
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x84 EP 4 IN
> bmAttributes 2
> Transfer Type Bulk
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0200 1x 512 bytes
> bInterval 0
> Device Qualifier (for other device speed):
> bLength 10
> bDescriptorType 6
> bcdUSB 2.00
> bDeviceClass 0 (Defined at Interface level)
> bDeviceSubClass 0
> bDeviceProtocol 0
> bMaxPacketSize0 64
> bNumConfigurations 1
> Device Status: 0x0001
> Self Powered

--
Martin Michlmayr
http://www.cyrius.com/



--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Saturday 13 September 2008, Martin Michlmayr wrote:
> > > If so, the classification error looks to be in the kernel and
> > > should be traceable with full lsusb output for the device.
>
> Frans/Joey, should this be reassigned to the kernel or udev or
> something?

As far as I've been able to tell that would be pointless. Fixing the
classification would require a device-specific quirk in udev as the
standard logic looks fine. Somehow I doubt that we want a huge list of
quirks in udev for such devices that all systems have to run through
every time the udev daemon is activated.

So the only realistic place to solve this IMO would be in the installer.
We'd have to detect such weird devices, add the quirk rule in a file in
/etc/udev/rules.d/ and either unload/reload the driver or ask the user to
unplug/reconnect the device.



--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Saturday 13 September 2008, Martin Michlmayr wrote:
> Index: src/lib/debian-installer-startup.d/S80anna-install
> ================================================== =================
> --- src/lib/debian-installer-startup.d/S80anna-install (revision 0)
> +++ src/lib/debian-installer-startup.d/S80anna-install (revision 0)

Please use architecture-specific scripts instead (i.e. scripts that only
get included for the appropriate architecture.



--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

* Frans Pop [2008-09-13 17:40]:
> Please use architecture-specific scripts instead (i.e. scripts that only
> get included for the appropriate architecture.

How about this:

Index: src/lib/debian-installer-startup.d/S80anna-install
================================================== =================
--- src/lib/debian-installer-startup.d/S80anna-install (revision 0)
+++ src/lib/debian-installer-startup.d/S80anna-install (revision 0)
@@ -0,0 +1,21 @@
+## Make sure some udebs are loaded automatically, even in lowmem level 2
+
+kver=$(uname -r)
+machine=$(grep "^Hardware" /proc/cpuinfo | sed 's/Hardware\s*:\s*//')
+case "`archdetect`" in
+ arm*/ixp4xx)
+ case "$machine" in
+ "Linksys NSLU2")
+ anna-install partman-auto
+ anna-install partman-ext3
+ anna-install usb-storage-modules-$kver-di
+ ;;
+ esac
+ ;;
+ mipsel/cobalt)
+ anna-install partman-auto
+ anna-install partman-ext2r0
+ anna-install partman-ext3
+ ;;
+esac
+
Index: src/lib/debian-installer-startup.d/Makefile
================================================== =================
--- src/lib/debian-installer-startup.d/Makefile (revision 55567)
+++ src/lib/debian-installer-startup.d/Makefile (working copy)
@@ -40,6 +40,11 @@
S40framebuffer-module-linux-mips
endif

+ ifneq (,$(filter mipsel,$(DEB_HOST_ARCH_CPU)))
+ files += \
+ S80anna-install
+ endif
+
ifneq (,$(filter alpha,$(DEB_HOST_ARCH_CPU)))
files += \
S40framebuffer-module-linux-alpha \
@@ -58,6 +63,7 @@

ifneq (,$(filter arm armel,$(DEB_HOST_ARCH_CPU)))
files += \
+ S80anna-install \
S99signal-status
endif


--
Martin Michlmayr
http://www.cyrius.com/



--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Saturday 13 September 2008, Martin Michlmayr wrote:
> * Frans Pop [2008-09-13 17:40]:
> > Please use architecture-specific scripts instead (i.e. scripts that
> > only get included for the appropriate architecture.
>
> How about this:

I'd have created two separate scripts: S80anna-install-arm and
S80anna-install-mipsel, but as they're both "your" arches I'll leave that
up to you.



--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Frans Pop writes:

> On Saturday 13 September 2008, Martin Michlmayr wrote:
>> * Frans Pop [2008-09-13 17:40]:
>> > Please use architecture-specific scripts instead (i.e. scripts that
>> > only get included for the appropriate architecture.
>>
>> How about this:
>
> I'd have created two separate scripts: S80anna-install-arm and
> S80anna-install-mipsel, but as they're both "your" arches I'll leave that
> up to you.

I agree with Frans here that it looks easier to read if you split it up.

--
O T A V I O S A L V A D O R
---------------------------------------------
E-mail: otavio@debian.org UIN: 5906116
GNU/Linux User: 239058 GPG ID: 49A5F855
Home Page: http://otavio.ossystems.com.br
---------------------------------------------
"Microsoft sells you Windows ... Linux gives
you the whole house."



--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Saturday 13 September 2008, Frans Pop wrote:
> So the only realistic place to solve this IMO would be in the
> installer. We'd have to detect such weird devices, add the quirk rule
> in a file in /etc/udev/rules.d/ and either unload/reload the driver or
> ask the user to unplug/reconnect the device.

A more user-friendly option would be to include all such quirks in the
installer by default, but only copy those that actually "fire" to the
installed system.

In both cases this would of course only solve the problem for devices that
are connected during installation, not in cases where the user first
connects the device after the system has been installed.
For that the quirks would have to be included in the regular udev package.
Maybe if some smart grouping is done that allows most rules to be quickly
skipped it would not be too bad to have it there.



--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Gordon, can you please test the patch below. The easiest way is
probably to unpack a daily image, add the script to
/lib/debian-installer-startup.d/ and to repack the image (but you can
of course rebuild rootskel with this patch and stick the udeb into
localudebs).

Index: src/lib/debian-installer-startup.d/S80anna-install-mipsel
================================================== =================
--- src/lib/debian-installer-startup.d/S80anna-install-mipsel (revision 0)
+++ src/lib/debian-installer-startup.d/S80anna-install-mipsel (revision 0)
@@ -0,0 +1,10 @@
+# Make sure some udebs are loaded automatically, even in lowmem level 2
+
+case "`archdetect`" in
+ mipsel/cobalt)
+ anna-install partman-auto
+ anna-install partman-ext2r0
+ anna-install partman-ext3
+ ;;
+esac
+
Index: src/lib/debian-installer-startup.d/S80anna-install-armel
================================================== =================
--- src/lib/debian-installer-startup.d/S80anna-install-armel (revision 0)
+++ src/lib/debian-installer-startup.d/S80anna-install-armel (revision 0)
@@ -0,0 +1,12 @@
+# Make sure some udebs are loaded automatically, even in lowmem level 2
+
+kver=$(uname -r)
+machine=$(grep "^Hardware" /proc/cpuinfo | sed 's/Hardware\s*:\s*//')
+case "$machine" in
+ "Linksys NSLU2")
+ anna-install partman-auto
+ anna-install partman-ext3
+ anna-install usb-storage-modules-$kver-di
+ ;;
+esac
+
Index: src/lib/debian-installer-startup.d/Makefile
================================================== =================
--- src/lib/debian-installer-startup.d/Makefile (revision 55567)
+++ src/lib/debian-installer-startup.d/Makefile (working copy)
@@ -40,6 +40,11 @@
S40framebuffer-module-linux-mips
endif

+ ifneq (,$(filter mipsel,$(DEB_HOST_ARCH_CPU)))
+ files += \
+ S80anna-install-mipsel
+ endif
+
ifneq (,$(filter alpha,$(DEB_HOST_ARCH_CPU)))
files += \
S40framebuffer-module-linux-alpha \
@@ -58,6 +63,7 @@

ifneq (,$(filter arm armel,$(DEB_HOST_ARCH_CPU)))
files += \
+ S80anna-install-armel \
S99signal-status
endif


--
Martin Michlmayr
http://www.cyrius.com/



--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

* Otavio Salvador [2008-09-13 14:43]:
> > I'd have created two separate scripts: S80anna-install-arm and
> > S80anna-install-mipsel, but as they're both "your" arches I'll
> > leave that up to you.
>
> I agree with Frans here that it looks easier to read if you split it
> up.

Okay, I'll do that.
--
Martin Michlmayr
http://www.cyrius.com/



--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Sat, Sep 13, 2008 at 13:17, Martin Michlmayr wrote:
> Gordon, can you please test the patch below. The easiest way is
> probably to unpack a daily image, add the script to
> /lib/debian-installer-startup.d/ and to repack the image (but you can
> of course rebuild rootskel with this patch and stick the udeb into
> localudebs).

The patch works on the NSLU2. I didn't see partman-auto, partman-ext3,
and usb-storage-modules-* in the list of installer modules as you
described.

I think that this change is a huge improvement because it makes the
installer more seamless for the user. It may trouble some of the etch
installer users at first, but I think that they'll soon get over not
having to select the correct modules ;-)

Gordon

--
Gordon Farquharson
GnuPG Key ID: 32D6D676



--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Your message dated Mon, 15 Sep 2008 06:47:02 +0000
with message-id
and subject line Bug#498795: fixed in rootskel 1.68
has caused the Debian Bug report #498795,
regarding Should automatically load required udebs for the nslu2
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


--
498795: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=498795
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems

* Otavio Salvador [2008-09-13 16:39]:
> > In both cases this would of course only solve the problem for devices that
> > are connected during installation, not in cases where the user first
> > connects the device after the system has been installed.
> > For that the quirks would have to be included in the regular udev package.
> > Maybe if some smart grouping is done that allows most rules to be quickly
> > skipped it would not be too bad to have it there.
>
> Yes, this kind of quirk should be available in regular udev package to
> allow later usage by user ... that is much more user friendly for me.

So should we reassign this bug to udev?
--
Martin Michlmayr
http://www.cyrius.com/



--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org