UFS How to recover a UFS partition

The difference between partitiony types freebsd and freebsd-ufs is very important, as _martin pointed out. Using BSD disklabel(8) is very oldschool, discouraged & I strongly ask you thus you should try to remember the hardest you can if you had done that.
IIRC you can change the partion type with gpart modify -i index -t type
EDIT when you changed the partition type to freebsd-ufs, you should be able to fsck(8) that partition.
 
mark_j said:
Why was it created at the wrong start point? Did you not enter -b 358909952?
So, can you fsck -n /dev/ada0s3?

If you did not use the -b, it should have just created it from that point anyway as it found it to be free. Specifying begin point and size is only to ENSURE this is the case. Peace of mind, so to speak.
Equally, just specifying -s would get the same result. It's more a habit I got into years ago when I occasionally trashed a partition: specify beginning and size to be sure.
Click to expand...
fsck -n /dev/ada0s3:-

Can't open /dev/ada0s3: No such file or directory

Looks like my dd command didn't work correctly because of the bs= parameter. Not sure what to set it to... the default is 512, so do I need to divide 'skip' and 'count' by 512?

dd if=/dev/ada0s3 of=/mnt/install/tmp/dump skip=358909952 count=141208240 bs=???
 
balanga: Have you even tried my command I pasted ? You can set the BS command to 1. That would be probably too slow. If you leave it to default, 512, you need to divide the skip (and count) by 512 (700996).
 
_martin said:
balanga: Note you specified the bs to 2M, so skip will do the 2M*skip size. Check this little test:
Code: 
$ echo 12345678 > /tmp/a
$ dd if=/tmp/a of=/tmp/b bs=1 skip=2 count=2
$ cat /tmp/b
$ dd if=/tmp/a of=/tmp/b bs=2 skip=2 count=2
$ cat /tmp/b
You need to use the same approach.

I'm coming late to the party. If it was I who was doing the recovery of the disk I'd dd the whole disk somewhere if data is important enough for me and then start changing stuff.
Type freebsd means you subdivided the partition (slice) into subpartitions (partitions). Are you sure you had this ?

Also any chance you had hybrid MBR ? What was the device (OS) you booted when it happened?
Click to expand...
I created a FreeBSD installation on my laptop a couple of years ago after shrinking the existing the Windows partition to provide room for it. Last week when I was messing around with various OS installations on numerous USB hard disks, I found the FreeBSD partition had disappeared, so am not sure what exactly removed it. The Windows installation is intact and does work, so my immediate aim is to discover whether the underlying data in the Free space area is untouched.
 
freebsd-ufs type is for GPT schema, so I don't think it was there. freebsd could have been there, but then you need to tread carefully. This "partition" (in the MBR scheme), or "slice" in disklabel was then further subdivided. I don't know the layout from top of my head, chances are disklabel will be able to read it.
Do that dd clone first though. If not sure how even dd the whole disk before proceeding further.

Also, "messing around with installations" and "missing partition" doesn't sound good. :)

If installer created that partition chances are there are more partitions inside that slice. Just to give you an idea how single slice with one partition looks like:

The whole disk, MBR schema, one partition defined:
Code: 
# gpart show md0
=>    1  65535  md0  MBR  (32M)
      1     62       - free -  (31K)
     63  64197    1  freebsd  [active]  (31M)
  64260   1276       - free -  (638K)
This partition, used by disklabel as slice, has only one partition in:
Code: 
# gpart show md0s1
=>    0  64197  md0s1  BSD  (31M)
      0     16         - free -  (8.0K)
     16  64181      1  !0  (31M)
Looking into slice with bsdlabel:
Code: 
# bsdlabel md0s1
# /dev/md0s1:
8 partitions:
#          size     offset    fstype   [fsize bsize bps/cpg]
  a:      64181         16    unused        0     0
  c:      64197          0    unused        0     0     # "raw" part, don't edit
#
 
Agreed on that partition type. I totally forgot about MBR... For me it's all GPT for more than a decade? Then you may be able to read the BSD label with bsdlabel [-A] ada0s3. Insert -A for historic BSD disklabel; I guess that's not necessary. For that, no data copy is necessary, it can not destroy any data, since it reads only ( bsdlabel -w writes, you're not going to do that). From this you can derive the oldschool partition name like ada0s3a. Then you should be able to fsck -p /dev/ada0s3x. This, too, can not destroy any data, 100% guarantee. I see no need to copy data around (is that paranoid?). Please correct me if I'm wrong.
 
balanga said:
fsck -n /dev/ada0s3:-

Can't open /dev/ada0s3: No such file or directory
Click to expand...
Ok, so now is the 'hard'-er part. Do you know if the partition was labelled as one giant one or broken up into parts?
So can anything be read with: disklabel -e /dev/ada0s3 ??
I suspect not because we're not seeing slices like /dev/ada0s31a /dev/ada0s31e etc etc.

balanga said:
Looks like my dd command didn't work correctly because of the bs= parameter. Not sure what to set it to... the default is 512, so do I need to divide 'skip' and 'count' by 512?

dd if=/dev/ada0s3 of=/mnt/install/tmp/dump skip=358909952 count=141208240 bs=???
Click to expand...

I honestly don't know what you're trying to achieve with the dd stuff? Yes, I see you're attempting to back it up, but why?
Mucking around with the partition table doesn't affect this per se. Providing you keep the original offsets, the partition table is held prior to the block 63 on the device, so it cannot corrupt your data held in the area post 358909952 blocks.
Anyway, blocks are 512bytes.
The syntax looks fine. What's the error?

(Sorry for the edits, I'm doing too much at once and disklabel stuff is so... yesterday).
 
balanga, I don't understand why you don't just capture the whole disk image.

When poking around on disks it is easy to make a miscalculation, and damage some maybe important data.
If you have a complete image stashed away, you can start over.
If you don't have, the data might be screwed by the slightest mistake.
 
Snurg said:
balanga, I don't understand why you don't just capture the whole disk image.

When poking around on disks it is easy to make a miscalculation, and damage some maybe important data.
If you have a complete image stashed away, you can start over.
If you don't have, the data might be screwed by the slightest mistake.
Click to expand...
Snurg I have a Lenovo ThinkPad X220 which has served me well for many years. It had Windows 7 installed on a 256GB MSata disk, and I do use Windows quite a bit and it has loads of software and data on it, and I hate the idea of dabbling with Windows because something always goes wrong. I did however shrink the Windows partition and installed FreeBSD on it a few years ago. Now, as far as I'm concerned my 'free space' should still contain my FreeBSD installation so I'm hoping to copy that elsewhere and maybe recover it at some point.

Once I do copy it I'd like to examine the output and determine if it does indeed look like a FreeBSD partition.
 
_martin said:
balanga: Have you even tried my command I pasted ? You can set the BS command to 1. That would be probably too slow. If you leave it to default, 512, you need to divide the skip (and count) by 512 (700996).
Click to expand...
Eventually came up with:-

dd if=/dev/ada0 of=/mnt/install/tmp/dump skip=700996 count=141208064

After some quick maths, decided that 'count' should be used to create a file equal in size to the partition ie 67GB (141208064 * 512) ( checked using bc() - a handy little command line calculator :) )
 
Caution, that depends if you use k:=1024 or k:=1000.
bc -e '67*1024*1024*1024/512' -e quit: 140509184
Whatever, when you have copied that partition in a file, you can fsck -p `mdconfig /mnt/install/tmp/dump` & mdconfig -l, mdconfig -du 0
 
balanga: :) I did paste you the # in the above command. But good, at least now you know how to count it next time. I'd specify the bs anyway, if anything, just to be sure.
 
Mjölnir said:
Caution, that depends if you use k:=1024 or k:=1000.
bc -e '67*1024*1024*1024/512' -e quit: 140509184
Whatever, when you have copied that partition in a file, you can fsck -p `mdconfig /mnt/install/tmp/dump` & mdconfig -l, mdconfig -du 0
Click to expand...
Cannot find file system superblock

After browsing through the 'dump' file I see a lot of Windows-isms so must be mistaken about this being a FreeBSD... It may well exist somewhere in the file, but I don't know of any particular string which would indicate a start of FreeBSD partition.

What I could really do with would be a viewer which could read raw data... Don't know if such a program exists...
 
_martin said:
Also any chance you had hybrid MBR ? What was the device (OS) you booted when it happened?
Click to expand...
I don't know what a hybrid MBR is, but I doubt I used one. It was just a standard MBR that came with Windows 7.

As far what OS was running when my FreeBSD partition disappeared, it's difficult to say... I was testing an unattended installation of FreeBSD, and besides the hard disk of my laptop I was also using two USB disks (one with 15 bootable partitions) and a USB pen drive. I tried avoiding ada0 altogether, but may well have slipped up somewhere.
 
Yes, I agree. Now with the information you provided I doubt it is a hybrid one. As I stated somewhere above there's no guarantee that FreeBSD partition starts exactly where the free space is. I don't know how start of the UFS FS looks like. This is where the hexdump can help ( do a virtual disk, create an UFS partition there and match with the current disk).

Now I used sysutils/testdisk in the past and was very happy with it. This is their testdisk homepage. I actually used it on Linux but it seems it's the same tool.
Doing this on a 1:1 dd copy of the disk is the best way to go, but you can choose the live disk too (at least to test what it finds).
 
You must log in or register to reply here.
Back
Top