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

Reply via email to