freebsd-update affecting kernel on custom kernel

loveydovey

loveydovey

Just to confirm, if a patch seems to update the kernel and I use a custom kernel, does that mean it'll overwrite the active kernel with GENERIC and I have to recompile kernel after the update? Does it also update kernel's source in /usr/src?
 
loveydovey said:
Just to confirm, if a patch seems to update the kernel and I use a custom kernel, does that mean it'll overwrite the active kernel with GENERIC
Click to expand...
freebsd-update(8) won't overwrite the active kernel. The active kerne, if it is named kernel, will be renamed in kernel.old:

/usr/sbin/freebsd-update
Code: 
620         config_BackupKernelDir /boot/kernel.old

loveydovey said:
I have to recompile kernel after the update?
Click to expand...
You can rename your renamed custom kernel into its original name and the updated kernel in something else (e.g. kernel.generic).

But, to maintain a custom kernel in a freebsd-update(8) managed system, best strategy is to exclude the kernel being updated by the tool.

This can be done by specifying the components to be updated in /etc/freebsd-update.conf:
Code: 
# Components of the base system which should be kept updated.
Components src world kernel
Remove here the 'kernel' component.

Of course you have to follow yourself for kernel updates. For example, track freebsd-security-notifications@ mailing list, or RSS: SECURITY ADVISORIES and ERRATA NOTICES.

loveydovey said:
Does it also update kernel's source in /usr/src?
Click to expand...
Not just the kernel sources, but also world (userland) as well, as there are updates. As shown in the configuration file above, 'src' is among the components selected for updates.
 
You could also reconsider using a custom kernel and simply use GENERIC. I've always used a custom kernel but I had been using -STABLE, so had to build everything anyway. When I got a lot more systems I used a -RELEASE version and the GENERIC kernel for those. Much easier to maintain. A custom kernel was simply too much hassle for little to no gain.
 
Well, I can't use the GENERIC kernel because some of my devices don't have support and I need to add it in.

And I can't exclude the kernel from being updated because some security patches patch the kernel. But it is a workaround that T-Daemon suggests - to exclude kernel from freebsd-update and then upgrade it manually, although this might cause an issue.
 
No, I just added my vendor/product id where needed. It's just one device right now - a USB ethernet dongle. I put a patch through, but it didn't get merged for some time now.
 
What SireDice says is your patches may not affect the kernel itself but some kernel modules that are probably untouched by the update.

I see if_ure.ko for example.
 
I know, but I have to change usbdevs, which is part of kernel. (sys/dev/usb/usbdevs). But I guess I could avoid that and just change if_ure.c
 
loveydovey said:
I know, but I have to change usbdevs, which is part of kernel. (sys/dev/usb/usbdevs).
Click to expand...
Did you report this? They're preparing for 15.1-RELEASE now, they might be able to squeeze it in before the release. Then you wouldn't have to rebuild anymore.
 
Might want to chase it, doesn't appear to have been applied yet. You probably want this MFC'ed to 15/stable too.
 
And just to confirm - you cannot just roll back to pre-update bectl environment if your freebsd-update included a kernel patch? You also need to roll back to kernel.old? And if so, is there a clean way to tie which kernel belongs to which bectl entry?
 
Patch updates are only one freebsd-update install, a BE "snapshot" is created just before the installation of the patch is done.
 
Ok, I think it's better to just do it all manually - git pull after a patch is released, create a bectl entry, and build/install kernel + world. This way you never mess anything up?
 
loveydovey said:
git pull after a patch is released, create a bectl entry, and build/install kernel + world. This way you never mess anything up?
Click to expand...
Which is exactly the order freebsd-update(8) would use. It creates the BE (of the current kernel+userland) then applies the patch (kernel, userland, or both). If things go south, you boot that BE and you'll be back to the state before the patch was applied. In other words, you are undoing the patch update (regardless if this patch was for the kernel, the userland, or both).

Patch updates -> Only one freebsd-update install, thus only one BE snapshot
Minor version upgrades -> Two consecutive freebsd-update install, thus two BE snapshots
Major version upgrades -> Three consecutive freebsd-update install, thus three BE snapshots.
 
You must log in or register to reply here.
Back
Top