From nobody Wed Apr 27 12:45:02 2022 X-Original-To: freebsd-stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id C60901AA8EDA for ; Wed, 27 Apr 2022 12:45:13 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4KpJPN4RlXz4c8c for ; Wed, 27 Apr 2022 12:45:11 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from kalamity.joker.local (123-1-111-80.area1b.commufa.jp [123.1.111.80]) (authenticated bits=0) by www121.sakura.ne.jp (8.16.1/8.16.1/[SAKURA-WEB]/20201212) with ESMTPA id 23RCj2at031964; Wed, 27 Apr 2022 21:45:03 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Wed, 27 Apr 2022 21:45:02 +0900 From: Tomoaki AOKI To: "Eugene M. Zheganin" Cc: freebsd-stable@freebsd.org Subject: Re: FreeBSD boot from root pool larger than 1Tb/cannot read MOS/all block copies unavailable Message-Id: <20220427214502.f9ef1317f2911fb5247d1757@dec.sakura.ne.jp> In-Reply-To: <2c2d774c-3677-c3b7-d099-71318743a434@zhegan.in> References: <2c2d774c-3677-c3b7-d099-71318743a434@zhegan.in> Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd13.0) List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4KpJPN4RlXz4c8c X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of junchoon@dec.sakura.ne.jp has no SPF policy when checking 153.125.133.21) smtp.mailfrom=junchoon@dec.sakura.ne.jp X-Spamd-Result: default: False [-1.30 / 15.00]; RCVD_TLS_LAST(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; NEURAL_HAM_LONG(-0.99)[-0.995]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[sakura.ne.jp]; AUTH_NA(1.00)[]; HAS_ORG_HEADER(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.76)[-0.764]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_MEDIUM(-0.95)[-0.945]; MLMMJ_DEST(0.00)[freebsd-stable]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7684, ipnet:153.125.128.0/18, country:JP]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[123.1.111.80:received] X-ThisMailContainsUnwantedMimeParts: N On Tue, 26 Apr 2022 19:10:51 +0500 "Eugene M. Zheganin" wrote: > Hello, > > recently I found another server that was running 12.x and became > unbootable because of the famous "cannot read MOS/all block copies > unavailable/etc" gptzfsboot message which can be randomly displayed when > boot blocks migrate beyond 1st Tb on a large root pool. I managed to > boot the server from CD (pointing out the root pool with > vfs.root.mountfrom) and then upgraded it to the recent 13.0, where is > showed no signs of being able to boot from disks again (so I'm treating > this as still not fixed, and probably as won't be fixed issue). > > Since this issue is like 10 years old and I see no light at the end of > the tunnel, could the bsdinstall at least be made aware about this so it > won't permit the large root pool creation by default ? Because as far as > I remember there's still no option in it to create a pool smaller than > the disk, and I have to use the custom installation script in order to > do this. > > I'm asking because unfortunately recently I've found two more of these > time bombs among my servers. > > > Thanks. > > > Eugene. > > > P.S. There have been speculations that switching to the UEFI loader may > help, because it's more functional and probably can see the migrated > over 1Tb boot blocks, can anyone confirm this ? > > Maybe. I've booting with around 1.5T or above (but under 2T) Root-on-ZFS installation via UEFI for years. Basically, UEFI requires GPT partitioning. So many of those would boot from larger than 1TB boot pool. As, IIRC, it is optional, some UEFI firmware would be able to boot from MBR-patritioned disk but there would be some risk that they have the same limitations as legacy BIOS in such situations. Note that possibly I'm just lucky enough not to be bitten. -- Tomoaki AOKI