Re: Upgrade 8.4-STABLE to 14-STABLE

On 1/28/24 17:02, Dan Mahoney wrote:
> 
> 
>> On Jan 26, 2024, at 23:55, Odhiambo Washington <odhiambo@gmail.com> wrote:
>>
>> Is there a way to upgrade 8.4-STABLE to 14-STABLE, or even change it to 14-RELEASE?
> 
> Most people are saying what my own thought would be, but I do have a "war story" to share.
> 
> For us, preserving configuration did not matter, our configuration management was done by a tool like Puppet or Chef or Ansible.
> 
> Dayjob has several single machines in very remote places, that were built with a too-small boot partition for FreeBSD-update to work (some had been in place since 5.x).  And we needed to do upgrades during a global pandemic, when the normal "go on-site to upgrade" process would not have worked.  Maybe your own situation is the same.
> 
> Some sites had remote consoles, some only remote serial consoles.  Availability of PXEboot was minimal, and bios access was even more minimal.
> 
> Where there *was* remote hands, they were much more comfortable installing Linux.
> 
> What worked for me was extracting the contents of an MFSBSD build over into my /boot direclory, and pumping my existing ip addresses, netmask, and gateway into /boot/loader.conf
> 
> On reboot, I had the ability to SSH in, clear out my disks, and start clean.
> 
> It took me a long time to mentally reach that point, and I only got it after I was sure all the other options (pxe boot an installer, freebsd-update, make buildworld, get-a-rescue-shell and just extract base.txz over my main filesystem).  Thanks to this being the 21st century, I was able to test a lot of my procedures on VMs of various flavors like VirtualBox and VMware.

So much nicer when you don't need a second machine or disks being 
cloned/backup+restored just to try out the process. I'm messing with a 
test run to see where I could get on virtualbox under windows10 going to 
an externally attached usb ssd but it feels like I'm being penalized 
noticeably by that setup.

> If you're still on 8.x, you may still be at the point where you have separate /usr, /var, and / partitions, and at some point, one of those will grow beyond what you've done.  So even if the upgrades all work, you're in a situation that will burn you (kernels and /boot partitions keep getting bigger, until modern BSD where it's all one partition).

Years ago I thought I should prepare a talk about only partitioning <= 
1/2 of a drive to avoid this among other problems. It would still serve 
a purpose to do so today with things like COW (such as what zfs uses) 
harming performance, always knowing you have room for a temporary 
backup, and room to rearrange layout in case of 4k alignment mistake, 
efi/swap/main area resizing, toggling encryption, adding/removing disks 
to a raid freely without a second set of disks being needed, or giving 
it up and growing partition space into it. No one wants to keep free 
space on disks, let alone >50% so it would likely be an unpopular chat.

> ====
> 
> With modern FreeBSD *most* of your configuration comes down to what's in /usr/local/etc, and /etc -- these tar up really easily, as well as /usr/home or /home or whatever.

/boot/loader.conf also comes to mind; I'll check my install notes I 
started making on a recent 14 setup attempt to get all my goodies listed.

> If you have database stuff like postgres or mysql, obviously there's that directory as well.
> 
> Your base packages, you can list out without dependencies with "pkg leaf".  If pkg leaf doesn't work, copy a modern /usr/local/etc/pkg.conf from another machine to get that command (or run the command it is aliased do).

Internet pkg repositories don't exist anymore for such old releases 
though the install media included a few packages on it (dvd usually had 
the most that I recall). 8.4 should have had pkg introduced but was more 
of an option to migrate to. My current steps I'll be posting mentions 
downloading an archived ports tree to `make install` it to avoid missing 
pkg as a package or needing any package for cvs/ctm/svn/git as old 
servers have been getting turned off and newer stuff like git wasn't 
there in base by default.

> ====
> 
> That said...
> 
> If the disk sizes *are* good (freebsd-update doesn't check), I might *try* to get there with freebsd-update, but with the knowledge that it's going to take me like a dozen leap-of-faith reboots, and more often than not, I have found that freebsd-update finds *some* chance to lose the linker and run into a long string of "cp: invalid argument" shooting itself in the foot.  I've had this happen.  If I were clever, I might keep a copy of base.txz on the disk beforehand so I could unbreak things.  (It's for this reason that I put in a bug that put ssh/scp into /rescue, where there's no copy of ftp.)
> 
> Also, if I were going to go this way, I would grab the freebsd-update script from a *modern* system, there are bugs in it that were fixed, that were present in your version.

Is there a reason why freebsd-update does not update itself before doing 
other work like what pkg does?

> Note well that I say what *I* might do in this case, not what you *should* do.
> 
> Hope this helps, or at least lends some perspective.
> 
> -Dan

Thanks for sharing experiences. I've only ran freebsd update once or 
twice and became too annoyed at the archaic task of manually merging 
files that I found very easy to get done with mergemaster and 
mergemaster handled many more things automatically with optional 
switches as long as I'd tolerate the build time proceeding it (generally 
easy when its a background job).