Date: Fri, 13 Sep 2019 12:57:24 -0700 From: David Christensen <dpchrist@holgerdanske.com> To: freebsd-questions@freebsd.org Subject: Re: Moving boot disk - does not seem easy? Message-ID: <6bf3e5dd-24f8-0f06-031d-91724cf2c0a7@holgerdanske.com> In-Reply-To: <03d6bfcb-aaad-c3a5-d2a6-b14f819113c2@mansionfamily.plus.com> References: <03d6bfcb-aaad-c3a5-d2a6-b14f819113c2@mansionfamily.plus.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 9/12/19 2:26 PM, james wrote: > I had thought that this would be straightforward but it seems not. > > I have a freebsd 12 system, UFS boots /ada0p2. Mounts some ZFS > partitions and I'm away. > > I add a new PCIe card with a SATA SSD, and it grabs ada0. > > I want to move my boot to the SSD, not least because the boot priority > now favours it as ada0, and I had to manually boot ada1p2. > > There's not much on ada1p2 now, but I want the new ada0p2 to be smaller, > so dd is not attractive. > > What's the easiest way to set ata0 to be much like ada0p2 was (given > that I booted from ada1p2)? > > Ideally I'd like boot and swap etc set up as well, which I kinda did > already with sade. > > I already had the issue with freebsd-install/MANIFTEST missing and did a > basic install to ada0, but it seems a bit naff to unmount all my ZFS > mountpoints just to tar across all the rest of it. > > Any pointers? I have been installing FreeBSD-11.2-RELEASE-amd64 via BIOS, the FreeBSD installer, and "ZFS (Auto)" partitioning. The installer applies MBR partitioning to the system drive. If I then attempt to migrate such a system image to a different device via dd(1) (no size changes), I have found that the destination device may not boot. The problem is that /boot/loader.conf encodes device nodes in various variable names and/or values. The work-around is to use a FreeBSD installer rescue shell, live image, etc., edit /boot/loader.conf on the target system drive as required, and move aside /boot/zfs/zpool.cache on the target system drive. I believe a better solution is use UEFI, GPT partitioning, and GPT labels. If the labels can then used throughout the bootloader chain, this would eliminate the device node problems when moving system images between devices. While it should be possible to partition the new SSD, change partition sizes, create file systems, dump(8) and restore(8) boot and/or root, find and fix all necessary configuration files, etc., I would feel more confident backing up the old system drive, disconnecting the old system drive, disconnecting the data drives, installing the new system drive, doing a fresh install (using UEFI boot, GPT partitioning, and labels), updating FreeBSD, restoring the system drive, and reconnecting/ reconfiguring the data drives. David
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6bf3e5dd-24f8-0f06-031d-91724cf2c0a7>