Pkgbase 15 to 15.1 stories?

Zare

Zare

As this is probably the first instance of release FreeBSD being upgraded by another means, I wanted to do some chit chat before the upgrade.
The minor version bump using pkgbase looks pretty straightforward.
However the major version bump seems awfully "rude" as if there was not a procedure but a way to make it work that way using env vars and complicated workflow.

Has anyone done it yet, 15 to 15.1 using pkgbase, did it go seamless per instructions?
 
Hi Mate

I upgraded to 15.1 using pkgbase

Using a bectl boot environment and poudriere to build the nvidia-driver and nvidia-drm-66-kmod
Which took 11 and half hours to build on my Dell xps 15 2019 with 16 gb of ram

Heres the forum post

NapoleonWils0n

Thread 'Success Freebsd 15.1 upgrade with pkgbase and Poudriere'

I just upgrade to Freebsd 15.1 with pkgbase and Poudriere on my Dell XPS 15 2019

I used a bectl boot environment with Poudriere to install the new Nvidia driver and nvidia-drm-66-kmod

The trick is you have to split the Poudriere set up into 2 parts
You can do part of the poudriere set up while on 15-p10

But you have to build the jail and install the ports once you have booted into Freebsd 15.1
because you cant build a Freebsd 15.1 jail on Freebsd 15-p10

The notes exceed the character count for a forum post so here are the notes on github...
  • Like

and my notes

github.com

cerberus/freebsd/freebsd-15-1-upgrade.org at master · NapoleonWils0n/cerberus

cerberus code library. Contribute to NapoleonWils0n/cerberus development by creating an account on GitHub.
github.com github.com
 
Zare said:
As this is probably the first instance of release FreeBSD being upgraded by another means, I wanted to do some chit chat before the upgrade.
The minor version bump using pkgbase looks pretty straightforward.
However the major version bump seems awfully "rude" as if there was not a procedure but a way to make it work that way using env vars and complicated workflow.

Has anyone done it yet, 15 to 15.1 using pkgbase, did it go seamless per instructions?
Click to expand...

Yes, and ran into PR 296052 as per this thread.

/grandpa
 
Been smooth on several upgrades. I did run into issues with the machine that had an Nvidia card. I also used bectl first to create a backup boot environment. For me, I had to, after updating the machine with Nvidia, update ports to the newest, and then install nvidia-drm-kmod and nvidia-drm-66-kmod. Gory details here

S

Post in thread 'Good news today'

Ok, this might be a longish one, and I even thought of giving it its own thread, but anyway...

My main workstation is an older Dell with an Nvidia card. I went to update it via the instructions, but it said it was up to date, though it was running 15.0-p10. So, I finally realized that on both this machine and the headless one that I couldn't update until I edited what was in /usr/local/etc/pkg/repos that both this one and the headless one had a FreeBSD-base.conf as well as FreeBSD.conf, and that FreeBSD.conf has a line
Code: 
 FreeBSD-base: { enabled: yes }.
So yesterday, I fixed...
  • Thanks

But on a few AMD machines and a Thinkpad laptop, all went smoothly.
 
Yes no problem
S

Post in thread 'Good news today'

Well, I upgraded my secondary machine, which went fine. As mentioned, that headless one wasn't upgrading, so I just edited its /usr/local/etc/pkg/repos/FreeBSD.conf to match the one that upgraded successfully, then it pulled in the necessary packages and upgraded to 15.1. All machines are on packagebase. Pretty straight forward.
  • Thanks
  • Like
Upgrade
 
I'm writing a script for that, but it's not yet ready.

It managed these upgrades:

- 15.0-RELEASE -> 15.1-RC2
- 15.1-RC2 -> 15.1-RELEASE
- 15.0-RELEASE -> 15.1-RELEASE
- 15.1-RELEASE -> 15-STABLE
- 15.0-RELEASE -> 15-STABLE
- 15.1-RELEASE -> 16-CURRENT

It works for major version change.
It uses both temporary repo conf file and var ABI change.
It checks and avoids some pitfalls.
It forces kmods upgrade in all cases and all pkg in case of a major version upgrade.

I'm convinced we need a tool like this as we have freebsd-update on the other side.
So, I move things forward, at least for me, as upgrades under pkgbase aren't as easy as with freebsd-update.
 
I'm not doing pkgbase, but since pkg has worked just fine for a long time, I would think pkgbase should be no different.

What NapoleonWils0n and scottro say about manually creating a new BE is a good idea; especially since one can mount a BE and pkg supports a "-c" option which does a chroot.
When I do an upgrade across a release, I create new BE, mount it, use freebsd-update with -b and -d to do the updates into the new BE, then pkg-static -c to upgrade the new BE.
That should also work for pkgbase (of course not using freebsd-update).

An advantage of doing this is a single reboot into the new BE, you can make the new BE consistent with base and ports, you can tweak etc/rc.conf to not load problematic modules (drm).
 
I went from a 15.0-RELEASE installed with pkgbase to 15.1-RELEASE and couldn't log in after the upgrade. The pam related packages were missing for some reason. Installed those and was able login.

Also found that I had a slew of older packages that had to be manually removed. This was likely due to some mistake on my part months ago.

pkgbase is MUCH more fragile than freebsd-update imo. It tends to be easier to fix if there is an issue but there was very seldom an issue with freebsd-update. ymmv.
 
dkh said:
I went from a 15.0-RELEASE installed with pkgbase to 15.1-RELEASE and couldn't log in after the upgrade. The pam related packages were missing for some reason. Installed those and was able login.

Also found that I had a slew of older packages that had to be manually removed. This was likely due to some mistake on my part months ago.

pkgbase is MUCH more fragile than freebsd-update imo. It tends to be easier to fix if there is an issue but there was very seldom an issue with freebsd-update. ymmv.
Click to expand...
That was on the release notes: https://www.freebsd.org/releases/15.1R/relnotes/#userland-packages
 
dkh said:
pkgbase is MUCH more fragile than freebsd-update imo. It tends to be easier to fix if there is an issue but there was very seldom an issue with freebsd-update. ymmv.
Click to expand...
Is it really more fragile or is it "different from freebsd-update" which requires rethinking ones process?
I pointed out in another thread that one can create a new BE, effectively chroot into it and do all the updates. That would give a person a coherent BE on the new versions (base and applications/ports) and would require a single reboot.
freebsd-update gives you a bit of protection by automatically creating a new BE (default setting) when you do freebsd-update install.
Lots of people will create a new BE before doing pkg upgrade around quarterly; perhaps that mindset will make pkgbase feel less fragile.
 
mer said:
Is it really more fragile or is it "different from freebsd-update" which requires rethinking ones process?
I pointed out in another thread that one can create a new BE, effectively chroot into it and do all the updates. That would give a person a coherent BE on the new versions (base and applications/ports) and would require a single reboot.
freebsd-update gives you a bit of protection by automatically creating a new BE (default setting) when you do freebsd-update install.
Lots of people will create a new BE before doing pkg upgrade around quarterly; perhaps that mindset will make pkgbase feel less fragile.
Click to expand...

Fragile in the sense that it doesn't take much to perturb the system, having something wrong or changing something in the pkg configuration can have a long messy tail.

Creating a BE before the fact is trivial but I do look forward to seeing the updated freebsd-update tucking all of the new steps together.

I expect things will be fine when everything settles in. Right now I'm content to limit its use to a couple of virtual systems.
 
  • Like
Reactions: mer
dkh said:
It was. I seem to have FreeBSD-set-minimal installed so it should have been handled automatically. I can't swear to it having been there when I did the upgrade but I believe it was.
Click to expand...
It could have been issue with pkg dependency resolution, it does funny things if dependencies are not well specified.
A past example for me was switching xorg to xlibre which pulled seatd, reinstalling xorg (which auto removes xlibre), eventually I removed seatd (was not using it), some time passea tried xlibre again (removed xorg), doesn't pull seatd again, so no working X11..
 
Zare said:
As this is probably the first instance of release FreeBSD being upgraded by another means, I wanted to do some chit chat before the upgrade.
The minor version bump using pkgbase looks pretty straightforward.
However the major version bump seems awfully "rude" as if there was not a procedure but a way to make it work that way using env vars and complicated workflow.

Has anyone done it yet, 15 to 15.1 using pkgbase, did it go seamless per instructions?
Click to expand...
Yes, I followed the release instructions https://www.freebsd.org/releases/15.1R/upgrading/ for my system which was a fresh 15.0 pkgbase install with ufs file system and minor upgrades to p10.

It went smoothly with desktop and applications working like nothing had happened.

Like it!
 
brassmonkeys said:
Yes, I followed the release instructions https://www.freebsd.org/releases/15.1R/upgrading/ for my system which was a fresh 15.0 pkgbase install with ufs file system and minor upgrades to p10.
Click to expand...

My system is an original 15.0 installed system which I installed with ZFS. I followed the same upgrade instructions as shown (above). My 15.0 system had previously been upgraded to p10.

Everything pkg wise upgraded well and I thought the entire upgrade from 15.0 to 15.1 was going to be a 100% success 👍until I typed "startx" to start xorg X windows - and I got a FreeBSD kernel panic.

I checked the Internet and this forum and discovered that the FreeBSD kernel panic was a known issue with the FreeBSD 15.1 upgrade.

I performed the following steps to get my newly install 15.1 system successfully upgraded to support my NVIDIA GeForce RTX 4070 graphic card:
  • I updated /usr/ports to the 2nd quarter 2026 FreeBSD ports -- using the git command as follows:
  • I then compiled and installed port drm-66-kmod
    • # cd /usr/ports/graphics/cd drm-66-kmod
    • # make BATCH=yes
    • # make deinstall
    • # make install
  • I then compiled and installed port nvidia-driver
    • # cd /usr/ports/x11/nvidia-driver
    • # make BATCH=yes
    • # make deinstall
    • # make install
  • I then shutdown my 15.1 system and restarted/rebooted it
  • I then logged in and typed "startx" at the command prompt -- and X Windows started and worked normally.
I want to say ! THANK YOU ! to the FreeBSD development, release coordination and other support staff for their excellent work on delivering the 15.1-RELEASE. FreeBSD continues to run extremelly well -- the operating system runs amazingly fast and is highly performant. Thank you again.
 
Just successfully upgraded from FreeBSD 15.0-RELEASE-p10 to FreeBSD 15.1-RELEASE-p0 🌟

Followed the official upgrade instructions to the letter.
Server running remote on VMware without any X11.
  • Took under 5 minutes from start to finish, including reboot.
  • No questions asked.
  • No *.pkgnew found ( # find /etc /usr/local/etc -name '*.pkgnew' -ls).
  • Needed to change from ada0 to da0 ( # gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 da0).
Code: 
FreeBSD srv11 15.1-RELEASE FreeBSD 15.1-RELEASE releng/15.1-n283562-96841ea08dcf GENERIC amd64

# freebsd-version -kru
15.1-RELEASE
15.1-RELEASE
15.1-RELEASE

🍻
 
Upgraded using `freebsd-update` and got a kernel panic on boot, going into a reboot/panic loop.
Was doing it remotely, so had to go to the console to edit `/etc/rc.conf` and comment out the intel graphics driver (there could be a reminder in the upgrade instructions).

After this the upgrade went smoothly, including the EFI.
 
Thank you for all your answers.

Emrion said:
I'm convinced we need a tool like this as we have freebsd-update on the other side.
So, I move things forward, at least for me, as upgrades under pkgbase aren't as easy as with freebsd-update.
Click to expand...

Absolutely there is no reasoning why freebsd-update shouldn't become a script that automates the pkgbase update cycle.

I have these on my system since my nvidia has recently become legacy

Code: 
linux-nvidia-libs-580-580.159.04 NVIDIA graphics libraries and programs (Linux)
nvidia-driver-580-580.159.04   NVIDIA graphics driver userland
nvidia-drm-66-kmod-580-580.159.04.1500068_1 NVIDIA DRM Kernel Module
nvidia-drm-kmod-580-580.159.04_1 NVIDIA DRM kernel module
nvidia-kmod-580-580.159.04.1500068 NVIDIA graphics driver kernel module
nvidia-settings-595.80         Display Control Panel for NVIDIA graphics
py311-nvidia_ml_py-13.590.48   Python bindings to the NVIDIA Management Library

I have three packages I built from ports

Code: 
Currently locked packages:
furnace-0.6.8.3_2
vlc-3.0.22_2,4
wine-proton-10.0.1

Is anything wrong with nvidia on 15.1? Shouldn't the last, step 8 from pkgbase wiki, "upgrade ports (using available packages)" be a mere pkg upgrade which will fecth new packages due to changed ABI? Any issue with nvidia here?

I get I will have to build those three ports again, that's fine.
 
For me, with a GT1030 card, (which takes the nvidia-580 stuff) upgrading with the instructions didn't pull in the pkgs. So, I updated my ports to the latest, and built the port for nvidia-kmod-drm and nvidia-kmod-66-drm. This pulled in whatever else was necessary, I didn't really pay attention. I didn't try to use the pkg, it might have worked for all I know. But when I ran
Code: 
pkg upgrade -r FreeBSD-ports-kmods
it didn't do anything with Nvidia stuff, so as experience has shown me that sometimes I need the port rather than package for nvidia after an upgrade, and as building the port doesn't take very long, I just did it through ports. I upgraded ports first because I did once have an experience where I upgraded by ports, it still didn't work, and it turned out I was using an older version of the port.

So, doing it that way has pretty much become my habit.
 
For me the upgrade has been tragic. My wireless network does not work ('Realtek Semiconductor Co., Ltd.', 'RTL8821CE 802.11ac PCIe Wireless Network Adapter'). Xorg segfaults (replacing with "i915kms" from "nvidia-drm" works). Thank god for bectl, I'll be on 15.0-RELEASE-p10 for a while.
 
my 2 cents: new to freebsd (less than 6 months). Followed the official instructions and went smoothly for me. Both servers are fine. I have a bastille jellyfin jail that was updated too with no issues. Both servers used to be OpenMediaVault.
 
You must log in or register to reply here.
Back
Top