Best way to update with a custom kernel/base


#1

Okay. I unfortunately need to have a custom kernel/base, and I used the instructions here:

https://wiki.freebsd.org/PkgBase

to do that via pkg, and that seems to be working. However, what’s not clear to me is how well pc-updatemanager is going to deal with that, since presumably, when there’s an update, I’m going to need it to update to the new, normal kernel/base and then rebuild the kernel/base for the exact same commit with my changes. When there’s a newer kernel/base in the TrueOS package repo, will it grab those packages and install them? Will it grab the new base packages but not update my kernel, because it’s a different package name (since it has a different KERNCONF)? Will it just not update any of my kernel/base packages, because I explicitly installed them from my local repo?

Basically, is it going to work in some manner to just use pc-updatemanager and then rebuild the kernel/base with my changes after the update, or am I going to have to explicitly reinstall the base/kernel from the TrueOS repo so that I can update cleanly (and then rebuild the kernel/base with my changes after the update)? Certainly, it seems like if I’m not careful here, I’m going to end up with a borked system when I try and update (which would then be revertible via boot environments, but the need to successfully update still remains).


#2

Interesting problem. I don’t know, but imagine that you be able to tell the update manager to not update a package or at the very least, set for you to manually approve/check what you want installed.
Most of the problems with FreeBSD kernel and userland getting out of sync revolve around changing kernel APIs, but there are options in KERNCONF to keep backwards compatibility for different versions.
Did you just modify KERNCONF or do you have source code mods? If just KERNCONF, what did you need that wasn’t in GENERIC? My reason for asking is that the apcupsd port used to require disabling usbhid, but using the nut port for UPS config doesn’t need that.


#3

I want to be in sync with the TrueOS repos. I just need to rebuild the kernel/base for the new version with my changes after I update. The question is what it takes to get pc-updatemanager to update everything properly before I rebuild the kernel/base. I don’t want problems caused by having the kernel/base being out of sync with the ports/packages. And with the TrueOS team doing stuff like changing the init system, it’s that much more critical to make sure that everything is in sync.

For the moment, I have to add WITHOUT_LLVM_LIBUNWIND=1 to /etc/src.conf, since the D runtime currently ends up with bus errors when exceptions are thrown and libunwind is enabled (which is now the default in CURRENT). I expect that at some point here, I’ll have time to sort out what’s going wrong and get it fixed so that libunwind will work, and I won’t need to make that change, but for now, it’s pretty critical, since I do a fair amount with D.

However, the change that I will need to make long term (and likely permanently) is that I need to disable sound support in the kernel so that I can use oss, since the sound card support in the kernel is generally sucky and ancient (e.g. AFAIK, it doesn’t support any PCI-E sound cards), and it definitely doesn’t properly support mine. So, without oss, the sound is atrocious if I get it at all. And oss doesn’t work if the sound drivers were built into the kernel, so I need a custom kernel config. Unfortunately, oss doesn’t build on FreeBSD CURRENT right now (I’m currently trying to track down which commit broke that so that I can figure out how to patch it), so I’m even more screwed on sound than normal, but once I get that sorted out, to use oss, I need a custom kernel config. And unless someone with the right expertise actually decides to make it so that FreeBSD has decent sound card support, I’m permanently stuck with oss and that custom kernel config. But since FreeBSD’s focus tends to be servers, I don’t exactly have my hopes up.


#4

Dumb question. have you talked to @kris about changing the defaut kernel?

Not sure your change could love with the default kernel, but …


#5

He did respond to a question about it once on the old mailing list and mentioned the possibility of supporting alternate kernels, but with all of the major changes that are being done, that’s obviously gone nowhere thus far. Maybe eventually, I’ll be able to just install a TrueOS kernel package that doesn’t include the sound drivers, and I can just use oss without having to do anything custom, but for now, I need to figure out how to deal with it on my own, and the libunwind problem forces me to rebuild the base with local changes anyway. So, even if there were a TrueOS kernel package without sound drivers, I’d still need a custom build until I sort out the libunwind problem.

As for changing what the the default kernel does, maybe the sound drivers could be loaded as a module so that they wouldn’t need to be built in. I don’t know. But unless someone is having issues with their soundcard, they’re likely going to want to just use the normal sound drivers, and pulseaudio doesn’t work with oss. So, making oss the default way to do sound on TrueOS wouldn’t make sense.

Regardless, the basic question is still valid, and someone else may need a custom kernel with changes that no one else would want, and they’d need to figure out how to deal with updating too. So, I think that there should be a sane way to deal with upgrading TrueOS when you need a custom kernel/base build, even if most folks are lucky enough to not need to worry about that.


#6

Thanks. Until I started using TrueOS this year, I’ve been rolling my own FreeBSD systems for a while, so I “feel your pain”. I think the fundamental issue is you want to have a mixed system; some built from source, some binary updates from pkg. I don’t know what the right answer is, but if I run across anything that may help, I’ll point it out.


#7

Its still on my radar, but its not quite as easy a fix as I had hoped.
We can add custom kernels to package base builder, no problem. The issue
comes when we figure out how to update and mark the “default” one. I.E.
there’s going to need to be some extra tooling to make sure "GENERIC"
stays the default kernel when we start pushing out others. Not
impossible, just work TODO, both in the updater, and in the system
installer.

If you can bug me about it sometime after the new years, I might be able
to spare a few cycles to do it. The OpenRC changes are now mostly down
to the easier bugfixes, and don’t need me looking so close at them.


#8

Well, it’s good to hear that I may eventually get a pre-built kernel for TrueOS that does what I need, but the original question still remains. Given the current situation and the fact that I built and installed a custom kernel and base (as packages), do I need to reinstall the ones from the TrueOS repo to upgrade with pc-updatemanager? Or will upgrading with pc-updatemanager just end up installing the new kernel and base from the TrueOS repo and work without my having to switch back to the normal TrueOS kernel and base packages before updating?


#9

Hey guys. I’m interested in testing of touchscreen drivers as explained in this thread. I also need to build custom kernel and reading this thread makes me wonder if I’ll be able to accomplish rebuild at all. I have had to rebuild kernel while ago when I was learning FreeBSD and know this is timely procedure. I noticed that already first step in editing GENERIC file on TrueOS is not the one mentioned in “uname -a” like I used on FreeBSD.


#10

I’ve done some dabbling with creating a custom kernel as well. I guess I always thought they way was:

  1. Clone source from TrueOS’s FreeBSD repo.
  2. Sync the repo to the same checkout (you can find that via uname or about)
  3. Edit, compile, and install you new kernel.
  4. Rinse and repeat steps 2 & 3 when you upgrade.

This has worked for me, but it was more just for some experiments I’ve been running myself. But as @jmdavis points out, I may not have the same /etc/src.conf as what they are using and that can cause issues. Is there a place one can look at those issues.

One idea that TrueOS could try is going with the modules-only kernel (i.e., the absolute basics are in the compiled kernel and everything else is just loaded as a module). That would make these sort of problems go away. But when I tried it last, there were still some things that worked better compiled in than they did as modules.


#11

twschulz thanks a lot. i got the same problem so i was searching for how to deal with it. thanks a lot for step by step instructions. so far i haven’t tried it but i will now. do you mind if i am going to have some questions for you to ask in the future? thanks a lot!


#12

Have you thought of trying it in a VM and see what happens? See if you can get your hands on a slightly older iso, add your custom pkgbase kernel, and then run pc-updatemanager?


#13

Sure. I would say just post the questions here (or in the thread). Remember that Boot Environments and Snapshots are your friends here. Read up on them and this experimentation becomes pretty painless. Trying in a VM as @dinsdale suggests can also work.


#14