* Rudolf Leitgeb <[email protected]> [2011-12-19 14:40]: > Am Montag, 19. Dezember 2011, 13:52:40 schrieb Henning Brauer: > > gotta compromise for crippled systems. solvable with a little shell > > script run from cron and rc.shutdown. > Wait: your solution would be to periodically remount some volume > read/write, merge the changes and then drop back to ro ? You aren't > serious, are you?
sure I am. that is how many if not most of these devices work - giant ramdisk, config data is written back to permanent storage on request or scheduled. ever wondered why you need to do a "write config" on your switch? > > for the scenario i had in mind - servers in some data center - that is > > the one solution. > Agreed. Many posts ago, BTW, so why do you still bring it up? I specifically > differentiated between devices that "store" and devices that "do". not in the statements i responded to. > Data center servers which have baby sitters in an office nearby don't > need automagic thingies. you apparently don't have much experience with that... > > I don't buy the "countless" at all, we're really only talking embedded > > here, and for embedded style use cases you'll have to adopt. that is > > the "special" case and not the norm. > Embedded systems with configurable settings are a "special case"? > Where were you during the last 10 years? you might have missed that openbsd isn't primarily targeted as embedded OS... > > while i was mostly talking about a console and not fsck -y, i do > > believe that an automagic fsck -y is pretty damn stupid. > Guess what your home router does, I don't need to guess. I know. It doesn't do fsck -y. > and what (if you have one) > your cell phone does? Also your car and your TV set? None of these > drop you into a console after the 3rd power outage and people > would laugh you out the door if you tried to sell such a product. what is your point again? openbsd is not an embedded out of the box product, and if you want to use it as such, you gotta adjust yourself. > > while we're really good in that and fsck almost always succeeds and > > fixes things up i have seen different. > And most likely the problems were not caused by fsck but by faulty > hardware creating the mess to begin with. No serial console can fix > faulty RAM chips, itchy power supplies or loose SATA cables, so it > wouldn't help the proud owner of a "do" device one bit. I honestly don't remember wether I ever had a case where fsck -y did not succeed but the hardware was fine. i dunno. but you are so focussed on fsck, not me. there are a gazilion things that can go wrong that require console access. and yes, the majority of them is a fuckup by a human. > As I have written before: I don't care whether the default install of OBSD > comes with "fsck -p" or "fsck -y", but calling people who suggest "fsck -y" > in certain situations cheapskates and stupid shows blatant ignorance. i see an interesting pattern here. 1) pick a seemingly simple "solution" 2) getting told that there are better ones, but you prefer to ignore that, since you've already chosen 1) and cannot possibly have been wrong. automagic fsck -y is stupid. -- Henning Brauer, [email protected], [email protected] 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/
