I actually had that naming issue myself which necessitating me doing a complete reformat and reinstall of the system. In my case, I wrote the BSD Disklabel directly down on the MBR sector. While FreeBSD is ok with it, many third party disk utilities will complain about it, and may even nuke the disklabel to install a proper partition table. This is known as a dangerously dedicated disk.
In looking at the OP's question, da0s1 indicates that he does not have a dangerously dedicated disk. So the partitions within the slice are going to be da0s1a, da0s1b, etc....
I see, indeed I knew about the distinction between writing the BSD label to then MBR, followed partitioning into slices (which I think it's equal to set BSD as partition table, then partitioning) which shall return da0a, da0b....partitions, or choosing to preserve MBR, and make lone-standing UFS partitions (da0s1, da0s2...). However I did not realize that, one can also make a separate BSD label partition inside a MBR disk, then subdivide it into slices, as you stated, which would ultimately be named da0s1a, da0s1b......so sorry
Vincent FAUQUEZ for that, Maelstrom was right and it was me having got it wrong, and not having looked at your code more carefully to get a grasp of how things stood in the first place
I have a USB storage, where I wrote the BSD label to the MBR (I'm to guess it's to be called a dangerously dedicated disk now
) and it look like that:
Code:
gpart show da0 =>
0 7954432 da0 BSD (3.8G)
0 7954432 1 freebsd-ufs (3.8G)
and as expected BSD is indicated as partition table, while the only UFS partition present is called
da0a
Now, since OP has a MBR disk, containing a lone-standing BSD label (
da0s1), which in turn hosts a single freebsd-ufs slice, then that one should be correctly named
da0s1a
Update :
Code:
newfs -N /dev/da0s1a
/dev/da0s1a: 476940.0MB (976773104 sectors) block size 32768, fragment size 4096
using 762 cylinder groups of 626.22MB, 20039 blks, 80256 inodes.
super-block backups (for fsck_ffs -b #) at:
192, 1282688, 2565184, 3847680, 5130176..............973414656, 974697152, 975979648
Code:
fsck_ufs -y -b 192 /dev/da0s1a
Alternate super block location: 192
** /dev/da0s1a better,
192 is not a file system superblock
Help will be appreciate
Regards,
Snurg made a good suggestion about cloning it to your hard drive
, however, bearing in mind bad superblocks are likely to be found, operation may be cut off in between the moment dd tries to write the bad block to output. If that happened to be the case, you can try use
sysutils/safecopy to create a raw image of your corrupted UFS partition (see
safecopy(1) for more details):
An example with increased verbosity, stronger recover attempting, and more in-depth check
safecopy /dev/da0s1a ~/ufs.img ~/ -r 5 --debug 4 --stage3
Then you should be able to make a virtual drive out of it with
mdconfig(8):
mdconfig -f ~/ufs.img -u 0
and mount it regularly:
mount -t ufs /dev/md0 /mnt
You may want to run fsck_ffs on the created image before ever creating the md drive, otherwise chances are high it will fail to mount
I 'd suggest trying specifying the other superblocks detected by
newfs -N. It's happened to me before, and second/third alternative superblock might be a FS one, even though they look way too much distant from first.
Another worthwhile try is to take the superblock location revealed by
dumpfs | grep superblock. See
dumpfs(8)
Then checking the drive for bad blocks/wrong sectors would be a good idea. I'd try both
smartctl(8) from
sysutils/smartmontools, which is noticeably better, and the deprecated
badblocks(8) from
sysutils/ef2progs, for a double-check.
First run (unless you have
smartd(8) enabled, and perform daily scheduled tests, including the external drive) :
smartctl -c /dev/da0 to display how long would it take to perform a long test (on ~400Gb should be around 90min)
Then perform a long test and wait the predicted time:
smartctl -t long /dev/da0
Look up the report for errors:
smartctl -ax /dev/ada0 | grep -i errors
Look it up for reallocated sectors as well, as wblock@ suggested in
Thread repair bad block.27507:
smartctl -ax /dev/ada0 | less -Sp Reallocated_Sector_Ct
Move to the right of the smartctl summary, and look for the value displayed under column
RAW_VALUE for the underline Reallocated-Sector row. If count is > 0, then FS is probably corrupted, and a blanking (
dd if=/dev/zero of=/dev/da0 bs=512 conv=sync; will take years on such a large drive, but 512 as blocksize is the safest bet for blanking) followed by a reformat, might be your only choice.
If smartctl does not reveals any issue, try with badblocks, although chances it will succeed where smartmontools failed are narrow:
badblocks -fnv -b=2048 /dev/da0 ....it will take a lot
To reformat your external HDD instead, with GPT:
Code:
gpart delete -i 1 da0s1
gpart delete -i 1 da0
gpart destroy da0
gpart create -s gpt da0
gpart add -t freebsd-ufs da0
newfs -U -o space /dev/da0p1
