Root on ZFS, LiveCD and BE

[Victor Sudakov]

Brandon J. Wandersee wrote:

[dd]

> > Kevin, this is all good advice how not to screw up the second (fixit) system
> > into which the zroot of the first (original) one is being temporarily imported.
> > However, I am more concerned about not screwing up the first,
> > *original* system whose zroot is temporarily mounted to another fixit
> > system and then again used as a bootable root pool. 
> 
> I'll chime in here, as I think I understand Victor correctly: You have a
> production system that presently will not boot, and want to mount it in
> the LiveCD/Fixit environment for maintenance. However, you're concerned
> about (a) the mount points for the imported pool being stacked atop
> those of the running system, leaving it unresponsive; and (b) potential
> harm that the imported pool might suffer from the import process. If I'm
> mistaken about this, please let me know. ;)

Yes, my concern is (b).

[dd]
> 
> Regarding concern (b), importing a pool should never cause any damage to
> it, even if it is in a 'degraded' state. (If the pool is in a 'faulted'
> state, such that it cannot be used at all, `zpool import` will simply
> fail with an error message.) ZFS is designed so that everything that's
> already on the disk is all but guaranteed to remain intact and
> consistent in the event of an unclean dismount or shutdown, or failure
> to boot. Note that this includes the mistake that leads to the scenario
> in concern (a): you mount the ZFS pool over the LiveCD/Fixit
> environment, leaving both unresponsive. You could just cut the power to
> the machine, and the pool should be just fine (there is always the
> possiblity that it won't be, but it's quite unlikely).
> 
> Now, when you try to import a pool that was previously part of another
> running system, `zpool` will tell you that "forcing" the import is the
> only way to get the result you want. Doing so is safe; ZFS is just
> concerned because its record shows that the pool was last seen attached
> to a running system and it wasn't properly exported, and so wants to
> make certain you aren't trying to use a pool on two different systems
> simultaneously. So to sum up the past two paragraphs, importing the pool
> should never have any effect at all beyond mounting the datasets, and
> those datasets should always be in a clean state.

This sounds reassuring. To make it more clear, do I need to export the
production pool after the maintenance is finished?

> 
> As for your question regarding boot environments, I'll limit myself to
> the suggestion that if your pool isn't booting, I would guess the most
> likely cause (given the use of beadm) is that the 'bootfs=' property is
> not properly set. 

Well, it *is* booting, it only looks like /dev is not populated for
some obscure reason.

> I looked over the bug report you filed and noticed
> that you're using the development version beadm. I'd recommend using the
> stable release of beadm and seeing if that works. You could also
> `chroot` into the system while it's mounted in the LiveCD environment
> and use beadm to gather some information.

I'll check with the stable version of beadm  in bhyve tomorrow, but
please note that BE selection made by beadm-devel itself (from a
working system) works perfectly. It's only the loader BE selection
menu that has this problem.


-- 
Victor Sudakov,  VAS4-RIPE, VAS47-RIPN
sip:sudakov at sibptus.tomsk.ru