Description of problem:
I am using a modified Red Hat 7.3 on kernel-2.4.18-10 with initscripts-6.67-1. I
have logical volume management (LVM) enabled on an initial ramdisk (initrd) and
managing both my root ("/dev/vg0/lv-ROOT") and swap ("/dev/vg0/lv-SWAP")
partitions. The error that I get at shutdown by "/etc/rc.d/init.d/halt" is:
  Turning off swap:  swapoff: /dev/vg0/lv-SWAP: Invalid argument [FAILED].
Another symptom is that after boot, "/proc/swaps" shows that my swap partition
has been deleted even though it continues to function:
  Filename                    Type       Size    Used  Priority
  /dev/vg0/lv-SWAP (deleted)  partition  786424  0     -1


Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
Since I have a customized configuration, the steps to reproduce the errors would
involve setting up a similar system. I have one hard disk with an ext3
filesystem "/boot" on one small, ordinary partition, and an LVM physical volume
on another large, ordinary partition containing separate logical volumes for
swap and the reiserfs filesystems "/", "/home", "/tmp", "/usr", "/var".

Additional info:

The actual problem seems to be in "/etc/rc.d/rc.sysinit". The relevant schematic
boot sequence for my computer is:
  (1) LILO loads kernel and initrd,
  (2) kernel mounts initrd filesystem as root filesystem,
  (3) "/linuxrc" from initrd runs "vgscan" and "vgchange -ay" which initializes
    LVM volumes "/dev/vg0/lv-ROOT" and "/dev/vg0/lv-SWAP",
  (4) root pivots from initrd to "/dev/vg0/lv-ROOT",
  (5) "/sbin/init" loads from "/dev/vg0/lv-ROOT" and runs
    "/etc/rc.d/rc.sysinit",
  (6) "rc.sysinit" runs "swapon -a -e" (for swap partitions, ostensibly)
    activating "/dev/vg0/lv-SWAP" from "/etc/fstab",
  (7) "rc.sysinit" runs "vgscan" and "vgchange -a y",
  (8) "rc.sysinit" runs "vgscan" and "vgchange -a y" again, and
  (9) "rc.sysinit" runs "swapon -a" (for swap files, ostensibly).

So, "vgscan" and "vgchange" are run three times, and "swapon -a" is run twice,
intermixed with various other commands. When "vgscan" is first run from the
initrd, "/dev/vg0/lv-SWAP" is  made available as a logical partition and its
block device is assigned a particular inode. "swapon" then uses this inode to
activate the swap partition for swapping. When "vgscan" is run for the second
time, it assigns the "/dev/vg0/lv-SWAP" block device a different inode than it
had the first time. Swapping still continues to function even though the inode
did change. When "vgscan" is run for the third time, the inode is not changed
from the second time, although that may be happenstance. When "swapon -a"
(without "-e") is run the second time, it seems to ignore the swap partition
"/dev/vg0/lv-SWAP" that was activated before, even though the swap partition has
been marked as deleted.

Since a swap partition could potentially be on any logical volume, it should be
swapped-on only after all LVM volumes have been found by "vgscan" and activated
by "vgchange -a y". A simple solution that seems to work is to not run the first
"swapon -a -e" command in "rc.sysinit" (add the Bash shell comment mark "#" to
the beginning of the relevant line). The second "swapon -a" command will
activate the LVM swap partition just fine. The comments in "rc.sysinit" seem to
indicate that the intent of having "swapon -a" twice is to activate swap
partitions before swap files presumably because partitions are more efficient
than files, but swap priorities might be designated by "swapon -p PRIORITY"
combined with the "pri=PRIORITY" option for swap in "/etc/fstab" if that is the
case. Also, the manual pages for "swapon" and "fstab" indicate that the "swapon
-a" command activates partitions indicated by block devices and not ordinary
files, although the manual page may be wrong compared with the current release
of "swapon".

As an additional, minor note, the command in "linuxrc" which is given as
"vgchange -ay" is given in "rc.sysinit" as "vgchange -a y". Note the "space"
between "a" and "y". Since "vgchange" still seems to work, I don't know if the
discrepancy matters.