Circling back around to smartos.img having the same i/o error, but not attributable to 16-bit math, tells me it means "VTOC's maths don't add up." IOW, "sector misalignment." Apparently they didn't get Peter's memo on installing ZFS rpool to a slice. ;-) G'head, burn it, boot it, tell me about s9, bork it, won't reboot... now, boot any other illumos including smartos, and point "format -e" at it, now:
format> q # reboot -p See, it's already fixed! Except you have to move s9 manually, either before or after rebooting... unless you pointed parted at it and answered "yes" to "fix" in which case it's fixed and s9 relocates. What I was thinkin' before about those hogs, was wrong. Has nothing to do with the template you use when partitioning. What causes the desired behavior is, when you "pack your bags" so to speak, you set s9 to 0xFFFF's (not that I've figured out how as yet). This = 2TB, or wherever the new "end of drive" is. With my partitioning on a 512GB SATA, I was able to clone to a 500GiB NVMe with no room to spare, because somehow it "just worked" while it doesn't budge when I clone to a larger drive. What isn't UEFI compatible, is PMBR-SMI. Only PMBR-GPT is UEFI approved, and if you zero out s0 and s2 you're fully interoperable so long as you're not using UFS, because ZFS puts "Solaris Backup" inside the pool. The reason the Wizard was confused between PMBR-SMI/PMBR-EFI, was simply not knowing what to make of 16-bit math. So, PMBR is something you don't need at all, if your firmware boots partitions instead of devices -- the partitions are GUID "either way you slice it." -Eric ------------------------------------------ illumos: illumos-discuss Permalink: https://illumos.topicbox.com/groups/discuss/Te6d81d754118b912-M385a66ba3fb7293ee3bdbc2e Delivery options: https://illumos.topicbox.com/groups/discuss/subscription
