FAQ
Hi

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

Search Discussions

  • Phil Schaffner at Mar 31, 2011 at 10:24 am

    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?
  • Nick at Mar 31, 2011 at 11:46 am

    On 31/03/11 15:24, Phil Schaffner wrote:
    Cal Sawyer wrote on 03/31/2011 08:13 AM:
    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.
    Do you really mean "OS" - i.e. CentOS 5.4? I would guess you are merely
    referring to the kernel, 2.6.18-164el5PAE.

    N
  • Akemi Yagi at Mar 31, 2011 at 12:33 pm

    On Thu, Mar 31, 2011 at 8:46 AM, Nick wrote:
    On 31/03/11 15:24, Phil Schaffner wrote:
    Cal Sawyer wrote on 03/31/2011 08:13 AM:
    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.
    Do you really mean "OS" - i.e. CentOS 5.4? ? I would guess you are merely
    referring to the kernel, 2.6.18-164el5PAE.
    You would seriously want to go through all the security updates that
    came out after 2009-09-02 and assess the vulnerability of your CentOS
    5.4 system:

    https://rhn.redhat.com/errata/rhel-server-errata-security.html

    Akemi
  • Rudi Ahlers at Mar 31, 2011 at 12:57 pm

    On Thu, Mar 31, 2011 at 6:33 PM, Akemi Yagi wrote:
    On Thu, Mar 31, 2011 at 8:46 AM, Nick wrote:
    On 31/03/11 15:24, Phil Schaffner wrote:
    Cal Sawyer wrote on 03/31/2011 08:13 AM:
    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.
    Do you really mean "OS" - i.e. CentOS 5.4? I would guess you are merely
    referring to the kernel, 2.6.18-164el5PAE.
    You would seriously want to go through all the security updates that
    came out after 2009-09-02 and assess the vulnerability of your CentOS
    5.4 system:

    https://rhn.redhat.com/errata/rhel-server-errata-security.html

    Akemi
    _______________________________________________
    I don't think the OP asked how secure, or in-secure, his system is. So
    please try and keep on-topic?

    @Cal,

    You could assign a LABEL to each hard drive. The LABEL is attached to the
    drive's UID (I think?) so even if you move the drive to anther port it will
    still be accessible via the same LABEL

    Look here: http://lissot.net/partition/ext2fs/labels.html
    --
    Kind Regards
    Rudi Ahlers
    SoftDux

    Website: http://www.SoftDux.com
    Technical Blog: http://Blog.SoftDux.com
    Office: 087 805 9573
    Cell: 082 554 7532
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.centos.org/pipermail/centos/attachments/20110331/8b51da25/attachment.html
  • John R. Dennison at Mar 31, 2011 at 1:02 pm

    On Thu, Mar 31, 2011 at 06:57:00PM +0200, Rudi Ahlers wrote:
    I don't think the OP asked how secure, or in-secure, his system is. So
    please try and keep on-topic?
    Whether asked for or not it is negligent to _not_ point out that
    there are holes large enough to fly a space shuttle through on
    that box; just as it is negligent to _not_ encourage the OP to
    update the box.
    @Cal,
    This is twitter now? :)



    John
    --
    The political machine triumphs because it is a united minority acting
    against a divided majority.

    -- Will Durant (1885-1981), American historian, philosopher and writer
    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: not available
    Type: application/pgp-signature
    Size: 189 bytes
    Desc: not available
    Url : http://lists.centos.org/pipermail/centos/attachments/20110331/3cb23426/attachment.bin
  • Rudi Ahlers at Mar 31, 2011 at 1:09 pm

    On Thu, Mar 31, 2011 at 7:02 PM, John R. Dennison wrote:
    On Thu, Mar 31, 2011 at 06:57:00PM +0200, Rudi Ahlers wrote:

    I don't think the OP asked how secure, or in-secure, his system is. So
    please try and keep on-topic?
    Whether asked for or not it is negligent to _not_ point out that
    there are holes large enough to fly a space shuttle through on
    that box; just as it is negligent to _not_ encourage the OP to
    update the box.
    @Cal,
    This is twitter now? :)



    John
    --

    But as with so many posts on the mailing lists these days everyone seem to
    wonder off from the original topic and not even bother to help with OP with
    the original question. Surely he has a good reason why his system not
    updated yet.


    --
    Kind Regards
    Rudi Ahlers
    SoftDux

    Website: http://www.SoftDux.com
    Technical Blog: http://Blog.SoftDux.com
    Office: 087 805 9573
    Cell: 082 554 7532
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.centos.org/pipermail/centos/attachments/20110331/04be2ff7/attachment.html
  • Charles Polisher at Apr 7, 2011 at 11:11 pm

    Rudi Ahlers wrote:
    John R. Dennison wrote:
    Rudi Ahlers wrote:
    <snip />
    But as with so many posts on the mailing lists these days everyone seem to
    wonder off from the original topic and not even bother to help with OP with
    the original question. Surely he has a good reason why his system not
    updated yet.
    Amen.

    To the OP, from man mke2fs:

    -L new-volume-label
    Set the volume label for the filesystem to new-volume-label.
    The maximum length of the volume label is 16 bytes.

    Method 1:
    When creating a new filesystem with mke2fs use the "-L mylabel"
    option, or use e2label to change the label on a previously-
    created filesystem. In /etc/fstab use a corresponding LABEL=mylabel
    filesystem spec (first field).

    Method 2:
    Use blkid to get the uuid for your partitions. Then use
    UUID�000000-1111-2222-3333-444455556666 in /etc/fstab in the
    first field. From my point of view the advantage is that if
    during some service manouver a disk is shuffled into the wrong
    slot, you can puzzle out how to put humpty-dumpty back together.
    (Having previously made an off-host copy of /etc/fstab.)

    --
    Charles Polisher
  • Lamar Owen at Mar 31, 2011 at 1:26 pm

    On Thursday, March 31, 2011 10:24:42 am Phil Schaffner wrote:
    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.
    No to pick on you, Phil, but the OP may have very specific reasons to run that particular system; and he may not. And while the advice 'please update' is a good thing, it doesn't really answer the question at hand.

    Cal, you might want to rethink your udev script for one; also, module load order may not be something you can easily control; while you might easily load the RAID controller's module first, then load the others, that is no guarantee that the RAID controller will be detected first. These days, you have to be resilient to drive device changes, even for the root filesystem. And that module load order will be found in the initramfs (initrd), and you'd have to go in and hack that to get things to load in the order you want. But then that will all break when you go to C6 or later, as udev is used from the initrd using dracut, and hardcoding module load order becomes much more difficult.

    For instance, I have a Fedora 14 box (which acts much like a CentOS 6 box would act, and not like a C5 box acts, but that's beside the point) where different boots can bring up a different device order; in this particular case, I have a 3Ware RAID controller from which I boot and which has four 250GB SATA drives on it in RAID5 for boot and root, then a SATA/eSATA 64-bit PCI-X board (two internal SATA, two eSATA, 3Gb/s ports) with two interal 750GB drives in MD RAID 1, and I do boot with eSATA drives plugged in, or not, at different times. This box is also connected via dual-port Fibre Channel to our SAN, and it has several multipath LUNs associated with that.

    My last detected SCSI device is currently /dev/sdab, but that is without any eSATA or USB devices, so I could see /dev/sdad or higher on occasion; and because it's set up with multipathing based on scsi_dh_emc, it doesn't have contiguous device names, either (the current setup is: sda, sdb, sdf, sdg, sdi, sdj, sdp, sdu, sdw, sdx, sdy, sdab). This is not only subject to change at each boot, but it's subject to change while the system is running, thanks to scsi_dh_emc, and thanks to there being more than even two paths to a given LUN.

    I haven't had any trouble, even when the RAID array was the one that got detected dead last, as /dev/sdac (in /etc/fstab, /boot is mounted by UUID, and root by LVM).

    But I'm also not automounting hotplugged eSATA drives, either. USB devices get automounted into /media with their labels as they should; that's the out-of-box behavior.

    Trying to get specific about device order is going to become increasingly difficult as time goes on; you might consider trying to get away from hardcoded drive names.

    But in the short term, try starting your hotplugged devices at /dev/sde or f and see if that fixes the /dev/sdd not working issue.
  • Neubyr at Mar 31, 2011 at 6:22 pm
    Hi,

    I need to mount a LVM in rescue mode to create a new initrd image. I
    am not sure how do I fond out which LogVol is to be mounted. How do I
    find it out? In most of the configs I have used LogVol00 with ext3
    filesystem which contains OS install. This particular system is not
    installed by me and I am not sure how do I find it out. I did try 'lvm
    lvs' command, but probably that's not the right command here. Any
    help?

    --
    thanks,
    neuby.r.
  • Winter at Mar 31, 2011 at 8:50 pm

    On 3/31/2011 6:22 PM, neubyr wrote:
    Hi,

    I need to mount a LVM in rescue mode to create a new initrd image. I
    am not sure how do I fond out which LogVol is to be mounted. How do I
    find it out? In most of the configs I have used LogVol00 with ext3
    filesystem which contains OS install. This particular system is not
    installed by me and I am not sure how do I find it out. I did try 'lvm
    lvs' command, but probably that's not the right command here. Any
    help?

    --
    thanks,
    neuby.r.
    Good evening, Neuby

    When you boot into rescue mode are you given the option to
    continue-mount or read-only-mount the system to /mnt/sysimage? You
    could try to view /mnt/sysimage/etc/fstab to find the partition types.

    Regards,

    W.
  • Nico Kadel-Garcia at Mar 31, 2011 at 9:39 pm

    On Thu, Mar 31, 2011 at 8:50 PM, Winter wrote:
    On 3/31/2011 6:22 PM, neubyr wrote:
    Hi,

    I need to mount a LVM in rescue mode to create a new initrd image. I
    am not sure how do I fond out which LogVol is to be mounted. How do I
    find it out? ?In most of the configs I have used LogVol00 with ext3
    filesystem which contains OS install. This particular system is not
    installed by me and I am not sure how do I find it out. I did try 'lvm
    lvs' command, but probably that's not the right command here. Any
    help?

    --
    thanks,
    neuby.r.
    Good evening, Neuby

    When you boot into rescue mode are you given the option to
    continue-mount or read-only-mount the system to /mnt/sysimage? ?You
    could try to view /mnt/sysimage/etc/fstab to find the partition types.

    Regards,

    W.
    If he could do *that*, he would already have the volumes mounted,
    barring other strangeness going on. They'd all be mounted under
    "/mnt/sysimage", and would be revealed by the "df" or "mount"
    commands.

    If this isn't available, the "pvscan", "vgscan", and "lvscan" commands
    are all available in the bootable CD, *but* they are all built into
    the underlying "lvm" command. So type "lvm pvscan" to find what
    physical volumes are set up for LVM, "lvm vgscan" to find the volume
    groups, and "lvm lvscan" to find the volumes.

    Re-activating an 'inactive' LVM due to a messed up configuration or
    volume is left as an exercise for the reader.
  • Neubyr at Mar 31, 2011 at 11:36 pm

    On Thu, Mar 31, 2011 at 8:39 PM, Nico Kadel-Garcia wrote:
    On Thu, Mar 31, 2011 at 8:50 PM, Winter wrote:
    On 3/31/2011 6:22 PM, neubyr wrote:
    Hi,

    I need to mount a LVM in rescue mode to create a new initrd image. I
    am not sure how do I fond out which LogVol is to be mounted. How do I
    find it out? ?In most of the configs I have used LogVol00 with ext3
    filesystem which contains OS install. This particular system is not
    installed by me and I am not sure how do I find it out. I did try 'lvm
    lvs' command, but probably that's not the right command here. Any
    help?

    --
    thanks,
    neuby.r.
    Good evening, Neuby

    When you boot into rescue mode are you given the option to
    continue-mount or read-only-mount the system to /mnt/sysimage? ?You
    could try to view /mnt/sysimage/etc/fstab to find the partition types.

    Regards,

    W.
    If he could do *that*, he would already have the volumes mounted,
    barring other strangeness going on. They'd all be mounted under
    "/mnt/sysimage", and would be revealed by the "df" or "mount"
    commands.

    If this isn't available, the "pvscan", "vgscan", and "lvscan" commands
    are all available in the bootable CD, *but* they are all built into
    the underlying "lvm" command. So type "lvm pvscan" to find what
    physical volumes are set up for LVM, "lvm vgscan" to find the volume
    groups, and "lvm lvscan" to find the volumes.

    Re-activating an 'inactive' LVM due to a messed up configuration or
    volume is left as an exercise for the reader.
    _______________________________________________
    CentOS mailing list
    CentOS at centos.org
    http://lists.centos.org/mailman/listinfo/centos
    It's not mounting any volumes by default as it's not able to read
    partition table and hence says no Linux partitions found. But I am
    able to see partitions using fdisk and check LVM volumes. I am not
    sure which volume of that contains OS install VolGroup00-LogVol00 or
    VolGroup00-LogVol01. Is there any way I can determine it?
  • Cal Sawyer at Apr 1, 2011 at 3:54 am
    Apologies in advance for excerpting or leaving out the messages sent to the list as i was in digest mode so got them all in one lump.

    Rudi Ahlers:

    You could assign a LABEL to each hard drive. The LABEL is attached to the
    drive's UID (I think?) so even if you move the drive to anther port it will
    still be accessible via the same LABEL
    Unfortunately, the removable devices are utterly random and rarely if ever the same device seen twice.
    Kind Security Advisors, i appreciate the potential issues resulting from not upgrading. These systems are behind VPNs, so out of reach other than from within a secured environment. They are not production systems per se - i consider them more as appliances and that necessitates a certain hands-off-it-works approach. If gives any relief, front-facing production systems i manage _are_ patched up to the earholes. However, i will take your advice seriously and look into the logistics of performing remote security-level patches without breaking something irreparably.
    Lamar, thank you for your comments. My suspicion is that bus enumeration is the source of the initial device ordering - a similar thing happens when installing a secondary NIC, which sets itself up as eth0/eth1 ahead of the onboard NIC ports if they haven't; been preconfigured. I'm sure you've all read about that issue. However, I'm not aware of any way to alter the order of enumeration. Module load order appears to occur further down the chain - or does it?
    I have this synopsis of rc.sysint: http://www.comptechdoc.org/os/linux/startupman/linux_surcsysinit.html and will see if it's possible to get my array statically mounted before all of the dynamic stuff licks in.

    thanks, all! If anyone has any ideas that aren't security related ;) please feel free.

    - cal
    ?
  • Rudi Ahlers at Apr 1, 2011 at 4:23 am

    On Fri, Apr 1, 2011 at 9:54 AM, Cal Sawyer wrote:

    Apologies in advance for excerpting or leaving out the messages sent to the
    list as i was in digest mode so got them all in one lump.

    Rudi Ahlers:

    You could assign a LABEL to each hard drive. The LABEL is attached to the
    drive's UID (I think?) so even if you move the drive to anther port it will
    still be accessible via the same LABEL
    Unfortunately, the removable devices are utterly random and rarely if
    ever the same device seen twice.
    Yes, that's why you assign a LABEL to the device :) If the same hard drive
    gets used on the same server, but on random ports every time then the LABEL
    will still stay the same. I have a similar setup where I mount about 40-odd
    USB drives to a server on a regular basis. They each have their own mount
    points in /mnt/usb-hdd/xxxxxxxxxx and irrespective of which drive I connect
    to which USB port, or on which order, they all get mounted where they're
    supposed to :)

    --
    Kind Regards
    Rudi Ahlers
    SoftDux

    Website: http://www.SoftDux.com
    Technical Blog: http://Blog.SoftDux.com
    Office: 087 805 9573
    Cell: 082 554 7532
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.centos.org/pipermail/centos/attachments/20110401/e8c4647f/attachment.html
  • Cal Sawyer at Apr 1, 2011 at 6:08 am
    Nope sir. Assume never the same device twice and no control over those
    devices, so UUID is out of the question.



    thank you,



    - csawyer





    From: centos-bounces at centos.org [mailto:centos-bounces at centos.org] On
    Behalf Of Rudi Ahlers
    Sent: 01 April 2011 09:24
    To: CentOS mailing list
    Cc: Cal Sawyer
    Subject: Re: [CentOS] Controlling the order of /dev/sdX devices?





    On Fri, Apr 1, 2011 at 9:54 AM, Cal Sawyer
    wrote:

    Apologies in advance for excerpting or leaving out the messages sent to
    the list as i was in digest mode so got them all in one lump.

    Rudi Ahlers:


    You could assign a LABEL to each hard drive. The LABEL is attached to
    the
    drive's UID (I think?) so even if you move the drive to anther port it
    will
    still be accessible via the same LABEL
    Unfortunately, the removable devices are utterly random and rarely if
    ever the same device seen twice.



    Yes, that's why you assign a LABEL to the device :) If the same hard
    drive gets used on the same server, but on random ports every time then
    the LABEL will still stay the same. I have a similar setup where I mount
    about 40-odd USB drives to a server on a regular basis. They each have
    their own mount points in /mnt/usb-hdd/xxxxxxxxxx and irrespective of
    which drive I connect to which USB port, or on which order, they all get
    mounted where they're supposed to :)


    --
    Kind Regards
    Rudi Ahlers
    SoftDux

    Website: http://www.SoftDux.com
    Technical Blog: http://Blog.SoftDux.com
    Office: 087 805 9573
    Cell: 082 554 7532

    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.centos.org/pipermail/centos/attachments/20110401/549049f3/attachment.html
  • Brunner, Brian T. at Apr 1, 2011 at 9:50 am

    centos-bounces at centos.org wrote:
    Nope sir. Assume never the same device twice and no control
    over those devices, so UUID is out of the question.
    UUID is out of the question where I have 3 drives (main and two backup)
    with "wear leveling" wherein ANY of the drives, put in /dev/sda's
    position, is the boot drive, the identical backup on /dev/sdb will get
    backed-up-to on a daily basis, and on a weekly basis the drive in
    /dev/sdb moves to /dev/sda's connector (becoming the boot drive),
    '/dev/sda' goes off-site, and the third moves to /dev/sdb's position
    (and gets backed-up-onto promptly.

    LABEL also fails here.
    Yes, that's why you assign a LABEL to the device :) If the
    same hard drive gets used on the same server, but on random
    ports every time then the LABEL will still stay the same. I
    have a similar setup where I mount about 40-odd USB drives to
    a server on a regular basis. They each have their own mount
    points in /mnt/usb-hdd/xxxxxxxxxx and irrespective of which
    drive I connect to which USB port, or on which order, they
    all get mounted where they're supposed to :)
    This is excellent where each drive has distinct content.

    Insert spiffy .sig here:
    Life is complex: it has both real and imaginary parts.

    //me
    *******************************************************************
    This email and any files transmitted with it are confidential and
    intended solely for the use of the individual or entity to whom
    they are addressed. If you have received this email in error please
    notify the system manager. This footnote also confirms that this
    email message has been swept for the presence of computer viruses.
    www.Hubbell.com - Hubbell Incorporated**
  • Cal Sawyer at Apr 1, 2011 at 10:04 am
    I think that everyone lese lives in a far more ordered universe than i
    do. My "problem" - no, wait - "challenge" is that i have zero control
    over the origin of incoming media on USB and eSATA. Could be any brand
    of USB stick sold under the sun or HDDs formatted FAT32, NTFS, ext2/3.
    The only constants are things i directly control (sysdisk, RAID) -
    everything else is a crap-shoot. Everyone else can use labels.

    I don't know about you but it "feels" like mounting a RAID array,
    possibly with an active mySQL database on it under udev is kind of
    disaster-prone. I would much rather mount via fstab.


    - csawyer

    -----Original Message-----
    From: centos-bounces at centos.org [mailto:centos-bounces at centos.org] On
    Behalf Of Brunner, Brian T.
    Sent: 01 April 2011 14:51
    To: CentOS mailing list
    Subject: Re: [CentOS] Controlling the order of /dev/sdX devices?

    centos-bounces at centos.org wrote:
    Nope sir. Assume never the same device twice and no control
    over those devices, so UUID is out of the question.
    UUID is out of the question where I have 3 drives (main and two backup)
    with "wear leveling" wherein ANY of the drives, put in /dev/sda's
    position, is the boot drive, the identical backup on /dev/sdb will get
    backed-up-to on a daily basis, and on a weekly basis the drive in
    /dev/sdb moves to /dev/sda's connector (becoming the boot drive),
    '/dev/sda' goes off-site, and the third moves to /dev/sdb's position
    (and gets backed-up-onto promptly.

    LABEL also fails here.
    Yes, that's why you assign a LABEL to the device :) If the
    same hard drive gets used on the same server, but on random
    ports every time then the LABEL will still stay the same. I
    have a similar setup where I mount about 40-odd USB drives to
    a server on a regular basis. They each have their own mount
    points in /mnt/usb-hdd/xxxxxxxxxx and irrespective of which
    drive I connect to which USB port, or on which order, they
    all get mounted where they're supposed to :)
    This is excellent where each drive has distinct content.

    Insert spiffy .sig here:
    Life is complex: it has both real and imaginary parts.

    //me
    *******************************************************************
    This email and any files transmitted with it are confidential and
    intended solely for the use of the individual or entity to whom
    they are addressed. If you have received this email in error please
    notify the system manager. This footnote also confirms that this
    email message has been swept for the presence of computer viruses.
    www.Hubbell.com - Hubbell Incorporated**

    _______________________________________________
    CentOS mailing list
    CentOS at centos.org
    http://lists.centos.org/mailman/listinfo/centos
  • Robert Heller at Apr 1, 2011 at 10:42 am

    At Fri, 1 Apr 2011 15:04:04 +0100 CentOS mailing list wrote:
    I think that everyone lese lives in a far more ordered universe than i
    do. My "problem" - no, wait - "challenge" is that i have zero control
    over the origin of incoming media on USB and eSATA. Could be any brand
    of USB stick sold under the sun or HDDs formatted FAT32, NTFS, ext2/3.
    The only constants are things i directly control (sysdisk, RAID) -
    everything else is a crap-shoot. Everyone else can use labels.
    Nevermind the incoming (removable) media on USB and eSATA -- that is
    not really your problem. *Your* problem is only the system disk and
    the 3ware RAID disk. I understand that the sysdisk gets handed
    properly early in the initrd (before udev's hotplug rule ruins your
    day), this leaves the RAID disk. It presumable shows up with
    *something* in .../device/vender that is specific to the 3ware
    controller. Since the (hardware) RAID disk is never going to be real
    hardware disk (I presume you are not running the controller in JOBD
    mode), it is going to have some 'made up' disk vendor / model,
    generated by the RAID controller. You should be able to use this
    information in a SYSFS{device/vendor} check (eg
    SYSFS{device/vendor}!="3warediskvendor") in your special hotplug rule
    to force read-only mounting of "random" removable USB and eSATA disks
    to force this rule to leave the RAID disk alone, no matter what it
    shows up as. OR you can have another rule to make the RAID disk show
    up as *something* other than /dev/sdXX -- this is what I did with my
    thumb drive, making it show up as /dev/thumb -- I also did something
    similar with an old (now defunk) SCSI Zip and ORB2 drive. There is
    nother 'sacred' about the device files being /dev/sdXX, so long as the
    major and minor device numbers are correct for the physical device.
    I don't know about you but it "feels" like mounting a RAID array,
    possibly with an active mySQL database on it under udev is kind of
    disaster-prone. I would much rather mount via fstab.


    - csawyer

    -----Original Message-----
    From: centos-bounces at centos.org [mailto:centos-bounces at centos.org] On
    Behalf Of Brunner, Brian T.
    Sent: 01 April 2011 14:51
    To: CentOS mailing list
    Subject: Re: [CentOS] Controlling the order of /dev/sdX devices?

    centos-bounces at centos.org wrote:
    Nope sir. Assume never the same device twice and no control
    over those devices, so UUID is out of the question.
    UUID is out of the question where I have 3 drives (main and two backup)
    with "wear leveling" wherein ANY of the drives, put in /dev/sda's
    position, is the boot drive, the identical backup on /dev/sdb will get
    backed-up-to on a daily basis, and on a weekly basis the drive in
    /dev/sdb moves to /dev/sda's connector (becoming the boot drive),
    '/dev/sda' goes off-site, and the third moves to /dev/sdb's position
    (and gets backed-up-onto promptly.

    LABEL also fails here.
    Yes, that's why you assign a LABEL to the device :) If the
    same hard drive gets used on the same server, but on random
    ports every time then the LABEL will still stay the same. I
    have a similar setup where I mount about 40-odd USB drives to
    a server on a regular basis. They each have their own mount
    points in /mnt/usb-hdd/xxxxxxxxxx and irrespective of which
    drive I connect to which USB port, or on which order, they
    all get mounted where they're supposed to :)
    This is excellent where each drive has distinct content.

    Insert spiffy .sig here:
    Life is complex: it has both real and imaginary parts.

    //me
    *******************************************************************
    This email and any files transmitted with it are confidential and
    intended solely for the use of the individual or entity to whom
    they are addressed. If you have received this email in error please
    notify the system manager. This footnote also confirms that this
    email message has been swept for the presence of computer viruses.
    www.Hubbell.com - Hubbell Incorporated**

    _______________________________________________
    CentOS mailing list
    CentOS at centos.org
    http://lists.centos.org/mailman/listinfo/centos
    _______________________________________________
    CentOS mailing list
    CentOS at centos.org
    http://lists.centos.org/mailman/listinfo/centos
    --
    Robert Heller -- 978-544-6933 / heller at deepsoft.com
    Deepwoods Software -- http://www.deepsoft.com/
    () ascii ribbon campaign -- against html e-mail
    /\ www.asciiribbon.org -- against proprietary attachments
  • Lamar Owen at Apr 1, 2011 at 9:17 am

    On Friday, April 01, 2011 04:23:40 am Rudi Ahlers wrote:
    Yes, that's why you assign a LABEL to the device :)
    According to the OP's initial message, I think he's already doing this:
    SATA system HDD /dev/VolGroup00/LogVol00 /
    RAID array LABEL=STORE /store ## mounts ==
    /dev/sdb1
    But I could be wrong.

    The issue seemed to be that the udev rule prevented the detection of the LVM on that RAID completely when it came up as /dev/sdd.

    The other udev rule in-thread seems to be a possible solution; will be interesting to see if it works.
  • Cal Sawyer at Apr 1, 2011 at 9:53 am
    Nope, no LVM on the RIAD array. It just needs to load right after the main LVM so that something removable doesn't wiggle its way in and mess up the device order.

    Yes, the suggestion from Robert H looks promising - working on it now. Did i say i hate udev? I thought there was going to be a replacement for it at some point?

    - cal sawyer
    ?


    -----Original Message-----
    From: centos-bounces at centos.org [mailto:centos-bounces at centos.org] On Behalf Of Lamar Owen
    Sent: 01 April 2011 14:18
    To: CentOS mailing list
    Subject: Re: [CentOS] Controlling the order of /dev/sdX devices?
    On Friday, April 01, 2011 04:23:40 am Rudi Ahlers wrote:
    Yes, that's why you assign a LABEL to the device :)
    According to the OP's initial message, I think he's already doing this:
    SATA system HDD /dev/VolGroup00/LogVol00 /
    RAID array LABEL=STORE /store ## mounts ==
    /dev/sdb1
    But I could be wrong.

    The issue seemed to be that the udev rule prevented the detection of the LVM on that RAID completely when it came up as /dev/sdd.

    The other udev rule in-thread seems to be a possible solution; will be interesting to see if it works.
    _______________________________________________
    CentOS mailing list
    CentOS at centos.org
    http://lists.centos.org/mailman/listinfo/centos
  • Lamar Owen at Apr 1, 2011 at 10:19 am

    On Friday, April 01, 2011 09:53:06 am Cal Sawyer wrote:
    Nope, no LVM on the RIAD array. It just needs to load right after the main LVM so that something removable doesn't wiggle its way in and mess up the device order.
    Ok, so the LVM line was for the previous filesystem; it wasn't completely clear from the post. The LABEL line was clear, though.
    Yes, the suggestion from Robert H looks promising - working on it now. Did i say i hate udev? I thought there was going to be a replacement for it at some point?
    udev *is* the replacement, and with C6 you're going to find it far earlier in the boot process, inside the initramfs courtesy of dracut.

    Like it or not, fixed always-the-same device ids are going away for disk drives in Fedora-derived (and by extension, Red Hat derived) distributions. udev might seem to be overkill, but it is what it is and it's here to stay, in CentOS-land at least, for as long as C6 is supported. Might as well bite the bullet and learn how to do what needs to be done in udev. Once figured out, you might find it more powerful than fixed ids ever were; I don't know, because I've not tried to do things like your situation.

    Let us know if the suggeston works, and how well or not well it works. Your 'read-only for all external drives' situation is unique; note that there are times that I've booted up a box with a removable plugged in, and the removable failed to enumerate at all. It would only enumerate when it was hotplugged after the kernel systems were up; the particular case is with a USB3 drive and an ExpressCard USB 3 controller on Fedora 14, but I have had the issue with USB 2 devices on previous Fedoras, that might be reflected in C6.
  • Cal Sawyer at Apr 1, 2011 at 1:08 pm
    ack, i can feel my hair greying ... again. *But*, i do appreciate your insight into the future direction of CentOS device handling. Having read this, i'm going to bite the bullet and dive into smarting-up my udev rules, feeding a handler script that will decide what to do about what kind of device before blindly executing mounts based on KERNEL values.

    Two silly questions:

    1. in udev rule's RUN+-"", can i pass an arbitrary string that's not one of the %tokens? I pass %k %n, of course, but i'd like to tag something to indicate which rule was processed in a downstream script.
    2. Will udev, as it develops (i hope), will there be any provision blacklisting/whitelisting devices?

    Were it not for the removable-read-only requirement, i'd have been content with HAL doing the work. It does work well for handling CD/DVDROM discs (the 3rd type of removable we deal with) but doesn't do granular device detection well enough to set read-only for removable media only and a read-only RAID array is not that useful.

    many thanks - good weekend, all

    - csawyer
    ?


    -----Original Message-----
    From: centos-bounces at centos.org [mailto:centos-bounces at centos.org] On Behalf Of Lamar Owen
    Sent: 01 April 2011 15:19
    To: CentOS mailing list
    Subject: Re: [CentOS] Controlling the order of /dev/sdX devices?
    On Friday, April 01, 2011 09:53:06 am Cal Sawyer wrote:
    Nope, no LVM on the RIAD array. It just needs to load right after the main LVM so that something removable doesn't wiggle its way in and mess up the device order.
    Ok, so the LVM line was for the previous filesystem; it wasn't completely clear from the post. The LABEL line was clear, though.
    Yes, the suggestion from Robert H looks promising - working on it now. Did i say i hate udev? I thought there was going to be a replacement for it at some point?
    udev *is* the replacement, and with C6 you're going to find it far earlier in the boot process, inside the initramfs courtesy of dracut.

    Like it or not, fixed always-the-same device ids are going away for disk drives in Fedora-derived (and by extension, Red Hat derived) distributions. udev might seem to be overkill, but it is what it is and it's here to stay, in CentOS-land at least, for as long as C6 is supported. Might as well bite the bullet and learn how to do what needs to be done in udev. Once figured out, you might find it more powerful than fixed ids ever were; I don't know, because I've not tried to do things like your situation.

    Let us know if the suggeston works, and how well or not well it works. Your 'read-only for all external drives' situation is unique; note that there are times that I've booted up a box with a removable plugged in, and the removable failed to enumerate at all. It would only enumerate when it was hotplugged after the kernel systems were up; the particular case is with a USB3 drive and an ExpressCard USB 3 controller on Fedora 14, but I have had the issue with USB 2 devices on previous Fedoras, that might be reflected in C6.
    _______________________________________________
    CentOS mailing list
    CentOS at centos.org
    http://lists.centos.org/mailman/listinfo/centos
  • Cal Sawyer at Apr 1, 2011 at 6:05 am
    The reason for the udev hotplug rule is simply for the purpose of mounting removable devices as read-only. If udev is left to its devices, everything plugged up is read-write which is verboten in this application. Unfortunately, there seems to be no way (i've found) to distinguish, at device/bus level, between a system HDD, a hardware RAID volume and an eSATA device and handle the eSATA device uniquely from others. All eSATA and USB devices _must_ mount read-only. If everything is lined up at boot, sda and sdb are camped via fstab and udev deals with sdc and above, mounting what are known to be removable devices as r/o. Shotgun, i know, but there is no way of knowing in advance what devices the system (er, appliance) will see.

    tangled, huh?

    thanks

    - csawyer

    Robert Heller heller at deepsoft.com
    Thu Mar 31 14:20:55 EDT 2011

    Previous message: [CentOS] CentOS Digest, Vol 74, Issue 31
    Next message: [CentOS] figuring out LogVol details for mount
    Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
    At Thu, 31 Mar 2011 18:23:00 +0100 CentOS mailing list 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.

    - cal sawyer
    ?
  • Robert Heller at Apr 1, 2011 at 7:41 am

    At Fri, 1 Apr 2011 11:05:35 +0100 CentOS mailing list wrote:
    The reason for the udev hotplug rule is simply for the purpose of mounting removable devices as read-only. If udev is left to its devices, everything plugged up is read-write which is verboten in this application. Unfortunately, there seems to be no way (i've found) to distinguish, at device/bus level, between a system HDD, a hardware RAID volume and an eSATA device and handle the eSATA device uniquely from others. All eSATA and USB devices _must_ mount read-only. If everything is lined up at boot, sda and sdb are camped via fstab and udev deals with sdc and above, mounting what are known to be removable devices as r/o. Shotgun, i know, but there is no way of knowing in advance what devices the system (er, appliance) will see.

    tangled, huh?
    Does this give you a clue (this is a rule I use for my thumb drive,
    which is a vfat file system, and thus cannot have a LABEL'd file system):

    gollum.deepsoft.com% cat /etc/udev/rules.d/10-local.rules
    KERNEL=="sd[a-z]*", BUS=="scsi", SYSFS{device/vendor}=="Kingston", NAME="thumb"

    Hint: the 'brand' of thumb drive I have is Kingston and == can be
    replaced with !=.

    In your special mount read-only hot plug rule, you just need a
    SYSFS{device/vendor}!="3ware" (or whatever the vendor of the RAID array
    shows up as -- look in /sys/block/sd<mumble>/device/vendor)
    thanks

    - csawyer

    Robert Heller heller at deepsoft.com
    Thu Mar 31 14:20:55 EDT 2011

    Previous message: [CentOS] CentOS Digest, Vol 74, Issue 31
    Next message: [CentOS] figuring out LogVol details for mount
    Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
    At Thu, 31 Mar 2011 18:23:00 +0100 CentOS mailing list 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.

    - cal sawyer
    ??
    _______________________________________________
    CentOS mailing list
    CentOS at centos.org
    http://lists.centos.org/mailman/listinfo/centos
    --
    Robert Heller -- 978-544-6933 / heller at deepsoft.com
    Deepwoods Software -- http://www.deepsoft.com/
    () ascii ribbon campaign -- against html e-mail
    /\ www.asciiribbon.org -- against proprietary attachments
  • Winter at Apr 3, 2011 at 3:26 pm

    When you boot into rescue mode are you given the option to
    continue-mount or read-only-mount the system to /mnt/sysimage? You could
    try to view /mnt/sysimage/etc/fstab to find the partition types.

    Regards,

    W.
    Hello everyone,

    I was, of course, a numbnut for suggesting this. I don't normally LVM
    the / partition, so I didn't think of it. I'll try to, er, open my mind
    out of my environment for future helpful suggestions.

    Actually, the thread was an example of why I don't LVM /. I think it
    adds another layer I'd rather not have to deal with when things go
    casters up. But that is just My Way and it is not The Only Way.

    Not a knock on Neuby, since it wasn't installed by him.

    How goes the battle, by the way?

    W.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupcentos @
categoriescentos
postedMar 31, '11 at 8:13a
activeApr 7, '11 at 11:11p
posts26
users13
websitecentos.org
irc#centos

People

Translate

site design / logo © 2022 Grokbase