/boot/kernel/ums.ko - unsupported file type ; link_elf_obj: symbol evdev_is_grabbed undefined

Status
Not open for further replies.

ums(4)

man.freebsd.org man.freebsd.org

Note, if you have "linker-hint" messages while booting you can fix it by running,
Code: 
kldxref /boot/kernel
This rebuilds the "hints".

Note, if you rebuild the kernel from source it should rebuild ums also.
make installkernel will put the same "version" for your kernel and ums module and make all symbols used by ums known.
 
But why I should do all this if I haven't re-compiled a custom kernel ? I'm scared that your command will break something. The only commands that I have issued before the error has been : freebsd-update fetch ; freebsd-update install. Or I should just assume that these two commands that I have issued didn't finish the upgrade process for some reason ? Anyway,which ums.ko should I use ? the older or the newer ?
 
During the loading of modules the linker is complaining. So something is broken in your current setup.
The most logical fix is bringing the kernel and all it's modules to the same version and rebuild the "hints" with kldxref.
 
When you rebuild and install the kernel the ums.ko will get overwritten to the version compatible with your kernel.
So there is only one, the one "make installkernel" installs and which will have no "symbol" errors during module loading.

Note : Have a look at "Switch branches/tags" in (click on main),
github.com

GitHub - freebsd/freebsd-src: The FreeBSD src tree publish-only repository. Experimenting with 'simple' pull requests....

The FreeBSD src tree publish-only repository. Experimenting with 'simple' pull requests.... - freebsd/freebsd-src
github.com github.com
To be certain you checkout the correct git kernel sources branch for your setup.
 
Nope I didn't undestand. You told me to do : "kldxref /boot/kernel". I presume that before to issue this command,I should place the right ums.ko file on the directory /boot/kernel. I would like to know which one. When I have this information,I will give "kldxref /boot/kernel" and then "make installkernel". Is this right ?
 
You can run "kldxref /boot/kernel" without any problem, see if it fixes something after reboot.
For building a kernel have a look at,
docs.freebsd.org

Chapter 10. Configuring the FreeBSD Kernel

This chapter covers how to configure the FreeBSD Kernel. When to build a custom kernel, how to take a hardware inventory, how to customize a kernel configuration file, etc
docs.freebsd.org docs.freebsd.org
It's not complicated.

Once you checked out the correct kernel sources you need only
Code: 
cd /usr/src
make buildkernel
make installkernel
 
Alain De Vos said:
You can run "kldxref /boot/kernel" without any problem, see if it fixes something after reboot.
For building a kernel have a look at,
docs.freebsd.org

Chapter 10. Configuring the FreeBSD Kernel

This chapter covers how to configure the FreeBSD Kernel. When to build a custom kernel, how to take a hardware inventory, how to customize a kernel configuration file, etc
docs.freebsd.org docs.freebsd.org
It's not complicated.

Once you checked out the correct kernel sources you need only
Code: 
cd /usr/src
make buildkernel
make installkernel
Click to expand...

Usualy I get the freebsd source code from here ---> https://github.com/beckhoff/freebsd-src

I think its included also the kernel sources.
 
I suggest you contact the owner of that repository. We can only support the actual FreeBSD sources, for obvious reasons.
 
I don't think that it is correlated with what is happened yesterday because yesterday I didn't get any code from the corvin's repo. I've upgraded FreeBSD from p4 to p6 using the standard procedure (freebsd-update fetch ; freebsd-update install) and only after having done this,I've got the wrong ums.ko file which frozen the system. And anyway,Corvin uses the FreeBSD main source code except for some modifications related to bhyve. The rest of the source code is not touched by him. Is ums.ko a necessary file to make bhyve work correctly ? it they are uncorrelated,there can't be interferences.
 
I think the problem is, the freebsd-update pulled a new kernel and that new kernel has problems with whatever your custom built there before.
Obviously you are the only one with this problem and it is related to your custom build and not a FreeBSD bug.
 
The /boot/kernel/ums.ko file isn't included in the p6 patch update. So it came from somewhere else.

elgrande said:
I think the problem is, the freebsd-update pulled a new kernel and that new kernel has problems with whatever your custom built there before.
Click to expand...
That's the only reasonable explanation.
 
ziomario said:
I don't think that it is correlated with what is happened yesterday because yesterday I didn't get any code from the corvin's repo. I've upgraded FreeBSD from p4 to p6 using the standard procedure (freebsd-update fetch ; freebsd-update install) and only after having done this,I've got the wrong ums.ko file which frozen the system
Click to expand...
Mixing freebsd-update with a non standard source repo is asking for trouble. If you want to rely on freebsd-update to keep your system up to date, don’t even compile the kernel locally. Conversely, if you’re compiling the kernel & the world locally, don’t rely on freebsd-update.
 
eternal_noob said:
Here are all changes to original FreeBSD:

I'd say this is a completely different OS, but this is just my humble opinion.
Click to expand...

I'm not experienced,but my common sense tells me that it depends where the commits have been done. If they are related only to a specific part of the code,to improve a feature,the resulting OS is not completely different,is different in a specific part only because all the patches are located in one only area,even if they are a lot. And that's it. Because Corvin is interested to improve bhyve and the components strictly related to it only.
 
bakul said:
Mixing freebsd-update with a non standard source repo is asking for trouble. If you want to rely on freebsd-update to keep your system up to date, don’t even compile the kernel locally. Conversely, if you’re compiling the kernel & the world locally, don’t rely on freebsd-update.
Click to expand...

I can't. I need the improved bhyve of Corvin. It is one of the main reasons I'm still using FreeBSD. Luckily until now I have been able to mix his code and the official code without having huge problems. Now I want to ask directly to him if what happened is correlated with his code and my attempt to update the system using the traditional way.
 
A bit of this and a bit of that and you end op with a Franken-/boot-directory where modules don't load because of unknown symbols. Because they belong to a different kernel-source-tree and are used out of their context.
 
The last word belongs to the developers, not to the system administrators,because the first ones have a deeper knowledge,at least,I presume,of the features that they have added.
 
ziomario said:
I can't. I need the improved bhyve of Corvin. It is one of the main reasons I'm still using FreeBSD. Luckily until now I have been able to mix his code and the official code without having huge problems. Now I want to ask directly to him if what happened is correlated with his code and my attempt to update the system using the traditional way.
Click to expand...
Not that you haven’t already been told what happened *sigh*
 
Status
Not open for further replies.
Back
Top