From nobody Fri May 22 03:03:27 2026 X-Original-To: freebsd-questions@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with UTF8SMTP id 4gM98T2Xh5z6fglK for ; Fri, 22 May 2026 03:03:37 +0000 (UTC) (envelope-from paul@redbarn.org) Received: from util.redbarn.org (util.redbarn.org [IPv6:2001:559:8000:cd::222]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "*.redbarn.org", Issuer "Sectigo Public Server Authentication CA DV R36" (not verified)) by mx1.freebsd.org (Postfix) with UTF8SMTPS id 4gM98S736Zz3dqp for ; Fri, 22 May 2026 03:03:36 +0000 (UTC) (envelope-from paul@redbarn.org) Authentication-Results: mx1.freebsd.org; none Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "*.redbarn.org", Issuer "Sectigo Public Server Authentication CA DV R36" (not verified)) by util.redbarn.org (Postfix) with UTF8SMTPS id 4ECAB160B4C; Fri, 22 May 2026 03:03:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=redbarn.org; s=util; t=1779419008; bh=vTXo3mczMPrIu049OlGIhOXyx84JPyBCC2de8qTDCfs=; h=Date:From:To:Cc:In-Reply-To:References:Subject; b=Joykkwl5VmX8Tyk04gWVqvkNo/RYaVQo0ZKUhi9g5MCflyn7hNtP4+GDSCQiP2rAu SMmEk0KGw8XzU5ZbWBLT9sS8E+26kcTq+q51mh7vIZk1B7LFadWgQ16YXYVDEqWKx5 7kmBx4Os5sF7IHR2tUiv+gB2tIRGK2JrW8Ms0cEw= Received: from dummy.faircode.eu (unknown [IPv6:2001:559:8000:c9:77e5:e42b:27e8:6421]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange x25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by family.redbarn.org (Postfix) with UTF8SMTPSA id E20A91B; Fri, 22 May 2026 03:03:29 +0000 (UTC) Date: Thu, 21 May 2026 20:03:27 -0700 From: Paul Vixie To: "Dan Mahoney (Ports)" Cc: "Ronald F. Guilmette" , freebsd-questions@freebsd.org Message-ID: In-Reply-To: <40A6FD3F-162A-442A-91A5-BCE5C64FB867@gushi.org> References: <36211.1779411091@segfault.tristatelogic.com> <40A6FD3F-162A-442A-91A5-BCE5C64FB867@gushi.org> Subject: Re: Using dump/restore to combine partitions? List-Id: User questions List-Archive: https://lists.freebsd.org/archives/freebsd-questions List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-questions@freebsd.org Sender: owner-freebsd-questions@FreeBSD.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_19_163065592.1779419007492" X-Correlation-ID: X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:33651, ipnet:2001:559:8000::/48, country:US] X-Rspamd-Queue-Id: 4gM98S736Zz3dqp X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated ------=_Part_19_163065592.1779419007492 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit <> Sorry about that! Paul Vixie May 21, 2026 18:20:50 Dan Mahoney (Ports) : > > >> On May 21, 2026, at 5:51 PM, Ronald F. Guilmette 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 ------=_Part_19_163065592.1779419007492 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit <<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
------=_Part_19_163065592.1779419007492--