It was often asked and discussed on the list about "how to
change rpool HDDs from AHCI to IDE mode" and back, with the
modern routine involving reconfiguration of the BIOS, bootup
from separate live media, simple import and export of the
rpool, and bootup from the rpool. The documented way is to
reinstall the OS upon HW changes. Both are inconvenient to
say the least.
Linux and recent Windows are much more careless about
total changes of hardware underneath the OS image between
boots, they just boot up and work. Why do we shoot ourselves
in the foot with this boot-up problem?
Now that I'm trying to dual-boot my OI-based system, I hit
the problem hard: I have either a HW SATA (AMD Hudson, often
not recognized upon bootup, but that's another story) and a
VirtualBox SATA on different pci dev/vendor IDs, or Physical
and Virtual IDE which result in the same device path to cmdk
and pci-ide - so I'm stuck with IDE mode at least for these
So the basic question is: WHY does the OS want to use the
device path (/pci... string) coded into the rpool's vdevs
mid-way in the bootup during vfs root-import routine, and
fail with a panic if the device naming changed, when the
loader (GRUB) for example already had no problem reading
the same rpool? Is there any rationale or historic baggage
to this situation? Is it a design error or shortsight?
Isn't it possible to use the same routine as for other
pool imports, including import of this same rpool from a
live-media boot - just find the component devices (starting
with the one passed by the loader and/or matching by pool
name and/or GUID) and import the resulting pool? Perhaps,
this could be attempted if the current method fails, before
reverting to a kernel panic - try another method first.
Would this be a sane thing to change, or are there known
beasts lurking in the dark?
zfs-discuss mailing list