From nobody Sat Jan 29 18:06:18 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 618B51988F79 for ; Sat, 29 Jan 2022 18:06:25 +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 4JmMhc0Fr9z3q8T; Sat, 29 Jan 2022 18:06:23 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from kalamity.joker.local (123-48-130-181.area1b.commufa.jp [123.48.130.181]) (authenticated bits=0) by www121.sakura.ne.jp (8.16.1/8.16.1/[SAKURA-WEB]/20201212) with ESMTPA id 20TI6Inm078153; Sun, 30 Jan 2022 03:06:19 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Sun, 30 Jan 2022 03:06:18 +0900 From: Tomoaki AOKI To: Ulrich =?ISO-2022-JP?B?U3AbJEIiLhsoQnJsZWlu?= Cc: Eugene Grosbein , freebsd-stable@freebsd.org, Andriy Gapon Subject: Re: gptzfsboot can't boot from 4TB SSD Message-Id: <20220130030618.dd46cf514f98cdfa6caa1ad4@dec.sakura.ne.jp> In-Reply-To: References: <212cfd90-056f-d294-ae9c-fd2b632ae679@FreeBSD.org> 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=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4JmMhc0Fr9z3q8T 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 [0.95 / 15.00]; RCVD_TLS_LAST(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; FROM_HAS_DN(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[sakura.ne.jp]; AUTH_NA(1.00)[]; NEURAL_SPAM_SHORT(1.00)[0.998]; HAS_ORG_HEADER(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-0.45)[-0.445]; 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.48.130.181:received] X-ThisMailContainsUnwantedMimeParts: N On Sat, 29 Jan 2022 13:24:06 +0100 Ulrich Sp〓rlein wrote: > On Thu, Jan 27, 2022 at 5:18 PM Eugene Grosbein wrote: > > 27.01.2022 22:09, Ulrich Sp〓rlein wrote: > > > Or should I bring back a / UFS partition in the front instead, with > > > /usr and /var on ZFS? > > > > I would recommend to create 10GB partition at the beginning of boot drive, > > create distinct ZFS boot pool there for the OS to keep everything > > except of /usr/local, /home and maybe other file systems not belonging to the OS. > > > > Use rest of space for second ZFS pool to keep /usr/local, /home etc. > > And you'll never have your problem again. > > Thanks everyone, I managed to repurpose the swap partition to a root > UFS partition and > managed to copy everything over. What's puzzling is that I still get > zio_read errors. > > It looks like so now: > root@coyote:~# gpart show > => 40 7814037088 ada0 GPT (3.6T) > 40 1024 1 freebsd-boot (512K) > 1064 16777216 2 freebsd-ufs [bootme] (8.0G) > 16778280 16778200 4 freebsd-swap (8.0G) > 33556480 7780478976 3 freebsd-zfs (3.6T) > 7814035456 1672 - free - (836K) > > and I ran this to replace gptzfsboot with gptboot (or so I thought): > # gpart bootcode -b /boot/pmbr -p /boot/gptboot -i 1 ada0 > > But after rebooting, I get these errors on the console still. Why > would gptboot try to read zfs metadata? > > /boot/config: -Dh > Consoles: internal video/keyboard serial port > BIOS drive C: is disk0 > zio_read error: 5 > zio_read error: 5 > zio_read error: 5 > zio_read error: 5 > ZFS: i/o error - all block copies unavailable > ZFS: failed to read pool tank directory object > BIOS 628kB/523264kB available memory > > FreeBSD/x86 bootstrap loader, Revision 1.1 > Loading /boot/defaults/loader.conf > Loading /boot/defaults/loader.conf > Loading /boot/device.hints > Loading /boot/loader.conf > Loading /boot/loader.conf.local > / > Loading kernel... > > Cheers > Uli > > Do you still have vfs.root.mountfrom="zfs:your/tank/dataset" line in /boot/loader.conf on UFS? And/or having /boot.config (or /boot/config) having configuration touching your ZFS pool? If so, and the partition position problem is really the root cause, it can cause loader to look for your ZFS root pool and fail. (/boot/zfsloader is used instead of /boot/loader.) Comment it out and let /etc/rc.d/zpool to import your now-non-root pool. If (and only if) the import fails, possibly you need to delete everything you moved to UFS from ZFS to avoid collision. -- Tomoaki AOKI