Bug 248298 - Problems con usb disk and scanner
Summary: Problems con usb disk and scanner
Keywords:
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Fedora
Classification: Fedora
Component: udev
Version: 7
Hardware: i386
OS: Linux
low
high
Target Milestone: ---
Assignee: Harald Hoyer
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-07-15 16:12 UTC by Luigi Carlotto
Modified: 2008-08-02 23:40 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-04-25 04:19:45 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Luigi Carlotto 2007-07-15 16:12:04 UTC
Description of problem:

I have modernized Fedora from version 6 to version 7 and, to part some
configuration, seems to work nearly all to part two things:

1) I have two external discs usb that, with fedora 7, do not come mount in
automatic rifle to the start of the system, what that instead happened with
Fedora 6; the /etc/fstab file correctly are set up on /dev/sdc1 and /dev/sdd1
(modified from hd*). After the start are forced to execute the mount manually,
after that all work perfectly. My question is: in some way udev it influences on
the formulations of fstab, and in that way? How it is possible to modify this
behavior? Is to keep in mind who the two discs usb are always connects to the
system, and exists automatic procedures that use these discs for the backup of
the computer.

2) Always on a door usb a Canon N650U is connected scanner, than with Fedora 6
it worked perfectly; after the modernization to Fedora 7, this does not work
more, although they do not come visualizes error messages; the peripheral one
comes recognized perfectly (also with gimp), but as soon as I try to use it the
progression window jams in attended of answer from the scanner. To notice that
the program does not jam, allowing me to close it without problems. The scanner
it has been tried on a Windows system and works perfectly. Same question: it is
always udev that it creates the problem? I have tried also to move the connector
on other doors usb (all working), but verification the same problem.

Thanks


How reproducible:
always in whichever situation

Comment 1 Harald Hoyer 2007-07-16 11:01:26 UTC
1) look at the /dev/disk symlinks.. you may use those for fstab
2) don't know, why this is a udev problem??

Comment 2 Luigi Carlotto 2007-07-16 16:12:58 UTC
1) The situation in the directory /dev/disk is following:
# tree
.
|-- by-id
|   |-- scsi-SATA_MAXTOR_STM32506_4QE03BQ9 -> ../../sdb
|   |-- scsi-SATA_MAXTOR_STM32506_4QE03BQ9-part1 -> ../../sdb1
|   |-- scsi-SATA_Maxtor_6L250R0_L51564EG -> ../../sda
|   |-- scsi-SATA_Maxtor_6L250R0_L51564EG-part1 -> ../../sda1
|   |-- scsi-SATA_Maxtor_6L250R0_L51564EG-part2 -> ../../sda2
|   |-- scsi-SATA_Maxtor_6L250R0_L51564EG-part3 -> ../../sda3
|   |-- scsi-SATA_Maxtor_6L250R0_L51564EG-part4 -> ../../sda4
|   |-- scsi-SATA_Maxtor_6L250R0_L51564EG-part5 -> ../../sda5
|   |-- usb-Maxtor_6_Y080L0_200000002115 -> ../../sdc
|   |-- usb-Maxtor_6_Y080L0_200000002115-part1 -> ../../sdc1
|   |-- usb-WDC_WD25_00BB-00RDA0 -> ../../sdd
|   `-- usb-WDC_WD25_00BB-00RDA0-part1 -> ../../sdd1
|-- by-label
|   |-- 1 -> ../../sda2
|   |-- SWAP-hda3 -> ../../sda3
|   `-- boot1 -> ../../sda1
|-- by-path
|   |-- pci-0000:00:1d.7-usb-0:1:1.0-scsi-0:0:0:0 -> ../../sdd
|   |-- pci-0000:00:1d.7-usb-0:1:1.0-scsi-0:0:0:0-part1 -> ../../sdd1
|   |-- pci-0000:00:1d.7-usb-0:3:1.0-scsi-0:0:0:0 -> ../../sdc
|   |-- pci-0000:00:1d.7-usb-0:3:1.0-scsi-0:0:0:0-part1 -> ../../sdc1
|   |-- pci-0000:00:1f.1-scsi-0:0:0:0 -> ../../sda
|   |-- pci-0000:00:1f.1-scsi-0:0:0:0-part1 -> ../../sda1
|   |-- pci-0000:00:1f.1-scsi-0:0:0:0-part2 -> ../../sda2
|   |-- pci-0000:00:1f.1-scsi-0:0:0:0-part3 -> ../../sda3
|   |-- pci-0000:00:1f.1-scsi-0:0:0:0-part4 -> ../../sda4
|   |-- pci-0000:00:1f.1-scsi-0:0:0:0-part5 -> ../../sda5
|   |-- pci-0000:00:1f.1-scsi-0:0:1:0 -> ../../sdb
|   |-- pci-0000:00:1f.1-scsi-0:0:1:0-part1 -> ../../sdb1
|   |-- pci-0000:00:1f.1-scsi-1:0:0:0 -> ../../scd0
|   `-- pci-0000:00:1f.1-scsi-1:0:1:0 -> ../../scd1
`-- by-uuid
    |-- 003a4e95-6e06-4cfd-9457-826a667282b2 -> ../../sda2
    |-- 7c4b05b0-45c7-4227-a2cc-3bed2517af59 -> ../../sdc1
    |-- 97aba172-ccc0-44e4-97b3-def9cde912fb -> ../../sdd1
    |-- f02ff3d3-28c7-456c-8dd3-541c6368164f -> ../../sda1
    `-- f2ca9561-b85a-4df1-920e-ab653da4ab2f -> ../../sdd

currently the two discs, as you can see, are mount to you and use the simlinks
/dev/sdc1 and /dev/sdd1; in that way I can address them on fstab, if these after
the start of the system come associate to you in this way?

2) In effects they are not sure that this is caused from udev, but I do not
succeed to understand where it can be the problem. Moving the connector of the
scanner on various doors, this comes associated correctly to various addresses,
but however it does not work. I presumed that also this anomaly was caused from
udev (like for discs usb), but I can also be mistaken. In the previous
modernizations with the several versions of Fedora this was not never happened.
According to you what can cause this problem?

Thanks for answer!!!


Comment 3 Luigi Carlotto 2007-07-16 16:28:40 UTC
1) I have executed some tests and I have noticed that the problem is caused from
the fact that the two discs usb do not come seen to the start of the system.
After the start it is necessary to start discs newly (off/on), or to remove and
then to reconnect the connector usb. Fact this all then works. If this procedure
is not executed, in directory /dev/disk two discs usb they do not come
visualizes to you.

Comment 4 Luigi Carlotto 2007-07-21 17:37:13 UTC
I have executed the modernization to kernel "2.6.22.1-27.fc7 #1 SMP" and the
problem with external discs usb seems is returned to place.
As soon as I can I will make a test with the scanner in order to see if also
this problem has been arranged.

Comment 5 Harald Hoyer 2008-02-20 11:31:48 UTC
still a problem in F8?

Comment 6 Brian Powell 2008-04-25 04:19:45 UTC
The information we've requested above is required in order
to review this problem report further and diagnose/fix the
issue if it is still present.  Since there have not been any
updates to the report since thirty (30) days or more since we
requested additional information, we're assuming the problem
is either no longer present in the current Fedora release, or
that there is no longer any interest in tracking the problem.

Setting status to "CLOSED INSUFFICIENT_DATA".  If you still
experience this problem after updating to our latest Fedora
release and can provide the information previously requested, 
please feel free to reopen the bug report.

Thank you in advance.

Note that maintenance for Fedora 7 will end 30 days after the GA of Fedora 9.


Note You need to log in before you can comment on or make changes to this bug.