Solved Kernel panic in upgrade to 13.3

I have a system that was at 13.2 and am attempting to upgrade it to 13.3. I first did:
freebsd-update fetch freebsd-update install
and then rebooted to get from 13.2-RELEASE-p2 to 13.2-RELEASE-p10. Then I did:
freebsd-update upgrade -r 13.3 freebsd-update install
It asked me to reboot to finish the installation, as expected. When I did, I got a kernel panic during startup:
Code:
<6>[drm] amdgpu kernel modesetting enabled

Fatal trap 12: Page fault while in kernel mode
...
fault code = supervisor read instruction, page not present
...
(Since it was on the console, I transcribed the highlights. I can take a photo of the whole thing if it would help.)

freebsd-version -ruk currently reports:
Code:
13.3-RELEASE
13.2-RELEASE-p10
13.2-RELEASE-p10

Any ideas on what I can try? I'm relatively new to FreeBSD. I'm able to boot the system if I tell the boot loader to use kernel.old.
If I attempt to upgrade to 14.0 at this point, will it overwrite kernel.old the only working kernel on this system?

This is my main desktop system, and it was very stable with 13.2 (and earlier) kernels. I was able to update an old laptop to 13.3 (and then 14.0) with no problems.
 
Thanks, Emrion, your post got me past this problem. I remove amdgpu from /etc/rc.conf, rebooted using the new kernel, and finished the installation. Once all packages were updated, I brought amdgpu back and there is no longer a kernel panic.
 
I confirm, amdgpu driver (from drm-kmod package) should be recompiled and reinstalled. Got to same issue today after 13.2 -> 13.3 upgrade. I think this should be added to Errata.
 
I confirm, amdgpu driver (from drm-kmod package) should be recompiled and reinstalled. Got to same issue today after 13.2 -> 13.3 upgrade. I think this should be added to Errata.

In my opinion we need separate builders when two FreeBSD releases are in support, even if they have the same major version number. I realized that they would build > 30000 identical packages for < 10 different ones, but those that are different are important to users.

Plus the module should refuse to load in the wrong version, instead of loading and then causing a panic.
 
… the module should refuse to load in the wrong version, …

A ported kernel module that's built against a particular version of base will not necessarily fail if used with a superior version number.

Refusal by design (assuming failure) would be a greater problem.
 
A ported kernel module that's built against a particular version of base will not necessarily fail if used with a superior version number.

Refusal by design (assuming failure) would be a greater problem.

Fair enough. But an additional builder would avoid the problem altogether.
 
Back
Top