Re: sata0 is not sda
On 03/04/2013 02:14 PM, Ken Teh wrote:
I've seen the same behaviour with my LSI MegaRAIDs and I find it very
disconcerting.
EL6 was supposed to not be as nondeterministic as it has ended up being
(I know, horrible grammar, but gets the point across). Later Fedoras
are worse in this respect.
I use kickstart to upgrade machines by doing a full install. I
reserve the
system disks so I can wipe them out and reinstall at will. Now that I
don't
know which disk is which, kickstart becomes more cumbersome. Either I
have to
record the UUIDs and embed them in the kickstart file or open the box and
disconnect any non-system drive.
Back in the days of VMware ESX 3.x, the instructions from VMware
specifically stated to not attach any SAN or external drives, and to
only have the system drives active, during an install or update on a
host. The RHEL underlying ESX 3.x (NOT ESXi, a different beast) is a
modified and licensed version 3.x, and it was much more deterministic
about disks; but VMware still cautioned against having data disks attached.
I know it's a bother, but kickstarting to a machine with only the system
drive(s) installed is the safest thing to do. And using either mount by
{LABEL|UUID} or LVM is the only way to reliably do things if you have
multiple controllers these days.
I've decided to just not worry about the actual device name, and either
use labels, LVM with unique volgroups and logical volumes, or UUID's. I
have more important things to worry about.
But I don't use kickstart, either.
Re: sata0 is not sda
On Mon, Feb 18, 2013 at 03:01:00PM -0600, Ken Teh wrote: > > During a kickstart install, how are drives mapped? > Effectively randomly. For example, if I run the SL6.3 installer from a USB disk, sometimes this USB disk is named /dev/sda and the installer puts GRUB on it, instead of the disks where the system is installer - ruining the USB installer disk (overwrites the installer boot loader) and creating an unbootable system (no boot loader on the system disks). > > I notice that sata0 is not always sda. > I am not sure what you mean by "sata0". In my experience, the only reliable way to definitely identify the correct disks is by serial numbers. -- Konstantin Olchanski Data Acquisition Systems: The Bytes Must Flow! Email: olchansk-at-triumf-dot-ca Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada
Re: sata0 is not sda
On Mon, Mar 04, 2013 at 01:14:20PM -0600, Ken Teh wrote: > > I use kickstart to upgrade machines by doing a full install. I reserve the > system disks so I can wipe them out and reinstall at will. > ... > Now that I don't know which disk is which, ... > This is an intractable problem - Linux does not know which disks you think should be the system disks. This was true even in the "good old /dev/hda days" if you had more than one IDE controller. (system disk on the add-on "UDMA100" PCI card, data disks on the on-board "UDMA33" ports). Even if Linux could read your mind perfectly, when you run a kickstart that automatically irreversibly erases disks, you better disconnect all the "wrong" disks first, just in case you have a brain fart at the wrong moment. -- Konstantin Olchanski Data Acquisition Systems: The Bytes Must Flow! Email: olchansk-at-triumf-dot-ca Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada
Re: sata0 is not sda
On 03/04/2013 12:03 PM, Lamar Owen wrote: This is partially due in EL6 to the use of dracut and it's new initrd udev-ish system. I have one RHEL 6 box that is hooked to a pretty good-sized array on fibre-channel; it's fully HA, so there are four paths to any given LUN. My boot device, a 3Ware 9500-series SATA RAID card, ends up with a device name for it's first logical disk anywhere between /dev/sda and /dev/sdah; it's been /dev/sdu, /dev/sds, /dev/sdt, /dev/sdz, /dev/sdab, and pretty much everything in between, and it will vary from one boot to the next; it's at /dev/sdad right now. But I have the 3ware card, an on-motherboard U320 SCSI controller, a four-port Silicon Image SATA card, and a dual-port FC card hooked to the SAN. I've seen the same behaviour with my LSI MegaRAIDs and I find it very disconcerting. I use kickstart to upgrade machines by doing a full install. I reserve the system disks so I can wipe them out and reinstall at will. Now that I don't know which disk is which, kickstart becomes more cumbersome. Either I have to record the UUIDs and embed them in the kickstart file or open the box and disconnect any non-system drive.
Re: sata0 is not sda
On 02/18/2013 11:06 PM, Nico Kadel-Garcia wrote: IDE drives used to be listed as "/dev/ide0, /dev/ide1, etc." in deterministic fashion, but that got tossed out when they started labeling all drives as /dev/sda to gove access to special SCSI compatible commands. Aka 'the libata takeover'. It does make all drives pretty much consistent. There are still a few older controllers that behave better with the old IDE drivers than with libata; old Intel P4 chipsets in particular. The result is that it's guesswork. This is why our favorite upstream vendor tried for a while to use "LABEL=" settings to identify particular partitions, instead of trying to deduce what would be detected where. This is partially due in EL6 to the use of dracut and it's new initrd udev-ish system. I have one RHEL 6 box that is hooked to a pretty good-sized array on fibre-channel; it's fully HA, so there are four paths to any given LUN. My boot device, a 3Ware 9500-series SATA RAID card, ends up with a device name for it's first logical disk anywhere between /dev/sda and /dev/sdah; it's been /dev/sdu, /dev/sds, /dev/sdt, /dev/sdz, /dev/sdab, and pretty much everything in between, and it will vary from one boot to the next; it's at /dev/sdad right now. But I have the 3ware card, an on-motherboard U320 SCSI controller, a four-port Silicon Image SATA card, and a dual-port FC card hooked to the SAN.
Re: [SCIENTIFIC-LINUX-USERS] sata0 is not sda
On Thu, Feb 21, 2013 at 5:41 PM, jdow wrote: > On 2013/02/21 04:26, Tom H wrote: >> >> You can use "list-hardrives" in "%pre" and parse its output. >> >> If you want to see what its output looks like, you can install >> anaconda - although the actual anaconda executable, IIRC, is >> "list-hardrives-". > > # /usr/lib/anaconda/list-harddrives-stub > sda 476940.023438 > sr0 64.361328125 Yes; stub! Thanks.
Re: [SCIENTIFIC-LINUX-USERS] sata0 is not sda
I just do this
"
clearpart --all
part /boot --fstype ext3 --size=100
part pv.01 --size=10 --grow
volgroup SystemVG00 pv.01
logvol swap --fstype swap --name=SwapVol01 --vgname=SystemVG00 --size=12288
logvol / --fstype ext4 --name=RootVol --vgname=SystemVG00 --size=5120
logvol /usr --fstype ext4 --name=UsrVol --vgname=SystemVG00 --size=5120
logvol /home --fstype ext4 --name=HomeVol --vgname=SystemVG00 --size=5120
logvol /var --fstype ext4 --name=VarVol --vgname=SystemVG00 --size=10240
logvol /log --fstype ext4 --name=VarLogVol00 --vgname=SystemVG00 --size=20480
"
Then I deal with any additional physical disks using whatever the
automation dejour for the environment happens to be after the
kickstart.
I find it a lot less aggravating than any other solution mostly
because it reliable, simple and doesn't care what your RAID controller
calls the drives.
On Fri, Feb 22, 2013 at 1:06 PM, Graham Allan wrote:
> On Wed, Feb 20, 2013 at 07:57:22AM -0600, Pat Riehecky wrote:
>> On 02/19/2013 10:14 AM, Graham Allan wrote:
>> >On Mon, Feb 18, 2013 at 07:33:37PM -0700, Orion Poplawski wrote:
>> >>On 02/18/2013 02:01 PM, Ken Teh wrote:
>> >>>During a kickstart install, how are drives mapped? I notice that sata0
>> >>>is not always sda. This is especially true when there are very large
>> >>>drives in the mix.
>> >>The sd* letters are simply handed out in order of enumeration and,
>> >>as you noted, is not deterministic. If you need that, use the
>> >>/dev/disk/by-{id,label,path,uuid} labels.
>> >For this reason we use a script during the kickstart %pre section which
>> >attempts to examine the available drives and determine which is the
>> >appropriate one to install on (also waits for confirmation if an
>> >unexpected partition table is found).
>> >
>> >G.
>>
>> Any chance you can share that script? It sounds interesting!
>
> Well I hope I haven't oversold this - it's not a miracle cure but it
> works for our environment.
>
> Back in the SL3/4/5 days we made some basic assumptions in kickstart
> %pre that if there was an hda device, that would be the OS drive,
> otherwise use sda. If a workstation didn't match that model, we'd
> generally beat on it until it did :-) IIRC SL6 changed so that ATA drives,
> and any connected usb drives, appeared as sd* devices, and you couldn't be
> certain about the ordering.
>
> There will be lots of deeply unfashionable things in this script such as
> using regular drive partitions instead of LVM, using separate /var,
> etc... Also please remember it's been hacked together as edge cases were
> discovered so it's not pretty, or commented as well as it might be.
>
> It tries to examine all candidate drives (after eliminating USB devices)
> and will select a drive for installation if it either contains no
> partition table, or finds a /boot directory (actually that hardly seems
> foolproof, there might be better choices). Otherwise if it finds an
> unfamiliar partition table, it prints it and asks for confirmation.
>
> The rest of the script is concerned with stashing away ssh keys and
> suchlike, for restoration after a reinstall.
>
> Here goes, hope vim didn't mangle it overmuch during pasting, and don't
> judge it too harshly!
>
> %pre
>
> ##
> # Figure out where to install to
>
> #Make sure USB storage devices are GONE
> modprobe -r usb_storage
>
> mkdir /mnt/tmp
>
> for i in `ls /dev/sd?`; do
> CANDIDATE_DISK="$i"
>
> echo "UMPHYS: Checking $CANDIDATE_DISK for partition table" | tee -a
> /tmp/ks.log >> /dev/tty3
>
> if parted -s "$CANDIDATE_DISK" print >/dev/null; then
> echo "parted found a partition table" | tee -a /tmp/ks.log >>
> /dev/tty3
> if mount "${CANDIDATE_DISK}1" /mnt/tmp; then
> if [ -d /mnt/tmp/boot ]; then
> INSTALL_DISK=$CANDIDATE_DISK
> echo "Found /boot on ${CANDIDATE_DISK}1, using
> $CANDIDATE_DISK as system disk" | tee -a /tmp/ks.log >> /dev/tty3
> umount /mnt/tmp
> break
> else
> echo "Couldn't find /boot on ${CANDIDATE_DISK}1, moving on to
> next disk..." | tee -a /tmp/ks.log >> /dev/tty3
> umount /mnt/tmp
> fi
> umount /mnt/tmp
> fi
> else
> echo "Failed to mount ${CANDIDATE_DISK}1, moving on to next
> disk..." | tee -a /tmp/ks.log >> /dev/tty3
> fi
> else
> echo "parted found no partition table, using $CANDIDATE_DISK as
> system disk" | tee -a /tmp/ks.log >> /dev/tty3
> INSTALL_DISK="$CANDIDATE_DISK"
> break
> fi
> done
>
> if [ "${INSTALL_DISK}x" = "x" ]; then
> echo "" >> /dev/tty1
> echo "Initial check failed to find a suitable system disk!" >> /dev/tty1
> echo "" >> /dev/tty1
> for i in `ls /dev/sd?`; do
> CANDIDATE_DISK="$i"
> if mount "${CANDIDATE_DISK}
Re: [SCIENTIFIC-LINUX-USERS] sata0 is not sda
On Wed, Feb 20, 2013 at 07:57:22AM -0600, Pat Riehecky wrote:
> On 02/19/2013 10:14 AM, Graham Allan wrote:
> >On Mon, Feb 18, 2013 at 07:33:37PM -0700, Orion Poplawski wrote:
> >>On 02/18/2013 02:01 PM, Ken Teh wrote:
> >>>During a kickstart install, how are drives mapped? I notice that sata0
> >>>is not always sda. This is especially true when there are very large
> >>>drives in the mix.
> >>The sd* letters are simply handed out in order of enumeration and,
> >>as you noted, is not deterministic. If you need that, use the
> >>/dev/disk/by-{id,label,path,uuid} labels.
> >For this reason we use a script during the kickstart %pre section which
> >attempts to examine the available drives and determine which is the
> >appropriate one to install on (also waits for confirmation if an
> >unexpected partition table is found).
> >
> >G.
>
> Any chance you can share that script? It sounds interesting!
Well I hope I haven't oversold this - it's not a miracle cure but it
works for our environment.
Back in the SL3/4/5 days we made some basic assumptions in kickstart
%pre that if there was an hda device, that would be the OS drive,
otherwise use sda. If a workstation didn't match that model, we'd
generally beat on it until it did :-) IIRC SL6 changed so that ATA drives,
and any connected usb drives, appeared as sd* devices, and you couldn't be
certain about the ordering.
There will be lots of deeply unfashionable things in this script such as
using regular drive partitions instead of LVM, using separate /var,
etc... Also please remember it's been hacked together as edge cases were
discovered so it's not pretty, or commented as well as it might be.
It tries to examine all candidate drives (after eliminating USB devices)
and will select a drive for installation if it either contains no
partition table, or finds a /boot directory (actually that hardly seems
foolproof, there might be better choices). Otherwise if it finds an
unfamiliar partition table, it prints it and asks for confirmation.
The rest of the script is concerned with stashing away ssh keys and
suchlike, for restoration after a reinstall.
Here goes, hope vim didn't mangle it overmuch during pasting, and don't
judge it too harshly!
%pre
##
# Figure out where to install to
#Make sure USB storage devices are GONE
modprobe -r usb_storage
mkdir /mnt/tmp
for i in `ls /dev/sd?`; do
CANDIDATE_DISK="$i"
echo "UMPHYS: Checking $CANDIDATE_DISK for partition table" | tee -a
/tmp/ks.log >> /dev/tty3
if parted -s "$CANDIDATE_DISK" print >/dev/null; then
echo "parted found a partition table" | tee -a /tmp/ks.log >> /dev/tty3
if mount "${CANDIDATE_DISK}1" /mnt/tmp; then
if [ -d /mnt/tmp/boot ]; then
INSTALL_DISK=$CANDIDATE_DISK
echo "Found /boot on ${CANDIDATE_DISK}1, using $CANDIDATE_DISK
as system disk" | tee -a /tmp/ks.log >> /dev/tty3
umount /mnt/tmp
break
else
echo "Couldn't find /boot on ${CANDIDATE_DISK}1, moving on to
next disk..." | tee -a /tmp/ks.log >> /dev/tty3
umount /mnt/tmp
fi
umount /mnt/tmp
fi
else
echo "Failed to mount ${CANDIDATE_DISK}1, moving on to next
disk..." | tee -a /tmp/ks.log >> /dev/tty3
fi
else
echo "parted found no partition table, using $CANDIDATE_DISK as system
disk" | tee -a /tmp/ks.log >> /dev/tty3
INSTALL_DISK="$CANDIDATE_DISK"
break
fi
done
if [ "${INSTALL_DISK}x" = "x" ]; then
echo "" >> /dev/tty1
echo "Initial check failed to find a suitable system disk!" >> /dev/tty1
echo "" >> /dev/tty1
for i in `ls /dev/sd?`; do
CANDIDATE_DISK="$i"
if mount "${CANDIDATE_DISK}1" /mnt/tmp; then
if ! [ -d /mnt/tmp/boot ]; then
echo -e "\n\nCouldn't find /boot on ${CANDIDATE_DISK}1" >>
/dev/tty1
echo -n "Partition table for ${CANDIDATE_DISK}:" >> /dev/tty1
fdisk -l ${CANDIDATE_DISK} >> /dev/tty1
doit="default"
while ! echo "$doit" | grep -P "([Y|y]es|[N|n]o)" > /dev/null
2>&1; do
echo -n "Install linux on ${CANDIDATE_DISK}? [Yes/No] " >>
/dev/tty1
read doit
done
if echo "$doit" | grep -P "[Y|y]es" > /dev/null 2>&1; then
INSTALL_DISK="$CANDIDATE_DISK"
umount /mnt/tmp
break
else
echo "moving on to next disk..." >> /dev/tty1
fi
umount /mnt/tmp
fi
else
echo -ne "\n\nPartition table for ${CANDIDATE_DISK}:" >> /dev/tty1
fdisk -l ${CANDIDATE_DISK} >> /dev/tty1
doit="default"
while ! echo "
Re: [SCIENTIFIC-LINUX-USERS] sata0 is not sda
On 2013/02/21 04:26, Tom H wrote:
On Wed, Feb 20, 2013 at 8:57 AM, Pat Riehecky wrote:
On 02/19/2013 10:14 AM, Graham Allan wrote:
On Mon, Feb 18, 2013 at 07:33:37PM -0700, Orion Poplawski wrote:
On 02/18/2013 02:01 PM, Ken Teh wrote:
During a kickstart install, how are drives mapped? I notice that sata0
is not always sda. This is especially true when there are very large
drives in the mix.
The sd* letters are simply handed out in order of enumeration and,
as you noted, is not deterministic. If you need that, use the
/dev/disk/by-{id,label,path,uuid} labels.
For this reason we use a script during the kickstart %pre section which
attempts to examine the available drives and determine which is the
appropriate one to install on (also waits for confirmation if an
unexpected partition table is found).
Any chance you can share that script? It sounds interesting!
You can use "list-hardrives" in "%pre" and parse its output.
If you want to see what its output looks like, you can install
anaconda - although the actual anaconda executable, IIRC, is
"list-hardrives-".
# /usr/lib/anaconda/list-harddrives-stub
sda 476940.023438
sr0 64.361328125
{^_^}
Re: [SCIENTIFIC-LINUX-USERS] sata0 is not sda
On Wed, Feb 20, 2013 at 8:57 AM, Pat Riehecky wrote:
> On 02/19/2013 10:14 AM, Graham Allan wrote:
>> On Mon, Feb 18, 2013 at 07:33:37PM -0700, Orion Poplawski wrote:
>>> On 02/18/2013 02:01 PM, Ken Teh wrote:
During a kickstart install, how are drives mapped? I notice that sata0
is not always sda. This is especially true when there are very large
drives in the mix.
>>>
>>> The sd* letters are simply handed out in order of enumeration and,
>>> as you noted, is not deterministic. If you need that, use the
>>> /dev/disk/by-{id,label,path,uuid} labels.
>>
>> For this reason we use a script during the kickstart %pre section which
>> attempts to examine the available drives and determine which is the
>> appropriate one to install on (also waits for confirmation if an
>> unexpected partition table is found).
>
> Any chance you can share that script? It sounds interesting!
You can use "list-hardrives" in "%pre" and parse its output.
If you want to see what its output looks like, you can install
anaconda - although the actual anaconda executable, IIRC, is
"list-hardrives-".
Re: sata0 is not sda
On 02/19/2013 05:38 AM, Ken Teh wrote: If the disks cannot be identified deterministically, then I cannot avoid making my kickstart installs 2-stepped. Whether I pre-label the disks or install the system with a single disk and add the second disk after the install. I appreciate the situation from the kernel's perspective. Driver loads, disk detection, etc. But it sure puts a crinkle in the beauty of a kickstart install. This needs to be tweaked for different systems, but: clearpart --linux --drives=/dev/disk/by-path/pci-:00:1f.1-scsi-0:0:0:0,/dev/disk/by-path/pci-:00:1f.1-scsi-1:0:0:0 part raid.1 --size=200 --ondisk=/dev/disk/by-path/pci-:00:1f.1-scsi-0:0:0:0 part raid.2 --size=200 --ondisk=/dev/disk/by-path/pci-:00:1f.1-scsi-1:0:0:0 part raid.3 --size=4 --grow --ondisk=/dev/disk/by-path/pci-:00:1f.1-scsi-0:0:0:0 part raid.4 --size=4 --grow --ondisk=/dev/disk/by-path/pci-:00:1f.1-scsi-1:0:0:0 If you have very different systems, that doesn't help much I'm afraid. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com
Re: [SCIENTIFIC-LINUX-USERS] sata0 is not sda
On 02/19/2013 10:14 AM, Graham Allan wrote:
On Mon, Feb 18, 2013 at 07:33:37PM -0700, Orion Poplawski wrote:
On 02/18/2013 02:01 PM, Ken Teh wrote:
During a kickstart install, how are drives mapped? I notice that sata0
is not always sda. This is especially true when there are very large
drives in the mix.
The sd* letters are simply handed out in order of enumeration and,
as you noted, is not deterministic. If you need that, use the
/dev/disk/by-{id,label,path,uuid} labels.
For this reason we use a script during the kickstart %pre section which
attempts to examine the available drives and determine which is the
appropriate one to install on (also waits for confirmation if an
unexpected partition table is found).
G.
Any chance you can share that script? It sounds interesting!
Pat
--
Pat Riehecky
Scientific Linux Developer
Re: sata0 is not sda
On Mon, Feb 18, 2013 at 07:33:37PM -0700, Orion Poplawski wrote:
> On 02/18/2013 02:01 PM, Ken Teh wrote:
> >During a kickstart install, how are drives mapped? I notice that sata0
> >is not always sda. This is especially true when there are very large
> >drives in the mix.
>
> The sd* letters are simply handed out in order of enumeration and,
> as you noted, is not deterministic. If you need that, use the
> /dev/disk/by-{id,label,path,uuid} labels.
For this reason we use a script during the kickstart %pre section which
attempts to examine the available drives and determine which is the
appropriate one to install on (also waits for confirmation if an
unexpected partition table is found).
G.
--
-
Graham Allan - I.T. Manager
School of Physics and Astronomy - University of Minnesota
-
Re: sata0 is not sda
On Feb 19, 2013, at 13:38 , Ken Teh wrote: > If the disks cannot be identified deterministically, then I cannot avoid > making my kickstart installs 2-stepped. Whether I pre-label the disks or > install the system with a single disk and add the second disk after the > install. You could detect the disk you want to install on in %pre, write the partitioning info into a file int /tmp, and %include that from your main ks config. > I appreciate the situation from the kernel's perspective. Driver loads, disk > detection, etc. But it sure puts a crinkle in the beauty of a kickstart > install. > > Thanks everyone for your replies. > > > On 02/18/2013 10:06 PM, Nico Kadel-Garcia wrote: >> On Mon, Feb 18, 2013 at 4:01 PM, Ken Teh wrote: >>> During a kickstart install, how are drives mapped? I notice that sata0 is >>> not always sda. This is especially true when there are very large drives in >>> the mix. >> >> It Depends(tm). There are confusing difficulties because the drive >> controllers may be pre-loaded modules, which will be loaded first, and >> because the later updates or manual drivers compiled for custom >> kernels may be loaded in different order or pre-loaded with mkinitrd. >> Then as drives or RAID arrays which look like drives are detected by >> the bios starting and loading the drivers from the *boot* partition >> for adiditional controllers, they're loaded in by the order detected, >> first drive /dev/sda, second drive /dev/sdb, etc., etc. This is why >> the boot loader is usually on "/dev/sda" >> >> IDE drives used to be listed as "/dev/ide0, /dev/ide1, etc." in >> deterministic fashion, but that got tossed out when they started >> labeling all drives as /dev/sda to gove access to special SCSI >> compatible commands. >> >> The result is that it's guesswork. This is why our favorite upstream >> vendor tried for a while to use "LABEL=" settings to identify >> particular partitions, instead of trying to deduce what would be >> detected where. -- Stephan Wiesand DESY - DV - Platanenallee 6 15732 Zeuthen, Germany
Re: sata0 is not sda
If the disks cannot be identified deterministically, then I cannot avoid making my kickstart installs 2-stepped. Whether I pre-label the disks or install the system with a single disk and add the second disk after the install. I appreciate the situation from the kernel's perspective. Driver loads, disk detection, etc. But it sure puts a crinkle in the beauty of a kickstart install. Thanks everyone for your replies. On 02/18/2013 10:06 PM, Nico Kadel-Garcia wrote: On Mon, Feb 18, 2013 at 4:01 PM, Ken Teh wrote: During a kickstart install, how are drives mapped? I notice that sata0 is not always sda. This is especially true when there are very large drives in the mix. It Depends(tm). There are confusing difficulties because the drive controllers may be pre-loaded modules, which will be loaded first, and because the later updates or manual drivers compiled for custom kernels may be loaded in different order or pre-loaded with mkinitrd. Then as drives or RAID arrays which look like drives are detected by the bios starting and loading the drivers from the *boot* partition for adiditional controllers, they're loaded in by the order detected, first drive /dev/sda, second drive /dev/sdb, etc., etc. This is why the boot loader is usually on "/dev/sda" IDE drives used to be listed as "/dev/ide0, /dev/ide1, etc." in deterministic fashion, but that got tossed out when they started labeling all drives as /dev/sda to gove access to special SCSI compatible commands. The result is that it's guesswork. This is why our favorite upstream vendor tried for a while to use "LABEL=" settings to identify particular partitions, instead of trying to deduce what would be detected where.
Re: sata0 is not sda
On Mon, Feb 18, 2013 at 4:01 PM, Ken Teh wrote: > During a kickstart install, how are drives mapped? I notice that sata0 is > not always sda. This is especially true when there are very large drives in > the mix. It Depends(tm). There are confusing difficulties because the drive controllers may be pre-loaded modules, which will be loaded first, and because the later updates or manual drivers compiled for custom kernels may be loaded in different order or pre-loaded with mkinitrd. Then as drives or RAID arrays which look like drives are detected by the bios starting and loading the drivers from the *boot* partition for adiditional controllers, they're loaded in by the order detected, first drive /dev/sda, second drive /dev/sdb, etc., etc. This is why the boot loader is usually on "/dev/sda" IDE drives used to be listed as "/dev/ide0, /dev/ide1, etc." in deterministic fashion, but that got tossed out when they started labeling all drives as /dev/sda to gove access to special SCSI compatible commands. The result is that it's guesswork. This is why our favorite upstream vendor tried for a while to use "LABEL=" settings to identify particular partitions, instead of trying to deduce what would be detected where.
Re: sata0 is not sda
On 02/18/2013 02:01 PM, Ken Teh wrote:
During a kickstart install, how are drives mapped? I notice that sata0
is not always sda. This is especially true when there are very large
drives in the mix.
The sd* letters are simply handed out in order of enumeration and, as
you noted, is not deterministic. If you need that, use the
/dev/disk/by-{id,label,path,uuid} labels.
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA DivisionFAX: 303-415-9702
3380 Mitchell Lane or...@cora.nwra.com
Boulder, CO 80301 http://www.cora.nwra.com
sata0 is not sda
During a kickstart install, how are drives mapped? I notice that sata0 is not always sda. This is especially true when there are very large drives in the mix.
