Diff for /wikisrc/wiki/RootOnZFS.mdwn between versions 1.1 and 1.2

version 1.1, 2020/02/22 19:17:04 version 1.2, 2020/02/25 19:56:20
Line 1 Line 1
 # Root On ZFS  # Root On ZFS
   
 NetBSD-9 gained much improved ZFS support.  NetBSD-9 gained much improved ZFS support.
 However, one feature it's still missing is the ability to have your system root on ZFS.  However, one feature it's still missing is the ability to have your system
 For that, we need to teach our boot loader about ZFS, but until then we can work around this limitation by using a FFS boot partition and a ZFS root ramdisk.  root on ZFS.
 You'll also need to use NetBSD-9.99.47 or newer.  For that, we need to teach our boot loader about ZFS,xi
   but until then we can work around this limitation by using a FFS boot
 The idea is simple - the boot loader loads the NetBSD kernel from FFS and the ZFS root ramdisk.  partition and a ZFS root ramdisk.
 The ramdisk then mounts the boot partition and copies the requires ZFS modules from it into the ramdisk.  You'll also need to use NetBSD-9.99.48 or newer.
 ZFS is then initialised to load the modules and then umounts the boot partition.  
 This step saves you from having to load the modules in boot.cfg.  The idea is simple - the boot loader loads the NetBSD kernel and the
 Because the initial root is on a ramdisk, we can then load the boot partition from inside the ZFS root to maintain it.  required modules *(solaris and zfs)* from FFS and the ZFS root ramdisk.
   The ramdisk then imports the ZFS root pool called `rpool`,
 Once ZFS is initialised, the ZFS root is then mounted and sysctl then instructs init to chroot to it and the normal boot procedure then starts.  mounts `rpool/ROOT` to `/altroot` and finally instructs the kernel to
 Once started, the kernel and modules can updated by mounting the boot partition to /altroot.  chroot to it.
   Because the initial root is on a ramdisk,
   we can then load the boot partition from inside the ZFS chroot to maintain it;
   for example to update the kernel and modules.
   
 ## Assumptions  ## Assumptions
   
 The ramdisk does make some assumptions as there is no way to pass variables from boot.cfg:  The ramdisk does make some assumptions as there is no way to pass variables
   from boot.cfg:
   
   *  The boot partition can be referenced as `NAME=boot` - for GPT this is as simple as giving it a label.    *  The kernel has matching modules installed in the same partition; you only need `solaris` and `zfs`.
   *  The ZFS root pool is called `rpool` and the root filesystem is called `ROOT`.    *  The ZFS root pool is called `rpool` and the root filesystem is called `ROOT`.
   
   Once inside the chroot the kernel will load modules from the ZFS filesystem
   because there is a symlink to it from the ramdisk.
   The same is true for any firmware needed after boot.
   
 ## Generic setup  ## Generic setup
   
 Until the NetBSD installer can be updated, here are the manual steps from fresh:  Until the NetBSD installer can be updated, here are the manual steps from fresh:
Line 31  Until the NetBSD installer can be update Line 39  Until the NetBSD installer can be update
   *  Create a partition for ZFS    *  Create a partition for ZFS
   *  Finish the NetBSD installation - install the etc, base and maybe rescue sets    *  Finish the NetBSD installation - install the etc, base and maybe rescue sets
   *  Reboot into your minimal NetBSD install    *  Reboot into your minimal NetBSD install
   *  Label the boot partition boot - if you don't do this then the ramdisk will moan it can't load modules  
   
 ## ZFS Setup  ## ZFS Setup
   
Line 51  So far, so good. Now we need to make the Line 58  So far, so good. Now we need to make the
   *  Add `name=boot /altroot ffs rw,noauto` to `/altroot/etc/fstab` along with any ZFS filesytems you created in '/usr' and '/var'    *  Add `name=boot /altroot ffs rw,noauto` to `/altroot/etc/fstab` along with any ZFS filesytems you created in '/usr' and '/var'
   *  Add the filesystems as well to `critical_filesystems_local` in `/altroot/etc/rc.conf` - such as `critical_filesystems_local="/usr /var /var/log"`    *  Add the filesystems as well to `critical_filesystems_local` in `/altroot/etc/rc.conf` - such as `critical_filesystems_local="/usr /var /var/log"`
   *  Copy the `ramdisk-zfsroot.fs` to `/`    *  Copy the `ramdisk-zfsroot.fs` to `/`
   *  Edit `/boot.cfg` and add `menu=Boot ZFS Root:fs /ramdisk-zfsroot.fs;boot`    *  Edit `/boot.cfg` and add `menu=Boot ZFS Root:load solaris;load zfs;fs /ramdisk-zfsroot.fs;boot`
   
 And done! You can now reboot and enjoy your root on ZFS and all the benefits it brings.  And done!
 When updating the kernel, remember to `mount /altroot` and update it there as well as the modules.  You can now reboot and enjoy your root on ZFS and all the benefits it brings.
   When updating the kernel, remember to `mount /altroot` and update it there as
   well as the modules.
   
 ## Future work  ## Future work
   
 All these steps could be done in the installer.  All these steps could be done in the installer.
 This is probably an easier task than adding ZFS support to the bootloader. But don't let that stop you if you are stuck for something to do!  This is probably an easier task than adding ZFS support to the bootloader.
   But don't let that stop you if you are stuck for something to do!
 # DANGER NETBSD ROOT ON ZFS USER, DANGER!  
   
 There seems to be an issue accessing `/dev` nodes on ZFS.  
 While -current has enough fixes to work somewhat, accessing the boot partition whilst while root is on ZFS will hang, panic and maybe even corrupt your boot partition.  
 As such, you'll have to reboot into single user. From here you can mount the ZFS partition to `/altroot` and copy the updated kernel and modules from there to the boot partition.  
 Ironically, this is what the ramdisk approach was designed to actively avoid. Hopefully we can get it resolved soon.  

Removed from v.1.1  
changed lines
  Added in v.1.2


CVSweb for NetBSD wikisrc <wikimaster@NetBSD.org> software: FreeBSD-CVSweb