#2424 closed bug (fixed)
usb disk not published if plugged during boot (vmware)
| Reported by: | emitrax | Owned by: | mmlr |
|---|---|---|---|
| Priority: | normal | Milestone: | R1 |
| Component: | System/Kernel | Version: | R1/pre-alpha1 |
| Keywords: | Cc: | ||
| Blocked By: | Blocking: | ||
| Platform: | All |
Description
If I plug my usb disk during boot (vmware) the device doesn't get published, I have to unplug it and plug it again in order to be able to mount it. I don't really know if it's the device manager, or the the usb explore thread.
Attachments (1)
Change History (13)
comment:1 by , 16 years ago
comment:2 by , 16 years ago
Log is over 3MB and I can't attach it here, is that ok if I send to your email address?
comment:4 by , 16 years ago
I've got the log and it looks perfectly fine to me. There is no actual problem. Not a single failed transfer or timeout. The device is detected and the partition is published. What I gather from the output is that the only partition on that disk is a FAT one? If so this boils down to that the FAT filesystem add-on is not loaded in the early boot process (as it doesn't have a boot module symlink). It is only loaded after the partition was published and scanned, but does not check the existing partitions for a FAT filesystem. I assume this would be an unimplemented feature in the disk device manager. If my suspicion is true, adding a symlink from "/boot/beos/system/add-ons/kernel/file_systems/fat" to "/boot/beos/system/add-ons/kernel/boot" should resolve this. Otherwise please correct me by providing info on the partitions/filesystems present on that device.
comment:5 by , 16 years ago
Spot on!
Making the link slow things a bit, but it mounts it automatically. So you think this is more a disk device manager issue?
comment:6 by , 16 years ago
| Component: | Drivers/USB → System/Kernel |
|---|
Nice. It is most probably an unimplemented feature that the disk device manager doesn't rescan yet unknown partitions when it loads a new filesystem add-on. In any case changing component to kernel as it's disk device manager issue. Will look into it, but maybe Ingo has an idea right away or can confirm this?
comment:7 by , 16 years ago
| Resolution: | → fixed |
|---|---|
| Status: | assigned → closed |
Should be fixed in hrev26128. The intel partitioning system would be associated with the disk as it just indicated supporting it with a priority of 0.1 and the actual FAT filesystem module that would have supported it with a higher priority wasn't loaded that early. Now the intel partitioning system will just leave it unsupported when it finds itself in a unlikely useful situation, therefore giving the second scan round with the FAT module available a chance of correctly identifying the partition/filesystem.
comment:8 by , 16 years ago
by , 16 years ago
| Attachment: | automounter.jpg added |
|---|
comment:10 by , 16 years ago
Well, that at least doesn't seem to have anything to do with this particular problem :-) It's probably another USB issue (I'm *so* glad that Michael tackled this!!! :-)).
comment:11 by , 16 years ago
In fact the timeout handling I introduced was broken at first. Could you please retry with a current revision and check if this still happens? Please open a new bug if it does.
I am unable to reproduce that on real hardware or on QEMU. Could you please provide a serial or syslog.