At Thu, 31 Mar 2011 18:23:00 +0100 CentOS mailing list centos@centos.org wrote:
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.
Do you have some *nonstandard* udev rule for hot plug devices? The *standard* hotplug udev rules are not tied to specific ranges of sdXX's -- my IDE-based laptop will properly handle a hot plugged USB device at /dev/sda for example.
The hot plug logic should also not mess with not hot pluged devices. If your RAID array is mounted in /etc/fstab (or has a 'noauto' line in /etc/fstab with the idea of mounting it manually later or has something in automount's config for automounting it), the hot plug system should not touch it, no matter what /dev/sdXX it happens to land at, so long as you are using volume labels or some such to reference the mountable volumes.
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.
It *sounds* like you have something non-standard / fishy going on in udev's rules -- I suspect you have some sort of funky homegrown rule somewhere.
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
- 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@NASA.gov Subject: Re: [CentOS] Controlling the order of /dev/sdX devices? To: centos@centos.org Message-ID: 4D948EAA.2070005@NASA.gov 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@centos.org http://lists.centos.org/mailman/listinfo/centos