Re: Using dump/restore to combine partitions?

<<because a prior coworker had made / and /var too small to take a freebsd-update to a modern OS.>>

Sorry about that!
Paul Vixie

May 21, 2026 18:20:50 Dan Mahoney (Ports) <[email protected]>:

> 
> 
>> On May 21, 2026, at 5:51 PM, Ronald F. Guilmette <[email protected]> wrote:
>> 
>> I have a bootable FreeBSD system that was partitioned in a way that I dislike,
>> and that I would like to now change.  The current system contains the following
>> partitions, which I would like to copy to a fresh new drive while consolidating
>> all of these partitions into a new _single_ partition on the new drive.  (The
>> new drive will end up being my new bootable drive.):
>> 
>> Filesystem      1M-blocks    Used  Avail Capacity  Mounted on
>> /dev/ada0p2           991     618    293    68%    /
>> devfs                   0       0      0   100%    /dev
>> /dev/ada0p4          2973    1357   1378    50%    /var
>> /dev/ada0p5          1983      16   1808     1%    /var/ftp
>> /dev/ada0p6           991      14    897     2%    /tmp
>> /dev/ada0p7         15853   12749   1835    87%    /usr
>> /dev/ada0p8         31726   27545   1642    94%    /home
>> procfs                  0       0      0   100%    /proc
>> 
>> My question is:  How do I accomplish this using dump/restore?
>> 
>> My current plan is to boot the system in question from a removable device
>> that will itself contain a full FreeBSD 15.1-STABLE system, mount the target
>> filesystem, perform all of the necessary dump and restore operations,
>> power-off, remove the removable drive, remove the old boot drive and then
>> boot from the new drive.
>> 
>> I need to know the exact set of commands necessary to accomplish all this.
>> 
>> Assuming that the new (single) bootable partition on the new drive will be
>> pre-formatted (UFS) and mounted as /mnt and that the source partitions
>> described above will end up having all of the same /dev names as listed
>> above, but with "ada0" changed to "ada1", then will the following set of
>> commands accomplish my goal?
> 
> In a talk at BSDCan I posted a slide that I titled "here goes nothing" where during a pandemic where smart hands was literally not allowed to come to the office, on a faraway system running Critical Things, that I had no out of band access to, I would copy mfsbsd over /boot, reboot and hope for the best, which would give me a memory-resident booted OS that would suspend me, mission-impossible-style, over the disk so I could reformat and reinstall, because a prior coworker had made / and /var too small to take a freebsd-update to a modern OS.
> 
> I mean, maybe, but....first off, you're going to be copying /usr over, which contains /usr/lib and /usr/bin and also /usr/local (so thus, all your installed binaries) with whatever shared libs (both base and from ports) that you had at the time.  This feels like a great way to induce pain.  Just reinstall your packages clean.  `pkg leaf` should show you the minimal install requirements.  From there, it *should* just be choice bits in /etc, most of /usr/local/etc, /home (wherever that is) and maybe /var (but again, you don't want to stomp your new pkg database).  What's in /tmp that you really care about after a reboot?
> 
> And second, dump is an interesting solution for streaming a partition/mountpoint to either a tape device, or over a pipe, but it's very block-level, which you don't really need.  Yes, there are some filesystem flags like noschg and stuff that a plain-vanilla `cp -pR` won't capture, but tar should absolutely suffice here.  Or Rsync.
> 
> -Dan