Date: Sat, 20 May 2017 03:55:11 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-bugs@FreeBSD.org Subject: [Bug 219411] [zfs] Stale zpool.cache corrupts renamed (but not exported) root zpool on boot Message-ID: <bug-219411-8@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D219411 Bug ID: 219411 Summary: [zfs] Stale zpool.cache corrupts renamed (but not exported) root zpool on boot Product: Base System Version: 11.0-STABLE Hardware: Any OS: Any Status: New Severity: Affects Some People Priority: --- Component: kern Assignee: freebsd-bugs@FreeBSD.org Reporter: eborisch+FreeBSD@gmail.com If the root zpool is -- via LiveCD -- renamed, but not exported, and the zpool.cache file is not removed, two versions of the pool (old and new name) are imported, and corruption soon follows. Discussed on mailing list: https://lists.freebsd.org/pipermail/freebsd-fs/2017-May/024717.html Steps to reproduce (don't do it to your live system!): Install FreeBSD root-on-zfs Reboot into LiveCD=20 Rename the installed root pool [1] [2] [3] Reboot into installed OS. Two pools will show under zpool list/status: the original name and the new name. Errors are quickly reported, and the pool is corrupted (will no longer import) very quickly. Kick off a scrub on either pool to force the issue for testing. Notes: [1] To do this, a 'zfs import -f ...' is required, as you can't export your root pool while it is, well, your root pool. There was some discussion on t= he mailing list if this is sufficient to just say "well, you've shot yourself = in the foot, congrats, not a bug." I contend it is not, as it is the existence= of the stale cache file that seems to cause the problem; the zpool itself is perfectly happy after being imported in this way. A bad config (cache) file shouldn't corrupt a zpool on boot. Halt the boot, by all means, if necessar= y, but don't trash the pool. [2] If you mount the pool at this point and remove the old zpool.cache file, the problem does not appear on reboot and everything appears to be OK. [3] If you export the pool before rebooting at this point, with our without removing the old zpool.cache file, the problem also doesn't occur. It seems that some combination of the bootloader's initial opening of a "currently imported" pool and the handoff to the kernel (and later parsing = of the zpool.cache file) mishandles the case where a pool described in the cac= he file with a different name but the same GUID is improperly imported again. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-219411-8>