Solved Upgrade from 13.0 to releng 13.1

Ofloo

Ofloo

I know releng 13.1 isn't released yet, however I thought better to address it now then to wait until it's released?

Before I started upgrading from 13.0 to 13.1 I've removed /usr/obj

Git branch "On branch releng/13.1"

Code: 
# freebsd-version
13.0-RELEASE-p10

make -j21 installkernel
Code: 
kldxref /boot/kernel
kldxref: error while reading /boot/kernel/iwlwifi-9000-pu-b0-jf-b0-46.ucode.ko: Bad address
kldxref: error while reading /boot/kernel/iwlwifi-9260-th-b0-jf-b0-46.ucode.ko: Bad address
--------------------------------------------------------------
>>> Installing kernel ABC completed on Sun Apr 17 09:00:17 CEST 2022
--------------------------------------------------------------
root@azkaban:/usr/src # git remote -v
origin  https://git.freebsd.org/src.git (fetch)

KERNEL CONFIG FILE:
Code: 
include                 GENERIC
ident                   ABC
options                 IPFIREWALL
options                 IPFIREWALL_VERBOSE
options                 IPFIREWALL_DEFAULT_TO_ACCEPT
options                 DUMMYNET
options                 IPDIVERT
options                 CONSPEED=115200
 
Well i did make -j21 buildworld buildkernel so maybe buildworld showed an error I didn't see ? But usually when that happens it exits. So no errorrs.
 
Code: 
--- kernel.full ---
linking kernel.full
ctfmerge -L VERSION -g -o kernel.full ...
      text      data       bss        dec         hex   filename
  23193839   1840041   4445696   29479576   0x1c1d298   kernel.full
--- kernel.debug ---
objcopy --only-keep-debug kernel.full kernel.debug
--- kernel ---
objcopy --strip-debug --add-gnu-debuglink=kernel.debug  kernel.full kernel
--------------------------------------------------------------
>>> Kernel build for ABC completed on Sun Apr 17 13:23:11 CEST 2022
--------------------------------------------------------------
>>> Kernel(s)  ABC built in 207 seconds, ncpu: 20, make -j21
--------------------------------------------------------------

Sorry that was obviously not my intention :p however I did a recompile and this was the result no errors as far as I can tell.

Code: 
# git -C /usr/src rev-list --max-count=1 HEAD
e74c79e48ef1620b7b5a3c29dd316d30bda55790

I did git pull yesterday so it should be fairly recent.
 
Same result sorry. I haven't ran installworld, shouldn't I installkernel before i installworld?

What I usually do is builworld buildkernel, then installkernel reboot and see if that works if the new kernel works then I'll installworld. Because installkernel only modifies the boot directory, and renaming kernel old and modules old back to the previous isn't that hard to do.

rollingback installworld is a bit more work.
 
Ofloo said:
What I usually do is builworld buildkernel, then installkernel reboot and see if that works if the new kernel works then I'll installworld.
Click to expand...
I rarely reboot after only updating the kernel. Install the kernel, install world, run etcupdate(8), run delete-old and delete-old-libs. Update packages, then reboot.

The need to boot the new kernel first only happened once, when upgrading from 4.x to 5.0. This was due to the UFS -> UFS2 change, if you didn't reboot the new kernel first then the installation would get completely hosed. Which happened to me because I didn't read /usr/src/UPDATING.

Ofloo said:
rollingback installworld is a bit more work.
Click to expand...
That's when boot environments are extremely useful.
 
kldxref(8) has repeatedly been a problem when upgrading from source. The reason is, it's not part of the build-tools built locally. Instead, the version already installed on the host is always used. This can fail if things changed that the (older) kldxref doesn't understand yet.

The good news is: The system will still be bootable, even when kldxref failed. Just complete the upgrade normally, ignoring the error, and then run installkernel again. This time it will work fine, because the newest kldxref is on your system.
 
Unfortunately when reboot the new kernel isn't activated yet. Normaly when you make installkernel and reboot the next boot cycle the new kernel is initiated, but that's not the case. So no it it's not just a warning.
 
Ofloo said:
Because installkernel only modifies the boot directory, and renaming kernel old and modules old back to the previous isn't that hard to do.
Click to expand...
Just copy /boot/kernel to /boot/kernel.good or something like it. Then you always have the old kernel to fallback on. You can select which kernel to boot on the "beasty" menu.
 
I renamed /boot/kernel to /boot/kernel_old then did make installkernel to see if it made a new /boot/kernel directory, rebooting now..

EDIT: rebooted now it did reboot into the right kernel.
 
Ofloo said:
I renamed /boot/kernel to /boot/kernel_old
Click to expand...
Careful with that naming convention. Installing a kernel with installkernel will copy the original kernel to /boot/kernel.old. It's really easy to mix up kernel_old and kernel.old.
 
Zirias said:
kldxref(8) has repeatedly been a problem when upgrading from source. The reason is, it's not part of the build-tools built locally. Instead, the version already installed on the host is always used. This can fail if things changed that the (older) kldxref doesn't understand yet.

The good news is: The system will still be bootable, even when kldxref failed. Just complete the upgrade normally, ignoring the error, and then run installkernel again. This time it will work fine, because the newest kldxref is on your system.
Click to expand...
Isn't kldxref part of world instead of kernel ? Or am i wrong ?
 
SirDice said:
I rarely reboot after only updating the kernel. Install the kernel, install world, run etcupdate(8), run delete-old and delete-old-libs. Update packages, then reboot.

The need to boot the new kernel first only happened once, when upgrading from 4.x to 5.0. This was due to the UFS -> UFS2 change, if you didn't reboot the new kernel first then the installation would get completely hosed. Which happened to me because I didn't read /usr/src/UPDATING.


That's when boot environments are extremely useful.
Click to expand...
I do the same. This time I upgrade a test server from 13.0 to 13.1 and while the current SSH connection was still working, new SSH connections were not possible. Only after the reboot the new SSH connections start working again. But I didn't try to restart sshd to see if this would make it to work without reboot.
 
Ofloo said:
Unfortunately when reboot the new kernel isn't activated yet. Normaly when you make installkernel and reboot the next boot cycle the new kernel is initiated, but that's not the case. So no it it's not just a warning.
Click to expand...
Then you have another issue not shown in your logs presented here. kldxref failure does not prevent installation of a bootable kernel. Been there quite a few times.
 
Alain De Vos said:
Isn't kldxref part of world instead of kernel ? Or am i wrong ?
Click to expand...
Yes it is. But when upgrading, you should install and boot the new kernel before installing world. Therefore, as I said, just repeat the installkernel step (which uses kldxref) after fully completing the upgrade and it will work fine.
 
So if i'm correct the correct procedure is :
Code: 
bectl create new
bectl activate new
make installkernel

reboot

make installworld
etcupdate
make -DBATCH_DELETE_OLD_FILES delete-old
make -DBATCH_DELETE_OLD_FILES delete-old-libs
 
Alain De Vos said:
So if i'm correct the correct procedure is :
Code: 
bectl create new
bectl activate new
make installkernel

reboot

make installworld
etcupdate
make -DBATCH_DELETE_OLD_FILES delete-old
make -DBATCH_DELETE_OLD_FILES delete-old-libs
Click to expand...

That looks wrong. bectl activate sets what will be active (mounted on /) at next reboot. Following the steps above would install the new kernel in the current BE, then reboot into 'new' (with the old kernel) and then installworld in the 'new' BE (with old kernel.)

You could:
Code: 
bectl create new
bectl activate new
reboot [still the same OS as you had been running, now in the new BE]

etcupdate [be sure to also 'etcupdate resolve' any identified issues]
make installkernel
make installworld
yes | make delete-old
reboot

update packages as needed

yes | make delete-old-libs
 
Slowly I'm coming to it :
Code: 
bectl create old

bectl create new
bectl activate new
reboot

make installkernel
reboot

make installworld
etcupdate
make -DBATCH_DELETE_OLD_FILES delete-old
reboot

make -DBATCH_DELETE_OLD_FILES delete-old-libs
freebsd-version -kru
 
Thank you for your sample on how you do it, still used mergemaster wasn't quite sure how to use etcupdate. Since I use mergemaster -p && mergemaster -iU
Code: 
# freebsd-version -kru
13.1-RC3
13.1-RC3
13.1-RC3

The installation now was a success, after renaming the kernel directory, it did install the new kernel. Which is strange this hasn't ever happend for me before.. and I'm compiling kernels since 4.9. So I've done my share of kernel compiles.
 
To remove older kernels sometimes i've done.
Code: 
cp /boot/loader.conf /tmp
rm -vfR /boot/*
cp /tmp/loader.conf /boot
I did not know what went wrong.
 
You must log in or register to reply here.
Back
Top