Loading ...
Sorry, an error occurred while loading the content.

Problem with usb mass storage

Expand Messages
  • Chu Tan
    I ve problem mounting my USB harddrive. PROBLEM: bash-2.05b# mount -t vfat /dev/sda1 /mnt/usbdrv/ mount: /dev/sda1 is not a valid block device ADDITIONAL INFO:
    Message 1 of 10 , Oct 9, 2004
    • 0 Attachment
      I've problem mounting my USB harddrive.

      PROBLEM:
      bash-2.05b# mount -t vfat /dev/sda1 /mnt/usbdrv/
      mount: /dev/sda1 is not a valid block device

      ADDITIONAL INFO:
      If I do cat /dev/sda I will get raw data from drive.
      If I do cat /dev/sda1 The output is
      cat: /dev/sda1: No such device or address

      By using fdisk -l I am able to list the partitions in the drive.

      Disk /dev/sda: 122.9 GB, 122941341696 bytes
      255 heads, 63 sectors/track, 14946 cylinders
      Units = cylinders of 16065 * 512 = 8225280 bytes

      Device Boot Start End Blocks Id System
      /dev/sda1 ? 1 14593 117218241 c W95 FAT32 (LBA)

      My kernel is compiled with legacy /proc/scsi support, scsi disk
      support, scsi generic support, probe all luns on each scsi device.

      cat /proc/scsi/scsi
      Host: scsi0 Channel: 00 Id: 00 Lun: 00
      Vendor: Maxtor Model: 3000LE v01.00.00 Rev: 0100
      Type: Direct-Access ANSI SCSI revision: 02

      I have run scandisk on the drive using windows, and no problem is found.
    • Chu Tan
      Update: I thought something is wrong with the partition tables, as if I unplug and plug in the usb drive, I get the following dmesg usb 1-3: new high speed USB
      Message 2 of 10 , Oct 9, 2004
      • 0 Attachment
        Update:

        I thought something is wrong with the partition tables, as if I unplug
        and plug in the usb drive, I get the following dmesg

        usb 1-3: new high speed USB device using address 5
        scsi2 : SCSI emulation for USB Mass Storage devices
        Vendor: Maxtor Model: 3000LE v01.00.00 Rev: 0100
        Type: Direct-Access ANSI SCSI revision: 02
        SCSI device sda: 240119808 512-byte hdwr sectors (122941 MB)
        sda: assuming drive cache: write through
        sda: unknown partition table
        ^^^^^^^^^^^^^^^^^^^^^^^
        Attached scsi disk sda at scsi2, channel 0, id 0, lun 0
        Attached scsi generic sg0 at scsi2, channel 0, id 0, lun 0, type 0
        USB Mass Storage device found at 5

        So I ran fdisk /dev/sda and 'w' to rewrite the partition tables. I get
        the following message:

        The partition table has been altered!

        Calling ioctl() to re-read partition table.

        WARNING: Re-reading the partition table failed with error 5:
        Input/output error.The kernel still uses the old table.
        The new table will be used at the next reboot.
        Syncing disks.


        Is my HD broken?
      • Horror Vacui
        On Sat, 09 Oct 2004 18:25:21 -0000 ... Ok, so the kernel doesn t know about this partition table type. Now, I have no clue about USB drives and don t know if
        Message 3 of 10 , Oct 9, 2004
        • 0 Attachment
          On Sat, 09 Oct 2004 18:25:21 -0000
          Chu wrote:

          >
          > Update:
          >
          > I thought something is wrong with the partition tables, as if I unplug
          > and plug in the usb drive, I get the following dmesg
          >
          > usb 1-3: new high speed USB device using address 5
          > scsi2 : SCSI emulation for USB Mass Storage devices
          > Vendor: Maxtor Model: 3000LE v01.00.00 Rev: 0100
          > Type: Direct-Access ANSI SCSI revision: 02
          > SCSI device sda: 240119808 512-byte hdwr sectors (122941 MB)
          > sda: assuming drive cache: write through
          > sda: unknown partition table
          > ^^^^^^^^^^^^^^^^^^^^^^^

          Ok, so the kernel doesn't know about this partition table type. Now, I
          have no clue about USB drives and don't know if there's a special
          partition table type for them, or it's one you created with another OS,
          but that's where you need to start solving the problem. Find out which
          partition table type it is, and compile a kernel capable of working with
          it, or - as you already tried - find out how to use one that your kernel
          already knows.

          > Attached scsi disk sda at scsi2, channel 0, id 0, lun 0
          > Attached scsi generic sg0 at scsi2, channel 0, id 0, lun 0, type 0
          > USB Mass Storage device found at 5
          >
          > So I ran fdisk /dev/sda and 'w' to rewrite the partition tables. I get
          > the following message:
          >
          > The partition table has been altered!
          >
          > Calling ioctl() to re-read partition table.
          >
          > WARNING: Re-reading the partition table failed with error 5:
          > Input/output error.The kernel still uses the old table.
          > The new table will be used at the next reboot.
          > Syncing disks.

          I assume you know that rewriting the partition tables usually (or
          always?) means you'll lose the data on that disk.

          Have you tried rebooting (though I think it would have been enough to
          unplug and plug in the drive)? Rebooting the system is sometimes
          necessary after altering the partition table.

          > Is my HD broken?

          It's possible, but I don't think it is.

          Cheers

          --
          Horror Vacui

          Registered Linux user #257714

          Go get yourself... counted: http://counter.li.org/
          - and keep following the GNU.
        • Michael Kjorling
          ... Hash: SHA1 ... It does not. /Changing/ the partition table, however, very often results in what appears to be loss of data (while in reality it is only
          Message 4 of 10 , Oct 9, 2004
          • 0 Attachment
            -----BEGIN PGP SIGNED MESSAGE-----
            Hash: SHA1

            2004-10-09 21:56, horrorvacui@... wrote in <20041009215636.6f875d1e.horrorvacui@...>:
            > I assume you know that rewriting the partition tables usually (or
            > always?) means you'll lose the data on that disk.

            It does not. /Changing/ the partition table, however, very often
            results in what appears to be loss of data (while in reality it is
            only loss of metadata) when the partition boundaries move around and
            thus critical parts of the file systems are not physically present
            where the kernel expects them to be. Simply starting fdisk on the
            device and telling it to rewrite what it just read off the disk should
            not change anything at all.

            I would start out with the message saying that the kernel doesn't
            understand the partition table, and if I can't figure it out that way
            would write down the physical alignment numbers (CHS or LBA address
            plus partition size and type - everything except the type down to the
            sector), clear out the partition table and then recreate it. I believe
            GNU parted will let you do this kind of low-level stuff without
            fussing, if good old fdisk won't. Once that is done, run a decent file
            system checker - ScanDisk has never been known to find more than the
            most obvious problems. Back when I was still running DOS, Norton Disk
            Doctor quite often uncovered a lot of problems on disks ScanDisk gave
            a clean bill of health...

            All this knowing, of course, that one false step or a single digit
            copied incorrectly when recreating the partition table may very well
            cost you the data on the disk.

            - --
            Michael Kjörling, michael@... - http://michael.kjorling.com/
            OpenPGP Fingerprint: 3723 9372 c245 d6a8 18a6 36ac 758F8749 BDE9ADA6
            * ASCII Ribbon Campaign: Against HTML Mail, Proprietary Attachments *
            * No bird soars too high if he soars with his own wings. -*- SM0YBY *

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

            iD8DBQFBaEaGdY+HSb3praYRAjPPAJwPnADk3rMV2WgZFxOHQmfC+QJhXwCZAUUg
            XFT749GtGKjiJfAXoPX6+zc=
            =APty
            -----END PGP SIGNATURE-----
          • Chu Tan
            Here s what I ve done. 1st, I use dd to write out the partition table to my harddrive, in case something goes wrong. Then, I copy down all the specifications
            Message 5 of 10 , Oct 9, 2004
            • 0 Attachment
              Here's what I've done.

              1st, I use dd to write out the partition table to my harddrive, in
              case something goes wrong.

              Then, I copy down all the specifications of the drive as listed in fdisk.

              Then I do a dd to zero out the MBR.

              Then use FDISK to recreate the partition table according to what I
              had, and write to the drive.

              It works! :)

              > I would start out with the message saying that the kernel doesn't
              > understand the partition table, and if I can't figure it out that way
              > would write down the physical alignment numbers (CHS or LBA address
              > plus partition size and type - everything except the type down to the
              > sector), clear out the partition table and then recreate it. I believe
              > GNU parted will let you do this kind of low-level stuff without
              > fussing, if good old fdisk won't. Once that is done, run a decent file
              > system checker - ScanDisk has never been known to find more than the
              > most obvious problems. Back when I was still running DOS, Norton Disk
              > Doctor quite often uncovered a lot of problems on disks ScanDisk gave
              > a clean bill of health...
              >
              > All this knowing, of course, that one false step or a single digit
              > copied incorrectly when recreating the partition table may very well
              > cost you the data on the disk.
              >
              > - --
              > Michael Kjörling, michael@k... - http://michael.kjorling.com/
              > OpenPGP Fingerprint: 3723 9372 c245 d6a8 18a6 36ac 758F8749 BDE9ADA6
              > * ASCII Ribbon Campaign: Against HTML Mail, Proprietary Attachments *
              > * No bird soars too high if he soars with his own wings. -*- SM0YBY *
              >
              > -----BEGIN PGP SIGNATURE-----
              > Version: GnuPG v1.2.3 (GNU/Linux)
              >
              > iD8DBQFBaEaGdY+HSb3praYRAjPPAJwPnADk3rMV2WgZFxOHQmfC+QJhXwCZAUUg
              > XFT749GtGKjiJfAXoPX6+zc=
              > =APty
              > -----END PGP SIGNATURE-----
            • Ed
              ... Hash: SHA1 On Sun, 10 Oct 2004 05:25:34 -0000 ... Could you have done; dd if=/dev/sda1 of=./partition_data so that when you recreate the partitions you can
              Message 6 of 10 , Oct 10, 2004
              • 0 Attachment
                -----BEGIN PGP SIGNED MESSAGE-----
                Hash: SHA1

                On Sun, 10 Oct 2004 05:25:34 -0000
                "Chu Tan" <ztan@...> wrote:

                > Here's what I've done.
                >
                > 1st, I use dd to write out the partition table to my harddrive, in
                > case something goes wrong.
                >
                > Then, I copy down all the specifications of the drive as listed in
                > fdisk.
                >
                > Then I do a dd to zero out the MBR.
                >
                > Then use FDISK to recreate the partition table according to what I
                > had, and write to the drive.

                Could you have done;

                dd if=/dev/sda1 of=./partition_data

                so that when you recreate the partitions you can then copy the data that
                is inside sda1 to the new patition and not loose data.

                - --
                Ed. Debian 3. OpenBSD 3.5. Two things came out of berkeley: BSD and
                LSD. I don't think this is a coincidence.
                PGP KeyID 04EDACDA A0F3 44E9 C367 C6C1 C891 4C71 69AF 3CF5 04ED ACDA
                You can't cross a chasm in two small jumps.
                -----BEGIN PGP SIGNATURE-----
                Version: GnuPG v1.2.5 (GNU/Linux)

                iD8DBQFBaRACaa889QTtrNoRArmSAJ4wkgd/8I7qYyzDtWJM7HCglMy5+QCg7AI5
                La5LugTsDKVETGeUYmRh340=
                =M2Ke
                -----END PGP SIGNATURE-----
              • Chu Tan
                ... That might be possible. But I ve never tried. Why not just back up that partition in that case? However, I got the following from the internet, and it
                Message 7 of 10 , Oct 10, 2004
                • 0 Attachment
                  > Could you have done;
                  >
                  > dd if=/dev/sda1 of=./partition_data
                  >
                  > so that when you recreate the partitions you can then copy the data that
                  > is inside sda1 to the new patition and not loose data.

                  That might be possible. But I've never tried. Why not just back up
                  that partition in that case?

                  However, I got the following from the internet, and it works when I
                  tried restoring the MBR image from my harddisk.

                  http://www.linux-consulting.com/Boot/Boot.Clear.MBR.txt

                  # back up
                  dd if=/dev/hda of=~/mbr.bin bs=512 count=1
                  # zero it. clear
                  dd if=/dev/zero of=/dev/hda bs=512 count=1
                • Ed
                  ... Hash: SHA1 On Sun, 10 Oct 2004 23:50:21 -0000 ... It just zeros the disk. I cant see what good it is after that is done, you will have to repartition it
                  Message 8 of 10 , Oct 11, 2004
                  • 0 Attachment
                    -----BEGIN PGP SIGNED MESSAGE-----
                    Hash: SHA1

                    On Sun, 10 Oct 2004 23:50:21 -0000
                    "Chu Tan" <ztan@...> wrote:

                    > # back up
                    > dd if=/dev/hda of=~/mbr.bin bs=512 count=1
                    > # zero it. clear
                    > dd if=/dev/zero of=/dev/hda bs=512 count=1

                    It just zeros the disk. I cant see what good it is after that is done,
                    you will have to repartition it and the contents is lost as what you
                    backed is exactly what you just zeroed, so to restore it you have to put
                    the disk back to its erroneous state.

                    - --
                    Ed. Debian 3. OpenBSD 3.5. Two things came out of berkeley: BSD and
                    LSD. Don't think this a coincidence. Can't cross chasm in small jumps
                    PGP KeyID 04EDACDA A0F3 44E9 C367 C6C1 C891 4C71 69AF 3CF5 04ED ACDA
                    -----BEGIN PGP SIGNATURE-----
                    Version: GnuPG v1.2.5 (GNU/Linux)

                    iD8DBQFBamP6aa889QTtrNoRApE5AKDd7IEhrplAoMOqWSeQWdDY1FYuqgCfXR4t
                    T3oCoE1LjV9DDKQhfXW5A4U=
                    =6GRn
                    -----END PGP SIGNATURE-----
                  • Michael Kjorling
                    ... Hash: SHA1 ... No, no, no and no. Check your dd manpage if you don t believe me. The above command zeroes out the first 512 bytes on the device, which is
                    Message 9 of 10 , Oct 11, 2004
                    • 0 Attachment
                      -----BEGIN PGP SIGNED MESSAGE-----
                      Hash: SHA1

                      2004-10-11 11:44, ed@... wrote in <20041011114410.57ad6289@debian>:
                      >> dd if=/dev/zero of=/dev/hda bs=512 count=1
                      >
                      > It just zeros the disk. I cant see what good it is after that is done,
                      > you will have to repartition it and the contents is lost as what you
                      > backed is exactly what you just zeroed, so to restore it you have to put
                      > the disk back to its erroneous state.

                      No, no, no and no. Check your dd manpage if you don't believe me. The
                      above command zeroes out the first 512 bytes on the device, which is
                      exactly where the MBR is located. Unless there is a major bug in dd,
                      this has *no* effect on the rest of the disk. Then recreating the
                      partition table using fdisk or a similar tool to enter exactly the
                      same numbers as you had before will give you back the same partition.
                      The file system will then be exactly where it is expected to be and
                      the data is readily accessible. (Even though I would personally
                      recommend a run of fsck, just to be absolutely certain, it should not
                      be strictly necessary.)

                      - --
                      Michael Kjörling, michael@... - http://michael.kjorling.com/
                      OpenPGP Fingerprint: 3723 9372 c245 d6a8 18a6 36ac 758F8749 BDE9ADA6
                      * ASCII Ribbon Campaign: Against HTML Mail, Proprietary Attachments *
                      * No bird soars too high if he soars with his own wings. -*- SM0YBY *

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

                      iD8DBQFBamqQdY+HSb3praYRAsAxAJ9/Bt27WkW3q+EKqKBkRnR4UVN9hQCfearp
                      vFxFbO+h/BeiGs9+mpNAKdA=
                      =MOIV
                      -----END PGP SIGNATURE-----
                    • Ed
                      ... Hash: SHA1 On Mon, 11 Oct 2004 13:12:16 +0200 ... Apologies I overlooked the count, please disregard my previous post in this thread. - -- Ed. Debian 3.
                      Message 10 of 10 , Oct 11, 2004
                      • 0 Attachment
                        -----BEGIN PGP SIGNED MESSAGE-----
                        Hash: SHA1

                        On Mon, 11 Oct 2004 13:12:16 +0200
                        Michael Kjorling <michael@...> wrote:

                        > No, no, no and no. Check your dd manpage if you don't believe me. The
                        > above command zeroes out the first 512 bytes on the device, which is
                        > exactly where the MBR is located.

                        Apologies I overlooked the count, please disregard my previous post in
                        this thread.

                        - --
                        Ed. Debian 3. OpenBSD 3.5. Two things came out of berkeley: BSD and
                        LSD. Don't think this a coincidence. Can't cross chasm in small jumps
                        PGP KeyID 04EDACDA A0F3 44E9 C367 C6C1 C891 4C71 69AF 3CF5 04ED ACDA
                        -----BEGIN PGP SIGNATURE-----
                        Version: GnuPG v1.2.5 (GNU/Linux)

                        iD8DBQFBamvOaa889QTtrNoRAmjwAJ9KsZfCffyxFU3Ran3CYlxRqfNzAwCgzrjg
                        viV+c3tFnjBKzlFyXSJx5Us=
                        =Qo9K
                        -----END PGP SIGNATURE-----
                      Your message has been successfully submitted and would be delivered to recipients shortly.