Date: Thu, 05 Jun 2014 22:34:36 -0500 From: Karl Denninger <karl@denninger.net> To: freebsd-stable@freebsd.org Subject: Re: ZFS boot pool selection Message-ID: <539136CC.3060900@denninger.net> In-Reply-To: <53912346.7010207@ish.com.au> References: <53902B1D.8030200@ish.com.au> <53909B22.7000801@yandex.ru> <53912346.7010207@ish.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
This is a cryptographically signed message in MIME format. --------------ms080505080904090300000100 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 6/5/2014 9:11 PM, Aristedes Maniatis wrote: > On 6/06/2014 2:30am, Andrey V. Elsukov wrote: > >> On 05.06.2014 12:32, Aristedes Maniatis wrote: >>> C. Once gptzfsboot is executing on the CPU, it is able to mount a ZFS= >>> pool in read only mode. Enough to read the kernel and get a full ZFS >>> implementation in place. >> gptzfsboot is able to find needed partition and ZFS pool, then it sear= ch >> the zfsloader or kernel and without mounting loads and starts it. >> >> http://www.freebsd.org/cgi/man.cgi?gpart#BOOTSTRAPPING >> AFAIK, it will try to boot from the first ZFS pool that it can find. > > Then it would seem that the ZFS property bootfs is pretty much ignored.= I know that I've never set it and everything seems to boot fine. Effecti= vely it will load zfsloader from a random pool from all the pools it find= s. No it's not. I use it to choose which filesystem to boot from when I=20 have multiple roots available, which I do when performing upgrades. > > Documentation is rather inconsistent too. One page [1] says bootfs shou= ld just point to the pool. Another page [2] that it points to the filesys= tem. > > I'm guessing this is inconsistent because that command actually does no= thing. No, it tells the system where the root filesystem is (which should=20 contain /boot) > =20 >>> 2. How does it know where to find the kernel once it mounts the ZFS >>> pool, or is the /boot/kernel location hardcoded into the gptzfsboot >>> code? >> /boot/kernel/kernel is hardcoded. But when zfsloader is used, it has >> some environment variables and you are able to change the kernel locat= ion. >> >>> 3. Once the kernel is booted, then it can read /boot/loader.conf. In >>> there we can see vfs.root.mountfrom=3D"zfs:tank" but isn't this a bit= >>> late? We've already mounted this pool and loaded the kernel from it. >> Kernel doesn't read loader.conf. The loader/zfsloader does that. >> >>> Can we omit vfs.root.mountfrom entirely? >> Yes. > > Right, so zfsloader reads loader.conf and uses vfs.root.mountfrom (if i= t exists) to work out which pool contains the kernel and root filesystem.= If vfs.root.mountfrom doesn't exist then it tries the pool that already = contains zfsloader. Which makes vfs.root.mountfrom a bit pointless. > > When the machine boots the kernel you get dmesg text scrolling by in a = light font. I'm guessing that when that font changes to a darker colour t= hat's the point at which the kernel has now mounted the system read-write= and it ready to load userland. > > Should vfs.root.mountfrom and bootfs be removed from the latest ZFS how= to instructions? Absolutely not on bootfs, as it is honored if set. --=20 -- Karl karl@denninger.net --------------ms080505080904090300000100 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFTzCC BUswggQzoAMCAQICAQgwDQYJKoZIhvcNAQEFBQAwgZ0xCzAJBgNVBAYTAlVTMRAwDgYDVQQI EwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExLzAtBgkqhkiG9w0BCQEWIGN1c3Rv bWVyLXNlcnZpY2VAY3VkYXN5c3RlbXMubmV0MB4XDTEzMDgyNDE5MDM0NFoXDTE4MDgyMzE5 MDM0NFowWzELMAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExFzAVBgNVBAMTDkthcmwg RGVubmluZ2VyMSEwHwYJKoZIhvcNAQkBFhJrYXJsQGRlbm5pbmdlci5uZXQwggIiMA0GCSqG SIb3DQEBAQUAA4ICDwAwggIKAoICAQC5n2KBrBmG22nVntVdvgKCB9UcnapNThrW1L+dq6th d9l4mj+qYMUpJ+8I0rTbY1dn21IXQBoBQmy8t1doKwmTdQ59F0FwZEPt/fGbRgBKVt3Quf6W 6n7kRk9MG6gdD7V9vPpFV41e+5MWYtqGWY3ScDP8SyYLjL/Xgr+5KFKkDfuubK8DeNqdLniV jHo/vqmIgO+6NgzPGPgmbutzFQXlxUqjiNAAKzF2+Tkddi+WKABrcc/EqnBb0X8GdqcIamO5 SyVmuM+7Zdns7D9pcV16zMMQ8LfNFQCDvbCuuQKMDg2F22x5ekYXpwjqTyfjcHBkWC8vFNoY 5aFMdyiN/Kkz0/kduP2ekYOgkRqcShfLEcG9SQ4LQZgqjMpTjSOGzBr3tOvVn5LkSJSHW2Z8 Q0dxSkvFG2/lsOWFbwQeeZSaBi5vRZCYCOf5tRd1+E93FyQfpt4vsrXshIAk7IK7f0qXvxP4 GDli5PKIEubD2Bn+gp3vB/DkfKySh5NBHVB+OPCoXRUWBkQxme65wBO02OZZt0k8Iq0i4Rci WV6z+lQHqDKtaVGgMsHn6PoeYhjf5Al5SP+U3imTjF2aCca1iDB5JOccX04MNljvifXgcbJN nkMgrzmm1ZgJ1PLur/ADWPlnz45quOhHg1TfUCLfI/DzgG7Z6u+oy4siQuFr9QT0MQIDAQAB o4HWMIHTMAkGA1UdEwQCMAAwEQYJYIZIAYb4QgEBBAQDAgWgMAsGA1UdDwQEAwIF4DAsBglg hkgBhvhCAQ0EHxYdT3BlblNTTCBHZW5lcmF0ZWQgQ2VydGlmaWNhdGUwHQYDVR0OBBYEFHw4 +LnuALyLA5Cgy7T5ZAX1WzKPMB8GA1UdIwQYMBaAFF3U3hpBZq40HB5VM7B44/gmXiI0MDgG CWCGSAGG+EIBAwQrFilodHRwczovL2N1ZGFzeXN0ZW1zLm5ldDoxMTQ0My9yZXZva2VkLmNy bDANBgkqhkiG9w0BAQUFAAOCAQEAZ0L4tQbBd0hd4wuw/YVqEBDDXJ54q2AoqQAmsOlnoxLO 31ehM/LvrTIP4yK2u1VmXtUumQ4Ao15JFM+xmwqtEGsh70RRrfVBAGd7KOZ3GB39FP2TgN/c L5fJKVxOqvEnW6cL9QtvUlcM3hXg8kDv60OB+LIcSE/P3/s+0tEpWPjxm3LHVE7JmPbZIcJ1 YMoZvHh0NSjY5D0HZlwtbDO7pDz9sZf1QEOgjH828fhtborkaHaUI46pmrMjiBnY6ujXMcWD pxtikki0zY22nrxfTs5xDWGxyrc/cmucjxClJF6+OYVUSaZhiiHfa9Pr+41okLgsRB0AmNwE f6ItY3TI8DGCBQowggUGAgEBMIGjMIGdMQswCQYDVQQGEwJVUzEQMA4GA1UECBMHRmxvcmlk YTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExDMRwwGgYD VQQDExNDdWRhIFN5c3RlbXMgTExDIENBMS8wLQYJKoZIhvcNAQkBFiBjdXN0b21lci1zZXJ2 aWNlQGN1ZGFzeXN0ZW1zLm5ldAIBCDAJBgUrDgMCGgUAoIICOzAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNDA2MDYwMzM0MzZaMCMGCSqGSIb3DQEJBDEW BBQMN2bLhkaN5UKPP6u8HJ5d40UMuDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjAL BglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFA MAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIG0BgkrBgEEAYI3EAQxgaYwgaMwgZ0xCzAJBgNV BAYTAlVTMRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoT EEN1ZGEgU3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExLzAtBgkq hkiG9w0BCQEWIGN1c3RvbWVyLXNlcnZpY2VAY3VkYXN5c3RlbXMubmV0AgEIMIG2BgsqhkiG 9w0BCRACCzGBpqCBozCBnTELMAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExEjAQBgNV BAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1zIExMQzEcMBoGA1UEAxMTQ3Vk YSBTeXN0ZW1zIExMQyBDQTEvMC0GCSqGSIb3DQEJARYgY3VzdG9tZXItc2VydmljZUBjdWRh c3lzdGVtcy5uZXQCAQgwDQYJKoZIhvcNAQEBBQAEggIAK6CYn4XHksGLy3f5cUMYcEFqw3An DA6Vq/XZUNu+HcNoOC7B8CQagMhisJBgF7J+yAS7InCVOLS7Jbr9JBcCjuFbmAfh/krx4+lQ wfWvUg8GzmgBxE6IlwZVzNno/8UOHdFFh3b9snDSn3LSHcyy/7ryc4KgBF1JenUmWu/RtXms Uutf6kEsUnIASPVmG0BrTgnMTyNgQhAew8XRU18IhgWN8I7vFexa+a/avNwTrKNzefjI1QMf tWQvGMMSd0M8RxKbdl2U4HDeCBQnA8zNwTY1925eCkvZvVZGgoqvaWUjanGQz4dIrW/G7MFq MoEF33LzmmiqZXAS8WCvJ/uT1HPab8b5r19HQExVE17XqDirabhT50ls0Sa7ThmS05KCBhkJ 7fgUgCXXZoj7jC7Vjrw/laMi28MBOV5q1MpwJXk/bK/B3m9DIa+iir0qr05NWHcbsMnVlVCg 90lDYnctfWIOpyb1kF6oIXVmm5pbK2T8oBL26RaRwTQrF2dW/fbHwJWCQhRBw6VoOrf9FL9T b8u9p5p5c9+XvgS0kyTgCjDz60NiH2Uo7oGnKxfzTAUqChiYjtEhZEPFrYgCL4381HCQcFZB jSPL/v6nZKIyZLyE2tXqwz0XeIGTcdvEt0OOZDkbRvEzb2P89axFQmf8RWBX+RSTffJb2HvN A/8pozYAAAAAAAA= --------------ms080505080904090300000100--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?539136CC.3060900>