2007-01-16 13:39:56

by Turbo Fredriksson

[permalink] [raw]
Subject: 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 -----
root@pegasos:~# cfdisk -P s /dev/sda
Partition Table for /dev/sda

First Last
# Type Sector Sector Offset Length Filesystem Type (ID) Flag
-- ------- ----------- ----------- ------ ----------- -------------------- ----
1 Primary 0 781417664 63 781417665 Linux raid auto (FD) None
root@pegasos:~# cfdisk -P s /dev/sdb
Partition Table for /dev/sdb

First Last
# Type Sector Sector Offset Length Filesystem Type (ID) Flag
-- ------- ----------- ----------- ------ ----------- -------------------- ----
1 Primary 0 781417664 63 781417665 Linux raid auto (FD) None
root@pegasos:~# 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, 20480000, 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.
root@pegasos:~# 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 <device>

root@pegasos:~# 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

root@pegasos:~# dmesg | tail -n1
[154695.371073] EXT3-fs: sdb1: couldn't mount because of unsupported optional features (20000).
----- s n i p -----

I tried using fdisk instead. Note that fdisk finds a different
partition table than cfdisk above!

----- s n i p -----
root@pegasos:~# fdisk -l /dev/sdb
/dev/sdb
# type name length base ( size ) system
/dev/sdb1 Apple_partitiooma}amamamamamama Apple 63 @ 1 ( 31.5k) Unknown
/dev/sdb2 Apple_gee_e_e_e_e_e_ o%G�%@~%G�%@o%G�%@.%G�%@.%G�%@.%G�%@.%G�%@ 781434611 @ 781397715 (372.6G) Unknown

Block size=512, Number of Blocks=781422768
DeviceType=0x0, DeviceId=0x0

root@pegasos:~# dd if=/dev/zero of=/dev/sdb count=10000
10000+0 records in
10000+0 records out
5120000 bytes (5.1 MB) copied, 0.366181 seconds, 14.0 MB/s
root@pegasos:~# fdisk -l /dev/sdb
root@pegasos:~# cfdisk -P s /dev/sdb
FATAL ERROR: No partition table.

=> [fdisk /dev/sdb and chooses 'initialize partition map'] <=
root@pegasos:~# fdisk -l /dev/sdb
/dev/sdb
# type name length base ( size ) system
/dev/sdb1 Apple_partitmooma}amamamamamama Apple 63 @ 1 ( 31.5k) Unknown
/dev/sdb2 Apple_gee_e_e_e_e_e_ o%G�%@~%G�%@o%G�%@.%G�%@.%G�%@.%G�%@.%G�%@ 781434611 @ 781397715 (372.6G) Unknown

Block size=512, Number of Blocks=781422768
DeviceType=0x0, DeviceId=0x0

root@pegasos:~# cfdisk -P s /dev/sdb
FATAL ERROR: No partition table.

=> [fdisk /dev/sdb and deletes both partitions (!!)] <=
root@pegasos:~# fdisk -l /dev/sdb
/dev/sdb
# type name length base ( size ) system
/dev/sdb1 Apple_Free Extra 63 @ 1 ( 31.5k) Free space
/dev/sdb2 Apple_gee_e_e_e_e_e_ o%G�%@~%G�%@o%G�%@.%G�%@.%G�%@.%G�%@.%G�%@ 781434611 @ 781397715 (372.6G) Unknown

Block size=512, Number of Blocks=781422768
DeviceType=0x0, DeviceId=0x0

=> [in the syslog during the fdisk sessions:] <=
root@pegasos:~# 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: [154926.817515] sdb: [mac] sdb1 sdb2
Jan 16 07:15:59 localhost kernel: [154926.987204] printk: 292503 messages suppressed.
Jan 16 07:15:59 localhost kernel: [154926.987230] Buffer I/O error on device sdb2, logical block 781434368
Jan 16 07:15:59 localhost kernel: [154926.987238] Buffer I/O error on device sdb2, logical block 781434369
Jan 16 07:15:59 localhost kernel: [154926.987245] Buffer I/O error on device sdb2, logical block 781434370
Jan 16 07:15:59 localhost kernel: [154926.987252] Buffer I/O error on device sdb2, logical block 781434371
Jan 16 07:15:59 localhost kernel: [154926.987258] Buffer I/O error on device sdb2, logical block 781434372
Jan 16 07:15:59 localhost kernel: [154926.987265] Buffer I/O error on device sdb2, logical block 781434373
Jan 16 07:15:59 localhost kernel: [154926.987272] Buffer I/O error on device sdb2, logical block 781434374
Jan 16 07:15:59 localhost kernel: [154926.987279] Buffer I/O error on device sdb2, logical block 781434375
Jan 16 07:15:59 localhost kernel: [154926.988530] Buffer I/O error on device sdb2, logical block 781434368
Jan 16 07:15:59 localhost kernel: [154926.988538] Buffer I/O error on device sdb2, logical block 781434369
Jan 16 07:16:00 localhost kernel: [154927.448100] SMB connection re-established (-5)
Jan 16 07:16:01 localhost kernel: [154928.859934] SCSI device sdb: 781422768 512-byte hdwr sectors (400088 MB)
Jan 16 07:16:01 localhost kernel: [154928.865115] SCSI device sdb: drive cache: write back
Jan 16 07:16:01 localhost kernel: [154928.865381] sdb: [mac] sdb1 sdb2
Jan 16 07:17:01 localhost /USR/SBIN/CRON[4826]: (root) CMD ( run-parts --report /etc/cron.hourly)
Jan 16 07:17:41 localhost kernel: [155028.253528] SCSI device sdb: 781422768 512-byte hdwr sectors (400088 MB)
Jan 16 07:17:41 localhost kernel: [155028.259334] SCSI device sdb: drive cache: write back
Jan 16 07:17:41 localhost kernel: [155028.259613] sdb: [mac] sdb1 sdb2
Jan 16 07:17:41 localhost kernel: [155028.377550] printk: 254 messages suppressed.
Jan 16 07:17:41 localhost kernel: [155028.377577] Buffer I/O error on device sdb2, logical block 781434368
Jan 16 07:17:41 localhost kernel: [155028.377586] Buffer I/O error on device sdb2, logical block 781434369
Jan 16 07:17:41 localhost kernel: [155028.377593] Buffer I/O error on device sdb2, logical block 781434370
Jan 16 07:17:41 localhost kernel: [155028.377600] Buffer I/O error on device sdb2, logical block 781434371
Jan 16 07:17:41 localhost kernel: [155028.377606] Buffer I/O error on device sdb2, logical block 781434372
Jan 16 07:17:41 localhost kernel: [155028.377613] Buffer I/O error on device sdb2, logical block 781434373
Jan 16 07:17:41 localhost kernel: [155028.377620] Buffer I/O error on device sdb2, logical block 781434374
Jan 16 07:17:41 localhost kernel: [155028.377627] Buffer I/O error on device sdb2, logical block 781434375
Jan 16 07:17:41 localhost kernel: [155028.379062] Buffer I/O error on device sdb2, logical block 781434368
Jan 16 07:17:41 localhost kernel: [155028.379073] Buffer I/O error on device sdb2, logical block 781434369
Jan 16 07:17:43 localhost kernel: [155030.273386] SCSI device sdb: 781422768 512-byte hdwr sectors (400088 MB)
Jan 16 07:17:43 localhost kernel: [155030.279303] SCSI device sdb: drive cache: write back
Jan 16 07:17:43 localhost kernel: [155030.279591] sdb: [mac] sdb1 sdb2
----- s n i p -----

Note that I don't get a pip in the logs if I do a dd from /dev/zero to /dev/sdb
and the full length/size of the disk. Also not a word about I/O errors when
mkfs'ing the disk...
This when using cfdisk to partition the disk! I only get that when I'm using
the MAC table (!?).


If I use cfdisk to create ONE partition, but which starts a couple of megs
in (cfdisk say the disk is exactly 400085.84Mb so if I create a partition
that's 400000Mb and which is located at the _end_ of the disk), then the
partition isn't found!

----- s n i p -----
cfdisk 2.12r

Disk Drive: /dev/sdb
Size: 400088457216 bytes, 400.0 GB
Heads: 255 Sectors per Track: 63 Cylinders: 48641

Name Flags Part Type FS Type [Label] Size (MB)
------------------------------------------------------------------------------
Pri/Log Free Space 82.26
sdb1 Primary Linux 400003.60
[... quit ...]
root@pegasos:~# cfdisk -P s /dev/sdb
FATAL ERROR: Bad primary partition 0: Partition ends after end-of-disk
----- s n i p -----

I also saw this 'after end-of-disk' problem earlier (can't reproduce it now
though). When I used 'less -f /dev/sdb' (didn't have any partitions then)
less stopped after a few bytes. Also 'dd if=/dev/sdb | hexdump -c' stopped
after only a few lines/bytes.

The whole reason I found out that something was seriosly wrong with this/it
was that I could not do a 'pvcreate' on the disk (choosed to use disk, not
partition):

----- s n i p -----
root@pegasos:~# pvcreate /dev/sdb
Physical volume "/dev/sdb" successfully created
root@pegasos:~# pvscan
PV /dev/md0 VG movies lvm2 [372.61 GB / 0 free]
PV /dev/hdb lvm2 [74.53 GB]
Total: 2 [447.14 GB] / in use: 1 [372.61 GB] / in no VG: 1 [74.53 GB]
----- s n i p -----

If/when I get sdb working, it will become the degraded md1 which I could
vgcreate togheter with md0 which is now mounted. Md1 is also a degraded
mirror - containing only sda - which is an identical disk as sdb.

The smallest 'Free Space' I can create (see above) seems to be 8.23Mb
and that doesn't show 'Partition ends after end-of-disk' but still
shows the same 'unsupported optional features' in the logs...
Next step(s) is: 16.46, 24.68, 32.91, 41.13. At 41.13, I get (in syslog)
'sdb: unknown partition table' so somewhere between 32.91Mb and 41.13Mb
there's something "weird" (sorry, but I have NO idea how else to describe
it :).


Just in case someone wonders/cares about the two decraded mirrors... I
can't afford 4 400Gb disk at the moment, but I don't want to lock myself
into a corner (or complicate matters like have to move data back and forth)
when I DO afford more disk. I could just add disk(s) to the mirrors...
Guess I could do that with LVM to, but I don't have much experience
with LVM at the moment, but I do know md quite well...


2007-01-16 14:20:10

by Ken Moffat

[permalink] [raw]
Subject: 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.

> root@pegasos:~# 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, 20480000, 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.
> root@pegasos:~# 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 <device>
>

> root@pegasos:~# dmesg | tail -n1
> [154695.371073] EXT3-fs: sdb1: couldn't mount because of unsupported optional features (20000).
> ----- s n i p -----
>
> I tried using fdisk instead. Note that fdisk finds a different
> partition table than cfdisk above!
>
> ----- s n i p -----
> root@pegasos:~# fdisk -l /dev/sdb
> /dev/sdb
> # type name length base ( size ) system
> /dev/sdb1 Apple_partitiooma}amamamamamama Apple 63 @ 1 ( 31.5k) Unknown
> /dev/sdb2 Apple_gee_e_e_e_e_e_ o%G�%@~%G�%@o%G�%@.%G�%@.%G�%@.%G�%@.%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
>
> root@pegasos:~# dd if=/dev/zero of=/dev/sdb count=10000
> 10000+0 records in
> 10000+0 records out
> 5120000 bytes (5.1 MB) copied, 0.366181 seconds, 14.0 MB/s
> root@pegasos:~# fdisk -l /dev/sdb
> root@pegasos:~# 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

2007-01-17 10:06:43

by Turbo Fredriksson

[permalink] [raw]
Subject: 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 400000'):

Jan 17 11:03:41 localhost kernel: [254985.117447] EXT2-fs: sdb1: couldn't mount RDWR because of unsupported optional features (10000).


The 'unsupported optional features' number keeps changing... ?

2007-01-17 11:45:36

by Erik Mouw

[permalink] [raw]
Subject: 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 400000'):
>
> Jan 17 11:03:41 localhost kernel: [254985.117447] EXT2-fs: sdb1: couldn't mount RDWR because of unsupported optional features (10000).

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 -- http://www.harddisk-recovery.com -- +31 70 370 12 90 --
| Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands

2007-01-18 00:18:44

by Ken Moffat

[permalink] [raw]
Subject: 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 Apple 63 @ 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

2007-01-20 20:09:29

by Turbo Fredriksson

[permalink] [raw]
Subject: 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: <20070118001838.GA340@deepthought> (Ken Moffat's message of
"Thu, 18 Jan 2007 00:18:38 +0000")
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