box boots only without swap partition - SCO

This is a discussion on box boots only without swap partition - SCO ; Hello, I have a SCO Openserver 5.0.6 box that hangs during startup. After I boot with DEFBOOTSTR SWAP=NONE it starts up without a problem. It ist also possible to set the swap partition manually after the box is up. If ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: box boots only without swap partition

  1. box boots only without swap partition

    Hello,

    I have a SCO Openserver 5.0.6 box that hangs during startup.
    After I boot with DEFBOOTSTR SWAP=NONE it starts up without a problem.
    It ist also possible to set the swap partition manually after the box is up.
    If any of you have had the same issue and have any advice, I would
    appreciate it.

    Thanks, Ole

  2. Re: box boots only without swap partition

    Ole Hansen wrote:

    > I have a SCO Openserver 5.0.6 box that hangs during startup.
    > After I boot with DEFBOOTSTR SWAP=NONE it starts up without a problem.
    > It ist also possible to set the swap partition manually after the box is up.
    > If any of you have had the same issue and have any advice, I would
    > appreciate it.


    Did this start suddenly?

    Swap assignment is a little bit delicate. When you set it manually
    after bootup, you're running something like:

    # swap -a /dev/swap

    The `swap` command does a stat() on the device node you name, and passes
    its major/minor device number to the kernel. /dev/swap is the default
    _name_ for this device, and 1/41 is the default _device number_, but
    running `swap -a /dev/swap` circumvents this default binding.

    That is: suppose /dev/swap _isn't_ 1/41 on your system. Suppose you
    deleted the /dev/swap that was created at install time, and created a
    new one on another disk, again naming it "/dev/swap". Its device number
    might be 1/108. Now, booting with the default swap area wouldn't work
    (though I doubt it would hang without a useful error message). You
    would need to change things in one of several ways:

    You could boot with "swap=none", then run `swap -a /dev/swap` after
    bootup. The `swap` program would look up /dev/swap's major/minor device
    number and pass it to the kernel.

    You could add "swap=hd(108)" to DEFBOOTSTR in your /etc/default/boot. A
    possible danger of that method is that you need to remember to add it to
    _every_ boot. If you add a new bootable entry to /etc/default/boot, it
    won't work if you forget the "swap=" statement. Likewise, if you walk
    up to the console and manually enter "unix", it won't work unless you
    remember the "swap=".

    Probably the most proper way to change this is to actually change the
    kernel's default idea of the swap device. This is done in the file
    /etc/conf/cf.d/sassign; see sassign(F). For my example, you would
    write:

    swap hd 108

    ("hd" is the name of block major number 1; that is, the entry in
    /etc/conf/cf.d/mdevice whose 5th field is "1".)

    Whatever technique you use to override the swap device, make sure you've
    also thought about the dump device. This is where the kernel writes a
    memory dump during a panic. Panic dumps are very useful for debugging,
    so it is unwise to set up a system that cannot successfully dump.

    The default is to use the same device for dump as for swap. Most
    systems are configured that way, mostly because most systems have pretty
    vanilla swap setups. Even if you're doing something unusual with swap,
    you still probably want to use the same device for dumping. In that
    case you should override it in the same place as you override swap: in
    sassign or on the kernel command line. (There's no runtime way to
    change the dump device; I don't think `swap -a /some/device` changes
    dumpdev, but it might have a special case for the first swap assignment
    after booting with "dump=none".)

    There are some cases where you might want to separate swap and dump.
    Dumps can be directed to a SCSI tape drive (obviously not useful for
    swapping...) You could cycle between several dump devices if you are
    fighting a frequent panic and want to quickly collect several dumps to
    compare.

    I just tried a crazy experiment. Not recommended on any system you want
    to keep in a sane state, but ... I created a dump _file_, booted with
    "dump=marry(1)", and ran `marry -a /tmp/dump`. Then I caused a panic.
    I first did this with a dump file as large as memory. This wrote a
    successful dump. So then I got really crazy and did the same thing with
    an _empty_ married dump file. This also created a successful dump!
    Married files can grow dynamically.

    I strongly recommend not trying to use a married dump file on a
    production system. The reason panics are written to a block device is
    to minimize the amount of kernel code used during a panic. If the
    system is panicing, it's because the kernel is in some sort of unstable
    state. Asking it to write to my root filesystem was a foolish thing for
    me to do; asking it to dynamically grow a file during a panic state was
    much more daring. I felt safe because I was doing this on a throwaway
    VMWare cloned machine, and because I knew how and why the system was
    panicing (I was provoking it!)

    ================================================== ===========================

    Well, getting back to the question at hand.

    Your problem might be because the kernel is coming up with a different
    device number than you. Check sassign; check DEFBOOTSTR in
    /etc/default/boot; compare those to the major/minor numbers of /dev/swap
    (or whatever you're using).

    If you haven't solved it by then, come back with: your exact OSR5
    release (`uname -X`); major patches you've applied; problem history (new
    install? suddenly started happening on a previously working machine?);
    and show us what the screen looks like when it hangs. What are the last
    few bootup messages before the hang?

    >Bela<


+ Reply to Thread