aboutsummaryrefslogtreecommitdiffstats
path: root/sbin/zfsbootcfg/zfsbootcfg.c
Commit message (Collapse)AuthorAgeFilesLines
* loader: zfs should support bootonce an nextbootToomas Soome2020-09-211-78/+220
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | bootonce feature is temporary, one time boot, activated by "bectl activate -t BE", "bectl activate -T BE" will reset the bootonce flag. By default, the bootonce setting is reset on attempt to boot and the next boot will use previously active BE. By setting zfs_bootonce_activate="YES" in rc.conf, the bootonce BE will be set permanently active. bootonce dataset name is recorded in boot pool labels, bootenv area. in case of nextboot, the nextboot_enable boolean variable is recorded in freebsd:nvstore nvlist, also stored in boot pool label bootenv area. On boot, the loader will process /boot/nextboot.conf if nextboot_enable is "YES", and will set nextboot_enable to "NO", preventing /boot/nextboot.conf processing on next boot. bootonce and nextboot features are usable in both UEFI and BIOS boot. To use bootonce/nextboot features, the boot loader needs to be updated on disk; if loader.efi is stored on ESP, then ESP needs to be updated and for BIOS boot, stage2 (zfsboot or gptzfsboot) needs to be updated (gpart or other tools). At this time, only lua loader is updated. Sponsored by: Netflix, Klara Inc. Differential Revision: https://reviews.freebsd.org/D25512 Notes: svn path=/head/; revision=365938
* zfsbootcfg: use vfs.root.mountfrom and update nextboot on every vdevToomas Soome2020-06-051-21/+69
| | | | | | | | | | | | vfs.zfs.boot.primary_pool is only set on BIOS boot, use vfs.root.mountfrom instead and update all vdevs on pool. Reviewed by: allanjude Sponsored by: Netflix, Klara Inc. Differential Revision: https://reviews.freebsd.org/D25103 Notes: svn path=/head/; revision=361842
* zfsbootcfg: a simple tool to set next boot (one time) options for zfsbootAndriy Gapon2016-10-291-0/+98
(gpt)zfsboot will read one-time boot directives from a special ZFS pool area. The area was previously described as "Boot Block Header", but currently it is know as Pad2, marked as reserved and is zeroed out on pool creation. The new code interprets data in this area, if any, using the same format as boot.config. The area is immediately wiped out. Failure to parse the directives results in a reboot right after the cleanup. Otherwise the boot sequence proceeds as usual. zfsbootcfg writes zfsboot arguments specified on its command line to the Pad2 area of a disk identified by vfs.zfs.boot.primary_pool and vfs.zfs.boot.primary_vdev kenv variables that are set by loader during boot. Please see the manual page for more. Thanks to all who reviewed, contributed and made suggestions! There are many potential improvements to the feature, please see the review for details. Reviewed by: wblock (docs) Discussed with: jhb, tsoome MFC after: 3 weeks Relnotes: yes Differential Revision: https://reviews.freebsd.org/D7612 Notes: svn path=/head/; revision=308089