-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
cannot import pool in initramfs after reboot if zpool.cache is absent #1213
Comments
Note that cleanly exporting the pool while in initramfs, and rebooting, does help boot, but at next reboot, the same problem happens again. |
This won't help you in the short term, but we are moving on implementing multiple modified protection (MMP) as a new feature flag (#745). That should allow us to retire this hostid nonsense while proving stronger guarantees that the pool isn't in use elsewhere. |
What's the story? I still can't get the pool to import properly. Without the zpool.cache, no matter what hostid of the system, it just won't import on boot. With the zpool.cache, pool imports fail when the pool is reconfigured, because the zpool.cache file is out of date. :-( |
The plan remains the same, the zpool.cache file is going away (at least as the default, it will probably be preserved for legacy systems). The hold up is available man power to work on this. |
@Rudd-O @behlendorf Is this closed by #2353? |
@FransUrbo The #2353 changes are unrelated. However, the systemd patches may have improved the situation at least for non-root pools, 881f45c. |
So what's left to do? |
Actually, I suppose openzfs/spl@acf0ade should address the original issue here regarding the hostid. I'm OK with closing this. I'd say the full solution is along the lines of #1587. |
I think this may solve my problem that required me to force pool import. We'll see. I need to rig my build server such that it builds a new bootable Fedora image, and test that way. |
For those on the older version, here is a hook for initramfs-tools to remove the zpool.cache file during initramfs creation. Place this in /etc/initramfs-tools/hooks and make sure it is executable (chmod +x) #!/bin/sh
PREREQ="zfs"
prereqs() {
echo "$PREREQ"
}
case $1 in
prereqs)
prereqs
exit 0
;;
esac
. /usr/share/initramfs-tools/hook-functions
if [ -f "${DESTDIR}/etc/zfs/zpool.cache" ]; then
rm "${DESTDIR}/etc/zfs/zpool.cache";
fi |
…_agent (openzfs#1213) build(deps): bump aho-corasick in /cmd/zfs_object_agent Bumps [aho-corasick](https://github.com/BurntSushi/aho-corasick) from 1.0.5 to 1.1.0. - [Commits](BurntSushi/aho-corasick@1.0.5...1.1.0) --- updated-dependencies: - dependency-name: aho-corasick dependency-type: indirect update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <[email protected]> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
For some reason, if the pool is not exported at poweroff, and the zpool.cache is absent in the initramfs, the pool cannot be imported with 'pool may be in use from another system'.
I went into the source here:
https://github.com/Rudd-O/zfs/blob/master/cmd/zpool/zpool_main.c#L1699
the linked check above just fails. Checked with zdb and indeed the pool config does not have a hostid attribute. Which leads me to believe that the hostid attribute is, for some reason, never getting written in the pool, so next reboot it cannot be read, thus the check for "same hostid" (if ((unsigned long)hostid != system_hostid) {, two lines below the above code) never takes place.
This seems to be a bug -- if the pool is not exported, the hostid attribute should still be in the pool config, cache or not. Naturally, this breaks zfs-on-root.
Help?
The text was updated successfully, but these errors were encountered: