Are you sure that the system with failed mounts came up NOT in a
read-only root moment, and that your removal of /etc/zfs/zpool.cache
did in fact happen (and that you did not then boot into an earlier
BE with the file still in it)?
On a side note, repairs of ZFS mount order are best done with a
single-user mode boot (-s as a kernel parameter in GRUB), which
among other things spawns very few programs and keeps your FSes
not busy. Also you (should) get to log in as root directly even
if it normally a "role" account and not a "user" on your box.
2012-10-22 15:06, Edward Ned Harvey
(opensolarisisdeadlongliveopensolaris) пишет:
From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
boun...@opensolaris.org] On Behalf Of Edward Ned Harvey
If you rm /etc/zfs/zpool.cache and reboot... The system is smart enough (at
least in my case) to re-import rpool, and another pool, but it didn't figure out
to re-import some other pool.
How does the system decide, in the absence of rpool.cache, which pools it's
going to import at boot?
So, in this thread, I haven't yet got the answer that I expect or believe.
Because, the behavior I observed was:
I did a "zfs send" from one system to another, received onto
/localpool/backups. Side note, the receiving system has three pools: rpool, localpool,
and iscsipool. Unfortunately, I sent the zfs properties with it, including the
mountpoint. Naturally, there was already something mounted on / and /exports and
/exports/home, so the zfs receive failed to mount on the receiving system, but I didn't
notice that. Later, I rebooted.
During reboot, of course, rpool mounted correctly on /, but then the system
found the localpool/backups filesystems, and mounted /exports, /exports/home
and so forth. So when it tried to mount rpool/exports, it failed. Then,
iscsipool was unavailable, so the system failed to bootup completely. I was
able to login to console as myself, but I had no home directory, so I su'd to
root.
I tried to change the mountpoints of localpool/backups/exports and so forth -
but it failed. Filesystem is in use, or filesystem busy or something like
that. (Because I logged in, obviously.) I tried to export localpool, and
again failed. So I wanted some way to prevent localpool from importing or
mounting next time, although I can't make it unmount or change mountpoints this
time.
rm /etc/zfs/zpool.cache ; init 6
This time, the system came up, and iscsipool was not imported (as expected.)
But I was surprised - localpool was imported.
Fortunately, this time the system mounted filesystems in the right order -
rpool/exports was mounted under /exports, and I was able to login as myself,
and export/import / change mountpoints of the localpool filesystems. One more
reboot just to be sure, and voila, no problem.
Point in question is - After I removed the zpool.cache file, I expected rpool
to be the only pool imported upon reboot. That's not what I observed, and I
was wondering how the system knew to import localpool?
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
