CentOS - Nov 2008 - noauto option ignored in CentOS 5.1?

I have worked quite a bit with CentOS 4.x with
SAN, multipathing, LVM etc. The way I mount my
file systems is using a script that is called during
startup that runs fsck, imports the physical volumes,
and volume groups, activates the logical volumes, creates
the mount point if needed then mounts the volume, I mainly
made it for software iSCSI due to the iscsi stack loading
after the system mount process. I adapted it to my fiber
channel systems as well and it worked great(mainly so
I could have a consistent experience between FC and
iSCSI).

In testing with CentOS 5.1 it seems that my entries
in /etc/fstab that are marked "noauto" are still infact
queried when the system boots (before multipathing, etc
fires up). These devices don't exist at the time which
causes the boot to halt(so I can fsck the file system
manually). I have worked around it by commenting out the
line in fstab, and just adjusting my script to look for
the commented line, but this never happened under
CentOS 4.x, seems like a bug ? I peeked at Red Hat's
bugzilla but didn't see much.

If so I can file one..

thanks

nate

On Wed, 2008-11-19 at 10:29 -0800, nate wrote:
> I have worked quite a bit with CentOS 4.x with
> SAN, multipathing, LVM etc. The way I mount my
> file systems is using a script that is called during
> startup that runs fsck, imports the physical volumes,
> and volume groups, activates the logical volumes, creates
> the mount point if needed then mounts the volume, I mainly
> made it for software iSCSI due to the iscsi stack loading
> after the system mount process. I adapted it to my fiber
> channel systems as well and it worked great(mainly so
> I could have a consistent experience between FC and
> iSCSI).
> 
Hmm.. not sure about older versions of CentOS but for lvm over iscsi in
5.2 all you should need is 

/dev/foo.vg/foo.lv /foo xfs _netdev,noatime,rw 0 0

in /etc/fstab and iscsi node startup set to automatic (which is the
default I believe). _netdev being the key as it will mount it after
iscsi is loaded and connected. 

And since the volume is being asked to mount at boot time, the startup
scripts are smart enough to find and activate the volume group and
logical volume.

Nothing extra required. 

Only issue I've had is sometimes after unclean shutdowns the volume
group gets deactivated and must be manually activated and mounted,
though this has never prevented booting.

Though this doesn't include the fsck'ing you mentioned..
-- 
Matthew Kent \ SA \ bravenet.com

nate wrote:
> Found the root issue here I believe in /etc/rc.sysinit
>
> if [ "${RHGB_STARTED}" != "0" -a -w
/etc/rhgb/temp/rhgb-console ]; then
>                 fsck -T -t noopts=_netdev -A $fsckoptions >
After changing _netdev above to "noauto" the system boots
normally. I'm not sure if I could specify noopts=_netdev,noauto
or what the syntax is, can't find that syntax in the docs.

Before:

device-mapper: create ioctl failed: Device or resource busy
Setting up Logical Volume Management:   Volume group
"san-p-mysql001a-db" is
exported
  Volume group "san-p-mysql001a-log" is exported
[FAILED]
Checking filesystems
Checking all file systems.
[/sbin/fsck.ext3 (1) -- /] fsck.ext3 -a /dev/sda3
/1: clean, 80554/59834368 files, 2441697/59807986 blocks
[/sbin/fsck.ext3 (1) -- /san/MrT/mysql/db] fsck.ext3 -a
/dev/san-p-mysql001a-log/san-p-mysql001a-log
fsck.ext3: No such file or directory while trying to open
/dev/san-p-mysql001a-log/san-p-mysql001a-log
/dev/san-p-mysql001a-log/san-p-mysql001a-log:
The superblock could not be read or does not describe a correct ext2
filesystem.  If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock is
corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>

[/sbin/fsck.ext3 (1) -- /san/MrT/mysql/log] fsck.ext3 -a
/dev/san-p-mysql001a-db/san-p-mysql001a-db
fsck.ext3: No such file or directory while trying to open
/dev/san-p-mysql001a-db/san-p-mysql001a-db
/dev/san-p-mysql001a-db/san-p-mysql001a-db:
The superblock could not be read or does not describe a correct ext2
filesystem.  If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock is
corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>

[/sbin/fsck.ext3 (1) -- /boot] fsck.ext3 -a /dev/sda1
/boot: clean, 35/26104 files, 17544/104388 blocks
[FAILED]

*** An error occurred during the file system check.
*** Dropping you to a shell; the system will reboot
*** when you leave the shell.
Give root password for maintenance
(or type Control-D to continue):


after:

Setting up Logical Volume Management:   Volume group
"san-p-mysql001a-db" is
exported
  Volume group "san-p-mysql001a-log" is exported
[FAILED]
Checking filesystems
Checking all file systems.
[/sbin/fsck.ext3 (1) -- /] fsck.ext3 -a /dev/sda3
/1: clean, 80554/59834368 files, 2441697/59807986 blocks
[/sbin/fsck.ext3 (1) -- /boot] fsck.ext3 -a /dev/sda1
/boot: clean, 35/26104 files, 17544/104388 blocks
[  OK  ]
Remounting root filesystem in read-write mode:  [  OK  ]
Mounting local filesystems:  [  OK  ]
Enabling /etc/fstab swaps:  [  OK  ]
[..]
Starting mount_san:  Scanning and activating SAN-based volume groups
  PV /dev/dm-3    is in exported VG san-p-mysql001a-db [2.00 TB / 1.51 TB
free] PV /dev/dm-2    is in exported VG san-p-mysql001a-log [1023.99 GB /
973.99
GB free]
  Total: 2 [3.00 TB] / in use: 2 [3.00 TB] / in no VG: 0 [0   ]
  Volume group "san-p-mysql001a-db" successfully imported
  Volume group "san-p-mysql001a-log" successfully imported
Checking LVM SAN filesystems..
e2fsck 1.39 (29-May-2006)
/dev/san-p-mysql001a-db/san-p-mysql001a-db: clean, 11/128000 files,
63258/131072000 blocks
e2fsck 1.39 (29-May-2006)
/dev/san-p-mysql001a-log/san-p-mysql001a-log: clean, 11/12800 files,
22733/13107200 blocks
Finished checking LVM SAN filesystems..
Scanning and mounting multipathed
filesystems.....[/san/MrT/mysql/db]....[/san/MrT/mysql/log]..done! [  OK  ]

So will file a bug with RH I suppose to get them to tweak that
so that "noauto" behaves as expected.

nate