Date: Sat, 06 Apr 2024 01:45:24 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 277886] ZFS boot loader gives up too easily on unsupported zpool flags Message-ID: <bug-277886-227-uUQFhaxwGK@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-277886-227@https.bugs.freebsd.org/bugzilla/> References: <bug-277886-227@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D277886 Tomoaki AOKI <junchoon@dec.sakura.ne.jp> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |junchoon@dec.sakura.ne.jp --- Comment #1 from Tomoaki AOKI <junchoon@dec.sakura.ne.jp> --- You are stating about loader, so I'll intentionally ignore here about featu= res not supported by features unsupported after boot (not implemented in zfs.ko, used AFTER kernel starts). For features supported by zfs.ko but not by loader (zfsloader, loader.efi), unsupported featres are categorized into 2. 1. Read-only compatible feature 2. Features not in 1. For case 1, loader can (theoretically) sanely read the pool. So should run sanely even if they are enabled and active. For case 2, if the features are enabled but not yet set to active and actua= lly used, theoretically loader can still read and boot the pool. But once any of the features are actually used, loader no longer can read i= t. For example, if new hash function which loader doesn't support is activated= and used, loader cannot calculate the hash to check whether the file (/boot/loader.conl, kernel itself, ...) is broken or not. As broken files S= HALL not be used to boot. The only solution for case 2 is to implement the unspported feature into loader. But if your complaints are about case 1, loader.should be fixed. --=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-277886-227-uUQFhaxwGK>