Slashdot Mirror

← Back to Stories (view on slashdot.org)

Preparing for the Worst in FreeBSD

Posted by CmdrTaco on from the when-it-rains-it-pours dept.

LiquidPC writes "In Part I of this series, Michael Lucas, from ONLamp.com, goes over preparing your FreeBSD computer for the worst in case of a system panic."

7 of 286 comments (clear)

  1. Big Scary Deamons by Alien54 · · Score: 5, Informative
    It is a bit easier to read without the ads, using the printer friendly page:

    Big_Scary_Daemons.html

    Yep, that is the name of the page.

    Michael Lucas lives in a haunted house in Detroit, Michigan

    Maybe we could move the ghost to Seattle?

    --
    "It is a greater offense to steal men's labor, than their clothes"
  2. Re:Nice article, but... by tftp · · Score: 4, Informative
    I don't know if Linux does this sort of stuff for you

    On Linux, the kernel prints the backtrace on the console, and into the syslog if it can. Later you can run ksymoops on this backtrace to match it to the symbolic names. This requires no preparation, but since I never saw FreeBSD backtraces I can't say if it is of a similar detail level.

  3. Good question: Why *haven't* they mentioned Rotor? by Zico · · Score: 4, Informative

    I mean c'mon. We get tons of mentions of .NET around here, talk about how Microsoft is only into closed source, etc. Now Microsoft actually releases 1.9 million lines of source code spread among almost 10,000 files that people can compile to get .NET up and running on their FreeBSD boxes, and Slashdot suddenly clams up about it?


    Who can honestly say that this isn't a story of interest to a large amount of people here, whether they hate .NET or not? There's a lot of discussion to be had about it. Comparisons to Mono/DotGnu? The licensing details? The performance? Comparisons to Java on FreeBSD? To pretend it doesn't exist is just silly and does seem to call Slashdot's motives into question.


    Well, for FreeBSD users who might be interested, I'll go ahead and post a link to a few articles about it myself, from O'Reilly's site who's been doing a pretty decent job of breaking it down: http://www.oreillynet.com/dotnet/. Discuss amongst yourselves. ;)

  4. More helpful when running 5-CURRENT... by d_force · · Score: 4, Informative
    Usually, upgrades in the 4.x-RELEASE branch are made when selected improvements have been regression tested in the 5.x-CURRENT branch. Thus, if you're running a 4.x version, chances are you don't need to configure your system to do a full dump; usually there are people who've ran into similar problems and you can search for the fixes via mailing lists/usenet/etc...

    For more info, check out the FreeBSD Release Engineering Page

    Disclaimer:
    Yes, there's a slight chance you might come across some new bug in the 4.x tree; however, it's unlikely.

    --
    SELECT * FROM USERS WHERE A_WINNER = "YUO";
  5. Who cares? by seanadams.com · · Score: 5, Informative

    I've been running two FreeBSD systems for over seven years each. I've had to do a grand total of *ONE* reboot that I can remember, aside from powering down to swap hardware, update the kernel, or to move the equipment.

    It's a damn stable OS. One of these machines is a dual PII/400, serving 700-1000kbps day in day out, with hundreds of active TCP connections at any given time, starting 15-20 new processes per second. The other machine is for a single, fairly busy web site doing 700kbps traffic.

    FreeBSD is rock solid. I have absolutely no need to plan for a kernel panic.

  6. Re:12 month uptime + crash = hardware failure by CoolVibe · · Score: 5, Informative
    Tell me about it... In fact, I have made a bootable CD-R with memtest86 that I can boot in servers that support cd-rom booting.

    I did it like this:

    1. Compile memtest86.
    2. make a floppy image: dd if=/dev/zero of=padding.img bs=512 count=2880
    3. append the image after the memtest.bin: cat padding.img >> memtest.bin
    4. cut the floppy image to size so mkisofs won't choke on it: dd if=memtest.bin of=bootfloppy.img bs=512 count=2880
    5. Make image with mkisofs: mkdir empty && cd empty && mkisofs -b ../bootfloppy.img -o boot.iso .
    6. Burn that image and you're done! Bootable memtest86 cd-rom. A handy tool for your toolchest.

    7. That thing saved my life countless times when dealing with old servers and spotty RAM.

  7. Re:12 month uptime + crash = hardware failure by CoolVibe · · Score: 4, Informative
    I hate replying to myself, but if you somehow try to compile memtest86 on *BSD, you need this file. It's a patched linkage.h. Edit the head.S file in the source tree to include this file instead of linux/linkage.h .

    Hope that helped you all out a bit :)