Date: Sun, 28 Jan 2024 16:02:43 -0800 From: Dan Mahoney <freebsd@gushi.org> To: Odhiambo Washington <odhiambo@gmail.com> Cc: questions <questions@freebsd.org> Subject: Re: Upgrade 8.4-STABLE to 14-STABLE Message-ID: <75DCCF1C-BA33-4917-988E-5B92955D1D17@gushi.org> In-Reply-To: <CAAdA2WNLg19usv2ryO-s=EavDw%2BA1BQq_m_xUTu8RYCTVpbDzg@mail.gmail.com> References: <CAAdA2WNLg19usv2ryO-s=EavDw%2BA1BQq_m_xUTu8RYCTVpbDzg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Jan 26, 2024, at 23:55, Odhiambo Washington <odhiambo@gmail.com> = wrote: >=20 > 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. 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). =3D=3D=3D=3D 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. 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).=20 =3D=3D=3D=3D 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. 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?75DCCF1C-BA33-4917-988E-5B92955D1D17>