I have an img (made with dd) of a FreeBSD installation on a 1TB HD.

This time i need to use a smaller disk (500GB), and of course if I try just to restore the same image it won't work, but even if I tried to manually adjust partition table and MBR my system doesn't boot.

What i did:

After dding, i went straight to sfdisk in order to adjust MBR ending sector, then i used parted to shrink partition to correct boundary.

To my calculations, given that the partition begins at sector 2048, for a 500GB disk it is correct to set ending sector at 976771120 (976773168 total).

New partition is then 2048 -> 976771120, and new MBR also uses this logic. In fact, I can reach FreeBSD boot manager 1st stage, but then i'm stuck at boot prompt (error 66). Maybe i'm not aware of how next bootloader stages work, probably is it not enough to fix partition scheme and MBR to make FreeBSD boot? There could be some conf file read early somewhere that also needs to be fixed? Not my primary OS so I'm on a trial/error process. Thanks

EDIT: added output, sorry for pic but my only choice. Didn't remember that real data were really few( <2GB).

First disk, 500GB scheme (not working). Second disk, 1TB original scheme (working).

I could already go with this and proceed with my work, but i think it's still interesting to understand what went wrong. Current situation

3 Answers 3


First you need a backup copy in case something went wrong. You need tools for filesystem you use, whatever it is.

First you need a program which will logically shrink your partition in filesystem you use. I did such thing few times before with ntfs and ext3 but idea is the same for every filesystem.

I assume that your image is image of partition (sda1.img), if it's whole disk (sda.img) then either "extract" partition only or put (the whole image) it on physical disk (1TB+) and work on it. Later you will copy your work on your new 500GB disk. Reason for that is that your resize program may not support offset partition which is the case with image of whole disk.

your old disk (sda):
| mbr... | sda1 (system)  | sda2...

1. Use ntfsresize/tune2fs/whatever-fs-resizer to shrink your partition filesystem (/dev/sda1(on a physical disk)/sda1.img(in the image)). This will resize down your filesystem within image (of partition)

2. Create new partition table on new (500GB) disk (/dev/sdb) that can fit your resized system partition plus some extra megabyte so the filesystem fits in new partition (/dev/sdb1). Use fdisk/cfdisk/(g)parted/whatever-you-like to that. Remember to make /dev/sdb1 bootable.

Technically one can calculate exactly how much you will need but don't worry - your resizer should be able to resize your filesystem (on /dev/sdb1) to fill whole partition (that's for later).

3. Copy your resized sda1.img to your new destination /dev/sdb1 (with dd or cat even: $ cat sda1.img > /dev/sdb1)

4. Format other partitions /dev/sdb2|3|4... to fit your needs.

5. Enjoy your work.


I'd solve it in the good old-fashioned way.

newfs /dev/ada1s1
mount /dev/ada1s1 /mnt
cd /mnt
dump -0a -f - /dev/ada0s1 | restore -rf -
gpart bootcode -b /boot/mbr -p /boot/boot1 ada1

This makes a fresh filesystem, mounts it and enters the destination directory because restore needs to work there. It copies the entire file system with the classic backup tools (that never fail for UFS). The last command writes the boot code.

Disclaimer: Please always verify the commands, because it is of course devastating, if some parameter is wrong!! You need to understand what is being done here.


That seems slightly masochistic to me.

Personally I would have done a dd for backup. Then I would shrink it and make sure it works before trying to move it (shrink->reboot->check->final dd).

I assume that you had less than 500 GB of data. But you do not know how it was structured on the disk.

You have then used sfdisk and parted to modify the partitions? But what have you done to conserve the filesystems? A naive change of the partition will not reorder the data in the file system nor manage the layout of the truncated filesystem.

So what you are missing is handling your filesystem. On FreeBSD you would typically use UFS or ZFS. For UFS you should look into growfs(8) (See Resizing UFS /root partition on FreeBSD). If you're using ZFS everything is a whole different ballgame as it is a combined volume manager and file system!

So to be able to answer your direct question we need a lot of additional information. The implicit question on how to get to your data is however much easier. Setup a bare and bootable FreeBSD installation on your new disk. Then copy the data.

Mount an image

When you have a dd image of your disk you can mount it. Either do it on a different system or have a portable USB disk/networkdrive.

So if you have the full original copy of /dev/ada0 as ada0.dd - then you can use the image as a virtual memory disk:

# mdconfig -a -t vnode -u 0 -f /home/realpclaudio/ada0.dd

This will give us /dev/md0 which should be your full disk.

You can then check everything looks good.

# fdisk /dev/md0

This should look exactly like your old disk. We can then start looking at the data but this depends on your file system.


We mount the UFS file system on the disk.

# mount -t ufs -o ro /dev/md0s1a /mnt

That is most likely the root file system of the 1st slice. If yoou have further slices you can mount them as well.

# mount -t ufs -o ro /dev/md0s1e /mnt/var
# mount -t ufs -o ro /dev/md0s1g /mnt/home


If you are using ZFS you can then manage the disk using the ZFS tools (see zpool Administration.

# zpool import -o altroot=/mnt mypool
# zfs list
  • Thanks for the answer, btw what do you mean exactly by "A naive change of the partition will not reorder the data in the file system"? Source img partition is zero filled at the end of relevant data, so I expected that putting arbitrary limit would not truncate anything useful. Mar 5, 2020 at 15:38
  • Too many assumption and too few facts. Was everything mounted on root with no partitions? Then maybe. But default install creates seperate partitions within the slice (See Example 3.13). If you have a full 1 TB image and have verified that the last 600 GB surely are 0 - then - and only then are you good to go. Mar 5, 2020 at 17:13
  • Remember a DOS partion is a FreeBSD slice - and a slice may have UFS partitions. Furthermore you may have had a fragmented system. It is your job to "defrag" before doing the dd to ensure data is ordered first. dump(8) is preferred for pure file system backup to avoid handling that. Then you do not need to make assumptions of the on-disk structure. For your task you are misusing dd. Mar 5, 2020 at 17:14
  • Updated post with some extra info, if you need more "facts" just ask. Just to be clear, i could go with 1TB drive without problems, i'm just following it to better understand the case in general. Thanks. Mar 6, 2020 at 12:09

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .