Re: Where Did It Go? A Re-Post

[Mercury Morris]

>  How do you mean "fail to recognize the drive" when you are
> also saying
>  you get a /dev/sdb1 created?  That sounds like the drive is recognized fine. 
On my system, I have four Western Digital SATA drives - /sda thru /sdd.
When the system boots with no disk in the drive, /dev/sde shows up and
all the code, except for sfdisk, sees it as a fifth SATA drive.  That
is why I claim that the drive is not recognized, at least not correctly.

One other point that I didn't mention before:  The only way to get the
/dev/sde4 created is to boot the system WITH a disk inside the ZIP drive.
That was not necessary with Fedora Core 6 and the 2.6.18 kernel(s).
The command, mknod /dev/sde4 b 8 68, does not create a valid device.
In order to get /dev/sde4 correctly created, there must be a ZIP disk
inside the ZIP drive before the system is booted.

Below, you can read what sfdisk has to say about the device, correcting
the error(s) generated by the kernel (kudzu or whatever).  But when
an attempt is made to write to the ZIP drive, or even just print out
the partition table, hundreds of error messages show up in the system log.
I've included only very few of the system log messages, below.

---------- Some of the console output (commands and responses) ----------
[root@estreet ~]# ls -alt /dev/sde*
brw-r----- 1 root disk 8, 64 2007-07-28 14:23 /dev/sde
brw-r----- 1 root disk 8, 68 2007-07-28 14:23 /dev/sde4

[root@estreet ~]# sfdisk -l /dev/sde

Disk /dev/sde: 0 cylinders, 255 heads, 63 sectors/track
Warning: The partition table looks like it was made
  for C/H/S=*/64/32 (instead of 0/255/63).
For this listing I'll assume that geometry.
Units = cylinders of 1048576 bytes, blocks of 1024 bytes, counting from 0

   Device Boot Start     End   #cyls    #blocks   Id  System
/dev/sde1          0       -       0          0    0  Empty
/dev/sde2          0       -       0          0    0  Empty
/dev/sde3          0       -       0          0    0  Empty
/dev/sde4   *      0+     95      96-     98288    6  FAT16

[root@estreet ~]# mount /dev/sde4 /mnt
mount: you must specify the filesystem type

[root@estreet ~]# mount -t vfat /dev/sde4 /mnt
mount: /dev/sde4: can't read superblock

---------- Some of the error messages from /var/log/messages ----------
Jul 28 15:02:23 estreet kernel: attempt to access beyond end of device
Jul 28 15:02:23 estreet kernel: sde: rw=0, want=196392, limit=1
Jul 28 15:02:23 estreet kernel: printk: 36 messages suppressed.
Jul 28 15:02:23 estreet kernel: Buffer I/O error on device sde4,
logical block 24544
Jul 28 15:02:23 estreet kernel: attempt to access beyond end of device
Jul 28 15:02:23 estreet kernel: sde: rw=0, want=196392, limit=1
Jul 28 15:02:23 estreet kernel: Buffer I/O error on device sde4,
logical block 24544

-- 
MM

Where Did It Go? A Re-Post

[Andy Green]

Somebody in the thread at some point said:

>  One other point that I didn't mention before:  The only way to
> get the
>  /dev/sde4 created is to boot the system WITH a disk inside the ZIP drive. 
...
>  Disk /dev/sde: 0 cylinders, 255 heads, 63 sectors/track 
0 cylinders....

>  Jul 28 15:02:23 estreet kernel: attempt to access beyond end of
> device
>  Jul 28 15:02:23 estreet kernel: sde: rw=0, want=196392, limit=1 
limit = 1... it's clearly not able to interrogate the drive to find out
the geometry properly...

I guess I would first stick it in Bugzilla at Fedora

https://bugzilla.redhat.com/bugzilla/index.cgi

-Andy

Where Did It Go? A Re-Post

[Mercury Morris]

On 7/31/07, Andy Green <andy(a)warmcat.com&gt; wrote:
>  Somebody in the thread at some point said:
>
>  > One other point that I didn't mention before:  The only way to get the
>  > /dev/sde4 created is to boot the system WITH a disk inside the ZIP drive.
>  ...
>  > Disk /dev/sde: 0 cylinders, 255 heads, 63 sectors/track
>
>  0 cylinders....
>
>  > Jul 28 15:02:23 estreet kernel: attempt to access beyond end of device
>  > Jul 28 15:02:23 estreet kernel: sde: rw=0, want=196392, limit=1
>
>  limit = 1... it's clearly not able to interrogate the drive to find out
>  the geometry properly...
>
>  I guess I would first stick it in Bugzilla at Fedora
>
>  https://bugzilla.redhat.com/bugzilla/index.cgi 
Thanks, Andy.  I'll see if I can find a path thru the Bugzilla maze!

-- 
MM

Where Did It Go? A Re-Post

[Mikkel]

Mercury Morris wrote:
> > How do you mean "fail to recognize the drive" when you
> are also saying
> > you get a /dev/sdb1 created?  That sounds like the drive is recognized fine.
>  
>  On my system, I have four Western Digital SATA drives - /sda thru /sdd.
>  When the system boots with no disk in the drive, /dev/sde shows up and
>  all the code, except for sfdisk, sees it as a fifth SATA drive.  That
>  is why I claim that the drive is not recognized, at least not correctly.
>  
>  One other point that I didn't mention before:  The only way to get the
>  /dev/sde4 created is to boot the system WITH a disk inside the ZIP drive.
>  That was not necessary with Fedora Core 6 and the 2.6.18 kernel(s).
>  The command, mknod /dev/sde4 b 8 68, does not create a valid device.
>  In order to get /dev/sde4 correctly created, there must be a ZIP disk
>  inside the ZIP drive before the system is booted.
>  
>  Below, you can read what sfdisk has to say about the device, correcting
>  the error(s) generated by the kernel (kudzu or whatever).  But when
>  an attempt is made to write to the ZIP drive, or even just print out
>  the partition table, hundreds of error messages show up in the system log.
>  I've included only very few of the system log messages, below.
>  
>  ---------- Some of the console output (commands and responses) ----------
>  [root@estreet ~]# ls -alt /dev/sde*
>  brw-r----- 1 root disk 8, 64 2007-07-28 14:23 /dev/sde
>  brw-r----- 1 root disk 8, 68 2007-07-28 14:23 /dev/sde4
>  
>  [root@estreet ~]# sfdisk -l /dev/sde
>  
>  Disk /dev/sde: 0 cylinders, 255 heads, 63 sectors/track
>  Warning: The partition table looks like it was made
>    for C/H/S=*/64/32 (instead of 0/255/63).
>  For this listing I'll assume that geometry.
>  Units = cylinders of 1048576 bytes, blocks of 1024 bytes, counting from 0
>  
>     Device Boot Start     End   #cyls    #blocks   Id  System
>  /dev/sde1          0       -       0          0    0  Empty
>  /dev/sde2          0       -       0          0    0  Empty
>  /dev/sde3          0       -       0          0    0  Empty
>  /dev/sde4   *      0+     95      96-     98288    6  FAT16
>  
>  [root@estreet ~]# mount /dev/sde4 /mnt
>  mount: you must specify the filesystem type
>  
>  [root@estreet ~]# mount -t vfat /dev/sde4 /mnt
>  mount: /dev/sde4: can't read superblock
>  
>  ---------- Some of the error messages from /var/log/messages ----------
>  Jul 28 15:02:23 estreet kernel: attempt to access beyond end of device
>  Jul 28 15:02:23 estreet kernel: sde: rw=0, want=196392, limit=1
>  Jul 28 15:02:23 estreet kernel: printk: 36 messages suppressed.
>  Jul 28 15:02:23 estreet kernel: Buffer I/O error on device sde4,
>  logical block 24544
>  Jul 28 15:02:23 estreet kernel: attempt to access beyond end of device
>  Jul 28 15:02:23 estreet kernel: sde: rw=0, want=196392, limit=1
>  Jul 28 15:02:23 estreet kernel: Buffer I/O error on device sde4,
>  logical block 24544
>   
What log messages do you get when you insert a disk in the drive
after booting without one? Also, what does /proc/scsi/scsi list the
drive as? From what you are reporting, it does not sounds like it is
being detected as a removable hard drive.

I do not have an IDE ZIP drive handy to test with. On the USB ZIP
drive, I get this after inserting a disk:
Jul 31 17:44:47 asus kernel: sd 3:0:0:0: [sdb] Spinning up disk....ready
Jul 31 17:44:47 asus kernel: sd 3:0:0:0: [sdb] 196608 512-byte
hardware sectors (101 MB)
Jul 31 17:44:47 asus kernel: sd 3:0:0:0: [sdb] Write Protect is off
Jul 31 17:44:47 asus kernel: sd 3:0:0:0: [sdb] Assuming drive cache:
write through
Jul 31 17:44:47 asus kernel: sd 3:0:0:0: [sdb] 196608 512-byte
hardware sectors (101 MB)
Jul 31 17:44:47 asus kernel: sd 3:0:0:0: [sdb] Write Protect is off
Jul 31 17:44:47 asus kernel: sd 3:0:0:0: [sdb] Assuming drive cache:
write through
Jul 31 17:44:47 asus kernel:  sdb: sdb4

I would expect something like that when a disk is inserted in an IDE
ZIP drive as well. If not, you could try to re-scan the SCSI bus the
ZIP drive is on. There is a script to do this at
http://www.garloff.de/kurt/linux/rescan-scsi-bus.sh-1.25 but I have
not had to use it. If you try it, let us know how it works. If it
lets you mount the drive, it should give the developers the clues
needed to fix the problem.

Mikkel
-- 

  Do not meddle in the affairs of dragons,
for thou art crunchy and taste good with Ketchup!