Date: Sun, 02 Feb 2025 17:55:34 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 284525] bsdinstall can make running system unbootable Message-ID: <bug-284525-227@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D284525 Bug ID: 284525 Summary: bsdinstall can make running system unbootable Product: Base System Version: 14.2-RELEASE Hardware: Any OS: Any Status: New Severity: Affects Some People Priority: --- Component: misc Assignee: bugs@FreeBSD.org Reporter: barneywolff@gmail.com Running bsdinstall on an existing system can make the system fail and be unbootable without manual console intervention. Script /usr/src/usr.sbin/bsdinstall/scripts/zfsboot line 804 forces export = of all existing zpools. There is NO warning of this, only that the disk/partit= ion being set up will be destroyed. The ASSumption seems to be that bsdinstall = is running on new hardware with the install medium as the only existing filesystem. Running bsdinstall on a working system to create a new system d= isk risks disaster. If the existing system has only a root zpool with all fbsd components, disaster is averted because the export fails. But if it has a r= oot zpool and a separate zpool for /usr, /var and so on, the system immediately fails, the session drops, and no new login is possible. What's worse, power cycling will not let the system come up, because the non-root zpool has been exported. If console access is available the operator can boot to single us= er and re-import the needed zpool. Otherwise, the system is out of service indefinitely. The basic issue here is that it's all but impossible to tell if there is a zpool on the install target, because the target may be described in a zpool status as either a device like da3p2 or diskid/..... or gpt/..... or ... . I certainly cannot predict how fbsd will choose to describe a given disk/partition. And once the system chooses a diskid/... the da3p2 descript= ion disappears. I have another system with a mirrored zpool where one of two identical disks is listed in the diskid form and the other in the da3p2 for= m. At the very minimum bsdinstall should not do zpool export -F, but just plain export if it's done at all. Or just display the zpool list to the user and = let the user decide whether there's a pool on the disk about to be destroyed. --=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-284525-227>