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.
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.
On Thu, Mar 31, 2011 at 8:50 PM, Winter winter@frostmarch.com 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.
On Thu, Mar 31, 2011 at 8:39 PM, Nico Kadel-Garcia nkadel@gmail.com wrote:
On Thu, Mar 31, 2011 at 8:50 PM, Winter winter@frostmarch.com 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@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?
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
On Fri, Apr 1, 2011 at 9:54 AM, Cal Sawyer <Cal.Sawyer@artsalliancemedia.com
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 :)
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@centos.org [mailto:centos-bounces@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 Cal.Sawyer@artsalliancemedia.com 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 :)
centos-bounces@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**
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@centos.org [mailto:centos-bounces@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@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@centos.org http://lists.centos.org/mailman/listinfo/centos
At Fri, 1 Apr 2011 15:04:04 +0100 CentOS mailing list centos@centos.org 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@centos.org [mailto:centos-bounces@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@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@centos.org http://lists.centos.org/mailman/listinfo/centos _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
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.
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@centos.org [mailto:centos-bounces@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@centos.org http://lists.centos.org/mailman/listinfo/centos
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.
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@centos.org [mailto:centos-bounces@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@centos.org http://lists.centos.org/mailman/listinfo/centos
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 <centos at 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.
- cal sawyer
At Fri, 1 Apr 2011 11:05:35 +0100 CentOS mailing list centos@centos.org 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 <centos at 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.
- cal sawyer
_______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
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.