Date: Thu, 21 May 2026 20:03:27 -0700 From: Paul Vixie <paul@redbarn.org> To: "Dan Mahoney (Ports)" <freebsd@gushi.org> Cc: "Ronald F. Guilmette" <rfg@tristatelogic.com>, freebsd-questions@freebsd.org Subject: Re: Using dump/restore to combine partitions? Message-ID: <a3ede9ee-df53-4713-beab-37cd4f9aef65@redbarn.org> In-Reply-To: <40A6FD3F-162A-442A-91A5-BCE5C64FB867@gushi.org> References: <36211.1779411091@segfault.tristatelogic.com> <40A6FD3F-162A-442A-91A5-BCE5C64FB867@gushi.org>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --]
<<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) <freebsd@gushi.org>:
>
>
>> On May 21, 2026, at 5:51 PM, Ronald F. Guilmette <rfg@tristatelogic.com> 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
[-- Attachment #2 --]
<html>
<head>
<meta name="viewport" content="width=device-width, initial-scale=1.0">
</head>
<body>
<span dir="ltr" style="margin-top:0; margin-bottom:0;"><<because a prior coworker had made / and /var too small to take a freebsd-update to a modern OS.>></span>
<br>
<br><span dir="ltr" style="margin-top:0; margin-bottom:0;">Sorry about that!</span>
<br>
<div class="fairemail_signature">
<span dir="ltr" style="margin-top:0; margin-bottom:0;">Paul Vixie</span>
<br>
</div>
<div class="fairemail_quote">
<div dir="ltr">
<p>May 21, 2026 18:20:50 Dan Mahoney (Ports) <freebsd@gushi.org>:</p>
</div>
<blockquote style="margin:0;border-left:3px solid #ccc; padding-left:10px;">
<div>
<br>
<br>
<blockquote style="margin:0;border-left:3px solid #ccc; padding-left:10px;">
On May 21, 2026, at 5:51 PM, Ronald F. Guilmette <rfg@tristatelogic.com> wrote:
<br>
<br>
I have a bootable FreeBSD system that was partitioned in a way that I dislike,
<br>
and that I would like to now change. The current system contains the following
<br>
partitions, which I would like to copy to a fresh new drive while consolidating
<br>
all of these partitions into a new _single_ partition on the new drive. (The
<br>
new drive will end up being my new bootable drive.):
<br>
<br>
Filesystem 1M-blocks Used Avail Capacity Mounted on
<br>
/dev/ada0p2 991 618 293 68% /
<br>
devfs 0 0 0 100% /dev
<br>
/dev/ada0p4 2973 1357 1378 50% /var
<br>
/dev/ada0p5 1983 16 1808 1% /var/ftp
<br>
/dev/ada0p6 991 14 897 2% /tmp
<br>
/dev/ada0p7 15853 12749 1835 87% /usr
<br>
/dev/ada0p8 31726 27545 1642 94% /home
<br>
procfs 0 0 0 100% /proc
<br>
<br>
My question is: How do I accomplish this using dump/restore?
<br>
<br>
My current plan is to boot the system in question from a removable device
<br>
that will itself contain a full FreeBSD 15.1-STABLE system, mount the target
<br>
filesystem, perform all of the necessary dump and restore operations,
<br>
power-off, remove the removable drive, remove the old boot drive and then
<br>
boot from the new drive.
<br>
<br>
I need to know the exact set of commands necessary to accomplish all this.
<br>
<br>
Assuming that the new (single) bootable partition on the new drive will be
<br>
pre-formatted (UFS) and mounted as /mnt and that the source partitions
<br>
described above will end up having all of the same /dev names as listed
<br>
above, but with "ada0" changed to "ada1", then will the following set of
<br>
commands accomplish my goal?
<br>
</blockquote>
<br>
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.
<br>
<br>
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?
<br>
<br>
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.
<br>
<br>
-Dan
<br>
</div>
</blockquote>
</div>
</body>
</html>
home |
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?a3ede9ee-df53-4713-beab-37cd4f9aef65>