Skip to content
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

Closed
Rudd-O opened this issue Jan 16, 2013 · 10 comments
Closed

cannot import pool in initramfs after reboot if zpool.cache is absent #1213

Rudd-O opened this issue Jan 16, 2013 · 10 comments
Labels
Type: Feature Feature request or new feature
Milestone

Comments

@Rudd-O
Copy link
Contributor

Rudd-O commented Jan 16, 2013

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?

@Rudd-O
Copy link
Contributor Author

Rudd-O commented Jan 16, 2013

Note that cleanly exporting the pool while in initramfs, and rebooting, does help boot, but at next reboot, the same problem happens again.

@behlendorf
Copy link
Contributor

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.

@Rudd-O
Copy link
Contributor Author

Rudd-O commented May 19, 2013

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. :-(

@behlendorf
Copy link
Contributor

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.

@FransUrbo
Copy link
Contributor

@Rudd-O @behlendorf Is this closed by #2353?

@behlendorf
Copy link
Contributor

@FransUrbo The #2353 changes are unrelated. However, the systemd patches may have improved the situation at least for non-root pools, 881f45c.

@FransUrbo
Copy link
Contributor

So what's left to do?

@behlendorf
Copy link
Contributor

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.

@Rudd-O
Copy link
Contributor Author

Rudd-O commented Jun 7, 2014

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.

@gnif
Copy link

gnif commented Jan 7, 2015

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

pcd1193182 pushed a commit to pcd1193182/zfs that referenced this issue Sep 26, 2023
…_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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Type: Feature Feature request or new feature
Projects
None yet
Development

No branches or pull requests

4 participants