# ‘Cannot identify running kernel’ after upgrading to FreeBSD 12



## Morris (Dec 17, 2018)

I have a VM that I use for some testing, playing around and other non-critical stuff. Because it’s not important I tend to be quite reckless with it, updating for the heck of it, not checking UPDATING before I do etc. Now, however, I have run into an issue that is throwing me off a bit, particularly because I have zero experience with boot related things.

*The problem*
I have done a `freebsd-update upgrade -r 12.0-RELEASE`. After this it wanted to reboot to complete the upgrade. After the reboot I now can’t run `freebsd-update install` (or quite a few other tasks) because it ‘Cannot identify running kernel’.

Apparently one of the situations in which this might happen is upgrading a ZFS volume that uses geli(), which is what I have. Researching this has given me some pointers but none of those have worked yet. It is probably something really small but all of the solutions out there predate release 12 and this may have something to do with the changes to the bootloader in release 12.

Does anyone have any pointers for a boot novice?

*This is my pool status:*

```
pool: bootpool
 state: ONLINE
status: Some supported features are not enabled on the pool. The pool can
    still be used, but some features are unavailable.
action: Enable all features using 'zpool upgrade'. Once this is done,
    the pool may no longer be accessible by software that does not support
    the features. See zpool-features(7) for details.
  scan: none requested
config:

    NAME        STATE     READ WRITE CKSUM
    bootpool    ONLINE       0     0     0
      vtbd0p2   ONLINE       0     0     0

errors: No known data errors

  pool: zroot
 state: ONLINE
status: Some supported features are not enabled on the pool. The pool can
    still be used, but some features are unavailable.
action: Enable all features using 'zpool upgrade'. Once this is done,
    the pool may no longer be accessible by software that does not support
    the features. See zpool-features(7) for details.
  scan: none requested
config:

    NAME           STATE     READ WRITE CKSUM
    zroot          ONLINE       0     0     0
      vtbd0p4.eli  ONLINE       0     0     0

errors: No known data errors
```

*What hasn’t worked so far:*
`zpool import bootpool` -> 
	
	



```
cannot import 'bootpool': a pool with that name is already created/imported, and no additional pools with that name were found
```

`zpool status bootpool` -> 
	
	



```
cannot open 'bootpool:': no such pool
```


----------



## Morris (Dec 20, 2018)

Right, I thought it was going to be something really small and it looks like it was.

I noticed that a lot of places link to /boot but that that dir actually didn't exist in my root. I added a symlink to point to /bootpool/root with `ln -s /bootpool/boot /boot` and it now appears to work.

I had to do a `freebsd-update fetch` followed by a `freebsd-update install` again as parts of the upgrade process had only half completed previously. Now things seem to work OK, though.

Could there be a problem with the updater that it removes the /boot dir in install with a ZFS encrypted volume?


----------



## coredumb (Mar 3, 2019)

Hi,
on a small FreeBSD box I'm stuck at a point where Morris was before. Same error message but the solution doesn't fit here.

```
root@minifreebsd:~ # uname -a
FreeBSD minifreebsd 12.0-RELEASE-p2 FreeBSD 12.0-RELEASE-p2 GENERIC  i386
```

The problem is this FreeBSD has no `/boot` or `/bootpool` directories. According to `find` there is no non-empty `boot` dir anywhere. Same with `kernel`. So I was wondering how this box managed to boot at all. System's filesystem is zfs, pool is healthy, vdev consists of one disk.

```
root@minifreebsd:~ # gpart show
=>       63  976773105  diskid/DISK-110609PBL400Q7E83ZYV  MBR  (466G)
         63  976773105                                 1  freebsd  [active]  (466G)

=>        0  976773105  diskid/DISK-110609PBL400Q7E83ZYVs1  BSD  (466G)
          0    4194304                                   1  freebsd-zfs  (2.0G)
    4194304    4194304                                   2  freebsd-swap  (2.0G)
    8388608  968384497                                   4  freebsd-zfs  (462G)

root@minifreebsd:~ #
```

But there seems to be a blast from the past, a FAT(?) partition with an MBR being "active". Maybe one that was the only filesystem option to let this box boot.

Now, my plan is to mount this {msdos|fat} partition in order to see if I can provide the above mentioned symbolic link to it and satisfy any kernel version lookups. But how to I mount it? Using that long diskid didn't work. How is it done corretly?

Thanks in advance!


----------



## SirDice (Mar 4, 2019)

coredumb said:


> But there seems to be a blast from the past, a FAT(?) partition with an MBR being "active".


That's a slice not a filesystem.


----------



## coredumb (Mar 7, 2019)

Thanks for the linked page with diagram showing a nested structure of a disk drive. Those seem to be quite similar to the disk I have my problem with, including being `/dev/ada0`. One of the differences, tho, is that under /dev there is no ada0s1 to properly mount that slice using:

```
root@minifreebsd:/dev # mount -v -t msdosfs /dev/ada0s1 /mnt/
mount_msdosfs: /dev/ada0s1: No such file or directory
tank/ROOT/default on / (zfs, local, noatime, nfsv4acls, fsid b5a186e2de02f1fe)
root@minifreebsd:/dev #
```

How can this slice be mounted? I keep confused by this many diskID/slice/volume designators ...


----------



## SirDice (Mar 8, 2019)

The slice contains BSD partitions, you normally mount the partitions (ada0s1a for example), not the slice. But, these are freebsd-zfs partitions. You cannot use mount(8) on ZFS. If you booted from a LiveCD (or something else) you will need to import the zpool first.


----------



## coredumb (Mar 8, 2019)

We seem to keep a bit of a misunderstanding here. On the ZFS side there's currently no problem. The pool is healthy, vdev is okay, datasets are mounted and working well. 
The problem is that the `/boot` directory is missing. It's not mounted on `/` or anywhere else, which I checked trying to `find` files or dirs named `boot` or files named `loader` or `kernel` without a match anywhere. The starting point was to run a `freebsd-update {fetch,install}` which constantly fails complaining:

```
root@minifreebsd:~ # freebsd-update fetch
src component not installed, skipped
Cannot identify running kernel
```
Of course it can't, there is no `/boot` present.

So my assumption is, with `gpart show` in mind (s. #3 above), that this FreeBSD installation comprises of two main parts: one boot slice (to me mysteriously not visible, not mounted, probably FAT format) and one slice with the beforementioned zfs pool with all the rest, which again is cool, no probs here. 

A minor problem is, that this box is a bit older and won't boot USB stuff (no sticks or any other USB devices) and hasn't got a CD or DVD drive built in. So I cannot insert a LiveCD in and have a look what's going on from a different perspective. But I can see the the partitioning scheme (please have a look above at #3) of this single disk drive `/dev/ada0`.

Is my assumption correct? What can I do to reach the boot slice, mount it and eventually update this FreeBSD installation? So far I've tried a lot of attempts to mount it via diskid / label but without success.


----------



## SirDice (Mar 8, 2019)

coredumb said:


> So my assumption is, with `gpart show` in mind (s. #3 above), that this FreeBSD installation comprises of two main parts: one boot slice (to me mysteriously not visible, not mounted, probably FAT format) and one slice with the before mentioned zfs pool with all the rest, which again is cool, no probs here.


It's not FAT formatted at all, it's just a slice. The partitions listed are _inside_ that slice. There is only one slice, not two. What you are seeing is information about the slice itself (the first part of the output), and the contents of that slice (the second part of the output). 


coredumb said:


> Is my assumption correct? What can I do to reach the boot slice, mount it and eventually update this FreeBSD installation?


You're looking at it from the wrong side. Look at the outputs from `zfs list` and `zfs mount`. Forget about the slices and partitions.


----------



## Morris (Nov 7, 2019)

I just did an upgrade from 12.0 p10 (I believe) to 12.1 and in the same situation (upgrading a ZFS volume that uses geli()) and exactly the same problem happened again.

Restoring the missing symlink with `ln -s /bootpool/boot /boot` did the trick again.


----------

