From nobody Mon Nov 28 04:24:56 2022 X-Original-To: freebsd-questions@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 4NLC792R53z4hwFr for ; Mon, 28 Nov 2022 04:25:09 +0000 (UTC) (envelope-from list_freebsd@bluerosetech.com) Received: from echo.brtsvcs.net (echo.brtsvcs.net [208.111.40.118]) (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 4NLC780C0fz4B88 for ; Mon, 28 Nov 2022 04:25:07 +0000 (UTC) (envelope-from list_freebsd@bluerosetech.com) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of list_freebsd@bluerosetech.com designates 208.111.40.118 as permitted sender) smtp.mailfrom=list_freebsd@bluerosetech.com; dmarc=none Received: from chombo.houseloki.net (65-100-43-2.dia.static.qwest.net [65.100.43.2]) by echo.brtsvcs.net (Postfix) with ESMTPS id B7CDC38D02 for ; Mon, 28 Nov 2022 04:25:00 +0000 (UTC) Received: from [10.26.25.100] (ivy.pas.ds.pilgrimaccounting.com [10.26.25.100]) by chombo.houseloki.net (Postfix) with ESMTPSA id 056BE2C21 for ; Sun, 27 Nov 2022 20:24:58 -0800 (PST) From: Mel Pilgrim Subject: kernel panic due to missing root when using boot environments To: freebsd-questions@freebsd.org Message-ID: <1c68d4e1-38ff-b820-f59e-a14fe3df0675@bluerosetech.com> Date: Sun, 27 Nov 2022 20:24:56 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 List-Id: User questions List-Archive: https://lists.freebsd.org/archives/freebsd-questions List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-questions@freebsd.org X-BeenThere: freebsd-questions@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spamd-Result: default: False [-3.26 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.96)[-0.960]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:36236, ipnet:208.111.40.0/24, country:US]; MLMMJ_DEST(0.00)[freebsd-questions@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; DMARC_NA(0.00)[bluerosetech.com]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_THREE(0.00)[3]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; RCVD_TLS_ALL(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-questions@freebsd.org]; TO_DN_NONE(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-Rspamd-Queue-Id: 4NLC780C0fz4B88 X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N I have a system running 12.3p6 with a GELI+ZFS root configuration that had a kernel panic on reboot because it wasn't mounting root correctly. The system has two pools involved in booting: bootkey: contains the UEFI partition, /boot, and the GELI keys for the devices under the nvme pool nvme: contains everything else Previously, the system set vfs.root.mountfrom in loader.conf. Then I reconfigured to use boot environments: # zfs get -s local all nvme/ROOT/freebsd12 NAME PROPERTY VALUE SOURCE nvme/ROOT/freebsd12 mountpoint / local nvme/ROOT/freebsd12 readonly off local nvme/ROOT/freebsd12 canmount noauto local # zpool get bootfs NAME PROPERTY VALUE SOURCE bootkey bootfs - default nvme bootfs nvme/ROOT/freebsd12 local With these settings, the kernel panics and reboots before it launches userland. I can't grab a log of the panic, but fast eyeballs caught: panic: no init Reboot again, set vfs.root.mountfrom manually from the loader prompt, and it boots fine. Thus a few queries: 1: In a configuration where the boot pool and root pool are not the same, how do I set bootfs? The obvious options of setting it the same on both pools or at least the boot pool won't work: # zpool set bootfs=nvme/ROOT/freebsd12 bootkey cannot set property for 'bootkey': 'nvme/ROOT/freebsd12' is an invalid name 1a: Why is the setting format bootfs=pool/dataset if I can't specify a different pool than the one on which I'm setting bootfs? 2. Why did the kernel panic instead of dropping to the mountroot prompt? Is it because the kernel assumed the filesystem containing /boot was / in absence of vfs.root.mountfrom and bootfs so there was no attempt to mount / to fail into the mountroot prompt?