ZFS and GPT boot - size issue bootblock v.s. default of sysinstall
Allan Jude
allanjude at freebsd.org
Fri Dec 30 18:25:51 UTC 2016
On 2016-12-30 07:33, Dirk-Willem van Gulik wrote:
>
>> On 28 Dec 2016, at 22:04, Allan Jude <allanjude at freebsd.org> wrote:
>>
>> On 2016-12-28 14:41, Dirk-Willem van Gulik wrote:
>>> On a default ZFS install (late 2014, 10.x) of a few years hence it seems sysinstall selected 64k as the default size of partition 1: with the bootblock:
>>>
>>> sudo gpart show
>>> => 34 7814037101 ada0 GPT (3.6T)
>>> 34 6 - free - (3.0K)
>>> 40 128 1 freebsd-boot (64K)
>>> 168 67108864 2 freebsd-swap (32G)
>>> 67109032 7746928096 3 freebsd-zfs (3.6T)
>>> 7814037128 7 - free - (3.5K)
>>>
>>> …. lots of disks snipped …..
>>>
>>> => 34 7814037101 ada35 GPT (3.6T)
>>> 34 6 - free - (3.0K)
>>> 40 128 1 freebsd-boot (64K)
>>> 168 67108864 2 freebsd-swap (32G)
>>> 67109032 7746928096 3 freebsd-zfs (3.6T)
>>> 7814037128 7 - free - (3.5K)
>>>
>>> Fair to assume that this (the 64k) is the reason that from 11.x onwards;
>>>
>>> gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ada0
>>>
>>> fails with an immediate:
>>>
>>> gpart: /dev/ada1p1: not enough space
>>>
>>> as gptzfsboot has grown in recent years to something towards the 90k mark ?
>>>
>>> -r--r--r-- 1 root wheel 88898 Dec 24 11:52 /boot/gptzfsboot
>>>
>>> And I guess avoiding a rebuild would mean something like gently disabling swap; shifting partition 1 & 2 carefully an so on ? Or is there a more clever way? ZFS has *already* been upgraded.
>>>
>>> Or am I missing something ?
>>
>> swapoff -a; gpart resize ...; swapon -a
>>
>> is likely your best bet.
>
> Aye - indeed a
>
> #!/bin/sh
>
> # gen 0 35 | while read I
>
> camcontrol devlist | grep ada | awk -F, '{ print $2 }' | sed -e 's/)//‘ | while read I
> do
> gpart delete -i 2 ada$I
> gpart resize -i 1 -s 512k ada$I
> gpart add -t freebsd-swap -i 2 ada$I
> gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ada$I
> done
>
> solved the issue for all machines affected.
>
> We’ve since spotted quite a few systems with too small a bootblock - so I guess sysinstall has historically been a bit stingy - and it may be an idea to include something like above logic in man-page or the upgrade logic.
>
>> The other option is to rebuild gptzfsboot without GELI support, and then
>> it will be under 64 KB.
>
> Unfortunately - we rather rely on GELI and PKCS#11.
>
This would only apply to gptzfsboot, the new feature I introduced in
11.0 that allows you to have even the /boot directory encrypted (rather
than having an unencrypted ufs partition, or a 2nd zpool that is not
encrypted).
If you are upgrading from 10.x or earlier, you can use gptzfsboot
without GELI, since it didn't exist before.
> Dw.
> _______________________________________________
> freebsd-hackers at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"
>
--
Allan Jude
More information about the freebsd-hackers
mailing list