Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

How to run fsck on an image made with dd_rescue?

2,271 views
Skip to first unread message

Torfinn Ingolfsen

unread,
Jun 2, 2011, 8:22:37 AM6/2/11
to
I made an image of a partition on a failing hard drive with dd_rescue[1].
According to dd_rescue output, the operation went well:
root@kg-vm# dd_rescue -v /dev/da0s1f /storage/web-usr-hd.image
dd_rescue: (info): about to transfer 0.0 kBytes from /dev/da0s1f to
/storage/web-usr-hd.image
dd_rescue: (info): blocksizes: soft 65536, hard 512
dd_rescue: (info): starting positions: in 0.0k, out 0.0k
dd_rescue: (info): Logfile: (none), Maxerr: 0
dd_rescue: (info): Reverse: no , Trunc: no , interactive: no
dd_rescue: (info): abort on Write errs: no , spArse write: if err
dd_rescue: (info): ipos: 95216640.0k, opos: 95216640.0k, xferd:
95216640.0k
errs: 0, errxfer: 0.0k, succxfer:
95216640.0k
+curr.rate: 22627kB/s, avg.rate: 26328kB/s,
avg.load: 4.8%

dd_rescue: (info): problems at ipos 95217152.0k: Unknown error: 0
fall back to smaller blocksize
dd_rescue: (info): ipos: 95217152.0k, opos: 95217152.0k, xferd:
95217152.0k
* errs: 0, errxfer: 0.0k, succxfer:
95217152.0k
+curr.rate: 30kB/s, avg.rate: 26204kB/s,
avg.load: 4.8%

dd_rescue: (info): read /dev/da0s1f (95217184.0k): EOF
dd_rescue: (info): Summary for /dev/da0s1f -> /storage/web-usr-hd.image:
dd_rescue: (info): ipos: 95217184.0k, opos: 95217184.0k, xferd:
95217184.0k
errs: 0, errxfer: 0.0k, succxfer:
95217184.0k
+curr.rate: 7kB/s, avg.rate: 26171kB/s,
avg.load: 4.8%

And I can mount the image:
root@kg-vm# mdconfig -f /storage/web-usr-hd.image
md0
root@kg-vm# mount /dev/md0 /media
root@kg-vm# df -h /media
Filesystem Size Used Avail Capacity Mounted on
/dev/md0 102G 3.5G 90G 4% /media

But when I try to copy files from it, there are errors (missing files).
So I thought why not run fsck on the image?
Unmounted it, then tried:
root@kg-vm# fsck_ufs -y /dev/md0
** /dev/md0

CANNOT READ BLK: 220542432
CONTINUE? yes

THE FOLLOWING DISK SECTORS COULD NOT BE READ: 220542432, 220542433,
220542434, 220542435,
ioctl (GCINFO): Inappropriate ioctl for device
fsck_ufs: /dev/md0: can't read disk label

So, how do I run fsck on a file that is an image of a hard disk partition?

References:
1) http://www.freshports.org/sysutils/dd_rescue/
--
Torfinn Ingolfsen,
Norway

Lowell Gilbert

unread,
Jun 3, 2011, 2:44:57 PM6/3/11
to
Torfinn Ingolfsen <ti...@home.no> writes:

> So I thought why not run fsck on the image?
> Unmounted it, then tried:
> root@kg-vm# fsck_ufs -y /dev/md0
> ** /dev/md0
>
> CANNOT READ BLK: 220542432
> CONTINUE? yes
>
> THE FOLLOWING DISK SECTORS COULD NOT BE READ: 220542432, 220542433,
> 220542434, 220542435,
> ioctl (GCINFO): Inappropriate ioctl for device
> fsck_ufs: /dev/md0: can't read disk label
>
> So, how do I run fsck on a file that is an image of a hard disk partition?

That's exactly how you're supposed to do it.
Are those sector numbers legitimate?

--
Lowell Gilbert, embedded/networking software engineer
http://be-well.ilk.org/~lowell/

Torfinn Ingolfsen

unread,
Jun 3, 2011, 5:55:53 PM6/3/11
to
On 06/03/2011 20:44, Lowell Gilbert wrote:
> Torfinn Ingolfsen<ti...@home.no> writes:
>
>> So I thought why not run fsck on the image?
>> Unmounted it, then tried:
>> root@kg-vm# fsck_ufs -y /dev/md0
>> ** /dev/md0
>>
>> CANNOT READ BLK: 220542432
>> CONTINUE? yes
>>
>> THE FOLLOWING DISK SECTORS COULD NOT BE READ: 220542432, 220542433,
>> 220542434, 220542435,
>> ioctl (GCINFO): Inappropriate ioctl for device
>> fsck_ufs: /dev/md0: can't read disk label
>>
>> So, how do I run fsck on a file that is an image of a hard disk partition?
>
> That's exactly how you're supposed to do it.
> Are those sector numbers legitimate?

I don't know. How do I tell? This is what dumpfs thinks (partial output):
root@kg-vm# dumpfs /dev/md0 | more
magic 19540119 (UFS2) time Thu Jun 2 01:40:53 2011
superblock location 65536 id [ 49d2865f 7fbf3e0c ]
ncg 587 size 55218144 blocks 53480579
bsize 16384 shift 14 mask 0xffffc000
fsize 2048 shift 11 mask 0xfffff800
frag 8 shift 3 fsbtodb 2
minfree 8% optim time symlinklen 120
maxbsize 16384 maxbpg 2048 maxcontig 8 contigsumsize 8
nbfree 6439732 ndir 40681 nifree 13558487 nffree 116824
bpg 11761 fpg 94088 ipg 23552 unrefs 0
nindir 2048 inopb 64 maxfilesize 140806241583103
sbsize 2048 cgsize 16384 csaddr 3000 cssize 10240
sblkno 40 cblkno 48 iblkno 56 dblkno 3000
cgrotor 430 fmod 0 ronly 0 clean 0
avgfpdir 64 avgfilesize 16384
flags unclean soft-updates
fsmnt /media
volname swuid 0

Is that helpful?
--
Torfinn Ingolfsen,
Norway

Mike Scott

unread,
Jun 4, 2011, 7:02:36 AM6/4/11
to
On 03/06/11 19:44, Lowell Gilbert wrote:
> Torfinn Ingolfsen<ti...@home.no> writes:
>
>> So I thought why not run fsck on the image?
>> Unmounted it, then tried:
>> root@kg-vm# fsck_ufs -y /dev/md0
>> ** /dev/md0
>>
>> CANNOT READ BLK: 220542432
>> CONTINUE? yes
>>
>> THE FOLLOWING DISK SECTORS COULD NOT BE READ: 220542432, 220542433,
>> 220542434, 220542435,
>> ioctl (GCINFO): Inappropriate ioctl for device
>> fsck_ufs: /dev/md0: can't read disk label
>>
>> So, how do I run fsck on a file that is an image of a hard disk partition?
>
> That's exactly how you're supposed to do it.
> Are those sector numbers legitimate?
>

I have wondered whether dd_rescue creates a sparse file when the source
data cannot be read; in which case fsck would presumably have a hard
time of it. I vaguely remember similar symptoms to this when trying to
recover a damaged floppy, although that problem is still pending :-)

--
Mike Scott (unet2 <at> [deletethis] scottsonline.org.uk)
Harlow Essex England

Torfinn Ingolfsen

unread,
Jun 4, 2011, 8:17:14 AM6/4/11
to
On 06/04/2011 01:02 PM, Mike Scott wrote:
>
> I have wondered whether dd_rescue creates a sparse file when the source
> data cannot be read; in which case fsck would presumably have a hard
> time of it. I vaguely remember similar symptoms to this when trying to
> recover a damaged floppy, although that problem is still pending :-)

Possibly. From http://www.garloff.de/kurt/linux/ddrescue/
"Copying this partition with normal Un*x tools like cat or dd will fail,
as those tools abort on error. dd_rescue instead will try to read and if
it fails, it will go on with the next sectors. The output file naturally
will have holes in it, of course. You can write a log file, to see,
where all these errors are located."

I just thought that dd_rescue would notice any errors in its normal output.

Maybe I should retry dd_rescue, this time with the log file option.

--
Torfinn Ingolfsen,
Norway

Gordon Burditt

unread,
Jun 12, 2011, 8:27:48 PM6/12/11
to
>>> THE FOLLOWING DISK SECTORS COULD NOT BE READ: 220542432, 220542433,
>>> 220542434, 220542435,

Aren't those sector numbers out of range for the size of the disk?

> I have wondered whether dd_rescue creates a sparse file when the source
> data cannot be read; in which case fsck would presumably have a hard
> time of it.

I would expect that if dd_rescue creates a sparse file when the
source data cannot be read, fsck would have an *EASIER* and *FASTER*
time reading nonexistent blocks of all zeroes. This is what sparse
files are supposed to do when read. Unwritten blocks read as 0
bytes, and they don't require a disk access to do it. If, however,
dd_rescue replaces unreadable sectors with random crap (nobody would
write it that way), I'd expect a *LOT* of references to out-of-range
block numbers.

I have a similar program I wrote a long time ago, then to rescue
damaged floppies, but it works also on CDROMs and hard drive
partitions.

I once created a very large filesystem (at least gigabytes) as a
file on a floppy disk. (Floppy capacity: 1.2Mbytes) It would fsck
fine.

A little bit of garbage, even one flipped bit, written into an inode
or indirect block could have fsck attempting to read blocks beyond
the limits of the partition. I suspect this is what is happening
here. I've also seen it happen on hard disk partitions that did
*NOT* have bad sectors, but suffered from manually patching the
wrong block.

I suspect that those errors will go away after you have cleared
either one inode or one block worth of inodes.

Torfinn Ingolfsen

unread,
Jun 16, 2011, 5:31:19 PM6/16/11
to
On 06/04/2011 14:17, Torfinn Ingolfsen wrote:
> I just thought that dd_rescue would notice any errors in its normal output.
>
> Maybe I should retry dd_rescue, this time with the log file option.

Ok, I retried dd_rescue tonight:
root@kg-vm# dd_rescue -v -l /storage/web-usr-hd2.log.txt -o
/storage/web-usr-hd2.bb.txt /dev/da0s1f /storage/web-usr-hd2.image


dd_rescue: (info): about to transfer 0.0 kBytes from /dev/da0s1f to

/storage/web-usr-hd2.image


dd_rescue: (info): blocksizes: soft 65536, hard 512
dd_rescue: (info): starting positions: in 0.0k, out 0.0k

dd_rescue: (info): Logfile: /storage/web-usr-hd2.log.txt, Maxerr: 0


dd_rescue: (info): Reverse: no , Trunc: no , interactive: no
dd_rescue: (info): abort on Write errs: no , spArse write: if err
dd_rescue: (info): ipos: 95216640.0k, opos: 95216640.0k, xferd:
95216640.0k
errs: 0, errxfer: 0.0k, succxfer:
95216640.0k

+curr.rate: 22943kB/s, avg.rate: 22206kB/s,
avg.load: 3.7%

dd_rescue: (info): problems at ipos 95217152.0k: Unknown error: 0
fall back to smaller blocksize
dd_rescue: (info): ipos: 95217152.0k, opos: 95217152.0k, xferd:
95217152.0k
* errs: 0, errxfer: 0.0k, succxfer:
95217152.0k

+curr.rate: 35kB/s, avg.rate: 22132kB/s,
avg.load: 3.7%

dd_rescue: (info): read /dev/da0s1f (95217184.0k): EOF

dd_rescue: (info): Summary for /dev/da0s1f -> /storage/web-usr-hd2.image:


dd_rescue: (info): ipos: 95217184.0k, opos: 95217184.0k, xferd:
95217184.0k
errs: 0, errxfer: 0.0k, succxfer:
95217184.0k

+curr.rate: 7kB/s, avg.rate: 22108kB/s,
avg.load: 3.7%

the log file just contains a copy of the screen output:
root@kg-vm# more /storage/web-usr-hd2.log.txt


dd_rescue: (info): about to transfer 0.0 kBytes from /dev/da0s1f to

/storage/web-usr-hd2.image


dd_rescue: (info): blocksizes: soft 65536, hard 512
dd_rescue: (info): starting positions: in 0.0k, out 0.0k

dd_rescue: (info): Logfile: /storage/web-usr-hd2.log.txt, Maxerr: 0


dd_rescue: (info): Reverse: no , Trunc: no , interactive: no
dd_rescue: (info): abort on Write errs: no , spArse write: if err

dd_rescue: (info): about to transfer 0.0 kBytes from /dev/da0s1f to

/storage/web-usr-hd2.image


dd_rescue: (info): about to transfer 0.0 kBytes from /dev/da0s1f to

/storage/web-usr-hd2.image


dd_rescue: (info): blocksizes: soft 65536, hard 512
dd_rescue: (info): blocksizes: soft 65536, hard 512
dd_rescue: (info): starting positions: in 0.0k, out 0.0k
dd_rescue: (info): starting positions: in 0.0k, out 0.0k

dd_rescue: (info): Logfile: /storage/web-usr-hd2.log.txt, Maxerr: 0
dd_rescue: (info): Logfile: /storage/web-usr-hd2.log.txt, Maxerr: 0


dd_rescue: (info): Reverse: no , Trunc: no , interactive: no
dd_rescue: (info): Reverse: no , Trunc: no , interactive: no
dd_rescue: (info): abort on Write errs: no , spArse write: if err
dd_rescue: (info): abort on Write errs: no , spArse write: if err

dd_rescue: (info): ipos: 95217152.0k, opos: 95217152.0k, xferd:
95217152.0k
* errs: 0, errxfer: 0.0k, succxfer:
95217152.0k

+curr.rate: 35kB/s, avg.rate: 22132kB/s,
avg.load: 3.7%

dd_rescue: (info): read /dev/da0s1f (95217184.0k): EOF

dd_rescue: (info): Summary for /dev/da0s1f -> /storage/web-usr-hd2.image:


dd_rescue: (info): ipos: 95217184.0k, opos: 95217184.0k, xferd:
95217184.0k
errs: 0, errxfer: 0.0k, succxfer:
95217184.0k

+curr.rate: 7kB/s, avg.rate: 22108kB/s,
avg.load: 3.7%

and there is no file with error block numbers in (possibly because
dd_rescue didn't find / notice any errors):
root@kg-vm# ls -lh /storage
total 95263732
drwxrwxr-x 2 root operator 512B Jun 1 21:07 .snap
-rw-r----- 1 root wheel 91G Jun 16 23:01 web-usr-hd2.image
-rw-r----- 1 root wheel 1.8K Jun 16 23:01 web-usr-hd2.log.txt

More after I try to rund fsck on this image.
--
Torfinn Ingolfsen,
Norway

Torfinn Ingolfsen

unread,
Jun 16, 2011, 5:38:58 PM6/16/11
to
On 06/16/2011 23:31, Torfinn Ingolfsen wrote:
> More after I try to rund fsck on this image.

fsck results:
root@kg-vm# mdconfig -f /storage/web-usr-hd2.image
md0


root@kg-vm# fsck_ufs -y /dev/md0
** /dev/md0

CANNOT READ BLK: 220542432
CONTINUE? yes

THE FOLLOWING DISK SECTORS COULD NOT BE READ: 220542432, 220542433,
220542434, 220542435,
ioctl (GCINFO): Inappropriate ioctl for device
fsck_ufs: /dev/md0: can't read disk label

Ok, so that is exactly the same blocks as the last time.
Now, if I only knew what to patch and / or clear...
--
Torfinn Ingolfsen,
Norway

Torfinn Ingolfsen

unread,
Jun 16, 2011, 5:41:53 PM6/16/11
to
On 06/13/2011 02:27, Gordon Burditt wrote:
> I suspect that those errors will go away after you have cleared
> either one inode or one block worth of inodes.

Two questions pop up:
a) how do I figure out which inodes and / or blocks to clear?
b) how do I do this (ie. which tool do I use?)
--
Torfinn Ingolfsen,
Norway

Torfinn Ingolfsen

unread,
Jun 16, 2011, 5:59:37 PM6/16/11
to

partial dumpfs output:
root@kg-vm# dumpfs /dev/md0 | more
magic 19540119 (UFS2) time Tue May 24 01:10:00 2011


superblock location 65536 id [ 49d2865f 7fbf3e0c ]
ncg 587 size 55218144 blocks 53480579
bsize 16384 shift 14 mask 0xffffc000
fsize 2048 shift 11 mask 0xfffff800
frag 8 shift 3 fsbtodb 2
minfree 8% optim time symlinklen 120
maxbsize 16384 maxbpg 2048 maxcontig 8 contigsumsize 8
nbfree 6439732 ndir 40681 nifree 13558487 nffree 116824
bpg 11761 fpg 94088 ipg 23552 unrefs 0
nindir 2048 inopb 64 maxfilesize 140806241583103
sbsize 2048 cgsize 16384 csaddr 3000 cssize 10240
sblkno 40 cblkno 48 iblkno 56 dblkno 3000
cgrotor 430 fmod 0 ronly 0 clean 0
avgfpdir 64 avgfilesize 16384
flags unclean soft-updates

fsmnt /usr

Ahem A Rivet's Shot

unread,
Jun 16, 2011, 5:52:33 PM6/16/11
to

At this stage I'd be inclined to mount it read only and copy the
data off with cpdup or similar.

--
Steve O'Hara-Smith | Directable Mirror Arrays
C:>WIN | A better way to focus the sun
The computer obeys and wins. | licences available see
You lose and Bill collects. | http://www.sohara.org/

Torfinn Ingolfsen

unread,
Jun 16, 2011, 6:02:23 PM6/16/11
to
On 06/16/2011 23:38, Torfinn Ingolfsen wrote:
>
> fsck results:
> root@kg-vm# mdconfig -f /storage/web-usr-hd2.image
> md0
> root@kg-vm# fsck_ufs -y /dev/md0
> ** /dev/md0
>
> CANNOT READ BLK: 220542432
> CONTINUE? yes
>
> THE FOLLOWING DISK SECTORS COULD NOT BE READ: 220542432, 220542433,
> 220542434, 220542435,
> ioctl (GCINFO): Inappropriate ioctl for device
> fsck_ufs: /dev/md0: can't read disk label
>
> Ok, so that is exactly the same blocks as the last time.

If I try to use the alternate superblock, fsck gets further.
Like this:
root@kg-vm# fsck_ufs -y -b 160 /dev/md0
[lots of output snipped]
UPDATE STANDARD SUPERBLOCK? yes

WRITING ZERO'ED BLOCK 220542464 TO DISK

UNEXPECTED SOFT UPDATE INCONSISTENCY

CANNOT WRITE BLK: 220542464
UNEXPECTED SOFT UPDATE INCONSISTENCY

CONTINUE? yes

THE FOLLOWING SECTORS COULD NOT BE WRITTEN: 220542464, 220542465,
220542466, 220542467, 220542468, 220542469, 220542470, 220542471,
220542472, 220542473, 220542474, 220542475, 220542476, 220542477,
220542478, 220542479, 220542480, 220542481, 220542482, 220542483,
220542484, 220542485, 220542486, 220542487, 220542488, 220542489,
220542490, 220542491, 220542492, 220542493, 220542494, 220542495,
WRITING ZERO'ED BLOCK 190450044 TO DISK

UNEXPECTED SOFT UPDATE INCONSISTENCY

CANNOT WRITE BLK: 190450044
UNEXPECTED SOFT UPDATE INCONSISTENCY

CONTINUE? yes

THE FOLLOWING SECTORS COULD NOT BE WRITTEN: 190450044, 190450045,
190450046, 190450047,

***** FILE SYSTEM MARKED DIRTY *****

***** FILE SYSTEM WAS MODIFIED *****

***** PLEASE RERUN FSCK *****

But no matter how many times I re-run fsck, it still says the same.
--
Torfinn Ingolfsen,
Norway

Bob Eager

unread,
Jun 16, 2011, 6:16:33 PM6/16/11
to
On Thu, 16 Jun 2011 23:41:53 +0200, Torfinn Ingolfsen wrote:

> On 06/13/2011 02:27, Gordon Burditt wrote:
>> I suspect that those errors will go away after you have cleared either
>> one inode or one block worth of inodes.
>
> Two questions pop up:
> a) how do I figure out which inodes and / or blocks to clear?

Dunno.

> b) how do
> I do this (ie. which tool do I use?)

clri


--
Using UNIX since v6 (1976)...

Use the BIG mirror service in the UK:
http://www.mirrorservice.org

Robert Bonomi

unread,
Jun 19, 2011, 8:00:39 AM6/19/11
to
In article <4dfa77f2$1...@news.broadpark.no>,

fsck_ufs is apparently telling fiction. It claims a read error at block
220,542,432 on a filesystem with just over than 190,000,000 blocks in it.

I have a _nasty_suspicion_ that this filesystem was on a 'BSD slice' in a
fdisk partition, where the slice was -not- at the beginning of the fdisk
partition.

IIRC, filesystem metadata uses 'absolute' block numbers within the fdisk
partition, with lower-/upper-bounds checks to ensure staying within the
limits of the filesystem. (As distinct from using 'relative' block numbers
_within_ the 'slice', where only an upper-bounds check is needed)

On that basis, it appears the size of the filesystem is somewhere around 95
gigabytes, plus/minus uncertainties for "1024 vs. 1000" multiplier counting.
With an apparent approximate 30 gigs (same uncertainties), at least, before
that filesystem on the logical disk (partition).

*IF*THIS*IS*CORRECT*, when you mount the slice image as a 'virtual disk',
there _is_ a mismatch between the 'absolute' block references internal to
the image, and the 'relative' offsets in the image file.

Now, _if_ the above is an accurate description of what's going on, then
one may need to make a rescue image of the _entire_ fdisk partition,
not just the BSD slice, mount the -partition- copy as 'md0', and then
fsck the _slice_ (something like '/dev/md0d') to fix errors.

CAVEAT: I have _not_ dug into any of this on FreeBSD specifically. I base
this on some experiences with _other_ versions of Unix, on other architectures.

Torfinn Ingolfsen

unread,
Jun 19, 2011, 9:09:42 AM6/19/11
to
On 06/19/2011 14:00, Robert Bonomi wrote:
> fsck_ufs is apparently telling fiction. It claims a read error at block
> 220,542,432 on a filesystem with just over than 190,000,000 blocks in it.
>
> I have a _nasty_suspicion_ that this filesystem was on a 'BSD slice' in a
> fdisk partition, where the slice was -not- at the beginning of the fdisk
> partition.

No need for suspicions, this is exactly the case, and was shown in my
first post:


root@kg-vm# dd_rescue -v /dev/da0s1f /storage/web-usr-hd.image

As you can see, this is partition f on slice 1 on that disk.

> IIRC, filesystem metadata uses 'absolute' block numbers within the fdisk
> partition, with lower-/upper-bounds checks to ensure staying within the
> limits of the filesystem. (As distinct from using 'relative' block numbers
> _within_ the 'slice', where only an upper-bounds check is needed)

Interesting.

> On that basis, it appears the size of the filesystem is somewhere around 95
> gigabytes, plus/minus uncertainties for "1024 vs. 1000" multiplier counting.
> With an apparent approximate 30 gigs (same uncertainties), at least, before
> that filesystem on the logical disk (partition).

The filesystem is about 102G:


root@kg-vm# df -h /media
Filesystem Size Used Avail Capacity Mounted on

/dev/md0 102G 3.1G 91G 3% /media


> *IF*THIS*IS*CORRECT*, when you mount the slice image as a 'virtual disk',
> there _is_ a mismatch between the 'absolute' block references internal to
> the image, and the 'relative' offsets in the image file.
>
> Now, _if_ the above is an accurate description of what's going on, then
> one may need to make a rescue image of the _entire_ fdisk partition,
> not just the BSD slice, mount the -partition- copy as 'md0', and then
> fsck the _slice_ (something like '/dev/md0d') to fix errors.

Good suggestions. I will try that.

> CAVEAT: I have _not_ dug into any of this on FreeBSD specifically. I base
> this on some experiences with _other_ versions of Unix, on other architectures.

Interesting information - thank you.
--
Torfinn Ingolfsen,
Norway

Torfinn Ingolfsen

unread,
Jun 19, 2011, 1:14:16 PM6/19/11
to
On 06/19/2011 02:00 PM, Robert Bonomi wrote:
> Now, _if_ the above is an accurate description of what's going on, then
> one may need to make a rescue image of the _entire_ fdisk partition,
> not just the BSD slice, mount the -partition- copy as 'md0', and then
> fsck the _slice_ (something like '/dev/md0d') to fix errors.

So I tried this, used dd_rescue to make an image of the whole slice:
root@kg-vm# dd_rescue -v -l /storage/web-usr-hd3.log.txt -o
/storage/web-usr-hd3.bb.txt /dev/da0s1 /storage/web-usr-hd3.image
dd_rescue: (info): about to transfer 0.0 kBytes from /dev/da0s1 to
/storage/web-usr-hd3.image


dd_rescue: (info): blocksizes: soft 65536, hard 512
dd_rescue: (info): starting positions: in 0.0k, out 0.0k

dd_rescue: (info): Logfile: /storage/web-usr-hd3.log.txt, Maxerr: 0


dd_rescue: (info): Reverse: no , Trunc: no , interactive: no
dd_rescue: (info): abort on Write errs: no , spArse write: if err

dd_rescue: (info): ipos: 101998592.0k, opos: 101998592.0k, xferd:
101998592.0k


errs: 0, errxfer: 0.0k, succxfer:

101998592.0k
+curr.rate: 22813kB/s, avg.rate: 22418kB/s,
avg.load: 3.8%

dd_rescue: (info): problems at ipos 101999104.0k: Unknown error: 0


fall back to smaller blocksize

dd_rescue: (info): ipos: 101999104.0k, opos: 101999104.0k, xferd:
101999104.0k


* errs: 0, errxfer: 0.0k, succxfer:

101999104.0k
+curr.rate: 43kB/s, avg.rate: 22360kB/s,
avg.load: 3.8%

dd_rescue: (info): read /dev/da0s1 (101999136.0k): EOF
dd_rescue: (info): Summary for /dev/da0s1 -> /storage/web-usr-hd3.image:
dd_rescue: (info): ipos: 101999136.0k, opos: 101999136.0k, xferd:
101999136.0k


errs: 0, errxfer: 0.0k, succxfer:

101999136.0k
+curr.rate: 8kB/s, avg.rate: 22341kB/s,
avg.load: 3.8%

Which got me an image file with all the partitions in it:
root@kg-vm# mdconfig -f /storage/web-usr-hd3.image
md0
root@kg-vm# ls /dev/md0*
/dev/md0 /dev/md0a /dev/md0b /dev/md0d /dev/md0e /dev/md0f

So let's run fsck on the 'f' partition:
root@kg-vm# fsck_ufs -y /dev/md0f
** /dev/md0f

CANNOT READ BLK: 220542432
CONTINUE? yes

THE FOLLOWING DISK SECTORS COULD NOT BE READ: 220542432, 220542433,
220542434, 220542435,
ioctl (GCINFO): Inappropriate ioctl for device

fsck_ufs: /dev/md0f: can't read disk label

OK, let's try with the alternate superblock:
it ends like this:
UPDATE STANDARD SUPERBLOCK? yes

WRITING ZERO'ED BLOCK 220542464 TO DISK

UNEXPECTED SOFT UPDATE INCONSISTENCY

CANNOT WRITE BLK: 220542464
UNEXPECTED SOFT UPDATE INCONSISTENCY

CONTINUE? yes

THE FOLLOWING SECTORS COULD NOT BE WRITTEN: 220542464, 220542465,
220542466, 220542467, 220542468, 220542469, 220542470, 220542471,
220542472, 220542473, 220542474, 220542475, 220542476, 220542477,
220542478, 220542479, 220542480, 220542481, 220542482, 220542483,
220542484, 220542485, 220542486, 220542487, 220542488, 220542489,
220542490, 220542491, 220542492, 220542493, 220542494, 220542495,

***** FILE SYSTEM MARKED DIRTY *****

***** FILE SYSTEM WAS MODIFIED *****

***** PLEASE RERUN FSCK *****

It seems to me like making an image out of the whole slice didn't make a
difference.
--
Torfinn Ingolfsen,
Norway

0 new messages