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 at spuddy.org> 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