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? ///Jim _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
