Date: Thu, 21 May 2026 18:20:50 -0700 From: "Dan Mahoney (Ports)" <freebsd@gushi.org> To: "Ronald F. Guilmette" <rfg@tristatelogic.com> Cc: freebsd-questions@freebsd.org Subject: Re: Using dump/restore to combine partitions? Message-ID: <40A6FD3F-162A-442A-91A5-BCE5C64FB867@gushi.org> In-Reply-To: <36211.1779411091@segfault.tristatelogic.com>
index | next in thread | previous in thread | raw e-mail
> 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. -Danhome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?40A6FD3F-162A-442A-91A5-BCE5C64FB867>