> 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 I'm reading my mail again before finally sending it, I'd like to say that if I may sound annoyed or ungrateful, that's not the case. 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. T.
