The sdc-factoryreset triggers a wipe of all ZFS pools during the fs-joyent script on the next boot. This wipe may fail if the pool is bootable/booting especially if it's a Triton Head Node where the "usb key" is on-pool.
Existing USB-key (or even ISO-boot in SmartOS) behavior should be emulated wherever possible in the disk-booting case.
Dan McDonald commented on 2023-05-19T12:31:20.269-0400 (edited 2023-05-19T12:32:08.896-0400):
The sdc-factoryreset script COULD and probably SHOULD invoke piadm bootable -d $POOL as part of its wiping-out procedure.
Dan McDonald commented on 2024-09-19T15:32:30.716-0400:
First we need to gather existing behaviors on pool-booting nodes. For each of Standalone SmartOS, Triton CN, Triton HN find out:
- SYSPOOL/zones boot post factoryreset.
- BOOTPOOL != SYSPOOL/zones boot post factoryreset.
Testing that will need to be done:
- post-factoryreset, the ability to boot noimport (even if the boot bits of the pool are gone and we boot from something else)
- <more to come>
Dan McDonald commented on 2025-01-29T16:57:31.960-0500:
Existing behavior test: Using a VMware “SmartOS new from scratch” VM, installing SmartOS from 20240123 ISO, booting off of disk (ISO drive detached), running sdc-factoryreset -s, and powering on by hand.
Pre-factoryreset existing behavior: smartos=true in bootparams, but no OBVIOUS way to know what pool was booted (unlike HNs… we should PROBABLY fix that independently of this, setting say smartos_bootpool in bootparams). After uttering sdc-factoryreset -s and then rebooting, I get the loader boot screen. NOTE: the loader screen can boot into a recovery mode where the zones pool can be imported, and the smartdc:factoryreset property on zones/var can be cleared.
Post-factoryreset existing behavior: Once it times out, we boot the ramdisk. The installer screen comes up. If I hit ^C and get a shell, I can use “zpool import -D zones” to recover the actually-destroyed pool. One could clear the the smartdc:factoryreset property on zones/var and still recover things. One also can recover the destroyed zones pool RIGHT at the part where the filesystem setup occurs in the installer, but doing so without clearing smartdc:factoryreset will cause the installer to fail due to pre-created filesystems. If one lets zones pool creation proceed, and goes through the installer, it will fail because piadm(8)'s media is not available.
Notes and possible conclusions: After failure, if one enters the shell with a working network one can utter piadm bootable -e -i latest zones and the command will download the smartos-latest.iso media and install it. A reboot will then bring up a freshly-installed system.
For standalone smartos, an installer that’s tripped after sdc-factoryreset COULD be convinced to use latest instead of media for installation (assuming a network that can DNS-resolve and reach Manta gets configured at installation time). This would require changes to both fs-joyent (to indicate globally somehow that a pool was destroyed), and one or more of smartos_prompt_config.sh (which would take the hint from fs-joyent that maybe no media is available) or piadm (which could take a new -i media-or-latest like option that would make it try harder).
Alternatively, an sdc-factoryreset that CLOBBERS all boot sectors for available bootable pools might send a stronger message.