Red Hat Bugzilla – Full Text Bug Listing
|Summary:||Problems con usb disk and scanner|
|Product:||[Fedora] Fedora||Reporter:||Luigi Carlotto <luigi.carlotto>|
|Component:||udev||Assignee:||Harald Hoyer <harald>|
|Status:||CLOSED INSUFFICIENT_DATA||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2008-04-25 00:19:45 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Luigi Carlotto 2007-07-15 12:12:04 EDT
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 07:01:26 EDT
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 12:12:58 EDT
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 12:28:40 EDT
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 13:37:13 EDT
I have executed the modernization to kernel "18.104.22.168-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 06:31:48 EST
still a problem in F8?
Comment 6 Brian Powell 2008-04-25 00:19:45 EDT
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.