Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 28 Nov 2011 08:02:55 -0700 (MST)
From:      Warren Block <>
To:        Robert <>
Cc:        "Julian H. Stacey" <>,
Subject:   Re: Invalid fdisk partition table found (fwd)
Message-ID:  <>
In-Reply-To: <20111128055529.2cd89955@dell64>
References:  <> <20111124113938.2d99eec2@dell64> <> <20111125095457.477e9501@dell64> <> <20111126135557.56f4ea06@dell64> <> <20111128055529.2cd89955@dell64>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help
On Mon, 28 Nov 2011, Robert wrote:

> Thanks for hanging in there with me. I am about ready to give up, but
> here is where everything stands now.

Before giving up, a few more suggestions.  First, check the BIOS 
settings.  It's possible the computer has a BIOS that "protects" the 
boot block from viruses by making it read-only.  Second, sudo is not the 
same as being root, there are differences.  So I'd also suggest trying 
these as root, just in case.

> [robert@dell64] ~> gpart destroy -F da1
> da1 destroyed
> [robert@dell64] ~> sudo gpart create -s mbr da1
> Password:
> da1 created
> [robert@dell64] ~> sudo gpart add -t "\!11" da1
> da1s1 added
> [robert@dell64] ~> gpart show da1
> =>   32  60448  da1  MBR  (29M)
>     32  60448    1  fat32  (29M)
> [robert@dell64] ~> newfs_msdos -F32 /dev/da1s1
> /dev/da1s1: 60296 sectors in 7537 FAT32 clusters (4096 bytes/cluster)
> BytesPerSec=512 SecPerClust=8 ResSectors=32 FATs=2 Sectors=60448
> Media=0xf0 SecPerTrack=32 Heads=64 HiddenSecs=0 FATsecs=59
> RootCluster=2 FSInfo=1 Backup=2
> [robert@dell64] ~> sudo mount_msdosfs /dev/da1s1 /mnt
> mount_msdosfs: /dev/da1s1: Invalid argument

That's odd.  da1s1 went away after being formatted.  Have these cards 
been heavily used to the point where they may be failing?

If the card is failing, I'd expect there to be something in 
/var/log/messages.  For that matter, even sysutils/smartmontools might 
work on these.

> [robert@dell64] ~> fdisk /dev/da1

Something I noticed when testing yesterday: fdisk results may not agree 
with gpart until the card has been reconnected.  In particular fdisk 
showed the single FAT32 partition as the last instead of the first.

> ******* Working on device /dev/da1 *******
> parameters extracted from in-core disklabel are:
> cylinders=29 heads=64 sectors/track=32 (2048 blks/cyl)
> parameters to be used for BIOS calculations are:
> cylinders=29 heads=64 sectors/track=32 (2048 blks/cyl)
> fdisk: invalid fdisk partition table found

> [robert@dell64] ~> sudo gpart destroy da1
> Password:
> gpart: Device busy

gpart won't destroy a GEOM unless it's unused.  So either delete all the 
partitions first, or use 'gpart destroy -F'.

Interesting that here the partition still exists, though.

> [robert@dell64] ~> dd if=/dev/null of=/dev/da1
> 0+0 records in
> 0+0 records out
> 0 bytes transferred in 0.000018 secs (0 bytes/sec)

This didn't write anything (0+0 records).  Should be
   dd if=/dev/zero of=/dev/da1 bs=512 count=35

count=35 to make sure MBR/disklabel or primary GPT are wiped out.

> It acts like there is some sort of write protect on sector 1

This is what made me think of a BIOS virus-protect mentioned above. 
Hopefully that's the problem.

> or the cards are defective.

It's worth contacting the manufacturer.  Maybe they have a reset or 
reformat program.  If you do get to the point of discarding the cards, 
I'd be interested in experimenting on them.

Want to link to this message? Use this URL: <>