Re: Weird harddisk behaviour
when there is no longer anything to take away. -- Antoine de Saint-Exupery Date: Sat, 20 Jan 2007 20:58:17 +0100 In-Reply-To: <[EMAIL PROTECTED]> (Ken Moffat's message of "Thu, 18 Jan 2007 00:18:38 +") Message-ID: <[EMAIL PROTECTED]> User-Agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/20.7 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Quoting Ken Moffat <[EMAIL PROTECTED]>: > So, you were using a valid tool, but what you put in your original > mail shows garbage - something like apple_partition_ma[mamama... That's what fdisk showed me. I don't have a true UTF-8 system, so when cutting-and-pasing between the shell and mail app, it might have been distorted. But the output WAS weird! > But if it isn't, somehow the data on the disk (or the data being > read from it) is corrupt. So how come it got corrupt? I did a 'dd if=/dev/zero of=/dev/sdb' (and waited for the whole disk to be zeroed - took HOURS! :). Then partitioned the disk and cut-and-pasted the output into the mail... EVERY time I check the partition table (using mac-fdisk and not cfdisk), that destorted output is shown. It's not distorted/corrupt if I use cfdisk though... Since I don't exactly know how to do all this with the tools in Linux, I took the disk to my girlfriends WinXP and is currently using 'OnTrack EasyRecorvery Professional - ERP' to do scanns and tests of the disk. I tried parition and format it there to, but the format failed (no reason why). I'm currently running the extended S.M.A.R.T. test. And there where other tests I could do to... I'll let you know. One weird thing though... ERP only found it as a 137Mb disk! It's supposed to be a 400Gb... -- Ft. Bragg ammonium genetic Ortega Nazi Uzi FSF Cocaine North Korea Cuba Delta Force Qaddafi Treasury kibo Marxist [See http://www.aclu.org/echelonwatch/index.html for more about this] [Or http://www.europarl.eu.int/tempcom/echelon/pdf/rapport_echelon_en.pdf] If neither of these works, try http://www.aclu.org and search for echelon. Note. This is a real, not fiction. http://www.theregister.co.uk/2001/09/06/eu_releases_echelon_spying_report/ http://www.aclu.org/safefree/nsaspying/23989res20060131.html#echelon - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Weird harddisk behaviour
On Wed, Jan 17, 2007 at 11:09:21AM +0100, Turbo Fredriksson wrote: > Quoting Ken Moffat <[EMAIL PROTECTED]>: > > > Certainly, fdisk from util-linux doesn't know about mac disks, and > > I thought the same was true for cfdisk and sfdisk. Many years ago > > there was mac-fdisk, I think also known as pdisk, but nowadays the > > common tool for partitioning mac disks is probably parted. > > Yes. See now that 'fdisk' is a softlink to 'mac-fdisk'... > Sorry for not replying earlier, cutting the Cc: list on lkml is not always conducive to quick replies. So, you were using a valid tool, but what you put in your original mail shows garbage - something like apple_partition_ma[mamama... followed later by some garbage which could admittedly have been UTF-8 getting trashed in the mail. I'm on my ibook at the moment, which has an old debian mac-fdisk on another partition. If I chroot to that and look at the disk I see things like /dev/hda #type name length base ( size ) system /dev/hda1 Apple_partition_map Apple63 @ 1( 31.5k) Partition map /dev/hda2 Apple_Bootstrap untitled 1954 @ 64 (977.0k) NewWorld bootblock and so forth. Notice that everything there is in legible ascii and can be read with sensible values. If what you actually see is similar, then it's just a problem in the mail. But if it isn't, somehow the data on the disk (or the data being read from it) is corrupt. ĸen -- das eine Mal als Tragödie, das andere Mal als Farce - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Weird harddisk behaviour
On Wed, Jan 17, 2007 at 11:09:21AM +0100, Turbo Fredriksson wrote: > Quoting Ken Moffat <[EMAIL PROTECTED]>: > > Certainly, fdisk from util-linux doesn't know about mac disks, and > > I thought the same was true for cfdisk and sfdisk. Many years ago > > there was mac-fdisk, I think also known as pdisk, but nowadays the > > common tool for partitioning mac disks is probably parted. > > Yes. See now that 'fdisk' is a softlink to 'mac-fdisk'... > > > Please try parted. > > Same thing ('mkpartfs primary ext2 0 40'): > > Jan 17 11:03:41 localhost kernel: [254985.117447] EXT2-fs: sdb1: couldn't > mount RDWR because of unsupported optional features (1). I don't know if any of those tools tell the kernel that the partition table changedand that it has to reread them. To be sure the kernel knows, run "blockdev --rereadpt /dev/sdb". Erik -- +-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 -- | Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Weird harddisk behaviour
Quoting Ken Moffat <[EMAIL PROTECTED]>: > On Tue, Jan 16, 2007 at 02:27:06PM +0100, Turbo Fredriksson wrote: >> A couple of weeks ago my 400Gb SATA disk crashed. I just >> got the replacement, but I can't seem to be able to create >> a filesystem on it! >> >> This is a PPC (Pegasos), running 2.6.15-27-powerpc (Ubuntu Dapper >> v2.6.15-27.50). > Hi Turbo, > > I think you have mac partitions (the first item is the partition > map itself - very different from the dos partitions common on x86). > > Certainly, fdisk from util-linux doesn't know about mac disks, and > I thought the same was true for cfdisk and sfdisk. Many years ago > there was mac-fdisk, I think also known as pdisk, but nowadays the > common tool for partitioning mac disks is probably parted. Yes. See now that 'fdisk' is a softlink to 'mac-fdisk'... > Please try parted. Same thing ('mkpartfs primary ext2 0 40'): Jan 17 11:03:41 localhost kernel: [254985.117447] EXT2-fs: sdb1: couldn't mount RDWR because of unsupported optional features (1). The 'unsupported optional features' number keeps changing... ? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Weird harddisk behaviour
On Tue, Jan 16, 2007 at 02:27:06PM +0100, Turbo Fredriksson wrote: > A couple of weeks ago my 400Gb SATA disk crashed. I just > got the replacement, but I can't seem to be able to create > a filesystem on it! > > This is a PPC (Pegasos), running 2.6.15-27-powerpc (Ubuntu Dapper > v2.6.15-27.50). Hi Turbo, I think you have mac partitions (the first item is the partition map itself - very different from the dos partitions common on x86). Certainly, fdisk from util-linux doesn't know about mac disks, and I thought the same was true for cfdisk and sfdisk. Many years ago there was mac-fdisk, I think also known as pdisk, but nowadays the common tool for partitioning mac disks is probably parted. > [EMAIL PROTECTED]:~# mke2fs -v -j /dev/sdb1 > mke2fs 1.38 (30-Jun-2005) > Filesystem label= > OS type: Linux > Block size=4096 (log=2) > Fragment size=4096 (log=2) > 48840704 inodes, 97677200 blocks > 4883860 blocks (5.00%) reserved for the super user > First data block=0 > 2981 block groups > 32768 blocks per group, 32768 fragments per group > 16384 inodes per group > Superblock backups stored on blocks: > 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, > 2654208, > 4096000, 7962624, 11239424, 2048, 23887872, 71663616, 78675968 > > Writing inode tables: done > Creating journal (32768 blocks): done > Writing superblocks and filesystem accounting information: done > > This filesystem will be automatically checked every 36 mounts or > 180 days, whichever comes first. Use tune2fs -c or -i to override. > [EMAIL PROTECTED]:~# e2fsck /dev/sdb1 > e2fsck 1.38 (30-Jun-2005) > e2fsck: Filesystem revision too high while trying to open /dev/sdb1 > The filesystem revision is apparently too high for this version of e2fsck. > (Or the filesystem superblock is corrupt) > > > The superblock could not be read or does not describe a correct ext2 > filesystem. If the device is valid and it really contains an ext2 > filesystem (and not swap or ufs or something else), then the superblock > is corrupt, and you might try running e2fsck with an alternate superblock: > e2fsck -b 8193 > > [EMAIL PROTECTED]:~# dmesg | tail -n1 > [154695.371073] EXT3-fs: sdb1: couldn't mount because of unsupported optional > features (2). > - s n i p - > > I tried using fdisk instead. Note that fdisk finds a different > partition table than cfdisk above! > > - s n i p - > [EMAIL PROTECTED]:~# fdisk -l /dev/sdb > /dev/sdb > #type name length base ( > size ) system > /dev/sdb1Apple_partitiooma}amamamamamama Apple 63 @ 1 > ( 31.5k) Unknown > /dev/sdb2Apple_gee_e_e_e_e_e_ [EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL > PROTECTED]@.%G�%@ 781434611 @ 781397715 (372.6G) Unknown > Well, that certainly looks like an apple partition map has been there at some time - you definitely can't use fdisk from util-linux on it. > Block size=512, Number of Blocks=781422768 > DeviceType=0x0, DeviceId=0x0 > > [EMAIL PROTECTED]:~# dd if=/dev/zero of=/dev/sdb count=1 > 1+0 records in > 1+0 records out > 512 bytes (5.1 MB) copied, 0.366181 seconds, 14.0 MB/s > [EMAIL PROTECTED]:~# fdisk -l /dev/sdb > [EMAIL PROTECTED]:~# cfdisk -P s /dev/sdb > FATAL ERROR: No partition table. > And I think that just says that cfdisk is looking for a dos partition table. Please try parted. Ken -- das eine Mal als Tragödie, das andere Mal als Farce - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Weird harddisk behaviour
A couple of weeks ago my 400Gb SATA disk crashed. I just got the replacement, but I can't seem to be able to create a filesystem on it! This is a PPC (Pegasos), running 2.6.15-27-powerpc (Ubuntu Dapper v2.6.15-27.50). - s n i p - [EMAIL PROTECTED]:~# cfdisk -P s /dev/sda Partition Table for /dev/sda First Last # Type Sector Sector OffsetLength Filesystem Type (ID) Flag -- --- --- --- -- --- 1 Primary 0 781417664 63 781417665 Linux raid auto (FD) None [EMAIL PROTECTED]:~# cfdisk -P s /dev/sdb Partition Table for /dev/sdb First Last # Type Sector Sector OffsetLength Filesystem Type (ID) Flag -- --- --- --- -- --- 1 Primary 0 781417664 63 781417665 Linux raid auto (FD) None [EMAIL PROTECTED]:~# mke2fs -v -j /dev/sdb1 mke2fs 1.38 (30-Jun-2005) Filesystem label= OS type: Linux Block size=4096 (log=2) Fragment size=4096 (log=2) 48840704 inodes, 97677200 blocks 4883860 blocks (5.00%) reserved for the super user First data block=0 2981 block groups 32768 blocks per group, 32768 fragments per group 16384 inodes per group Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 4096000, 7962624, 11239424, 2048, 23887872, 71663616, 78675968 Writing inode tables: done Creating journal (32768 blocks): done Writing superblocks and filesystem accounting information: done This filesystem will be automatically checked every 36 mounts or 180 days, whichever comes first. Use tune2fs -c or -i to override. [EMAIL PROTECTED]:~# e2fsck /dev/sdb1 e2fsck 1.38 (30-Jun-2005) e2fsck: Filesystem revision too high while trying to open /dev/sdb1 The filesystem revision is apparently too high for this version of e2fsck. (Or the filesystem superblock is corrupt) The superblock could not be read or does not describe a correct ext2 filesystem. If the device is valid and it really contains an ext2 filesystem (and not swap or ufs or something else), then the superblock is corrupt, and you might try running e2fsck with an alternate superblock: e2fsck -b 8193 [EMAIL PROTECTED]:~# mount /dev/sdb1 /mnt/sdb mount: wrong fs type, bad option, bad superblock on /dev/sdb1, missing codepage or other error In some cases useful info is found in syslog - try dmesg | tail or so [EMAIL PROTECTED]:~# dmesg | tail -n1 [154695.371073] EXT3-fs: sdb1: couldn't mount because of unsupported optional features (2). - s n i p - I tried using fdisk instead. Note that fdisk finds a different partition table than cfdisk above! - s n i p - [EMAIL PROTECTED]:~# fdisk -l /dev/sdb /dev/sdb #type name length base ( size ) system /dev/sdb1Apple_partitiooma}amamamamamama Apple 63 @ 1 ( 31.5k) Unknown /dev/sdb2Apple_gee_e_e_e_e_e_ [EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@.%G�%@ 781434611 @ 781397715 (372.6G) Unknown Block size=512, Number of Blocks=781422768 DeviceType=0x0, DeviceId=0x0 [EMAIL PROTECTED]:~# dd if=/dev/zero of=/dev/sdb count=1 1+0 records in 1+0 records out 512 bytes (5.1 MB) copied, 0.366181 seconds, 14.0 MB/s [EMAIL PROTECTED]:~# fdisk -l /dev/sdb [EMAIL PROTECTED]:~# cfdisk -P s /dev/sdb FATAL ERROR: No partition table. => [fdisk /dev/sdb and chooses 'initialize partition map'] <= [EMAIL PROTECTED]:~# fdisk -l /dev/sdb /dev/sdb #type name length base ( size ) system /dev/sdb1Apple_partitmooma}amamamamamama Apple 63 @ 1 ( 31.5k) Unknown /dev/sdb2Apple_gee_e_e_e_e_e_ [EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@.%G�%@ 781434611 @ 781397715 (372.6G) Unknown Block size=512, Number of Blocks=781422768 DeviceType=0x0, DeviceId=0x0 [EMAIL PROTECTED]:~# cfdisk -P s /dev/sdb FATAL ERROR: No partition table. => [fdisk /dev/sdb and deletes both partitions (!!)] <= [EMAIL PROTECTED]:~# fdisk -l /dev/sdb /dev/sdb #type name length base ( size ) system /dev/sdb1 Apple_Free Extra 63 @ 1 ( 31.5k) Free space /dev/sdb2Apple_gee_e_e_e_e_e_ [EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@.%G�%@ 781434611 @ 781397715 (372.6G) Unknown Block size=512, Number of Blocks=781422768 DeviceType=0x0, DeviceId=0x0 => [in the syslog during the fdisk sessions:] <= [EMAIL PROTECTED]:~# tail -f /var/log/syslog -n0 Jan 16 07:15:59 localhost kernel: [154926.816696] SCSI device sdb: 781422768 512-byte hdwr sectors (400088 MB) Jan 16 07:15:59 localhost kernel: [154926.817340] SCSI device sdb: drive cache: write back Jan 16 07:15:59 localhost kernel: [1549