From nobody Fri May 22 01:20:50 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 ESMTP id 4gM6tK3BPgz6fTHt for ; Fri, 22 May 2026 01:21:13 +0000 (UTC) (envelope-from freebsd@gushi.org) Received: from prime.gushi.org (prime.gushi.org [IPv6:2620:137:6000:10::142]) (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 ECDSA (secp384r1) client-digest SHA384) (Client CN "prime.gushi.org", Issuer "E8" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4gM6tJ6FWdz3LlH for ; Fri, 22 May 2026 01:21:12 +0000 (UTC) (envelope-from freebsd@gushi.org) Authentication-Results: mx1.freebsd.org; none Received: from smtpclient.apple ([IPv6:2001:500:6b:200:c000:0:0:32]) (authenticated bits=0) by prime.gushi.org (8.18.2/8.18.2) with ESMTPSA id 64M1L0uJ067522 (version=TLSv1.2 cipher=ECDHE-ECDSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 22 May 2026 01:21:01 GMT (envelope-from freebsd@gushi.org) DKIM-Filter: OpenDKIM Filter v2.10.3 prime.gushi.org 64M1L0uJ067522 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gushi.org; s=prime2014; t=1779412861; bh=mKKnDV1Yv6D4aL1KE6hmkIhufAcEFU/rcP+Tcp3pPbk=; h=Subject:From:In-Reply-To:Date:Cc:References:To; z=Subject:=20Re:=20Using=20dump/restore=20to=20combine=20partitions ?|From:=20"Dan=20Mahoney=20(Ports)"=20|In-Reply -To:=20<36211.1779411091@segfault.tristatelogic.com>|Date:=20Thu,= 2021=20May=202026=2018:20:50=20-0700|Cc:=20freebsd-questions@freeb sd.org|References:=20<36211.1779411091@segfault.tristatelogic.com> |To:=20"Ronald=20F.=20Guilmette"=20; b=gKOswBeRtlNXaOQowBLroKAPl7sOfWExZQUGh3FSjT0jwTyynASPg9KVlRKd/RPjc /dpJGCxSEKJSWtU9CD/v3qdO8Mp3+9NczdBDedHK4m3qLRyWueDfIceYoblN4nOl63 Ux9W229cSfnhsLrtVT++iwhU+EeQtvNsg7pO/VDRjlP+W1YdufcTTXEkF6OxIFx0fG foAYBS4h7/0M+J0soJKdAUDhHuZS6bYsKwVIe/i0+ddJD4PXYU1chreF3bPGdDNbYb 4dXAvSUs9WMrdW/LGBe4cLXNiK+620+W/vAsUelFs8NNV02mhPCeQ1HnOExnuDzbB8 1diyFy4mwrjjg== X-Authentication-Warning: prime.gushi.org: Host [IPv6:2001:500:6b:200:c000:0:0:32] claimed to be smtpclient.apple Content-Type: text/plain; charset=utf-8 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 (Mac OS X Mail 16.0 \(3864.600.51.1.1\)) Subject: Re: Using dump/restore to combine partitions? From: "Dan Mahoney (Ports)" In-Reply-To: <36211.1779411091@segfault.tristatelogic.com> Date: Thu, 21 May 2026 18:20:50 -0700 Cc: freebsd-questions@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <40A6FD3F-162A-442A-91A5-BCE5C64FB867@gushi.org> References: <36211.1779411091@segfault.tristatelogic.com> To: "Ronald F. Guilmette" X-Mailer: Apple Mail (2.3864.600.51.1.1) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.4 (prime.gushi.org [IPv6:2620:137:6000:10:0:0:0:142]); Fri, 22 May 2026 01:21:01 +0000 (UTC) X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:393507, ipnet:2620:137:6000::/44, country:US] X-Rspamd-Queue-Id: 4gM6tJ6FWdz3LlH X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated > On May 21, 2026, at 5:51=E2=80=AFPM, Ronald F. Guilmette = wrote: >=20 > 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.): >=20 > 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 >=20 > My question is: How do I accomplish this using dump/restore? >=20 > 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. >=20 > I need to know the exact set of commands necessary to accomplish all = this. >=20 > 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. =46rom 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=