Best of the Newsgroups: moving swap device

Main Index

Path: border1.nntp.dca.giganews.com!nntp.giganews.com!nf3.bellglobal.com!news.ca.mci.com!news.uunet.ca!enigma.xenitec.ca!jpradley.jpr.com!via-email
From: Bela Lubkin 
Newsgroups: comp.unix.sco.misc
Subject: Re: box boots only without swap partition
Date: 4 Nov 2005 04:25:20 -0500
Lines: 103
Sender: nouser@jpradley.jpr.com
Message-ID: <200511040125.aa23988@deepthought.armory.com>
References: 
X-Mailer: Mail User's Shell (7.2.6 beta(5) 1998-10-07 + patches)
Xref: number1.nntp.dca.giganews.com comp.unix.sco.misc:167688

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<
 



 




Click here to add your comments 




Don't miss responses! Subscribe to Comments by RSS or by Email


Click here to add your comments 


If you want a picture to show with your comment, go get a Gravatar






Why no "Digg this!" etc.?











 Take Control of Upgrading to Snow Leopard 

 Take Control of Exploring & Customizing Snow Leopard 
 

Jump to Comments

Many of the products and books I review are things I purchased for my own use. Some were given to me specifically for the purpose of reviewing them. I resell or can earn commissions from the sale of some of these items. Links within these pages may be affiliate links that pay me for referring you to them. That's mostly insignificant amounts of money; whenever it is not I have made my relationship plain. I also may own stock in companies mentioned here. If you have any question, please do feel free to contact me.

Specific links that take you to pages that allow you to purchase the item I reviewed are very likely to pay me a commission. Many of the books I review were given to me by the publishers specifically for the purpose of writing a review. These gifts and referral fees do not affect my opinions; I often give bad reviews anyway.

We use Google third-party advertising companies to serve ads when you visit our website. These companies may use information (not including your name, address, email address, or telephone number) about your visits to this and other websites in order to provide advertisements about goods and services of interest to you. If you would like more information about this practice and to know your choices about not having this information used by these companies, click here.