On Tue, Jan 14, 2014 at 08:54:33PM -0600, Les Mikesell wrote:
> On Tue, Jan 14, 2014 at 8:43 PM, Stephen Harris <lists@xxxxxxxxxx> wrote:
> > Ultimately what we have is a situation similar to hard disks. We've got
> > used to sd devices changing depending on the order disks are discovered
> > in, which is why we use LABEL or UUID.
>
> But those don't work until something has already identified the
> device. If you are old enough, you might remember unix versions that
At install time "we have a disk; we designate it 'datadisk' we give it
label DATA". That's what Anaconda does. The production kernel might
find it as another disk, but because it has the label then all works.
There's still a "boot" dependency, but there's not a lot we can do to
work around the BIOS.
> named disks by controller, bus, target numbers. Which worked, but
> wasn't very human-friendly either.
You mean the "modern" c0t0d0s0 type structures (eg Solaris SPARC) and similar
(truncated) SVR4 Intel paths? Heh, I'm much older than that.
That was actually not a bad scheme... but it required the bus to be
detected in a consistent format. The problem with the Intel architecture
is that this detection is _not_ consistent. It depends on module loading
order, hotplug device issues etc etc. "c0" isn't necessarily "c0" on an
Intel platform. That's where it all fell down.
Back in the day (if you can remember back that far), Dell servers were
a fun issue with RedHat; the install kernel would detect devices on the PCI
bus in one order but the production install kernel would detect them in
the _reverse_ order. So if you had two ethernet cards eth0 and eth1 would
be reversed between install and boot kernels. Some HP servers also did
this. Fun times!
--
rgds
Stephen
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
