Re: how to find dependencies when building a new kernel
On Wed, 30 Nov 2011 21:05:05 +0100 Jan Stary h...@stare.cz wrote: On Nov 30 10:26:46, T. Valent wrote: sure will solve what you have understood to be my problem. But what really annoys me here is that I'm not taken seriously when I say this isn't an option. Why don't you just believe my words instead of permanently speaking about things that I explicitly said are impossible? Because if someone simply says this is impossible, it is only natural to ask why is that impossible?. How does that annoy you? (Solving your problem is impossible. Really. Don't waste your time asking why.) Did you read my mail in which I said that the hardware cannot be changed? A new flashcard would be a change in hardware. So the 32MB storage is a CF card? Don't be surprised that people ask, because it begs the question (no really, it does): why can't you put a bigger CF card in there that would just hold GENERIC? No, really: why? Answering this question will take a few minutes of our time. I think you know that. You just don't take my words seriously and keep talking about things that I already said are not possible in this project. Why discuss this? From my point of view it's not me wasting your time, but it's you wasting your time, because you don't really care about what I said. The overall project is about updating multiple systems How many multiple systems? that are in production. By _just_ using just a software update. Changes in hardware are not an option. Putting, say, a bigger CF card in them is a change in hardware, granted. Would that change eliminate the need for the whole process of maintaining custom kernels and custom stripped down systems? If not, why? dmesg output of any of these devices would be possible, but like I said it's a very stripped down environment. dmesg is not part of it. I'd have to setup an old system with dmsg on it, So, at some point, you had a system on it that had dmesg(1). How long does it take to put that system on it again and run dmesg(1)? (That's not a rhetorical question that wants to be sarcastic - that's an honest question). Generally, how long does it take to put a new system in, once it is built? then export the output, just to convince you of what I've done in the past. Then, after I've proven my point with this dmesg output, we'd be no step further, Yes we would: we would know your hardware from OpenBSD's point of view. because like I said often enough now, I'm not interested in a hint like add this line to your config, but I want to learn about what steps to do, next time I run into the same problem (which I probably will with the next OpenBSD release that I want to migrate the systems to). If you can help me by explaining where to look and what to read to learn how to build the smallest custom kernels possible, I'd be happy. You have been told several times already: strip GENERIC down to what will fit on your system. Start with things you definitely do not need (sound? wifi?), then continue with the rest. If things break, put the last thing that you removed back there. It is a way to arrive at the smallest possible kernel that works for you. Isn't it? What he rather need is to boot GENERIC, then record dmesg, and strip the kernel down according to that dmesg.
Re: how to find dependencies when building a new kernel
So: your machine has 32MB of Flash storage that holds the entire system. On boot, it all gets loaded as a RAMDISK. Right? Doesn't have to do with my question, but: more or less correct. It certainly sounds interesting. Out of curiosity: what do these system do? Are their routers? Rocket launchers? These machines are used for measuring and controlling. (In German: Steuerungscomputer). Now come on. I got complaints about wasting peoples time. Let's not talk about things that have absolutely nothing to do with my problem. I can provide a dmesg from a virtual machine A dmesg from the actual machine would; really, it would. The dmesg I provided is not from one of the production machines, but from a VM on which I wasn't yet able to compile a minimal kernel, too. So if you say the dmesg helps, there you are! If I got a custom kernel on that VM (and would know WHY I had to add the lines that I had to add to get it running), I'm pretty sure, I'd get the kernel running on that embedded system, too. Because if someone simply says this is impossible, it is only natural to ask why is that impossible?. Might be a question of culture. For me this doesn't sound natural. If I'm being asked a question and given (detailed?) circumstances, I'd try to answer and take the circumstances as they are. I believe the person asking me might have reasons to tell me that this and that ain't possible, otherwise he wouldn't have said it, right? (Solving your problem is impossible. Really. Don't waste your time asking why.) This is the exact kind of answer you have to expect in certain situations. Why should I question the conclusion of an expert that I asked? If I knew better, why should I ask an expert? Say you ask a lawyer about what to do after you've stolen a Picasso and while you tried to sell it somewhere, it caught fire and was burned down. You tell the lawyer that there's no way you can give it back and you need an advice. Would you find it natural that the lawyer ignores that you said you cannot give it back and instead keeps on asking questions about where you burnt it, what you burnt it with, how hot the fire was, where the ashes are now and what the painting smelled like? I am an expert for the circumstances of this very defined little problem I have. I was seeking for help to find an answer to the question Which drivers are required for proper system functioning. That's it. I doubt that this is a question that cannot be answered. And I doubt that answering this question has to do with the hardware or what it is used for. So the 32MB storage is a CF card? Don't be surprised that people ask, because it begs the question (no really, it does): why can't you put a bigger CF card in there that would just hold GENERIC? No, really: why? Answering this question will take a few minutes of our time. These machines (100) are not on site here. The flash mem is inside a box which the people who run the box would have to screw open. The one reason that should stop all discussion about this: The project goal is to update existing systems by software only. Ever been given a project and then tried to discuss the project goals because you didn't find the solution (required lines in the config) within 3 days? I'm sure I can solve this since I have been able to in the past. I was just seeking for help to maybe find a quicker and more structured way than fiddling around with the config. How long does it take to put that system on it again and run dmesg(1)? (That's not a rhetorical question that wants to be sarcastic - that's an honest question). Generally, how long does it take to put a new system in, once it is built? That would be a second step. I'd need a running kernel on this test machine from which I gave the dmesg already, anyway. So until I don't have a running minimal kernel on this VM, it's not worth the effort. If I then don't get the kernel running on the production machine, that would be a point at which it would make sense to get the dmesg output of the production machines. But I'm not there yet. You have been told several times already: strip GENERIC down to what will fit on your system. Start with things you definitely do not need (sound? wifi?), then continue with the rest. If things break, put the last thing that you removed back there. It is a way to arrive at the smallest possible kernel that works for you. Isn't it? That's the way I've done it in the past (since OpenBSD 3.5). Because this is a lot of work to be done each time I'd update to a new OpenBSD version (which I admit I haven't done with every release), I was thinking I'd better try to understand what is really required at minimum. And then do it the other way round: Start with an empty file and add the entries I found to be required. To achieve this goal, I asked you folks. What I've learned now from this discussion is: Either there is no way to do it bottom up, or you folks don't know it either. Anyway, while
Re: how to find dependencies when building a new kernel
On 2011 Dec 01 (Thu) at 09:44:25 +0100 (+0100), T. Valent wrote: : You have been told several times already: strip GENERIC down to what : will fit on your system. Start with things you definitely do not need : (sound? wifi?), then continue with the rest. If things break, put : the last thing that you removed back there. It is a way to arrive : at the smallest possible kernel that works for you. Isn't it? : :That's the way I've done it in the past (since OpenBSD 3.5). Please compare the values you used in the previous release (I'm guessing 4.9), vs what you are attempting in this release. Since users (and developers) pretty much /only/ use GENERIC, there are many options which are not optional. We don't look for them, and many of them are required for proper use. Essentially, you are one of the very very few that does this. The only advice we can give is to do the top-down method of stripping out options. I know you don't want to do it, but it is what it is. -- Adolescence, n.: The stage between puberty and adultery.
Re: how to find dependencies when building a new kernel
On Tue, Nov 29, 2011 at 11:09:25PM +, Stuart Henderson wrote: On 2011-11-29, Torsten Valentin valen...@4ss.de wrote: welcome to the ignore list of many developers. You aren't even following directions on how to hurt yourself properly without wasting people's time. I always found that people waste my time when they write explanations and tons of bla bla that does not have to do with the issue itself, instead of just writing about what the problem really is. Because of the permanent repeating of USE THE GENERIC KERNEL instead of answering any questions that have to do with my problem: That's because your problem is not worth wasting other people's time on solving if you aren't prepared to do it yourself. If you really want that, tell us how much you're prepared to spend, maybe someone would be willing to sell you time to solve that very specific problem since obviously, no OpenBSD developer wants to do it for free, as it's considered a waste of time that could otherwise benefit the project for useful purposes...
Re: how to find dependencies when building a new kernel
@Gregory What he rather need is to boot GENERIC, then record dmesg, and strip the kernel down according to that dmesg. That is exactly what I've done and this led me to my first posting here, because it generally worked fine, but only to a certain extend. It didn't work completely. Something is still missing. With the help of Andres Perara I got one step further, means, I found one more dependency. After I could not find the dependency of the dependency, he pointed me to this: The npx driver is required for proper system functioning regardless of whether or not an NPX is present. so there's no 1:1 mapping between the devices you have and the ones you may need included in the kernel config. could potentially apply to other drivers So, unfortunately, it's not as easy as you and I thought. @Peter Please compare the values you used in the previous release (I'm guessing 4.9), vs what you are attempting in this release. Unfortunately I have to admit that I was a bit lazy and did not update for quite a while. The latest kernel config files I stripped down were from 4.3. So nearly 4 years ago. And even then I was just stripping down as much as was obvious to me would not be needed for me. I continued removing parts of the config until my goal was reached to have a small enough kernel. Now the kernel is much bigger than in 4.3 so I need to get rid of more stuff than I had to before. So comparing the config files could maybe help a bit, but won't generally solve my problem. Since users (and developers) pretty much /only/ use GENERIC, there are many options which are not optional. We don't look for them, and many of them are required for proper use. Yeah, I know and I don't think that this is a problem with OpenBSD. However, I'm in an unusual situation not comparable to the standard user or developer. I have a very special demand. I'm asking if anybody can tell me anything about how to find out which optional parameters aren't actually really optional. Essentially, you are one of the very very few that does this. I agree here. The only advice we can give is to do the top-down method of stripping out options. I know you don't want to do it, but it is what it is. Nah, it's not that I don't want to do it. It's just that I was searching for a better way. It seems there is none. Which is OK with me. Just asking. @marc If you really want that, tell us how much you're prepared to spend, maybe someone would be willing to sell you time to solve that very specific problem since obviously, no OpenBSD developer wants to do it for free, as it's considered a waste of time that could otherwise benefit the project for useful purposes... Well, I'd be ready to spend money for this, if that would mean a future change in the kernels config files in a way that mandatory options are marked as such. But that to happen is very unlikely. So it would only be a solution for 5.0 and it may happen that with 5.1 there is a new mandatoy driver which depends on another driver that's included in GENERIC but not in my configs and then I'd have to start all over. So thanks for the offer, but I'm not afraid of working my way through this. I was always just asking if there might be a more clever way which I just didn't know. Regards, T.
Re: how to find dependencies when building a new kernel
On Thu, Dec 01, 2011 at 12:08:38PM +0100, T. Valent wrote: @marc If you really want that, tell us how much you're prepared to spend, maybe someone would be willing to sell you time to solve that very specific problem since obviously, no OpenBSD developer wants to do it for free, as it's considered a waste of time that could otherwise benefit the project for useful purposes... Well, I'd be ready to spend money for this, if that would mean a future change in the kernels config files in a way that mandatory options are marked as such. But that to happen is very unlikely. So it would only be a solution for 5.0 and it may happen that with 5.1 there is a new mandatoy driver which depends on another driver that's included in GENERIC but not in my configs and then I'd have to start all over. So thanks for the offer, but I'm not afraid of working my way through this. I was always just asking if there might be a more clever way which I just didn't know. Ok, so I'll bite and give you a hint, just to end this thread. Use the config from RAMDISK as a starting point. It will produce a useable, small kernel. It wil have a ramdisk as root, but that should be easy to change. Of course drivers for your hardware might be missing, but at least you have a compiling kernel. But be warned: RAMDISK kernels miss some stuff you might actually need or want. Can we end this now? -Otto
Re: how to find dependencies when building a new kernel
Otto, thanks for your hint. Can we end this now? I thought I had initiated the end of this thread this morning by writing: I'm happy that some of you took the time and tried to explain over and over again what you thought was best for me. I really appreciate the good will. But I have to admit I cannot resist answering if someone comments on my mail. :-)
Re: how to find dependencies when building a new kernel
* T. Valent tmp...@4ss.de [2011-12-01 10:19]: It certainly sounds interesting. Out of curiosity: what do these system do? Are their routers? Rocket launchers? These machines are used for measuring and controlling. (In German: Steuerungscomputer). Now come on. I got complaints about wasting peoples time. Let's not talk about things that have absolutely nothing to do with my problem. out of curiosity was pretty clear, no? isn't it kinda natural that people are interested in uncommon use cases of the OS they write / are part of the community? I can provide a dmesg from a virtual machine A dmesg from the actual machine would; really, it would. The dmesg I provided is not from one of the production machines, but from a VM on which I wasn't yet able to compile a minimal kernel, too. So if you say the dmesg helps, there you are! still doesn't help a bit for figuring out what you might need on your production system. Because if someone simply says this is impossible, it is only natural to ask why is that impossible?. Might be a question of culture. For me this doesn't sound natural. If I'm being asked a question and given (detailed?) circumstances, I'd try to answer and take the circumstances as they are. I believe the person asking me might have reasons to tell me that this and that ain't possible, otherwise he wouldn't have said it, right? people often incorrectly assume an impossible is a given. when it isn't really. and instead of stupid ways to work around the problem you can give them a beter solution. your situation is partially exactly that, see below. Say you ask a lawyer about what to do after you've stolen a Picasso and while you tried to sell it somewhere, it caught fire and was burned down. You tell the lawyer that there's no way you can give it back and you need an advice. Would you find it natural that the lawyer ignores that you said you cannot give it back and instead keeps on asking questions about where you burnt it, what you burnt it with, how hot the fire was, where the ashes are now and what the painting smelled like? the lawyer would care about the why is it impssible to give back. and your answers to the why? aren't as convincing as a can't give back anytjing but the ashes. So the 32MB storage is a CF card? Don't be surprised that people ask, because it begs the question (no really, it does): why can't you put a bigger CF card in there that would just hold GENERIC? No, really: why? Answering this question will take a few minutes of our time. These machines (100) are not on site here. The flash mem is inside a box which the people who run the box would have to screw open. so. the decision to employ such a crippled system instead of using bigger flash was a bad one. you can try to work around that or draw the right conclusion - the extra cost for a flash card of a reasonable size, yes even hundreds of cases, can't be cheaper than the (not free) work time it takes you to build your strange images. now with a reasonable flash where you could just use mostly-standard kernels... of course that doesn't help you with your installed base. the question wether it is really a clever idea to invest a lot of time to build a system that fits in 32M (repeatedly, not just once) versus upgrading flash - which, yes, costs money too - is a valid one. Ever been given a project and then tried to discuss the project goals because you didn't find the solution (required lines in the config) within 3 days? when the goals were stupid (and too specific, the real goal was usually another from which the wrong conclusions lead to the project goals), yes, repeatedly. a good move. You have been told several times already: strip GENERIC down to what will fit on your system. Start with things you definitely do not need (sound? wifi?), then continue with the rest. If things break, put the last thing that you removed back there. It is a way to arrive at the smallest possible kernel that works for you. Isn't it? That's the way I've done it in the past (since OpenBSD 3.5). Because this is a lot of work to be done each time I'd update to a new OpenBSD version (which I admit I haven't done with every release), I was thinking I'd better try to understand what is really required at minimum. And then do it the other way round: Start with an empty file and add the entries I found to be required. To achieve this goal, I asked you folks. you have been given the answer repeatedly: start with GENERIC(.MP) and start stripping. you don't like the answer, but that doesn't make it wrong or bad or anything like that. What I've learned now from this discussion is: Either there is no way to do it bottom up, or you folks don't know it either. what do you expect? us explaining you every single line in GENERIC? ridiculous. offload YOUR job to the community. awesome. that rightly fails. and yes, there is very little knowledge about stripping kernels in the community
Re: how to find dependencies when building a new kernel
* Henning Brauer lists-open...@bsws.de [2011-12-01 13:21]: the extra cost for a flash card of a reasonable size, yes even hundreds of cases, can't be cheaper than the (not free) work time it takes you to build your strange images. err... that is pretty much the opposite of what I wanted to say. can be cheaper of course. can easily. -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services, http://bsws.de, Full-Service ISP Secure Hosting, Mail and DNS Services. Dedicated Servers, Root to Fully Managed Henning Brauer Consulting, http://henningbrauer.com/
Re: how to find dependencies when building a new kernel
On Thu, Dec 01, 2011 at 09:44:25AM +0100, T. Valent wrote: So: your machine has 32MB of Flash storage that holds the entire system. On boot, it all gets loaded as a RAMDISK. Right? Doesn't have to do with my question, but: more or less correct. It certainly sounds interesting. Out of curiosity: what do these system do? Are their routers? Rocket launchers? These machines are used for measuring and controlling. (In German: Steuerungscomputer). Now come on. I got complaints about wasting peoples time. Let's not talk about things that have absolutely nothing to do with my problem. Every little bit helps when you are attempting to attract help! Working on a device that will measure and control atomic energy plants to make Fukashima's impossible may well elicit more interest and thus potential solutions than a device measuring and controlling an espresso machine to produce a perfect cup of espresso. Or visa versa. Reluctance to describe the device can be taken as proving it is a NSA/Mossad/etc project to finally measure and control all communications. It seems well established by now that there is no magic bullet for your problem, since it is a problem few if anyone has had to address before within the constraints you have described. Ken
Re: how to find dependencies when building a new kernel
It seems well established by now that there is no magic bullet for your problem, since it is a problem few if anyone has had to address before within the constraints you have described. This is a good summary for that quite long thread. Again, thanks to everybody! I really do appreciate all your contributions. T.
Re: how to find dependencies when building a new kernel
On Thu, 01 Dec 2011 12:08:38 +0100 T. Valent wrote: Yeah, I know and I don't think that this is a problem with OpenBSD. However, I'm in an unusual situation not comparable to the standard user or developer. I have a very special demand. I'm asking if anybody can tell me anything about how to find out which optional parameters aren't actually really optional. What size do you need to get your kernel down to? If mines small enough I could share mine but if your having this much difficulty then I imagine you need to go further than what I do.
Re: how to find dependencies when building a new kernel
On Dec 01 09:44:25, T. Valent wrote: Because if someone simply says this is impossible, it is only natural to ask why is that impossible?. Might be a question of culture. For me this doesn't sound natural. If I'm being asked a question and given (detailed?) circumstances, I'd try to answer and take the circumstances as they are. I believe the person asking me might have reasons to tell me that this and that ain't possible, otherwise he wouldn't have said it, right? (Solving your problem is impossible. Really. Don't waste your time asking why.) This is the exact kind of answer you have to expect in certain situations. Why should I question the conclusion of an expert that I asked? If I knew better, why should I ask an expert? Say you ask a lawyer about what to do after you've stolen a Picasso and while you tried to sell it somewhere, it caught fire and was burned down. You tell the lawyer that there's no way you can give it back and you need an advice. Would you find it natural that the lawyer ignores that you said you cannot give it back and instead keeps on asking questions about where you burnt it, what you burnt it with, how hot the fire was, where the ashes are now and what the painting smelled like? That's a very weak analogy. A better analogy would be - So why don't you give the painting back? - That's impossible. - Why is it impossible? - Because I burned it. Can you spot the difference between this and the following? - So why don't you put a bigger CF card in there? - That's impossible. - Why is that impossible? - Don't ask. I am an expert for the circumstances of this very defined little problem I have. I was seeking for help to find an answer to the question Which drivers are required for proper system functioning. That's it. No, that's not it. You have said several times that you are NOT looking for an answer that goes add these three lines and it will work. Isn't that exactly adding the drivers that are required? I doubt that this is a question that cannot be answered. And I doubt that answering this question has to do with the hardware or what it is used for. LOLWUT? The set of pieces required to be in the kernel does not depend on which hardware you run? So the 32MB storage is a CF card? Don't be surprised that people ask, because it begs the question (no really, it does): why can't you put a bigger CF card in there that would just hold GENERIC? No, really: why? Answering this question will take a few minutes of our time. These machines (100) are not on site here. The flash mem is inside a box which the people who run the box would have to screw open. See? If you spent ten seconds putting this into your first email, nobody would question that it is indeed ruled out. The one reason that should stop all discussion about this: The project goal is to update existing systems by software only. Ever been given a project and then tried to discuss the project goals because you didn't find the solution (required lines in the config) within 3 days? I'm sure I can solve this since I have been able to in the past. I am sure you can (no sarcasm here), and that you have. So why don't you do the same you did before? What *did* you do before? Strip GENERIC down to what you absolutely need to have? Did it work? I was just seeking for help to maybe find a quicker and more structured way than fiddling around with the config. By definition, you *are* fiddling with kernel config. You have been told several times already: strip GENERIC down to what will fit on your system. Start with things you definitely do not need (sound? wifi?), then continue with the rest. If things break, put the last thing that you removed back there. It is a way to arrive at the smallest possible kernel that works for you. Isn't it? That's the way I've done it in the past (since OpenBSD 3.5). Because this is a lot of work to be done each time I'd update to a new OpenBSD version (which I admit I haven't done with every release), I was thinking I'd better try to understand what is really required at minimum. And then do it the other way round: Start with an empty file and add the entries I found to be required. To achieve this goal, I asked you folks. What I've learned now from this discussion is: Either there is no way to do it bottom up, or you folks don't know it either. I don't think there is a way to arrive to a minimal working kernel from below that would be easier/faster than striping down to a minimal kernel from above. Not if you know the internal dependencies in various parts of the kernel. (I sure don't.) Some of that information probably lives in the set of Makefiles in the src tree.
Re : how to find dependencies when building a new kernel
Hello, De : Kevin Chadwick ma1l1i...@yahoo.co.uk Split your config in half, choose the half you think is most likely to cause the problem and diff that half back to defaults and compile. Just to ack what Kevin says. You're trying to add and remove too many different things at once. First take the Generic kernel and add the driver that you wanted, compile. Then remove unecessary drivers from one type of hardware (for example soundcards), compile, repeat the process with other drivers (joysticks, scanners...). Make sure that you backup all working config files and restart from the last config that worked. The other way is to do like you did, add and remove options from the Generic kernel (keep a copy of it) but it requires the ability to understand the output when the compilation fails. Also if you understood what Vitali wrote, it should be quite straight forward to remove options in the kernel and then be able to compile it smoothly. I used to run a Custom kernel and removed as many options as I could but when something went wrong (in most cases I wanted to install a new software) I always wondered if that was due to my kernel, so each time I had to reboot on Generic and restarted to troubleshoot from there. Now I just find it more convenient to run Generic since I don't have specific requirements. However, I think that it's not a reason to say don't compile a Custom kernel (this is not a troll). It's part of a general OpenBSD knowledge to be able to build a Custom kernel. And this is different from I've built a Custom kernel, it compiled fine, but the system acts funny/wrong sometimes. Have a nice day
Re: how to find dependencies when building a new kernel
Stuart, I really don't want to be misunderstood: I really appreciate the help that's being offered from various users of this ML. However, the following is somewhat off topic as it does not contribute to the thread itself. Because of the permanent repeating of USE THE GENERIC KERNEL not worth wasting other people's time on solving if you aren't prepared to do it yourself. I'm not with you here. I'm really doing my best to try and learn how to solve my problems myself. I'm just asking for help and explanations to things that I don't understand. As far as I understand, that's what MLs are about. Alternatively: here's a nickel, get a flashcard from sometime later than 2005... I really understand that a lot of people are asking stupid questions in MLs and I'm pretty sure I've done so myself quite often. I take this as an explanation why you keep telling me things of which you probably are sure will solve what you have understood to be my problem. But what really annoys me here is that I'm not taken seriously when I say this isn't an option. Why don't you just believe my words instead of permanently speaking about things that I explicitly said are impossible? Did you read my mail in which I said that the hardware cannot be changed? A new flashcard would be a change in hardware. I think you know that. You just don't take my words seriously and keep talking about things that I already said are not possible in this project. Why discuss this? From my point of view it's not me wasting your time, but it's you wasting your time, because you don't really care about what I said. The overall project is about updating multiple systems that are in production. By _just_ using just a software update. Changes in hardware are not an option. dmesg output of any of these devices would be possible, but like I said it's a very stripped down environment. dmesg is not part of it. I'd have to setup an old system with dmsg on it, then export the output, just to convince you of what I've done in the past. Then, after I've proven my point with this dmesg output, we'd be no step further, because like I said often enough now, I'm not interested in a hint like add this line to your config, but I want to learn about what steps to do, next time I run into the same problem (which I probably will with the next OpenBSD release that I want to migrate the systems to). If you can help me by explaining where to look and what to read to learn how to build the smallest custom kernels possible, I'd be happy. If not, well, without any sarcasm: please don't waste your valuable time with this thread. T.
Re: how to find dependencies when building a new kernel
Thanks to everybody. I'll dig deeper into the config files soon. For now I think we've got it discussed as much as is possible in a ML.
Re: how to find dependencies when building a new kernel
On Wed, 30 Nov 2011, T. Valent wrote: SNIP dmesg output of any of these devices would be possible, but like I said it's a very stripped down environment. dmesg is not part of it. I'd have to setup an old system with dmsg on it, then export the output, just to dmesg is the lazy way to get this info, the same info is written to /var/log/messages during boot. Are you saying your system is so stripped down you don't even log anything? diana Past hissy-fits are not a predictor of future hissy-fits. Nick Holland(06 Dec 2005)
Re: how to find dependencies when building a new kernel
dmesg is the lazy way to get this info, the same info is written to /var/log/messages during boot. Are you saying your system is so stripped down you don't even log anything? Yep. And because the only persistent memory is Flash (32MB, which quickly dies if you permanently write to it), the whole system runs inside a RAMDISK only. And there is no terminal or ssh. Modifying the system means setting up a new system with modified /sbin/init each time. Hard to believe, I know, but what people do with OpenBSD is sometimes quite different from what you know from usual systems. I said it's embedded stuff. I said hardware cannot be changed. I said I cannot easily provide this info. There certainly is a way, but it's not worth the effort. I can provide a dmesg from a virtual machine that we use for testing purposes, but obviously that's not the same as the system that the kernel is going to be running on later in production environment. But, hey, yet, I haven't been able to compile the kernel on this testing machine, either. I explain this so elaborately because I know I'd otherwise get replies like: What did you tell us about having little memory and such, this is a usual virtual machine and therefor you've got no need to use a custom kernel... ;-) You know what I mean... My goal is to have kernel config files that will do on both, the virtual machine for testing and the production environment. Being able to compile a custom kernel on this VM would be a good first step. From there on I could add the drivers I need on the production machine and that way get closer to a final solution... I'm very curious how dmesg will help... OpenBSD 5.0 (GENERIC) #43: Wed Aug 17 10:10:52 MDT 2011 dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC cpu0: Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz (GenuineIntel 686-class) 3 GHz cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,SSE3,SSSE3,CX16,SSE4.1 real mem = 267907072 (255MB) avail mem = 253472768 (241MB) mainbus0 at root bios0 at mainbus0: AT/286+ BIOS, date 09/22/09, BIOS32 rev. 0 @ 0xfd780, SMBIOS rev. 2.4 @ 0xe0010 (98 entries) bios0: vendor Phoenix Technologies LTD version 6.00 date 09/22/2009 bios0: VMware, Inc. VMware Virtual Platform acpi0 at bios0: rev 2 acpi0: sleep states S0 S1 S4 S5 acpi0: tables DSDT FACP BOOT APIC MCFG SRAT acpi0: wakeup devices PCI0(S3) USB_(S1) P2P0(S3) S1F0(S3) S2F0(S3) S3F0(S3) S4F0(S3) S5F0(S3) S6F0(S3) S7F0(S3) S8F0(S3) S9F0(S3) Z00P(S3) Z00Q(S3) Z00R(S3) Z00S(S3) Z00T(S3) Z00U (S3) Z00V(S3) Z00W(S3) Z00X(S3) Z00Y(S3) Z00Z(S3) Z010(S3) Z011(S3) Z012(S3) Z013(S3) Z014(S3) Z015(S3) Z016(S3) Z017(S3) Z018(S3) Z019(S3) Z01A(S3) Z01B(S3) P2P1(S3) S1F0(S3) S2F 0(S3) S3F0(S3) S4F0(S3) S5F0(S3) S6F0(S3) S7F0(S3) S8F0(S3) S9F0(S3) Z00P(S3) Z00Q(S3) Z00R(S3) Z00S(S3) Z00T(S3) Z00U(S3) Z00V(S3) Z00W(S3) Z00X(S3) Z00Y(S3) Z00Z(S3) Z010(S3) Z0 11(S3) Z012(S3) Z013(S3) Z014(S3) Z015(S3) Z016(S3) Z017(S3) Z018(S3) Z019(S3) Z01A(S3) Z01B(S3) P2P2(S3) S1F0(S3) S2F0(S3) S3F0(S3) S4F0(S3) S5F0(S3) S6F0(S3) S7F0(S3) S8F0(S3) S 9F0(S3) Z00P(S3) Z00Q(S3) Z00R(S3) Z00S(S3) Z00T(S3) Z00U(S3) Z00V(S3) Z00W(S3) Z00X(S3) Z00Y(S3) Z00Z(S3) Z010(S3) Z011(S3) Z012(S3) Z013(S3) Z014(S3) Z015(S3) Z016(S3) Z017(S3) Z018(S3) Z019(S3) Z01A(S3) Z01B(S3) P2P3(S3) S1F0(S3) S2F0(S3) S3F0(S3) S4F0(S3) S5F0(S3) S6F0(S3) S7F0(S3) S8F0(S3) S9F0(S3) Z00P(S3) Z00Q(S3) Z00R(S3) Z00S(S3) Z00T(S3) Z00U(S3) Z00V(S3) Z00W(S3) Z00X(S3) Z00Y(S3) Z00Z(S3) Z010(S3) Z011(S3) Z012(S3) Z013(S3) Z014(S3) Z015(S3) Z016(S3) Z017(S3) Z018(S3) Z019(S3) Z01A(S3) Z01B(S3) PE40(S3) S1F0(S3) PE50(S3 ) S1F0(S3) PE60(S3) S1F0(S3) PE70(S3) S1F0(S3) PE80(S3) S1F0(S3) PE90(S3) S1F0(S3) PEA0(S3) S1F0(S3) PEB0(S3) S1F0(S3) PEC0(S3) S1F0(S3) PED0(S3) S1F0(S3) PEE0(S3) S1F0(S3) PE41(S 3) S1F0(S3) PE42(S3) S1F0(S3) PE43(S3) S1F0(S3) PE44(S3) S1F0(S3) PE45(S3) S1F0(S3) PE46(S3) S1F0(S3) PE47(S3) S1F0(S3) PE51(S3) S1F0(S3) PE52(S3) S1F0(S3) PE53(S3) S1F0(S3) PE54( S3) S1F0(S3) PE55(S3) S1F0(S3) PE56(S3) S1F0(S3) PE57(S3) S1F0(S3) PE61(S3) S1F0(S3) PE62(S3) S1F0(S3) PE63(S3) S1F0(S3) PE64(S3) S1F0(S3) PE65(S3) S1F0(S3) PE66(S3) S1F0(S3) PE67 (S3) S1F0(S3) PE71(S3) S1F0(S3) PE72(S3) S1F0(S3) PE73(S3) S1F0(S3) PE74(S3) S1F0(S3) PE75(S3) S1F0(S3) PE76(S3) S1F0(S3) PE77(S3) S1F0(S3) PE81(S3) S1F0(S3) PE82(S3) S1F0(S3) PE8 3(S3) S1F0(S3) PE84(S3) S1F0(S3) PE85(S3) S1F0(S3) PE86(S3) S1F0(S3) PE87(S3) S1F0(S3) PE91(S3) S1F0(S3) PE92(S3) S1F0(S3) PE93(S3) S1F0(S3) PE94(S3) S1F0(S3) PE95(S3) S1F0(S3) PE 96(S3) S1F0(S3) PE97(S3) S1F0(S3) PEA1(S3) S1F0(S3) PEA2(S3) S1F0(S3) PEA3(S3) S1F0(S3) PEA4(S3) S1F0(S3) PEA5(S3) S1F0(S3) PEA6(S3) S1F0(S3) PEA7(S3) S1F0(S3) PEB1(S3) S1F0(S3) P EB2(S3) S1F0(S3) PEB3(S3) S1F0(S3) PEB4(S3) S1F0(S3) PEB5(S3) S1F0(S3) PEB6(S3) S1F0(S3) PEB7(S3) S1F0(S3) SLPB(S4) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: apic clock
Re: how to find dependencies when building a new kernel
On Nov 30, 2011, at 12:15 PM, Torsten Valentin wrote: dmesg is the lazy way to get this info, the same info is written to /var/log/messages during boot. Are you saying your system is so stripped down you don't even log anything? Yep. And because the only persistent memory is Flash (32MB, which quickly dies if you permanently write to it), the whole system runs inside a RAMDISK only. And there is no terminal or ssh. Modifying the system means setting up a new system with modified /sbin/init each time. Would you be able to use TFTP to try booting test kernels off a remote machine? That's how I tend to do it when I'm trying not to write to flash on my routers while I'm building test kernels. You only have to change flags in the bootloader (of course, I have no idea how feasible that is for you, either; when you say there's no terminal, I assume you probably can't do that except through /etc/boot.conf). - Dave
Re: how to find dependencies when building a new kernel
Would you be able to use TFTP to try booting test kernels off a remote machine? Nope. I try every attempt with a hardware flash drive which I generate for that test machine. But I've got to get the kernel basically running on my test VM, then another not that damn small hardware. Once this is working, I just need to add one more network driver or so and that should be it. At least it it worked for me in the past.
Re: how to find dependencies when building a new kernel
On Nov 30 18:15:30, Torsten Valentin wrote: dmesg is the lazy way to get this info, the same info is written to /var/log/messages during boot. Are you saying your system is so stripped down you don't even log anything? Yep. And because the only persistent memory is Flash (32MB, which quickly dies if you permanently write to it), the whole system runs inside a RAMDISK only. And there is no terminal or ssh. Modifying the system means setting up a new system with modified /sbin/init each time. So: your machine has 32MB of Flash storage that holds the entire system. On boot, it all gets loaded as a RAMDISK. Right? Question: how do you actually put a new system onto that Flash storage? What kind of Flash storage is it? (I suppose it's not a CF card or an USB flash drive that you would plug out, put an image on it, and plug in.) Hard to believe, I know, but what people do with OpenBSD is sometimes quite different from what you know from usual systems. It certainly sounds interesting. Out of curiosity: what do these system do? Are their routers? Rocket launchers? I can provide a dmesg from a virtual machine that we use for testing purposes, but obviously that's not the same as the system that the kernel is going to be running on later in production environment. But, hey, yet, I haven't been able to compile the kernel on this testing machine, either. I explain this so elaborately because I know I'd otherwise get replies like: What did you tell us about having little memory and such, this is a usual virtual machine and therefor you've got no need to use a custom kernel... ;-) You know what I mean... My goal is to have kernel config files that will do on both, the virtual machine for testing and the production environment. Being able to compile a custom kernel on this VM would be a good first step. From there on I could add the drivers I need on the production machine and that way get closer to a final solution... I'm very curious how dmesg will help... A dmesg from the actual machine would; really, it would.
Re: how to find dependencies when building a new kernel
On Nov 30 10:26:46, T. Valent wrote: sure will solve what you have understood to be my problem. But what really annoys me here is that I'm not taken seriously when I say this isn't an option. Why don't you just believe my words instead of permanently speaking about things that I explicitly said are impossible? Because if someone simply says this is impossible, it is only natural to ask why is that impossible?. How does that annoy you? (Solving your problem is impossible. Really. Don't waste your time asking why.) Did you read my mail in which I said that the hardware cannot be changed? A new flashcard would be a change in hardware. So the 32MB storage is a CF card? Don't be surprised that people ask, because it begs the question (no really, it does): why can't you put a bigger CF card in there that would just hold GENERIC? No, really: why? Answering this question will take a few minutes of our time. I think you know that. You just don't take my words seriously and keep talking about things that I already said are not possible in this project. Why discuss this? From my point of view it's not me wasting your time, but it's you wasting your time, because you don't really care about what I said. The overall project is about updating multiple systems How many multiple systems? that are in production. By _just_ using just a software update. Changes in hardware are not an option. Putting, say, a bigger CF card in them is a change in hardware, granted. Would that change eliminate the need for the whole process of maintaining custom kernels and custom stripped down systems? If not, why? dmesg output of any of these devices would be possible, but like I said it's a very stripped down environment. dmesg is not part of it. I'd have to setup an old system with dmsg on it, So, at some point, you had a system on it that had dmesg(1). How long does it take to put that system on it again and run dmesg(1)? (That's not a rhetorical question that wants to be sarcastic - that's an honest question). Generally, how long does it take to put a new system in, once it is built? then export the output, just to convince you of what I've done in the past. Then, after I've proven my point with this dmesg output, we'd be no step further, Yes we would: we would know your hardware from OpenBSD's point of view. because like I said often enough now, I'm not interested in a hint like add this line to your config, but I want to learn about what steps to do, next time I run into the same problem (which I probably will with the next OpenBSD release that I want to migrate the systems to). If you can help me by explaining where to look and what to read to learn how to build the smallest custom kernels possible, I'd be happy. You have been told several times already: strip GENERIC down to what will fit on your system. Start with things you definitely do not need (sound? wifi?), then continue with the rest. If things break, put the last thing that you removed back there. It is a way to arrive at the smallest possible kernel that works for you. Isn't it?
how to find dependencies when building a new kernel
Hi!
I'm trying to build a new kernel. However, while compiling I get
complaints about undefined references like this:
ld -Ttext 0xD0200120 -e start -N --warn-common -S -x -o bsd
${SYSTEM_HEAD} vers.o ${OBJS}
machdep.o(.text+0x2791): In function `sys_sigreturn':
: undefined reference to `fpu_mxcsr_mask'
The above line is just an example. I have poked around with more or less
guessing what could be missing, but after 2 days I'm quite sure I need a
general solution to finding the dependencies instead of guessing.
I have no skills in kernel coding. I wonder if there's a good way to
find out which part I am missing in the config file(s).
This is what I do:
edit /usr/src/sys/conf/GENERIC
I'm fine with this so far.
Now to edit
/usr/src/sys/arch/i386/conf/GENERIC
I do
dmassage -t
and make sure all the hardware I need is included in my config file. I'm
quite sure I've included everything I need, I get the above mentioned
problems, which I understand as dependencies. However, I just don't know
how to find out which line of the config file I have to include to solve
this.
I know I am recommended to use the generic kernel. I need the kernel for
an embedded device where the hardware is well known in detail, it is
always the same, will not change and memory is very limited. So I need
to get rid of the unnecessary stuff in the kernel.
Thanks in advance!
T.
Re: how to find dependencies when building a new kernel
On Tue, Nov 29, 2011 at 4:35 AM, T. Valent tmp...@4ss.de wrote:
Hi!
I'm trying to build a new kernel. However, while compiling I get
complaints about undefined references like this:
ld -Ttext 0xD0200120 -e start -N --warn-common -S -x -o bsd
${SYSTEM_HEAD} vers.o ${OBJS}
machdep.o(.text+0x2791): In function `sys_sigreturn':
: undefined reference to `fpu_mxcsr_mask'
andres@pote:~ $ grep -rw fpu_mxcsr_mask /sys/arch/i386
...
/sys/arch/i386/include/npx.h:extern uint32_tfpu_mxcsr_mask;
/sys/arch/i386/isa/npx.c:uint32_t fpu_mxcsr_mask;
...
andres@pote:~ $ grep -rw npx /sys/arch/i386/conf/files.i386
/sys/arch/i386/conf/files.i386:device npx
/sys/arch/i386/conf/files.i386:attach npx at isa
/sys/arch/i386/conf/files.i386:file arch/i386/isa/npx.c
npx needs-flag
The above line is just an example. I have poked around with more or less
guessing what could be missing, but after 2 days I'm quite sure I need a
general solution to finding the dependencies instead of guessing.
I have no skills in kernel coding. I wonder if there's a good way to
find out which part I am missing in the config file(s).
note how the grep commands required no kernel coding skills
This is what I do:
edit /usr/src/sys/conf/GENERIC
I'm fine with this so far.
Now to edit
/usr/src/sys/arch/i386/conf/GENERIC
I do
dmassage -t
i might be wrong, but is this really aggressive auto spelling
corrector for dmesg?
and make sure all the hardware I need is included in my config file. I'm
quite sure I've included everything I need, I get the above mentioned
problems, which I understand as dependencies. However, I just don't know
how to find out which line of the config file I have to include to solve
this.
I know I am recommended to use the generic kernel. I need the kernel for
an embedded device where the hardware is well known in detail, it is
always the same, will not change and memory is very limited. So I need
to get rid of the unnecessary stuff in the kernel.
Thanks in advance!
T.
Re: how to find dependencies when building a new kernel
Andres, thanks a lot for your quick reply! I'm going to try this in a minute. dmassage -t i might be wrong, but is this really aggressive auto spelling corrector for dmesg? I found an example usage of dmassage on the web, but could not find the program. So I thought the same way as you did. It's not part of the official OpenBSD or the ports tree. And it does not do much more than providung a different view to what dmesg provides you with. Maybe people woule recognize this tool if it just got a not so silly name. Regards, T.
Re: how to find dependencies when building a new kernel
On 2011 Nov 29 (Tue) at 10:05:11 +0100 (+0100), T. Valent wrote: :I know I am recommended to use the generic kernel. I need the kernel for :an embedded device where the hardware is well known in detail, it is :always the same, will not change and memory is very limited. So I need :to get rid of the unnecessary stuff in the kernel. Can you say how much memory is very limited really means? 128M? 2G? Please give numbers. http://www.openbsd.org/faq/faq5.html#Why Is very clear on why you should not run a custom kernel. -- Measure with a micrometer. Mark with chalk. Cut with an axe.
Re: how to find dependencies when building a new kernel
On Tue, Nov 29, 2011 at 11:38, T. Valent tmp...@4ss.de wrote: [dmassage] It's not part of the official OpenBSD or the ports tree. Are you sure it's not in sysutils/dmassage? It would seem you're trying to build your own stripped-down kernel. Doing that sort of thing is typically a you break it, you get to keep the pieces activity. While I do not know the reasons [1] you have for doing so, you may have better luck solving issues using config(8). If you take that route, be sure to note down the changes needed so you can repeat the process at subsequent upgrades. Regards, Rogier 1. OpenBSD FAQ #5 http://openbsd.org/faq/faq5.html#Why
Re: how to find dependencies when building a new kernel
On 29-11-2011 11:38, T. Valent wrote: dmassage -t i might be wrong, but is this really aggressive auto spelling corrector for dmesg? I found an example usage of dmassage on the web, but could not find the program. So I thought the same way as you did. It's not part of the official OpenBSD or the ports tree. And it does not do much more than providung a different view to what dmesg provides you with. Maybe people woule recognize this tool if it just got a not so silly name. I wrote it 10 years ago, it's getting pretty obsolete now. I really think the name is the best part about it though! :-)
Re: how to find dependencies when building a new kernel
Andres,
may I kindly ask one more question, I'm sure after that I'll get it
right myself.
See:
# make
ld -Ttext 0xD0200120 -e start -N --warn-common -S -x -o bsd
${SYSTEM_HEAD} vers.o ${OBJS}
acpi_machdep.o(.text+0xcf): In function `acpi_sleep_machdep':
: undefined reference to `mem_range_softc'
[...]
# grep -rw mem_range_softc /sys/arch/i386
[...]
/sys/arch/i386/i386/mem.c:struct mem_range_softc mem_range_softc;
[...]
# grep -rw mem /sys/arch/i386/conf/files.i386
/sys/arch/i386/conf/files.i386:file arch/i386/i386/mem.c
Still I don't know which option/line is missing. There is no such thing
as i386 in GENERIC, from which I derive my config.
Thanks in advance.
T.
Re: how to find dependencies when building a new kernel
On Tue, Nov 29, 2011 at 12:29:28PM +0100, Camiel Dobbelaar wrote: On 29-11-2011 11:38, T. Valent wrote: dmassage -t i might be wrong, but is this really aggressive auto spelling corrector for dmesg? I found an example usage of dmassage on the web, but could not find the program. So I thought the same way as you did. It's not part of the official OpenBSD or the ports tree. And it does not do much more than providung a different view to what dmesg provides you with. Maybe people woule recognize this tool if it just got a not so silly name. I wrote it 10 years ago, it's getting pretty obsolete now. I really think the name is the best part about it though! :-) I alwast undestood it as a reference to inspector Clouseau and his pronunciation of the word message. Now I wonder if that association was intended or not. http://www.imdb.com/title/tt0084814/quotes You got read it with a thick french accent. -Otto
Re: how to find dependencies when building a new kernel
On 29 Nov 2011, at 04:05, T. Valent wrote: This is what I do: edit /usr/src/sys/conf/GENERIC I'm fine with this so far. I have to admit I've never needed to build my own OpenBSD kernel, so things might be a bit different from NetBSD and FreeBSD. However, unless you are a kernel maintainer, why are you editing GENERIC instead of copying it to, say, MYKERNEL, and mucking about with that? Michael
Re: how to find dependencies when building a new kernel
On 11/29/11 04:04, T. Valent wrote: ... This is what I do: edit /usr/src/sys/conf/GENERIC ... edit /usr/src/sys/arch/i386/conf/GENERIC welcome to the ignore list of many developers. You aren't even following directions on how to hurt yourself properly without wasting people's time. ... I know I am recommended to use the generic kernel. But I like pain well, your purpose in life mat be to become an example. I need the kernel for an embedded device where This: the hardware is well known in detail, it is always the same, will not change and memory is very limited. does not logically lead to this: So I need to get rid of the unnecessary stuff in the kernel. Put bluntly: I don't believe you. Hopefully, not that you are lying to us, but rather that you are deluding yourself. What possible production hardware can't run the GENERIC kernel, or would get a non-trivial amount of memory returned to it? I probably have a lesser machine in production. You are already inflicting pain upon yourself, AND crying for help after doing so. Your process is broke, using a tool you do not understand. I've watched people go through this kind of stuff...with hardware that won't change and watched it change or have to be tested in an alternative environment, and watched it take much longer than any hoped performance benefit was ever going to return. This also creates long-term maintenance nightmares. IF your hardware is so anemic that it can't run GENERIC, I think you will do much better getting more realistic hardware than by mangling the OS. On the other hand... I do have a lot of 4M RAM chips and 486 processors maybe I can sell you... Nick.
Re: how to find dependencies when building a new kernel
On 29-11-2011 13:00, Otto Moerbeek wrote: On Tue, Nov 29, 2011 at 12:29:28PM +0100, Camiel Dobbelaar wrote: On 29-11-2011 11:38, T. Valent wrote: dmassage -t i might be wrong, but is this really aggressive auto spelling corrector for dmesg? I found an example usage of dmassage on the web, but could not find the program. So I thought the same way as you did. It's not part of the official OpenBSD or the ports tree. And it does not do much more than providung a different view to what dmesg provides you with. Maybe people woule recognize this tool if it just got a not so silly name. I wrote it 10 years ago, it's getting pretty obsolete now. I really think the name is the best part about it though! :-) I alwast undestood it as a reference to inspector Clouseau and his pronunciation of the word message. Now I wonder if that association was intended or not. http://www.imdb.com/title/tt0084814/quotes You got read it with a thick french accent. Hehe, no, it's simpler then that. It's about massaging the system (and hence the dmesg) into shape. I'm pretty sure that back then google also gave exotic hits for the word dmassage from page 2 onwards. Which I thought was funny as well. :-)
Re: how to find dependencies when building a new kernel
reading the npx(4) gives out a really strong clue as to why you
shouldn't custom compile until you're familiar with everything:
The npx driver is required for proper system functioning regardless
of whether or not an NPX is present.
so there's no 1:1 mapping between the devices you have and the ones
you may need included in the kernel config. could potentially apply to
other drivers, so why waste time figuring out which ones fall under
this category and which ones don't?
as for your searches, they don't include the struct definition
i can't recall the name of the doc (possibly hosted at openbsd.org)
that explains the layout, but basically, you got the base
/sys/conf/files and arch-specific ones. you are only searching in arch
specific files
so far you have many factors contributing against you being able to
custom compile:
- don't know c
- don't know the kernel source file layout
- doesn't bother looking at official documentation regarding kernel
compilation process
On Tue, Nov 29, 2011 at 7:06 AM, T. Valent tmp...@4ss.de wrote:
Andres,
may I kindly ask one more question, I'm sure after that I'll get it
right myself.
See:
# make
ld -Ttext 0xD0200120 -e start -N --warn-common -S -x -o bsd
${SYSTEM_HEAD} vers.o ${OBJS}
acpi_machdep.o(.text+0xcf): In function `acpi_sleep_machdep':
: undefined reference to `mem_range_softc'
[...]
# grep -rw mem_range_softc /sys/arch/i386
[...]
/sys/arch/i386/i386/mem.c:struct mem_range_softc mem_range_softc;
[...]
# grep -rw mem /sys/arch/i386/conf/files.i386
/sys/arch/i386/conf/files.i386:file B B arch/i386/i386/mem.c
Still I don't know which option/line is missing. There is no such thing
as i386 in GENERIC, from which I derive my config.
Thanks in advance.
T.
Re: how to find dependencies when building a new kernel
Read through the changes you made, see if anything looks a likely cause,
revert it, rebuild, repeat as necessary.
Start with any changes you've made yourself rather than changes
dmassage has made (I'm pretty certain it would not have removed the
npx device you had problems with in your first email).
Shoe-horning the OS into a system so small that you need to make
these changes is possible, but you really need to understand what
you're doing in order to track down the problems you might encounter.
For a one-off most people would be advised to find more suitable
hardware (e.g. alix is really cheap and has a very usable amount of
ram).
Some people want to do this sort of thing for fun and they should
understand that they are going to have to do some extra work
themselves.
If it's for a commercial product, well, for your customers'
sake, you ought to have somebody available who can understand this
stuff without asking a mailing list...how are you going to diagnose
weird faults when you run out of kernel memory? If you report a
bug when you're running a custom kernel, you know what the first
question will be. Can you repeat it on GENERIC?
On 2011-11-29, T. Valent tmp...@4ss.de wrote:
Andres,
may I kindly ask one more question, I'm sure after that I'll get it
right myself.
See:
# make
ld -Ttext 0xD0200120 -e start -N --warn-common -S -x -o bsd
${SYSTEM_HEAD} vers.o ${OBJS}
acpi_machdep.o(.text+0xcf): In function `acpi_sleep_machdep':
: undefined reference to `mem_range_softc'
[...]
# grep -rw mem_range_softc /sys/arch/i386
[...]
/sys/arch/i386/i386/mem.c:struct mem_range_softc mem_range_softc;
[...]
# grep -rw mem /sys/arch/i386/conf/files.i386
/sys/arch/i386/conf/files.i386:file arch/i386/i386/mem.c
Still I don't know which option/line is missing. There is no such thing
as i386 in GENERIC, from which I derive my config.
Thanks in advance.
T.
Re: how to find dependencies when building a new kernel
Nick Holland n...@holland-consulting.net wrote to T. Valent: IF your hardware is so anemic that it can't run GENERIC, I think you will do much better getting more realistic hardware I differ. I have an old, very old laptop, running OpenBSD. The value of the laptop is not the hardware, but its use as typewriter - and much more - and not risking that it be stolen in a publich library when one leaves it for a while. It is not only a typewriter, I can surf with lynx, get files with ftp, read mail, etc. Perhaps for a computer hacker this is nothing, for me it is of great value. I think also for a hacker some years ago would have been of great value, a dream. Unfortunately I couldt compile the kernel: just the tar-ball was too big for the laptop, for the disc, for the ram. welcome to the ignore list of many developers. Few days ago I was also welcomed to a kill file, just for insisting a little that com.unix.bsd.openbsd.announce is not useless: for me as a casual user and perhaps for the whole project, for attracting people to it, then joining a mailing list, even if it is with gmane, supposes a previous involvement. Rodrigo.
Re: how to find dependencies when building a new kernel
welcome to the ignore list of many developers. You aren't even following directions on how to hurt yourself properly without wasting people's time. I always found that people waste my time when they write explanations and tons of bla bla that does not have to do with the issue itself, instead of just writing about what the problem really is. Because of the permanent repeating of USE THE GENERIC KERNEL instead of answering any questions that have to do with my problem: Total available disk space on the target system: 32MB The GENERIC Kernel of OpenBSD 5.0 is 8MB. I really do a lot to save every bit I can. I delete all programs that are not constantly needed from disk and compress seldom used programs and have wrappers that unzip these compressed in case they are needed. And so on. I don't want to bore you with details, but just take this: I need it and ... I probably have a lesser machine in production. I'd go for that bet! And pllleeaeee don't come up now with use different hardware!!! There are hundreds of things to think about when it comes to the hardware you'd be using for a certain purpose. And please don't make me explain why exactly this hardware is needed for this purpose. I've got all that running perfectly since OpenBSD 3.5. I've used custom kernels with success ever since, but with always spending a lot of time fiddling with which driver to use and which to get rid of. Now I'd like to find a more convenient way to generally solve this issue. If you guys say that there is no convenient way of solving this problem but to really dig into this and completely understand the architecture - then I still believe that I'll find a working config by fiddling around and trying this and that until I succeed. I just hoped I'd get a hint how to ease this process. T.
Re: how to find dependencies when building a new kernel
On Nov 29 13:55:45, sc...@web.de wrote: Nick Holland n...@holland-consulting.net wrote to T. Valent: IF your hardware is so anemic that it can't run GENERIC, I think you will do much better getting more realistic hardware I differ. I have an old, very old laptop, running OpenBSD. The value of the laptop is not the hardware, but its use as typewriter - and much more - and not risking that it be stolen in a publich library when one leaves it for a while. It is not only a typewriter, I can surf with lynx, get files with ftp, read mail, etc. Perhaps for a computer hacker this is nothing, for me it is of great value. I think also for a hacker some years ago would have been of great value, a dream. Unfortunately I couldt compile the kernel: just the tar-ball was too big for the laptop, for the disc, for the ram. That's not what cannot run GENERIC means.
Re: how to find dependencies when building a new kernel
On Nov 29 14:03:31, Torsten Valentin wrote: welcome to the ignore list of many developers. You aren't even following directions on how to hurt yourself properly without wasting people's time. I always found that people waste my time when they write explanations and tons of bla bla that does not have to do with the issue itself, instead of just writing about what the problem really is. Because of the permanent repeating of USE THE GENERIC KERNEL instead of answering any questions that have to do with my problem: Total available disk space on the target system: 32MB That's disk space, not memory. The GENERIC Kernel of OpenBSD 5.0 is 8MB. I really do a lot to save every bit I can. I delete all programs that are not constantly needed from disk and compress seldom used programs and have wrappers that unzip these compressed in case they are needed. And so on. I don't want to bore you with details, but just take this: I need it and ... I probably have a lesser machine in production. I'd go for that bet! And pllleeaeee don't come up now with use different hardware!!! There are hundreds of things to think about when it comes to the hardware you'd be using for a certain purpose. And please don't make me explain why exactly this hardware is needed for this purpose. I've got all that running perfectly since OpenBSD 3.5. I've used custom kernels with success ever since, So why don't you show us the dmesg of the most recent kernel that worked for you? Have you tried including everything that this last good kernel included?
Re: how to find dependencies when building a new kernel
Jan Stary h...@stare.cz wrote That's not what cannot run GENERIC means. Indeed. But at the beginning of the 21st century I installed netbsd in a laptop with 4MB ram through the serial port. The programs to install an OS are normaly the biggest problem: need more resources than the OS, they may not run, but the OS yes. In my newer laptop I was not able to install FreeBSD, but OpenBSD. I think my compiling problem may be solved using NFS, I will try it later. Rodrigo.
Which drivers are required for proper system functioning? (was: how to find dependencies when building a new kernel)
So why don't you show us the dmesg of the most recent kernel that worked for you? Because I don't see what that has to do with the issue. I'm not looking for that one line that's missing in my current config files. I'm not hoping for someone to tell me that I should include line #5 and then it will work. Instead I was hoping to learn a way how to find out myself which lines must be included (and which in my case don't need to). Quite what Andres Perera explained in his first reply. Just that Adres' explanation obviously cannot be the complete answer or at least I didn't fully understand it. To really get a minimal kernel, I'm going bottom up, not top down. I'm not deleting lines from GENERIC but I'm copying lines from GENERIC to an empty file. So there is no go back one step to where it worked the last time. Though it might be a lot of work, there must be a solution to this issue. The npx driver is required for proper system functioning regardless of whether or not an NPX is present. so there's no 1:1 mapping between the devices you have and the ones you may need included in the kernel config. could potentially apply to other drivers, so why waste time figuring out which ones fall under this category and which ones don't? To me it seems like this is the real question that I'm facing: To which drivers does this apply? Anyway, thanks to you all for your patience and attempts to help. Also please understand that it will not help if I explained why there is no way to use GENERIC and why the hardware cannot be changed. That would be a long story which in the end would lead to nothing... except wasting time.
Re: how to find dependencies when building a new kernel
Am 29.11.2011 14:03, schrieb Torsten Valentin: welcome to the ignore list of many developers. You aren't even following directions on how to hurt yourself properly without wasting people's time. I always found that people waste my time when they write explanations and tons of bla bla that does not have to do with the issue itself, instead of just writing about what the problem really is. Because of the permanent repeating of USE THE GENERIC KERNEL instead of answering any questions that have to do with my problem: Total available disk space on the target system: 32MB The GENERIC Kernel of OpenBSD 5.0 is8MB. I really do a lot to save every bit I can. I delete all programs that are not constantly needed from disk and compress seldom used programs and have wrappers that unzip these compressed in case they are needed. And so on. I don't want to bore you with details, but just take this: I need it and ... ... a gzipped GENERIC kernel is not 8MB. HTH, Markus
Re: Which drivers are required for proper system functioning? (was: how to find dependencies when building a new kernel)
Also please understand that it will not help if I explained why there is no way to use GENERIC and why the hardware cannot be changed. That would be a long story which in the end would lead to nothing... except wasting time. Maybe, to help you (wasting time), people her need this sort of information... - Mail original - De: Torsten Valentin valen...@4ss.de C: misc@openbsd.org EnvoyC): Mardi 29 Novembre 2011 14:48:47 Objet: Which drivers are required for proper system functioning? (was: how to find dependencies when building a new kernel) So why don't you show us the dmesg of the most recent kernel that worked for you? Because I don't see what that has to do with the issue. I'm not looking for that one line that's missing in my current config files. I'm not hoping for someone to tell me that I should include line #5 and then it will work. Instead I was hoping to learn a way how to find out myself which lines must be included (and which in my case don't need to). Quite what Andres Perera explained in his first reply. Just that Adres' explanation obviously cannot be the complete answer or at least I didn't fully understand it. To really get a minimal kernel, I'm going bottom up, not top down. I'm not deleting lines from GENERIC but I'm copying lines from GENERIC to an empty file. So there is no go back one step to where it worked the last time. Though it might be a lot of work, there must be a solution to this issue. The npx driver is required for proper system functioning regardless of whether or not an NPX is present. so there's no 1:1 mapping between the devices you have and the ones you may need included in the kernel config. could potentially apply to other drivers, so why waste time figuring out which ones fall under this category and which ones don't? To me it seems like this is the real question that I'm facing: To which drivers does this apply? Anyway, thanks to you all for your patience and attempts to help. Also please understand that it will not help if I explained why there is no way to use GENERIC and why the hardware cannot be changed. That would be a long story which in the end would lead to nothing... except wasting time. -- i l i m i t . . . Vincent Tamet vincent.ta...@ilimit.net CREA Infraestructures i Connectivitat 0034 937 333 375 VOLTA 1, 5C( 08224 TERRASSA.BCN La informaciC3 inclosa en aquest email C)s CONFIDENCIAL.En virtut d'allC2 establert a la Llei 15/1999 i la LSSICE 34/2002, l'informem que les seves dades formen part d'un fitxer automatitzat titularitat dB4ILIMIT COMUNICACIONS,S.L. La informaciC3 registrada s'utilitzarC per informar-li, per qualsevol mitjC electrC2nic, de les nostres novetats comercials. VostC( pot exercir els seus drets d'accC)s, rectificaciC3, cancelB7laciC3 i oposiciC3 a la segCent adreC'a: C/ VOLTA, 1 5C(, 08224 TERRASSA (BARCELONA).En compliment de la Llei 34/2002 dB411 de juliol de Serveis de la Societat de la InformaciC3 i del ComerC' ElectrC2nic, l'informem que pot revocar en qualsevol moment, de forma senzilla i gratuC/ta, el consentiment per a la recepciC3 de correu electrC2nic, enviant un correu electrC2nic amb la seva solB7licitud a: i...@ilimit.cat.
Re: Which drivers are required for proper system functioning? (was: how to find dependencies when building a new kernel)
On Tue, 29 Nov 2011, Torsten Valentin wrote: So why don't you show us the dmesg of the most recent kernel that worked for you? Because I don't see what that has to do with the issue. I'm not looking for that one line that's missing in my current config files. I'm not hoping for someone to tell me that I should include line #5 and then it will work. Instead I was hoping to learn a way how to find out myself which lines must be included (and which in my case don't need to). Quite what Andres Perera explained in his first reply. Just that Adres' explanation obviously cannot be the complete answer or at least I didn't fully understand it. Because the dmesg from the last working kernel will tell you what drivers need to be installed to run. I could go on, but others here have expressed my thoughts in detail. diana Past hissy-fits are not a predictor of future hissy-fits. Nick Holland(06 Dec 2005)
Re: Which drivers are required for proper system functioning? (was: how to find dependencies when building a new kernel)
On Nov 29 14:48:47, Torsten Valentin wrote: So why don't you show us the dmesg of the most recent kernel that worked for you? Because I don't see what that has to do with the issue. If the issue still is to get OpenBSD running on that hardware, then here is what it has to do with the issue: it might get you running OpenBSD on that hardware. I'm not looking for that one line that's missing in my current config files. I'm not hoping for someone to tell me that I should include line #5 and then it will work. Instead I was hoping to learn a way how to find out myself which lines must be included (and which in my case don't need to). Ah, so it's adifferent issue. Here is a way: include everuthing GENERIC includes (or better, include everything your last good running kernel included), and start stripping it line by line. Once you show us a dmesg of a kernel you run on that hardware (you say you do so since 3.8, right?), I might start believing you did that, and had reasons to do that. Quite what Andres Perera explained in his first reply. Just that Adres' explanation obviously cannot be the complete answer or at least I didn't fully understand it. To really get a minimal kernel, I'm going bottom up, not top down. I'm not deleting lines from GENERIC but I'm copying lines from GENERIC to an empty file. So there is no go back one step to where it worked the last time. The way you have been advised, you arrive at a minimal kernel from above. What problem do you have with that? Though it might be a lot of work, there must be a solution to this issue. Yes; see above; then do it; yes, it is a lot of tedious work. The npx driver is required for proper system functioning regardless of whether or not an NPX is present. so there's no 1:1 mapping between the devices you have and the ones you may need included in the kernel config. could potentially apply to other drivers, so why waste time figuring out which ones fall under this category and which ones don't? To me it seems like this is the real question that I'm facing: To which drivers does this apply? Answering this question requires an intimate knowledge of the kernel's internals, which you don't have (I don't either). Also please understand that it will not help if I explained why there is no way to use GENERIC and why the hardware cannot be changed. If you showed us your previous dmesg, we wouldn't have to ask you what the hardware is. be a long story which in the end would lead to nothing... except wasting time. ... and showing those you ask for help what that exotic hardware of yours actually is. Right?
Re: how to find dependencies when building a new kernel
On Tue, 29 Nov 2011 10:05:11 +0100 T. Valent wrote: `fpu_mxcsr_mask' The above line is just an example. I have poked around with more or less guessing what could be missing, but after 2 days I'm quite sure I need a general solution to finding the dependencies instead of guessing. I have no skills in kernel coding. I wonder if there's a good way to find out which part I am missing in the config file(s). The output from the build is usually quite good and clear more so than ports as to what is missing and working out what you can turn off is usually more related to hardware knowledge. I get the kernel down to 2Meg and running fine. Used to be a little less but the kernels grown quite a lot since then. Here's a trick I learnt from faulty unit mods in Total Annihilation when I was young and have used once on the OpenBSD kernel configs. Far better than pulling a unit out or adding one by one especially when twenty are broke. Split your config in half, choose the half you think is most likely to cause the problem and diff that half back to defaults and compile. If it works try the other half, if it doesn't split in half again, eventually you'll have a ureka moment sometimes almost immediately or possibly after finding there's more than one problem breaking the build and causing a bit of head scratching and a bit more work just when you thought you were getting near. You get the jist anyway, split and consider. The configs are far smaller and easier to use than Linux :-)
Re: how to find dependencies when building a new kernel
# grep -rw mem_range_softc /sys/arch/i386 [...] /sys/arch/i386/i386/mem.c:struct mem_range_softc mem_range_softc; [...] grep will not show you the #ifdef constructs surrounding some of these declarations. # grep -rw mem /sys/arch/i386/conf/files.i386 /sys/arch/i386/conf/files.i386:file arch/i386/i386/mem.c Still I don't know which option/line is missing. There is no such thing as i386 in GENERIC, from which I derive my config. Not even on the `machine' line? Miod
Re: how to find dependencies when building a new kernel
On Tue, Nov 29, 2011 at 9:25 PM, Miod Vallat m...@online.fr wrote: # grep -rw mem_range_softc /sys/arch/i386 [...] /sys/arch/i386/i386/mem.c:struct mem_range_softc mem_range_softc; [...] That's no that complicated to find dependencies as it may seem. Carefully read the kernel config file and man pages. For example there is mainbus. mainbus0 is installed on root, therefore the config line looks like mainbus0 at root Then there is bios. Where is the bios? Sure it's on the mainbus, the config line then will look like bios0 at mainbus0 It means that bios depends on the mainbus. Further, there is acpi installed on bios, i.e. acpi depends on bios, thus the config line looks like acpi0 at bios? All this together looks beautifully like: mainbus0 at root bios0 at mainbus0 acpi0 at bios? Do you see this beautiful harmony of the UNIX music? :) Moreover there are manual pages for all these devices: man mainbus man bios man acpi and so forth... and in the man pages you can see such recommendations as, for example SEE ALSO apm(4), intro(4) which you can admit as a cross reference (to a possible dependency). Vitali
Re: how to find dependencies when building a new kernel
On 2011-11-29, Torsten Valentin valen...@4ss.de wrote: welcome to the ignore list of many developers. You aren't even following directions on how to hurt yourself properly without wasting people's time. I always found that people waste my time when they write explanations and tons of bla bla that does not have to do with the issue itself, instead of just writing about what the problem really is. Because of the permanent repeating of USE THE GENERIC KERNEL instead of answering any questions that have to do with my problem: That's because your problem is not worth wasting other people's time on solving if you aren't prepared to do it yourself. Total available disk space on the target system: 32MB man boot, /gzip Alternatively: here's a nickel, get a flashcard from sometime later than 2005...
