Re: another error with md malloc based fs
Michael Schuh schrieb: hi Chuck, hi @list me again, behind the scenes, i would take over my Server by an hoster from Linux to FreeBSD on the running system, while the hoster takes money for pressing 2 buttons and put a disk in my Server...so i create now a mfs based system that can bootet from disk and resides fully in ram. I have tryed out Colin's depenguinator, but it fails...some times now i would do the steps by hand thanks cheers michael Hi Michael! Some months ago I modified the depenguinator and made it work again. But sorry, I didn't yet get to write down all the steps involved (I am not a good writer). But I recently found another much more comfortable way using QEMU which I documented. Does your provider offer a linux rescue system? If yes, you can try this: http://www.vrdevelopers.de/content/view/45/40/1/5/lang,en/ I'll try to follow up with the modified depenguinator asap, but don't hold your breath... HTH, Manuel ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: weird permitions
Hello, Can someone explain to me why next can happened on freebsd: 1. add 2 users in same group - user test and test-ro in group test 2. as user test: cd /home/test ; mkdir test; chmod 775 test; echo "asdasd" > ~/test/del.me 3. su - test-ro ; cd /home/test; vim del.me - make changes; force save (:x!) ls -l total 2 -rw-r--r-- 1 test-ro test 10 Nov 29 18:19 del.me (how is that possible ?) back "su - test" and try to edit this file - impossible! I do not know what the RFC says about it, but it is ultra weird for me that such ownership takeover is possible. 6.2-PRERELEASE FreeBSD Fri Oct 27 19:53:30 amd64 Correct me if I'm wrong... but you obviously were editing two completely distinct files. ~test/del.me (logged in as "test-ro") and ~test/test/del.me (logged in as "test") I fail to see anything odd here. You seem to have enabled group writable home directories though. M. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
[OT] Thanks
Just wanted to say thank you for clearing up my confusion about ECC. And also, I want to excuse for being a bit harsh in some posts. (I am a rather cynic person, this helps me against not going crazy over all this stuff.) Last night, after hours of working on the very same problem without any success at all, I was at the end of my powers. Sorry, I'll try to keep back from posting in such situations in the future. So it seems like I can not track down ram problems in software. Thanks very much, besides my lack of understanding ECC, I wasn't aware of that either. Lesson learned. Since everything worked fine before, I guess something must have broke when I took the machine out of the shelf. But I have decided now to go the easy way out and retire the hardware. This old box isn't worth wasting more time on... M. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 6.x CVSUP today crashes with zero load ...
Yes, the result may be correct. 'Do not take "ECC" for "equals additional security"' So I understand what's ECC good for, other than the usual "marketing talk". But, in FreeBSD, the function is a result of hardware-level correction. Something that only kicks in in _real_ _serious_ situations. I just would like you (not specifically you, Dmitry) to aknowledge that broken RAM is worth a "panic" in "standard situations"- if I may call it like that. If the RAM is broken for some bits, chances are great that there are more following soon. ... from the replies I got via PM, I feel some people don't agree with that Sticks don't just break on a single bit. From my experience, a stick that's got any problems at all, will cause even more trouble soon... If a hardware problem isn't worth panick'ing, what else is? (don't answer this one please, this was a rhetorical question - to those who didn't get it...) Still, I'd rather have the node break down completely than that... M.^ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 6.x CVSUP today crashes with zero load ...
So what do I need to do to make the box panic() on an ECC error? Is there a kernel parameter, sysctl, or what else? Thanks, M. Pete French schrieb: I am not looking for workarounds, like ECC. I want the box to break immediately once any single component goes wrong... Uh, that *is* what ECC does (or can do). Without ECC your broken hardware continues to run un-noticed. With ECC you can either make it break immediatley, or log an error or continue to run. Stop thinking of ECC as error correction and start thinking of it as error detection. No ECC gives you no way to detect failing memory. -pete. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 6.x CVSUP today crashes with zero load ...
Wow, Steven, you've been really helpful here... M. Steven Hartland schrieb: My advice would be dont feed the troll. Steve ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 6.x CVSUP today crashes with zero load ...
Dmitry Pryanishnikov schrieb: When you wrote "ECC is a way to mask broken hardware", you were plain wrong. If you're using hardware w/o ECC, it just can't tell whether error present or absent. So ECC _is_ the way to detect (not mask) broken hardware. Ok, thanks. I think I understand the meaning of ECC now. So, unlike my supplier claims, ECC is not supposed to help against hardware failures. But it is the way to detect them, right? If you want ECC corrector to raise NMI on corrected error (as well as uncorrectable), just set approproate bit in control register - every Intel's ECC-capable chipset allows it. But if we're speaking about production environment, such behaviour (abnormal termination on _corrected_ error) is unacceptable. "abnormal termination" is not only acceptable for me, it is what I am looking for. Make the node crash completely, so one of the others can take over its task(s). Don't get me wrong, but tracking bugs in FreeBSD is quite more of an effort than "just" akquiring a new box... I don't see connection between this sentence and ECC (which is hardware option). What I wanted to say: Looking for errors in the logs is only a few seconds. Finding out what caused them, is hours... Akquiring a new box is only $29,95 ;) - that's like 30 minutes, if you regard it from the business side. ... I rather rent 100 boxes to do the task of ten, than employ 100 admins to find the "real" problem. Thanks, Dmitry. I think I know what to look for now... M. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 6.x CVSUP today crashes with zero load ...
Ok... Does the standard fs, UFS2, do "extra sanity checks", then? Sorry, replying to myself... No, this does not matter. If the OS thinks the data is ok, UFS will write OK data... So, let me rephrase this: How can I make sure there is no broken hardware in my cluster? I am not looking for workarounds, like ECC. I want the box to break immediately once any single component goes wrong... ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 6.x CVSUP today crashes with zero load ...
Dmitry Pryanishnikov schrieb: Hello! On Mon, 26 Jun 2006, M.Hirsch wrote: ECC is a way to mask broken hardware. I rather have my hardware fail directly when it does first, so I can replace it _immediately_ You got it backwards. If your data has any value to you, then you don't want to miss any single-error bit in it, do you? If you're running hardware w/o ECC, your single-bit error in your data will go to the disk unnoticed, and you'll lose your data. With ECC, hardware will correct it. In (rare) case of multiple-bit error ECC logic will generate NMI for you, so you'll notice and "replace it _immediately_" instead of two weeks ago when your archive wont extract. Nope, I am right on track. I do not want to lose any data. So I'd prefer a ECC error to raise a panic so I can replace the hardware ASAP. Don't get me wrong, but tracking bugs in FreeBSD is quite more of an effort than "just" akquiring a new box... What's your hardware good for if it passes a "test", but fails in production? It's the way in what RAM will manifest single-bit errors: you run memory test - it won't catch them, later in production you'll miss this error because nothing will provide extra sanity check of your data. Ok... Does the standard fs, UFS2, do "extra sanity checks", then? M. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 6.x CVSUP today crashes with zero load ...
Wilko Bulte schrieb: You really have never seen a machine used for serious business apparantly. Depends on what you define "serious business"... Yes, I am rather new to FreeBSD (2y+) I am just trying to setup a /stable/ cluster of six machines right now. For over a week straight. 4.11 works perfectly. But support is going to be dropped very soon, so that's a bad option for me right now. Over all, the system is /only/ supposed to handle a few hundred hits per second. (but including dynamic stuff like php...) Dunno if that (or what else) is "serious business" for you. Which version would you suggest for "serious business"? Anyways, my point stands: I rather have any of my nodes panic than carrying the risk of creating invalid data... One in a billion can be high probability, soon... (just planning for the future...) panics like that should be eradicated, adding more nonsensical panics is not what we need. uh, I would not call hardware failure "nonsensical panics". I guess I must have misunderstood you... M. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 6.x CVSUP today crashes with zero load ...
Ok, sorry. Misunderstanding here. My point was, along what has been posted here in this thread: "An ECC error should raise a kernel panic immediately, not only a message in the log files." Any hardware showing ECC errors should be replaced asap.. Make them lazy admins do what they're getting paid for... Correct, you can't (quickly) detect this without ECC hardware, of course. But I keep reading about "ECC" being the solution to broken RAM sticks... Since FreeBSD panics on creating simple malloc() vnodes, it should do so on ECC errors first. Different mission, I guess ;) (And different problems with the recent fricking code...) M. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 6.x CVSUP today crashes with zero load ...
.. So the logs are there, all that's required is a utility to read them and, optionally, alert the administrator to the event, No, I think a panic _should_ occur, even if there was a correctable error. Not "when there's no other option left". Maybe make it optional via a kernel option. There are much less-significant problems that can cause a panic. Sure, you may be one of the few people out there who knows how to correctly run a _BSD_ system... There's few of yous out there, ;) M. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 6.x CVSUP today crashes with zero load ...
Nope, I'd like my bank data to be stored on a system that does ECC, no question. But please, on hard disk level (RAID; that is _permanent_), not in the RAM of a single node. If memory gets corrupted, please, raise a kernel panic... Even if there's ECC in place. Counter question: Would you like your bank account data to be stored on a medium where one failure can be corrected, two can be detected, but three go unnoticed? How unlikely is that, if you've got some hardware that is really /broken/? I know this is a rather random thing to happen. Still, I think ECC memory is overrated. Better have it fail immediately. _With a kernel panic, please_ M. Wilko Bulte schrieb: Balderdash. Following your rationale you want your bank account data silently be corrupted by hardware with bit errors? Be my guest, give me ECC any day. Proper hardware will log the ECC errors, a proper OS tailored to that hardware will log and notify the sysadmins. That is how it should be done. Wilko ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kernel can't find root filesystem
Sorry, doesn't help.
There is some kind of bug hiding somewhere in 6.1 where it does not
auto-detect the root partition under certain circumstances. Can't tell
when it worked last, as the last distro I consider "stable" was 4.X...
(sorry for the rant...)
I am not using (and don't want to use...) boot0 at all.
Well, I tried, but it didn't help the situation anyways...
It should work with the standard MBR and boot code ("/boot/mbr" and
"/boot/boot"), right?
i.e. fdisk -B and bsdlabel -B without further params should do the job
to get the system bootstrapped.
But it does not.
M.
If I'm not mistaken, you could also try to (re)install the boot0 loader:
boot0cfg /dev/da0
-Proto
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 6.x CVSUP today crashes with zero load ...
ECC is a way to mask broken hardware. I rather have my hardware fail directly when it does first, so I can replace it _immediately_ What's your hardware good for if it passes a "test", but fails in production? ECC is totally overrated. (sorry, couldn't resist...) M. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kernel can't find root filesystem
I had the same problem with 6.1. But only on some occasions, not always (iirc). The installations I made over the last weeks had all very different environments and deployment methods. I can't tell anymore when it happens and when not because I simply added the below loader.conf setting to my postinstall-script. Add "vfs.root.mountfrom=ufs:da0s1" to /boot/loader.conf to fix it. HTH, Manuel ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Question about current rc scripts
Another problem solved :) So when my script overwrote rc.conf, the file was already loaded and thus overwriting it had no effect. That's why it didn't work. (not with "BEFORE: initrandom" either). This must have changed somewhen between 6.0 and 6-STABLE because it did work in 6.0. Thanks vm. I'm going to publish a "freebsd 6 remote deployment" article on my blog after I got it working 100%. There really don't seem to be any good and recent guides for that out there... M. [LoN]Kamikaze schrieb: BTW, rc.subr only loads rc.conf if it hasn't already been loaded. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Question about current rc scripts
Ah, ok. I didn't get that correctly before. "It's just another shell script" - nice hack, thanks ;) M. Brooks Davis schrieb: Pete is suggested that you put the code in /etc/rc.conf. It's just another shell script. -- Brooks ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Question about current rc scripts
This is what I initially tried, but it didn't work due to a wrong "BEFORE:" tag. "rcconf" was removed from 6-STABLE, so my scripts didn't start at all anymore. Invalid dependencies seem to make rc-scripts not execute *at all* in 6-STABLE. (note taken) So far I think I got it working now. Thanks for your input! M. Pete French schrieb: Actually I was suggesting you overwrite rc.conf *itself* with the variable setting code - so every script which reloads it gets the variables set. Surely that would work ? Though it would mean your code would be run multiple times... -pete. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Question about current rc scripts
As stated in my initial post, I used "BEFORE: rcconf" up to and including 6.0. So what is an "appropriate BEFORE entry" for 6-STABLE? Sorry, I really can't find any documentation on this issue, not in UPDATING and not in the mailing list archives either. Thanks, M. Brooks Davis schrieb: Add appropriate BEFORE entries so it is before all unparented scripts. -- Brooks ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Question about current rc scripts
One question remains though: How can I make my script to be the very first rc script to be executed? M. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Question about current rc scripts
Yes, I think this is the solution. It seems to depend on the filename, specifically the ".sh" extension. CODE (in /etc/rc): /etc/rc.d/*.sh) # run in current shell Thanks, I am testing this now. I'll post back as soon as I got results (1h or so...) M. [LoN]Kamikaze schrieb: If your scripts name ends with .sh it will be sourced into the process and all variables set there will prevail (this feature only works in /etc/rc.d). If you do this you must not use the exit command anywhere in your script. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Question about current rc scripts
I have investigated a bit more. Setting the variables can't work. As far as I can see, rc.conf is sourced from rc.subr. And every single script in /etc/rc.d/ sources rc.subr, so they reload the rc.conf file for each call. The "rc" scripts are being executed in a sub-shell though. So overwriting variables in any of them will have no effect on the following files. It does work for /usr/local/etc/rc.d though, but I really need it to execute before anything else. I made it work by overwriting rc.diskless (again). Stupid /me, rc.diskless does not follow the syntax for rc scripts. It's just a "normal" shell script :) Anyways, I would still be interested in the "correct" way to do it. M. Pete French schrieb: I thought rc.conf was simply a script that set some variables. If this is the case then you don't need to overwrite it - you simply need to make your script set the appropriate variables and then drop it in as a repplacement for rc.conf - hence no need to rewrite rc.conf at all. -pcf. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Question about current rc scripts
Hello everybody, Before FreeBSD 6.1, I was able to write a rc script which modifies the rc.conf file. All rc scripts exectuted after this first one would use the new rc.conf then. To make this work, I put the script in /etc/rc.d/ and "tagged" it with "BEFORE: rcconf". Unfortunately, rcconf has been removed in FreeBSD 6.1 (or -STABLE?). I have tried many different ways, like "BEFORE:NETWORKING", and others. But none seems to work. I even overwrote "rc.diskless", but still no luck. What is the correct way for 6-STABLE to achieve what I want to do? (i.e. write the rc.conf from a rc script) Thanks in advance, M. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
