Solved freebsd-update fetch returns "Cannot identify running kernel" (possible Bug?)

subnetspider

subnetspider

Hello everyone,

I was trying to run freebsd-update fetch on two of my FreeBSD 13.1-RELEASE VMs but it wouldn't work, only telling me that it "Cannot identify running kernel".

However, freebsd-version -ur would return:
Code: 
13.1-RELEASE-p3
13.1-RELEASE-p5

and uname -a would return:
Code: 
FreeBSD localhost 13.1-RELEASE-p3 FreeBSD 13.1-RELEASE-p3 GENERIC amd64

So there definitely is a kernel and FreeBSD can find it.

I dug a little deeper and found that freebsd-update checks the location of the kernel with the command sysctl -n kern.bootfile (https://reviews.freebsd.org/D21892).

When I ran the command on my two struggling VMs, it returned the following:
Code: 
/boot/kernel/INS@sRpPOI

On another working VM, it returned the following instead:
Code: 
/boot/kernel/kernel

I was able to correct this by running sysctl kern.bootfile=/boot/kernel/kernel, after that I was again able to run freebsd-update fetch like normal.

I also checked the template VM I cloned the two struggling VMs from, and there exists the same problem.
This VM was originally 13.1-RELEASE and was manually updated to 13.1-RELEASE-p1, 13.1-RELEASE-p2, 13.1-RELEASE-p3 and so on.


Now my question would be how did this happen in the first place and how I can stop this from occurring in the future?
And is this incident something where writing a Bug report would make sense (if this is a bug at all)?

Cheers :)
 
I don't think it's time to fill a PR.

Look into /etc/sysctl.conf and /boot/loader.conf for some clues.
Is the file /boot/kernel/INS@sRpPOI actually exists?
 
Emrion said:
Look into /etc/sysctl.conf and /boot/loader.conf for some clues.
Click to expand...
Everything in /etc/sysctl.conf looks normal (haven't touched it) and /boot/loader.conf looks as expected (I manually limited the zfs arc).
Emrion said:
Is the file /boot/kernel/INS@sRpPOI actually exists?
Click to expand...
Yes, the file /boot/kernel/INS@sRpPOI does exist, it was created on the same day I last updated my FreeBSD template VM.
And the file /boot/kernel/kernel with the exact same size also exists, only difference is that it was created 3 minutes later.

I'm just a little surprised why the kernel is called "INS@sRpPOI" - all I can say is that kldstat also displays "INS@sRpPOI" instead of "kernel".
 
subnetspider said:
I'm just a little surprised why the kernel is called "INS@sRpPOI" - all I can say is that kldstat also displays "INS@sRpPOI" instead of "kernel".
Click to expand...

If this is the current loaded kernel, there is somewhere a config file that indicate to load it.
For example, you have: /boot/defaults/loader.conf and /boot/loader.conf.local.

You should try to use rgrep in order to find where "INS@sRpPOI" is writed.
 
Weird, because /boot/kernel/linker.hints has nothing to do with the file to load as kernel.
See: kldxref(8)

What is the boot method? Legacy BIOS or EFI?
If it's EFI, give us the output of: efibootmgr -v
 
Update

After not finding any clues on how the kernel got renamed to INS@sRpPOI, I did the following steps to resolve the problem:

1. Delete the Kernel file (a VM snapshot or ZFS boot environment is highly recommended!):

sudo rm /boot/kernel/INS@sRpPOI

2. Generate a new linker.hints file (or FreeBSD won't boot!):

sudo kldxref -R /boot

3. Reboot FreeBSD

sudo reboot


Output of kldstat before:

Code: 
Id Refs Address                Size Name
 1   33 0xffffffff80200000  1f30470 INS@sRpPOI
 2    1 0xffffffff82131000   5b93a8 zfs.ko
 3    1 0xffffffff826ec000     a158 cryptodev.ko
 4    1 0xffffffff82b18000     3218 intpm.ko
 5    1 0xffffffff82b1c000     2180 smbus.ko
 6    1 0xffffffff82b1f000     4304 virtio_console.ko
 7    1 0xffffffff82b24000     2a08 mac_ntpd.ko
 8    1 0xffffffff82b27000     4700 nullfs.ko
 9    1 0xffffffff82b2c000     7638 if_bridge.ko
10    1 0xffffffff82b34000     50d8 bridgestp.ko
11    1 0xffffffff82b3a000     3a64 if_epair.ko

Output of kldstat after:

Code: 
Id Refs Address                Size Name
 1   33 0xffffffff80200000  1f30470 kernel
 2    1 0xffffffff82132000   5b93a8 zfs.ko
 3    1 0xffffffff826ec000     a158 cryptodev.ko
 4    1 0xffffffff82b18000     3218 intpm.ko
 5    1 0xffffffff82b1c000     2180 smbus.ko
 6    1 0xffffffff82b1f000     4304 virtio_console.ko
 7    1 0xffffffff82b24000     2a08 mac_ntpd.ko
 8    1 0xffffffff82b27000     4700 nullfs.ko
 9    1 0xffffffff82b2c000     7638 if_bridge.ko
10    1 0xffffffff82b34000     50d8 bridgestp.ko
11    1 0xffffffff82b3a000     3a64 if_epair.ko

Another nice side effect is that now the affected FreeBSD VMs use the 13.1-RELEASE-p6 instead of the 13.1-RELEASE-p3 kernel.
 
I'm not experienced for sure,but some days ago I also had a problem (and I still have it) when I have upgraded 13.1-RELEASE p4 to p6. My sensation is that our problem is correlated and that we haven't misconfigured anything,but maybe the developers did.
 
You must log in or register to reply here.
Back
Top