I'd like to better understand the boot process as it applies to a ZFS on root approach in FreeBSD 9 or 10 using GPT. What I understand so far: A. BIOS is able to execute some code placed in a special partition on a GPT formatted disk. This code is 40kB of hand crafted code and installed using: gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ada0 The partition itself must be created as gpart add -s 222 -a 4k -t freebsd-boot -l boot0 ada0 B. For older BIOS systems without knowledge of GPT, the pmbr is installed in some other special location on the disk, outside any partitions. This is 512 bytes of code and does nothing other than pretend to be MBR to tell the old BIOS (or Windows?) to not mess with this disk. 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. Questions 1. If I have two zpools on this machine, how does gptzfsboot know which one to boot the kernel from? Does it just start by iterating through all zfs partitions until it finds the zpool metadata cache which give it enough information to mount some zpool? In other words, does it pick a random pool from what it can access? 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? 3. Once the kernel is booted, then it can read /boot/loader.conf. In there we can see vfs.root.mountfrom="zfs:tank" but isn't this a bit late? We've already mounted this pool and loaded the kernel from it. Can we omit vfs.root.mountfrom entirely? I understand grub a little better, since in that case you configure, then install a new configured grub artifact into the right places. But with the FreeBSD boot process there seems to be no configuration of the first stage boot loader. Thanks very much for helping me to understand this boot process in more detail Cheers Ari -- --------------------------> Aristedes Maniatis ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
On 6/5/2014 3:32 AM, Aristedes Maniatis wrote:> I'd like to better understand the boot process as it applies to a ZFS on root approach in FreeBSD 9 or 10 using GPT. What I understand so far: > > A. BIOS is able to execute some code placed in a special partition on a GPT formatted disk. This code is 40kB of hand crafted code and installed using: > > gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ada0 > > The partition itself must be created as > > gpart add -s 222 -a 4k -t freebsd-boot -l boot0 ada0 > > > B. For older BIOS systems without knowledge of GPT, the pmbr is installed in some other special location on the disk, outside any partitions. This is 512 bytes of code and does nothing other than pretend to be MBR to tell the old BIOS (or Windows?) to not mess with this disk. > > 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. > > > > Questions > > 1. If I have two zpools on this machine, how does gptzfsboot know which one to boot the kernel from? Does it just start by iterating through all zfs partitions until it finds the zpool metadata cache which give it enough information to mount some zpool? In other words, does it pick a random pool from what it can access?It looks at the pools until it finds "bootfs" defined on one of them, which tells it where to boot from.> > 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?Once it has found "bootfs" it expects the usual structures to be there (e.g. the "/boot" directory)> > 3. Once the kernel is booted, then it can read /boot/loader.conf. In there we can see vfs.root.mountfrom="zfs:tank" but isn't this a bit late? We've already mounted this pool and loaded the kernel from it. Can we omit vfs.root.mountfrom entirely?I do not have it in my /boot/loader.conf file. I have "beadm" set up which allows me to snapshot the existing running system structure off my root pool (a separate pool from where data lives) and then start it in a jail and perform an update on it there. I can then swap to it on the next boot if I wish while retaining the previous system copy (in case something goes wrong.)> > > I understand grub a little better, since in that case you configure, then install a new configured grub artifact into the right places. But with the FreeBSD boot process there seems to be no configuration of the first stage boot loader. > > > Thanks very much for helping me to understand this boot process in more detail > > > Cheers > Ari > >-- -- Karl karl at denninger.net -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2711 bytes Desc: S/MIME Cryptographic Signature URL: <http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20140605/2b19769f/attachment.bin>
On 05.06.2014 12:32, Aristedes Maniatis wrote:> A. BIOS is able to execute some code placed in a special partition on > a GPT formatted disk. This code is 40kB of hand crafted code and > installed using: > > gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ada0 > > The partition itself must be created as > > gpart add -s 222 -a 4k -t freebsd-boot -l boot0 ada0 > > > B. For older BIOS systems without knowledge of GPT, the pmbr is > installed in some other special location on the disk, outside any > partitions. This is 512 bytes of code and does nothing other than > pretend to be MBR to tell the old BIOS (or Windows?) to not mess with > this disk.No. BIOS starts bootcode from PMBR. Then it starts bootcode from freebsd-boot partition. Then it starts loader or kernel. This method also called as legacy boot. UEFI doesn't use bootcode on the freebsd-boot partition.> 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 search the zfsloader or kernel and without mounting loads and starts it. http://www.freebsd.org/cgi/man.cgi?gpart#BOOTSTRAPPING> Questions > > 1. If I have two zpools on this machine, how does gptzfsboot know > which one to boot the kernel from? Does it just start by iterating > through all zfs partitions until it finds the zpool metadata cache > which give it enough information to mount some zpool? In other words, > does it pick a random pool from what it can access?AFAIK, it will try to boot from the first ZFS pool that it can find.> 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 location.> 3. Once the kernel is booted, then it can read /boot/loader.conf. In > there we can see vfs.root.mountfrom="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. -- WBR, Andrey V. Elsukov