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.
