Re: CentOS Digest, Vol 74, Issue 31

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



thanks for the reply, Phil

It would, were udev not inserting USB and/or eSATA drives at /dev/sdb1
and/or /dev/sdc1 and exposing the array to the udev rule intended to
handle only removable devices (at sdc or sdd).  The array then mounts
unpredictably in /media/xxx-sdc1 or sdd1 - not what is wanted - depend
on how many removable devices are plugged at the time of rebooting. Of
course, a single removable device will camp at sdb, which is out of
reach of udev so the whole hotplug thing is broken until someone removes
all of the devices at site, allowing a clean boot. 

mapper correctly places the / filesystem higher in position in
rc.sysinit, followed by start_udev (where the damage gets done) and
finally fstab evaluation way down the line.  I suppose i could just
hardwire the array mount into rc.sysint to engage after modules get
loaded and hopefully before start_udev, unless there is a better way to
enforce it.  I'm not sure at this stage (need to analyse that ~1000-line
script) if there is a suitable insertion point.  It would be really good
if it could be done outside of rc.sysint in some predictable place.

We're "stuck" (but not unhappily) with this kernel/rev for the
foreseeable future - i have over 100 of these systems and they are
housed behind VPN'd networks, which mitigates somewhat their inevitable
vulnerabilities. 

regards,

- csawyer


  30. Re: Controlling the order of /dev/sdX devices? (Phil Schaffner)
CentOS 5.4(final) 2.6.18-164el5PAE.  I am trying to prevent removable
USB and eSATA devices from occupying /dev/sdX devices ahead of a 3ware
RAID controller.  For example: at boot, if a USB drive and eSATA HDD
(connected to an LSI 1068E onboard controller, reflashed in "IT" mode to
handle hotplug devices) were both present, they would occupy devices
/dev/sdb and /dev/sdc, ahead of the RAID controller which ends up as
/dev/sdd.  As these are removable devices, they should normally get
handled by custom udev script looking for adds matching
KERNEL=="sd[c-z][0-9]" ,SUBSYSTEM=="block", so the volume handled by
RAID controller gets grabbed by udev but fails to mount and subsequent
udev plug events fails due the slots left empty below /dev/sdd.  If no
hotplug devices are present while booting, fstab handles mounting of the
system and RAID volume:

SATA system HDD	/dev/VolGroup00/LogVol00 /
RAID array		LABEL=STORE      /store		## mounts ==
/dev/sdb1

I realise this description is kind of a tangle, but i am essentially
looking for a way to hard-map the 3ware RAID controller to /dev/sdb
(UUID won't work as there are multiples of this system) before PCI (?)
enumeration picks up the USB and LSI-managed devices so that udev can
take care of the device at /dev/sdc and above. I've tried blacklisting
the mpt and usb-storage modules and short-circuiting SUBSYSTEM=="block"
devices in 05-udev-early.rules, all with zero or negative effect.
rc.sysinit doesn't appear to be the right place and that's about as deep
down as i know how to go.

cheers,

cs

------------------------------

Message: 30
Date: Thu, 31 Mar 2011 10:24:42 -0400
From: Phil Schaffner <Philip.R.Schaffner@xxxxxxxx>
Subject: Re:  Controlling the order of /dev/sdX devices?
To: <centos@xxxxxxxxxx>
Message-ID: <4D948EAA.2070005@xxxxxxxx>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed

Cal Sawyer wrote on 03/31/2011 08:13 AM:
> Hi
>
> CentOS 5.4(final) 2.6.18-164el5PAE.

I hope you are aware that you are using a very obsolete OS with a lot of

known (i.e. exploitable) security holes and bugs that have subsequently 
been fixed.

...
> I realise this description is kind of a tangle

Indeed.  Why does a line in /etc/fstab like

LABEL=STORE      /store		ext3	defaults	1 2

not work?

_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos


[Index of Archives]     [CentOS]     [CentOS Announce]     [CentOS Development]     [CentOS ARM Devel]     [CentOS Docs]     [CentOS Virtualization]     [Carrier Grade Linux]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Linux USB]
  Powered by Linux