Solved How to prevent mounting the original ZFS file system from a cloned system?

skunk

skunk

When I clone a system to another disk, and then boot from that clone disk, it mounts not only the cloned ZFS pool, but also the source ZFS pool.
So I need some way to instruct the cloned system to not do this.

The cloning process is shown here.
Do you know what I need to edit/add/remove in the cloned pool so it boots without mounting both source and clone pools?
 
Exactly!
When booting from the disk with <clonepool> (different name), ZFS mounts both <clonepool> and <sourcepool> to the same mount points. This cannot be a good thing.
When booting from another computer without the disks containing <sourcepool>, I see a message from zfs while booting, something like "cannot mount <sourcepool>". But the system on <clonepool> appears to work fine.

So I need a way to make ZFS not to do the unwanted import/mount of <sourcepool>.

Edit:
The problem must be somewhere on the cloned pool.
Because, it does not mount the other bootable pool on other disks (that is named differently than <sourcepool>) on the other system.
So it seems that something on the system on the cloned pool <clonepool> instructs ZFS to mount a pool named "<sourcepool>" in addition to <clonepool>, on which zpool set bootfs=<clonepool>/ROOT/default <clonepool> has been set.
 
not really a "distro", strictly just making a set of tools to make FreeBSD easy to use and deploy in SOHO environments like mine.

You know the problem:
Imagine you have a desktop computer set up fine, with all stuff installed and configured.
And you want to clone it, for example onto your laptop, for your wife, or for your colleagues.
This is what the Skunk Cloner is intended for.

And now this problem: when attempting to test the cloned disk by booting from it, it imports the source ZFS pool also, so that all filesystems are mounted twice, on the source pool and on the target pool as well! This can be very destructive, and so I need to find out how to fix this...
 
This might be a good idea.
But first that issue with the unwanted import and mount of the source zpool must be solved somehow...
 
I also thought about canmount before, but I am not sure whether this is related to this problem.
The cloning is done via zfs send/receive, so afaiu the properties should be identical.

If it were a canmount issue, the behaviour would be the same with other systems as well.
But this problem only appears when booting the clone disk on the system it was cloned from.
In addition, the message something like "can´t import <sourcepool>" that appears when booting on another computer without a zpool named like <sourcepool> indicates that something on the cloned system actively looks for a pool <sourcepool> to import/mount. Other pools not named <sourcepool> are not being imported (except, of course, its clone <clonepool>). In this case, the system just works fine, only booting and mounting the new root pool <clonepool>.

And the question is now, how to deactivate/turn off this behavior of looking for pool <sourcepool> to import/mount...
 
What does make this thing even stranger is the fact that this message I mentioned, which said something like "Could not find <sourcepool>, when I booted the *first* time from another computer (which has no disk with <sourcepool>) is not in /var/log/messages.
On later attempts this message did *not* appear again.

However, after some grepping I found that the name of <sourcepool> was in /boot/zfs/zpool.cache and /etc/zfs/zpool.cache.
Deleting both files seems to fix the issue.

Is just deleting these files the correct way to do things?
Or is it necessary to re-create these files by some means?
 
Thank you! That hint was what I needed!
So it is best to just get rid of the cachefile to avoid this problem.

Problem solved ?
 
You must log in or register to reply here.
Back
Top