2012-10-05 4:57, Jerry Kemp wrote:
Its been awhile, but it seems like in the past, you would power the
system down, boot from removable media, import your pool then destroy or
archive the /etc/zfs/zpool.cache, and possibly your /etc/path_to_inst
file, power down again and re-arrange your hardware, then come up one
final time with a reconfigure boot. Or something like that.
Well, as I wrote in the OP, now the procedure is simpler; in your words:
* power the system down and re-arrange your hardware
(BIOS settings in case of SATA/Legacy=IDE switch)
* boot from removable media,
* import your rpool
* export rpool
* reboot from rpool
Your procedure CAN be useful i.e. if a secondary userdata pool fails
to import and causes kernel panics and such, or relies on external
hardware (NAS/SAN) which is no longer available; then by deleting
the rpool.cache you can avoid its automatic import upon OS boot.
This does not seem to be employed by rpool import routine.
This has a few "bad" steps I want to avoid:
1) Use of extra media. I'd go for at most a self-sufficient failsafe
boot image like that we had in SXCE/Sol10 (basically, it's just a
bigger boot_archive that you can log into); preferably the OS should
not need even that and switch to new rpool connection technology on
the fly during boot.
2) Reliance on some remapped PCI path numbers (i.e. it is often not
vendorid:devid, but a pci@number kind of address), which might be
changeable between boots if your enumeration is not cut in stone
for some reason. For example, I do worry whether the LiveUSB boots
can make the HDD seem to be at a different path than the plain HDD
boots - due to insertion/removal of a whole storage device tree
and change of BIOS boot order. (This laptop has no CD/DVD, and
I don't think buying and adding/removing a USB CD/DVD would be
a substantial change to adding/removing a USB HDD as I do now.)
Whatever device paths the live-media bootup sees, it writes into
the rpool headers upon successful import/export, and those strings
(only?) are probed by boot from rpool. That is, the newly booted
kernel does see enough of the pool to find these headers, then
follows them and perhaps finds no storage hardware at that address.
Well then, search/import the pool from the device WHERE you found
those headers? Duh?
zfs-discuss mailing list