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

Status
Not open for further replies.
I didn't understand what you want to mean. Rephrase,please.
The problem is, you have a custom build wildly mixing components without understanding what you are doing.
From other threads I noticed you are also not willing to learn concepts, read man pages or similar.
You are building an absolutely chaotic Frankenbuild without a real plan and then you are blaming others for what you did.
Also you are asking question but do not carefully read the answers and think about them.
Anyhow you will ignore this Input since you think you are right.
Was that rephrased clearly?
 
P.S.: For the specific „problem“:
You are building from a different external source and then using freebsd-update. This is a mistake. There is no alternative view on this. You just did wrong and that is the cause of your problem. Nothing else.
 
The problem is, you have a custom build wildly mixing components without understanding what you are doing.
From other threads I noticed you are also not willing to learn concepts, read man pages or similar.
You are building an absolutely chaotic Frankenbuild without a real plan and then you are blaming others for what you did.
Also you are asking question but do not carefully read the answers and think about them.
Anyhow you will ignore this Input since you think you are right.
Was that rephrased clearly?

You seem to be an excessive conformist guy,too traditionalist and too respectful of the best practices. I think that generally this is a good approach,but for sure there are different situations where you can take risks and try new features. Usually mixing sources hasn't prevented me from completing many projects or even having fun. I can passthru my gpu with the bhyve patches created by Corvin,since 1 year or so. He also added new features that are working great but that aren't still available for who wants to use only the common widely accepted FreeBSD code and I enjoy with them a lot every day. Scrupulously respecting consolidated practices without ever experimenting is not always a source of fun. Infact, perhaps it almost never is. Since I don't use the PC for work,I can and I want to have fun,even causing some problems to my system,which I will then try to solve and I will learn from their fixing.
 
Last edited:
P.S.: For the specific „problem“:
You are building from a different external source and then using freebsd-update. This is a mistake. There is no alternative view on this. You just did wrong and that is the cause of your problem. Nothing else.

What you suggest to someone (like me),who wants to use some features that aren't yet supported officially in FreeBSD,but that anyway they are available from a developer,who are supporting them in his github ? Imagine a scenario where you need these features. How can you avoid mixing different sources ? In addition,you should also imagine that you haven't a great knowledge of the OS that you are using,not yet. In other words,I would like to know what would you do if you were in my place. Thanks.
 
Last edited:
Can someone give a look at the picture below ? I see an error message (module kernel exists,but it is the wrong version),I would like to know if it is related to vbox or to the whole system. In this case,if the kernel is wrong,why I can still boot FreeBSD ? Thanks.

Screenshot_2023-02-20_01-20-43.jpg
 
Please allow me first to share an image from the movie "young Frankenstein".


And now a serious answer.
Make sure :
1)the bootloader /boot/boot...
2)the kernel : /boot/kernel
3)the kernel modules :/boot/modules
4)the userland : /sbin;/sbin/;/usr/bin;/usr/sbin;...
5)the packages : /usr/local/...
belong TOGETHER.

Then this will work under bhyve,qemu&virtualbox without any problem.
 
Unfortunately it is very hard to give you a recommendation.
Even though, you directly see the error resulting of your action, you still do not accept you did wrong.
Let's say it like this: You ran with your head into a wall. Despite having a big bump on your head, you still deny the wall being there.
 
What you suggest to someone (like me),who wants to use some features that aren't yet supported officially in FreeBSD,but that anyway they are available from a developer,who are supporting them in his github ?
Fetch the full tree from there, build and install it as described in the handbook, simple as that. Yes, this means building THE WHOLE BASE SYSTEM. And yes, this means NEVER USE ANYTHING BUILT FROM OFFICIAL SOURCES.

Maybe you need to hear this yet another time: You can't just mix up stuff built from diverging sources, you WILL break your system.
 
This is the message that I've got now from Corvin (the developer of bhvye) regarding a probable relation between ums.ko and bhvye and,consequently,a negative effect that I can have if I mix different sources :

"ums.ko has nothing to do with bhyve"

so,in this specific case,it didn't happen. Maybe it happened that I have mixed different component by mistake (I'm not even sure),but I know for sure that Corvin does not alter the full source code of FreeBSD,but only a limited part,related to the bhyve development,and ums.ko is not included. So,no,FreeBSD is not a totally different OS because someone wants to improve some part of it. If those changes works (and for me they work good),its a better OS even if not all the patches created have been accepted yet.
 
Unfortunately it is very hard to give you a recommendation.
Even though, you directly see the error resulting of your action, you still do not accept you did wrong.
Let's say it like this: You ran with your head into a wall. Despite having a big bump on your head, you still deny the wall being there.

Do you know how scientific reasoning works? a scientist never takes a theory for granted. Every time he wants to prove something, he searches for contrary evidences to try to disassemble it. So yes, I'll take your suggestions, but after having carefully examined them using a scientific approach,like Karl Popper teaches. Scientific reasoning is counterintuitive, it insists to exhaustion on trying to destroy the theory it wants to prove.
 
Do you know how scientific reasoning works? a scientist never takes a theory for granted. Every time he wants to prove something, he searches for contrary evidences to try to disassemble it. So yes, I'll take your suggestions, but after having carefully examined them using a scientific approach,like Karl Popper teaches.
This is hillarious!
You see the error with your own eyes and do not accept you did a mistake.
You were explained the reason of the error like 10 times.
It is a technical fact why there is the error with your modules and 10 people told you the technical background. There is nothing to discuss or think about, it is just a clear technical beginner fact.
What you are doing is not scientific, it is plainly stupid and no matter how often you are told, you are not listening.
There is an exact technical reason why your modules broke. It is clear and obvious.
I do not know what to say, this is so f!?*ing stupid, I want to bang my head on the table!
 
Corvin does not alter the full source code of FreeBSD,but only a limited part
And from that, you're jumping to conclusions because you just don't understand wtf you're doing. People knowing better tell you all the time. So, just stop posting, you're not interested in the answers.

Spoiler: no, he doesn't change every single source file, still his tree is on a very different state than the head of the official 13.1 release tree (as well as the head of main/CURRENT).

Just STOP MIXING STUFF. And if you continue to do, complain somwhere else.
 
In addition,you should also imagine that you haven't a great knowledge of the OS that you are using,not yet. In other words,I would like to know what would you do if you were in my place.
I would do one of the following:
  1. accept the limitations of what is officially supported.
  2. find an alternate repo that supports the features I want and accept *its* limitations since such forks usually don't keep up to date with the official repo. The main reason is the fork maintainer will have to constantly merge with the official changes.
  3. If I cared enough, I would roll up my sleeves and figure things out on my own. That involves reading code, experimenting etc.
Each has its pros and cons. For instance freebsd-update can't be used with 2. or 3.

What I would not do is rely on more than one repo. Mixing things up is asking for trouble. What I would not do is rely on advice from multiple posters here as each person is likely going to assume something different and following everyone’s advice is a recipe for confusion.
 
freebsd-update is unaware of the Beckhoff-kernel.
So the likelyhood running freebsd-update will break the specific Beckhoff-kernel&modules is high.
My feeling is it is a bad idea in your specific setup.
 
This is hillarious!
You see the error with your own eyes and do not accept you did a mistake.
You were explained the reason of the error like 10 times.
It is a technical fact why there is the error with your modules and 10 people told you the technical background. There is nothing to discuss or think about, it is just a clear technical beginner fact.
What you are doing is not scientific, it is plainly stupid and no matter how often you are told, you are not listening.
There is an exact technical reason why your modules broke. It is clear and obvious.
I do not know what to say, this is so f!?*ing stupid, I want to bang my head on the table!

Please try to take a moment to read carefully what I wrote : comment 61. I'm more sure that an error happened because my mistake (a mistake that I still haven't figured out,because there is a perfect timing that makes me perplexed (it appeared only after trying the upgrade with the official tool) than a conflict between the code of Corvin and the official code of FreeBSD. I'm also not sure that I'm using the Beckoff kernel. I'm not happy to say that I know that I don't know and my "work" is really hard because I'm trying to navigate inside a sea of uncertainties to find some small certainty. For sure I don't doubt of your precious suggestions, but I'm not sure if I have to apply them in this specific case or in some other cases, because I don't fully understand what are the consequences of some of my actions to the system. It can happen when you are still a newbie and you want to drive a complicated system like FreeBSD. So,please be patient. It has really no sense to blame someone like me that,despite all the errors that I make,I love FreeBSD and I spend a lot of time and efforts to learn,to experiment and to try to understand your considerations. With that said,an harsh tone in which someone of you is writing doesn't help me. Anyway,I'm going to upgrade the almost EOL 13.1 with the new 13.2 using this procedure :

Code:
# setenv  EDITOR  /usr/local/bin/nano
# setenv  VISUAL  /usr/local/bin/nano
# cd /usr
# zfs rename zroot/usr/src zroot/usr/src-old
# git clone https://git.FreeBSD.org/src.git /usr/src
# cd /usr/src
# git checkout releng/13.2
# make -j4 buildworld
# make -j4 kernel
# shutdown -r now
# etcupdate -p
# cd /usr/src
# make installworld
# etcupdate -B
# shutdown -r now
# etcupdate resolve

I hope its good.
 
It can happen when you are still a newbie and you want to drive a complicated system like FreeBSD.
FreeBSD is not a complicated system. You break it by messing around with parts you don't understand and shouldn't touch if you consider yourself a "newbie".
 
Please try to take a moment to read carefully what I wrote : comment 61. I'm more sure that an error happened because my mistake (a mistake that I still haven't figured out,because there is a perfect timing that makes me perplexed (it appeared only after trying the upgrade with the official tool) than a conflict between the code of Corvin and the official code of FreeBSD. I'm also not sure that I'm using the Beckoff kernel.
If you would actually bother to read the replies to your posts, you would have been answered exactly what you are talking about here.

!! DISCLAIMER !! PLEASE READ !! HERE IS THE EXPLANATION FOR YOUR ISSUE !!! REALLY !! JUST BELOW THIS !! PLEASE READ BELOW !! DO NOT SKIP !! READ THE ANSWER !! HERE IT IS !!

1. freebsd-updated pulled a new kernel. The FreeBSD standard kernel.
2. So you are not running a beckhoff kernel anymore but the one installed by 1.
3. Your modules previously compiled for the beckhoff kernel do not fit anymore to the kernel because of 1. and 2.
 
If you would actually bother to read the replies to your posts, you would have been answered exactly what you are talking about here.

!! DISCLAIMER !! PLEASE READ !! HERE IS THE EXPLANATION FOR YOUR ISSUE !!! REALLY !! JUST BELOW THIS !! PLEASE READ BELOW !! DO NOT SKIP !! READ THE ANSWER !! HERE IT IS !!

1. freebsd-updated pulled a new kernel. The FreeBSD standard kernel.
2. So you are not running a beckhoff kernel anymore but the one installed by 1.
3. Your modules previously compiled for the beckhoff kernel do not fit anymore to the kernel because of 1. and 2.

Yes,now I remember. Its happened when I have tried to apply the virtio-input emulation patch for the 13.1 (originally it wasn't written for the 13.1,but he tries to add it in his repo and I got it because I was not using 13.2 yet (it has been included officially on the 13.2). Corvin said that it is a kernel patch. But taking in consideration that I have upgraded the system a lot of time using the standard procedure and I never seen that error,it means that every patch created by Corvin for bhyve does not touch the official kernel.
 
Yes,now I remember. Its happened when I have tried to apply the virtio-input emulation patch for the 13.1 (it has been included officially on the 13.2). Corvin says that it is a kernel patch. But taking in consideration that I have upgraded the system a lot of time using the standard procedure and I never seen that error,it means that every patches created by Corvin for bhyve does not touch the official kernel.
read again. carefully. try to understand the 3 points I told you. really. it may seem strange to do so, think about them.
if you have question, tell me which of the 3 points you do not understand.
let's go step by step.
 
Yes,now I remember. Its happened when I have tried to apply the virtio-input emulation patch for the 13.1 (originally it wasn't written for the 13.1,but he tries to add it in his repo and I got it because I was not using 13.2 yet (it has been included officially on the 13.2). Corvin says that it is a kernel patch. But taking in consideration that I have upgraded the system a lot of time using the standard procedure and I never seen that error,it means that every patches created by Corvin for bhyve does not touch the official kernel.
If there is no problem we can consider the problems as fixed/solved. :)
 
Status
Not open for further replies.
Back
Top