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?
