Как переключить загрузку на UEFI

[kharkov_max]

Добрый день.

Есть вот такой вопрос.
Как то пару лет была куплена плата Asus Z97-K
На эту плату была установлена Freebsd 10, на данный момент обновленная до Freebsd 11.

Уже не помню как так получилось, но система была установлена на GPT UFS НЕ!!! UEFI.
Плата поддерживает UEFI и появилось желание переключить загрузку на UEFI.

Вот теперь вопрос как это правильно сделать.
На данный момент gpart show загрузочного диска:

Код: Выделить всё

=>       34  976773100  mirror/gm0  GPT  (466G)
         34       1024           1  freebsd-boot  [bootme]  (512K)
       1058  968883200           2  freebsd-ufs  (462G)
  968884258    7888875           3  freebsd-swap  (3.8G)
  976773133          1              - free -  (512B)

В системе 2 диска в gmirror, поэтому gm0...

gpart list загрузочтного диска:

Код: Выделить всё

Geom name: mirror/gm0
modified: false
state: OK
fwheads: 255
fwsectors: 63
last: 976773133
first: 34
entries: 128
scheme: GPT
Providers:
1. Name: mirror/gm0p1
   Mediasize: 524288 (512K)
   Sectorsize: 512
   Stripesize: 4096
   Stripeoffset: 1024
   Mode: r0w0e0
   rawuuid: b6eb6c95-7795-11e4-853a-6805ca099bfc
   rawtype: 83bd6b9d-7f41-11dc-be0b-001560b84f0f
   attrib: bootme
   label: (null)
   length: 524288
   offset: 17408
   type: freebsd-boot
   index: 1
   end: 1057
   start: 34
2. Name: mirror/gm0p2
   Mediasize: 496068198400 (462G)
   Sectorsize: 512
   Stripesize: 4096
   Stripeoffset: 1024
   Mode: r1w1e1
   rawuuid: b6ec1a4b-7795-11e4-853a-6805ca099bfc
   rawtype: 516e7cb6-6ecf-11d6-8ff8-00022d09712b
   label: (null)
   length: 496068198400
   offset: 541696
   type: freebsd-ufs
   index: 2
   end: 968884257
   start: 1058
3. Name: mirror/gm0p3
   Mediasize: 4039104000 (3.8G)
   Sectorsize: 512
   Stripesize: 4096
   Stripeoffset: 1024
   Mode: r1w1e0
   rawuuid: b6f00d60-7795-11e4-853a-6805ca099bfc
   rawtype: 516e7cb5-6ecf-11d6-8ff8-00022d09712b
   label: (null)
   length: 4039104000
   offset: 496068740096
   type: freebsd-swap
   index: 3
   end: 976773132
   start: 968884258
Consumers:
1. Name: mirror/gm0
   Mediasize: 500107861504 (466G)
   Sectorsize: 512
   Stripesize: 4096
   Stripeoffset: 0
   Mode: r2w2e3

Собственно какие логические действия я вижу для себя на данный момент.

1. Развалить gmirror и грузится с ada0 (второй диск оставить под бекап)
2. Грузимся с загрузочной флешки.
3. Удаляем раздел 1 freebsd-boot (не факт что даст без удаления остальных разделов ...)
4. Создаем раздел 1 efi
5. Заливаем загрузчик dd if=/boot/boot1.efifat of=/dev/ada0p1
6. В Bios переключаем загрузку на UEFI...

Возможно пункты 3 и 4 делать не нужно, а тупо залить новый загрузчик...
Пока ни где не экспериментировал, вопрос теоретический.

Подскажите верную последовательность действий...

[Хостинг HostFood.ru]

Тарифы на хостинг в России, от 12 рублей: https://www.host-food.ru/tariffs/hosting/
Тарифы на виртуальные сервера (VPS/VDS/KVM) в РФ, от 189 руб.: https://www.host-food.ru/tariffs/virtualny-server-vps/
Выделенные сервера, Россия, Москва, от 2000 рублей (HP Proliant G5, Intel Xeon E5430 (2.66GHz, Quad-Core, 12Mb), 8Gb RAM, 2x300Gb SAS HDD, P400i, 512Mb, BBU):
https://www.host-food.ru/tariffs/vydelennyi-server-ds/
Недорогие домены в популярных зонах: https://www.host-food.ru/domains/

[Neus]

0. оставить как есть.

[kharkov_max]

0. оставить как есть.

Не вариант, т.к. далее планируется замена МП на другую где вроде как загрузка только UEFI...

[f_andrey]

3.

даст.

В принципе схема рабочая, но если не разу не делалось, лучше на чём то не важном портенироваться.

[kharkov_max]

Вот еще вопрос

Код: Выделить всё

        34       1024           1  freebsd-boot  [bootme]  (512K)

Размер первого раздела ...
UEFI загрузчик вроде как до 800K, влезет ?

[f_andrey]

В принципе, там нынче

Код: Выделить всё

 # df -h /media
Filesystem     Size    Used   Avail Capacity  Mounted on
/dev/ada3p1    767K    131K    637K    17%    /media

Но упихивать конечно тогда руками, стандартный 800К, но он вроде не обязательно обязан быть первым, можно вон свап ужать, даже тут вроде когда то кто то предлагал схему. (но сам вроде так не пробовал)

[guest]

Добрый день.

Есть вот такой вопрос.
Как то пару лет была куплена плата Asus Z97-K
На эту плату была установлена Freebsd 10, на данный момент обновленная до Freebsd 11.

Уже не помню как так получилось, но система была установлена на GPT UFS НЕ!!! UEFI.
Плата поддерживает UEFI и появилось желание переключить загрузку на UEFI.

Вот теперь вопрос как это правильно сделать.
На данный момент gpart show загрузочного диска:

Код: Выделить всё

=>       34  976773100  mirror/gm0  GPT  (466G)
         34       1024           1  freebsd-boot  [bootme]  (512K)
       1058  968883200           2  freebsd-ufs  (462G)
  968884258    7888875           3  freebsd-swap  (3.8G)
  976773133          1              - free -  (512B)

Первое:

выше имеем:

Код: Выделить всё

         34       1024           1  freebsd-boot  [bootme]  (512K)

начало: сектор 34, размер 512K
а далее, с сектора 1058 начинается корень,

смотрим размер efifat:

Код: Выделить всё

 ls -la /boot/boot1.efifat 
-r--r--r--  1 root  wheel  819200  2 февр. 21:52 /boot/boot1.efifat

это 800K, те 1600 секторов по 512.

значит, 34+1600=1634, откуда должен начинаться корень

У Вас он с 1058.

образ efifat в реалии, раза в два больше чем нужно, если не плодить multiboot:

смотрим efifat:

Код: Выделить всё

# df -k /mnt/
Filesystem 1024-blocks Used Avail Capacity  Mounted on
/dev/da0p1         767  130   636    17%    /mnt
#

Код: Выделить всё

# ls -la /mnt/efi/boot/
total 130
drwxr-xr-x  1 root  wheel     512 Apr 12  2016 .
drwxr-xr-x  1 root  wheel     512 Apr 12  2016 ..
-rwxr-xr-x  1 root  wheel  131072 Apr 12  2016 bootx64.efi
-rwxr-xr-x  1 root  wheel      12 Apr 12  2016 startup.nsh
#

видим что в реалии, не 800K, а ~134K, если сделать свой образ efifat, можно уложиться до начала
вашего корня, те оставить те же 512K под efifat

Второе, можно сделать общий вариант: загрузка с GPT + загрузка с UEFI, как пример - memstick
от FreeBSD:

Код: Выделить всё

 gpart show da0
=>      3  1433741  da0  GPT  (7.4G) [CORRUPT]
        3     1600    1  efi  (800K)
     1603      125    2  freebsd-boot  (63K)
     1728  1429968    3  freebsd-ufs  (698M)
  1431696     2048    4  freebsd-swap  (1.0M)

образать внимание на "3 1433741 da0 GPT (7.4G) [CORRUPT]" не нужно, но и не нужно забывать что
efifat будет не 3'его сектора, а с 34, иначе GPT CORRUPT, ибо у нас не memstick для установки.

Вроде прозрачно расписано?

[kharkov_max]

Спасибо guest за разъяснения.
Т.к. особо пока не жмет, пойду правильным путем.

Развалю mirror, на 2м диске пересоздам партиции (первую сделаю до 2048K скорее всего сразу на EFI ) и с первого диска перлью систему на 2й (pax). Потом убью все на первом и в зеркало его на gmirror ...

[guest]

Спасибо guest за разъяснения.
Т.к. особо пока не жмет, пойду правильным путем.

Развалю mirror, на 2м диске пересоздам партиции (первую сделаю до 2048K скорее всего сразу на EFI ) и с первого диска перлью систему на 2й (pax). Потом убью все на первом и в зеркало его на gmirror ...

советую все ж потренироваться:

- берем флешку на 4GB или более

вариант 1 (стандартный efifat)

- размечаем ее руками: GPT, FAT32, заливаем efifat, newfs

# gpart destroy -F da0
# gpart create -s gpt da0
# gpart add -t efi -s 800K da0
# gpart add -t freebsd-ufs -s XGB da0
# gpart add -t freebsd-swap -s XGB da0
# dd if=/boot/boot1.efifat of=/dev/da0p1

- разворачиваем руками дистрибутив, настраиваем fstab и rc.conf
- загружаемся

вариант 2:

- размечаем руками GPT, FAT32 - но уже 512K, newfs
создаем свой efifat на 512K

Код: Выделить всё

# cd /tmp
# dd if=/dev/zero of=efiboot.img bs=1k count=512
# ls -la efiboot.img
# mdconfig -a -t vnode -f efiboot.img
# newfs_msdos -F 12 -m 0xf8 /dev/md0
# mkdir efi
# ls -la efi
# mkdir efi
# mount -t msdosfs /dev/md0 /tmp/efi
# mkdir -p efi/efi/boot
# cp /boot/loader.efi efi/efi/boot/bootx64.efi
# umount /tmp/efi
#  ls -la efiboot.img
-rw-r--r--  1 root  wheel  524288 Feb 27 14:58 efiboot.img
#

Все, имеем 512k - свой efiboot.img
Его и будем заливать dd'ей

# gpart destroy -F da0
# gpart create -s gpt da0
# gpart add -t efi -s 512k da0
# gpart add -t freebsd-ufs -s XGB da0
# gpart add -t freebsd-swap -s XGB da0
# dd if=/tmp/efiboot.img of=/dev/da0p1

Как разворачивать руками систему из txz, думаю, расписывать нет смысла, это просто и известно.

Со своим efifat образом, ничего переразмечать не надо, но и загрузка будет только UEFI, а я бы сделал
универсальную, как на memstick - и с GPT и с UEFI: pmbr - 512 байт, gptboot - 64k, efifat - от 140 до 512k,
можно рассчитать сколько нужно чтобы уложиться до корня, вроде 1024k хватает

Короче, попробуйте руками на флешке и получите готовую инструкцию, ничего передвигать и бекапить
не потребуется. Делов на 30 минут, ну на час с хождениями, оформлениями флешки, загрузкой под UEFI
и UEFI + CSM Legacy...

Зато потом без дрожи, с уверенностью и спокойствием.

ps. Команды проверьте на очепятки-ашипки. EFIFAT можно делать FAT12,16,32
FAT12 и FAT16 для мелких носителей, FAT32 для дисков, но это не суть, все варианты рабочие, в релизах
FreeBSD by default для memstick делают FAT12, ну а как сделан /boot/boot1.efifat - можно посмотреть,
да так же:
# file /boot/boot1.efifat
/boot/boot1.efifat: DOS/MBR boot sector, code offset 0x3c+2, OEM-ID "BSD4.4 ", root entries 512, sectors 1575 (volumes <=32 MB) , sectors/FAT 5, sectors/track 63, heads 1, serial number 0x5b811818, label: "EFI ", FAT (12 bit), followed by FAT
#

pps. Аналошично делаю для Grub2 в Linux: GPT + UEFI, и кстати, Proxmox делает свой bare-metal installer - так же.

[kharkov_max]

Добрый день, господа...
Вернулся к данному вопросу, паралельно решил перескочить на SSD.

Выношу на обсуждение последовательность действий, поправьте если что ...
Новый SSD диск ada1, старый gmirror (ada0 и один диск отключил ada1, вместо него подкинул SSD)
Gmirror находится в состоянии DEGRADED

Код: Выделить всё

# Создаем разметку на диске
gpart create -s gpt ada1
# Создаем загрузочные efi раздел
gpart add -t efi -l efi-boot -s 2048k ada1
# Создаем раздел под систему и данные
gpart add -t freebsd-ufs -l freebsd-ufs -s 216GB ada1
# Создаем SWAP раздел
gpart add -t freebsd-swap -l swap ada1
# Заливаем загрузчик
dd if=/boot/boot1.efifat of=/dev/ada1p1
# Форматируем раздел
newfs /dev/ada1p2

# Монтируем диск к каталогу
mount -t ufs /dev/ada1p2 /del

# Включаем trim для SSD
tunefs -t enable /dev/ada1p2
# Отключаем журналирование в файловой системе.
tunefs -J disable /dev/ada1p2
# Отключаем soft update.
tunefs -n disable /dev/ada1p2
# Отключаем soft update journaling.
tunefs -j disable /dev/ada1p2

# Проверка параметров раздела
tunefs -p /dev/ada1p2

sysctl kern.geom.debugflags=16

# Отмонтируем zfs pool, у меня есть такой ...
zpool export -f mypool

# Запускаем перенос всего от корня на новый смонтированный диск
cd / ; pax -p eme -X -rw . /del

# Корректируем fstab на новом диске
# Включаем в биосе uefi, и отключаем старый диск.
# Пытаемся грузится ....

# Включаем SWAP на новом диске
swapon /dev/ada1p3

[kharkov_max]

Таки да, план был верен, все взлетело, на удивление после первого ребута ...

Отправлено спустя 43 минуты 26 секунд:
Вылезло еще пару вопросов, в принципе не поэтой теме, но что бы не плодить тем напишу сюда.

Я выключил для раздела данных на SSD

Код: Выделить всё

# Отключаем журналирование в файловой системе.
tunefs -J disable /dev/ada1p2
# Отключаем soft update.
tunefs -n disable /dev/ada1p2
# Отключаем soft update journaling.
tunefs -j disable /dev/ada1p2

1. На сколько это правильно и актуально на данный момент ?
Я так понимаю что в критических ситуациях включенные опции могут както помочь ...

2. Может у кого есть более свежие / новые советы по увеличению срока жизни SSD, не хотелось бы получить через пол года труп..
Freebsd11 Stable, SSD из новых серий KINGSTON SUV400S37240G

[guest]

Таки да, план был верен, все взлетело, на удивление после первого ребута ...

Отправлено спустя 43 минуты 26 секунд:
Вылезло еще пару вопросов, в принципе не поэтой теме, но что бы не плодить тем напишу сюда.

Я выключил для раздела данных на SSD

Код: Выделить всё

# Отключаем журналирование в файловой системе.
tunefs -J disable /dev/ada1p2
# Отключаем soft update.
tunefs -n disable /dev/ada1p2
# Отключаем soft update journaling.
tunefs -j disable /dev/ada1p2

1. На сколько это правильно и актуально на данный момент ?
Я так понимаю что в критических ситуациях включенные опции могут както помочь ...

2. Может у кого есть более свежие / новые советы по увеличению срока жизни SSD, не хотелось бы получить через пол года труп..
Freebsd11 Stable, SSD из новых серий KINGSTON SUV400S37240G

tunefs -J disable - отключение gjournal, который не имеет отношения к журналированию UFS2 (опция -j)
gjournal - журналирование на уровне GEOM, клевое - не зависит от FS, но до жути медленное, ХЗ кто его использует...

SUJ [SU/SoftUpdates + UFS2 Journaling] == -n enable + -j enable ничего плохого с SSD не сделают, вопрос нужны ли
они на SSD?
Если Вы планируете БЫСТРУЮ ЗАГРУЗКУ - быструю отрабтку fsck во время загрузки, НЕ ПРИНУДИТЕЛЬНУЮ (наличие UPS),
тогда нужны.
А вот TRIM для UFS, если SSD поддерживает - обязательно:

# tunefs -t enable

Срок жизни в реалии у SSD - ничуть не хуже чем у HDD, поменьше слушайте болтовню и больше читайте
и изучайте, найдите материалы GOOGLя по анализу SSD, вроде как я здесь которотко писал про SSD.

Если SSD пришел не "бракованный" (с умирающими банками) и не с кривым firmware, жить будет долго,
это личный опыт и выводы анализа GOOGL по использованию и сроку жизни SSD.

Советую использовать Intel SSD серии DC: S3500/S3600/S3610 для обычных целей и не сильно нагруженных ZFS Storage,
и DC 3700/3710 для нагруженных.
Можно посмотреть в сторону модельного ряда Intel SSD Pro и подобрать что-то типа 535, 540, что интересно,
нашел несколько магазинов в Москве где можно взять: Intel 320/710
Есть достойные продукты у Samsung, Crucial...

[kharkov_max]

Продолжу спрашивать..

Собственно что делает trim, как я это понял.
При перезаписи ячейки памяти диска, trim помечает текущую ячейку как не использованную (контроллер диска планирует ее на очистку) и информация пишется в другую свободную ячейку, а потом, когда нагрузка на диск падает, к примеру идет только чтение а записи нет, контроллер диска ячейки помеченные trim высвобождает / очищает.

Таким образом происходит более менее равномерный процесс записи по ячейкам диска, что увеличивает его жизнь.

Читал по данной теме и нашел информацию, то при разметке SSD желательно оставлять порядка 10% диска не размеченным, собственно это необходимо для того самого trim.
Как я понял, когда на диск будет забит более чем на 90%, может создаться ситуация когда для выполнения того самого trim при записи не будет свободных ячеек (контроллер еще не успел очистить идет активный процесс записи...), диск начнет тупить, упадет скорость, т.е. контроллер начнет чистить ячейки т.к. нет свободных, а потом в них пойдет запись.
А если будут забронированны 10%, то свободные ячейки будут гарантированно зарезервированны и подобной ситуации с записью не возникнет ...

Может кто то выскажет свое мнение по данному поводу?
Имеет ли смысл оставить те самые 10% не размеченными?
Или все это баян ...

[pimlab]

Имеет ли смысл оставить те самые 10% не размеченными?

честно говоря понятия не имею как это работает, но откуда железка узнает что 10% не размечено?

Отправлено спустя 8 минут 50 секунд:
кстати мне так и не получилось загрузить уефи , если был ефи последним разделом... гугл особо не прояснил этот вопрос ... пришлось сломать разметку

[guest]

Имеет ли смысл оставить те самые 10% не размеченными?

честно говоря понятия не имею как это работает, но откуда железка узнает что 10% не размечено?

+ за красивый и толковый ответ

если хочется оставить 10% - их можно оставить неразмеченными в partition table, только
это явная шняга, железке фиолетово что на каких банках памяти: pmbr, gpt table, esp, рабочие партиции
или свободное место.

Отправлено спустя 8 минут 50 секунд:
кстати мне так и не получилось загрузить уефи , если был ефи последним разделом... гугл особо не прояснил этот вопрос ... пришлось сломать разметку

ESP должна находиться в пределах 2TB от начала диска, если память не изменяет, те в стандарте нет
о том что обязательно в начале, UEFI ищет ее на диске, и ей фиолетово где она, а вот как написан
загрузчик efi в той или иной ОС - это вопрос. Который можно проверить.

[kharkov_max]

pimlab,

честно говоря понятия не имею как это работает, но откуда железка узнает что 10% не размечено?

Вот в том то и дело, что контроллер диска по идее использует ячейки всего SSD, и ему фиалетово на партиции.
В том то и теория, если к примеру заранее обрезать SSD 50%, то диск проживет в 2 раза дольше (в разрезе заблокированных ячеек, уже не перезаписываемых), как то так....

[pimlab]

ESP должна находиться в пределах 2TB от начала диска, если память не изменяет, те в стандарте нет
о том что обязательно в начале, UEFI ищет ее на диске, и ей фиолетово где она, а вот как написан
загрузчик efi в той или иной ОС - это вопрос. Который можно проверить.

диски были 3тб, уефи просто не находило раздел с ефи.
Сейчас конечно не актуально, так как все работает и такое не повторится.
Весьма интересно узнать как ефи работает применительно к фреебсд. допустим на диске разделов с UFS не один или два. Так как ефи будет искать ядро в разныx разделаx или чего оно там грузит? Заглядывая в каждый начиная с первого или как?

Отправлено спустя 7 минут 34 секунды:
Также мне интересно, как себя поведет такая связка, как в существующий раздел HDD гмиррор добавить для скорости раздел с ССД?

[guest]

pimlab,

честно говоря понятия не имею как это работает, но откуда железка узнает что 10% не размечено?

Вот в том то и дело, что контроллер диска по идее использует ячейки всего SSD, и ему фиалетово на партиции.
В том то и теория, если к примеру заранее обрезать SSD 50%, то диск проживет в 2 раза дольше (в разрезе заблокированных ячеек, уже не перезаписываемых), как то так....

бррр

странная теория... По ней, нельзя покупать SSD больших емкостей ))

Если SSD обрезать на 50% - то имеем просто мат.вероятность...

ps. Sorry, hardware часть SSD не разбирал - какие там алгоритмы работы и тд и тп. Ибо там сейчас наворотили разных
технологий и использования той или иной памяти для банков...

pps. Sorry, в одном письме сразу: использовать gmirror с SSD? На кой если есть ZFS mirror - который может меньше напрягать
физическое устройство по своей архитектуре? gmirror на 1xSSD и 1xHDD - на кой?
Mirror по большому счету - фуфло, проще иметь рабочую SSD 40/56GB для системы (в России хрен купишь),
или 100/120GB и одну-две таких в резерве.

[kharkov_max]

День добрый.
Делаю следующий шаг, пытаюсь из 2х SSD создать GMIRROR
На SSD ada0 стоит рабочая система, такой же SSD ada1 пустой.

Делаю так:

Код: Выделить всё

gmirror label -v -b round-robin gm0 /dev/ada1
gpart backup ada0 > /home/part.txt
gpart restore mirror/gm0 < /home/part.txt

gpart bootcode -b /boot/boot1 mirror/gm0
gpart bootcode -p /boot/gptboot -i 1 mirror/gm0

newfs -U /dev/mirror/gm0p2

# Включаем trim для SSD
tunefs -t enable /dev/mirror/gm0p2

mount /dev/mirror/gm0p2 /mnt
sysctl kern.geom.debugflags=16

cd / ; pax -p eme -X -rw . /mnt

# изменяем fstab

umount /dev/mirror/gm0p2
reboot

После перезагрузки и переключения на нужный диск пишет что нет загрузчика.
Я сильно сомневаюсь в следующем коде:

Код: Выделить всё

gpart bootcode -b /boot/boot1 mirror/gm0
gpart bootcode -p /boot/gptboot -i 1 mirror/gm0

Можете разъяснить как верно прописать загрузчик под gmirror на GPT и EFI ?

[snorlov]

Нафиг вы сразу зеркало создаете, разбейте первый диск, таблицу перенесите на второй, запишите загрузчики на оба и создавайте зеркало...

[kharkov_max]

Первый диск уже разбит и на нем работает система, а второй чистый.
Тупо создать gmirror на первом, а потом добавить второй (как я делал раньше) не получается, видимо потому что GPT, а не как раньше MBR.
Поэтому делаю как советует google, сначала на чистом диске создаю партиции, потом зеркало, записываю загрузчик и на него переношу данные, а после того как загружусь на зеркале, добавлю в gmirror первый диск.

[snorlov]

Загрузчик пишется на зеркало, если вы его создали в начальный момент, т.е. загрузились бы с сд(юсб), создали зеркало, затем gpt ну и т.д. А если система уже стоит и очень хочется ее зазеркалировать, то вигвам, т.е. загрузчик надо писать прямо на диск, а не на зеркало...

[kharkov_max]

Правильно ли я понимаю что в данной ситуации у меня уже не получится создать зеркало gmirror ?

[snorlov]

Правильно ли я понимаю что в данной ситуации у меня уже не получится создать зеркало gmirror ?

Если вы имеете в виду диск, то да нельзя, а вот на раздел в нем пожалуйста...

[guest]

Первый диск уже разбит и на нем работает система, а второй чистый.
Тупо создать gmirror на первом, а потом добавить второй (как я делал раньше) не получается, видимо потому что GPT, а не как раньше MBR.
Поэтому делаю как советует google, сначала на чистом диске создаю партиции, потом зеркало, записываю загрузчик и на него переношу данные, а после того как загружусь на зеркале, добавлю в gmirror первый диск.

Здесь у основной массы видимо ПРИНЯТО не изучать документацию и систему...

- Где создаются метаданные при использовании GEOM?
- В последнем секторе провайдера.

# man geom
# man gmirror

- Что характерно для GPT?
- Наличие альтернативной таблицы в ПОСЛЕДНИХ 33'ех секторах.

- Что будет при создании gmirror для СЫРОГО ДИСКА (adaX или daY)?
- Запись метаданных в последний сектор чего? провайдера. Что является провайдером в случае gmirror FULL-DISK?
диск adaX или daY.
- Что будет с последним сектором на adaX или daY и что там в случае уже размеченного диска по схеме GPT?
- один из альтернативных секторов GPT и при gmirror [adaX|daY] - geom заптрет один из секторов ALT-GPT своими
метаданными

- Что будет после создания gmirror [adaX|daY] и перезагрузки?
- GEOM будет производить проверку соответствия MAIN и ALT копий GPT и тут наступит ...

Этой истории - сто лет в обед, Елсуков исправил проверку, можно жить без альтернативной копии и делать gmirror целого
диска, но для этого, нужно (два варианта на выбор):
1) соответствующим образом ПРИГОТОВИТЬ gmirror для целого диска:
http://bu7cher.blogspot.ru/2011/03/free ... t-ufs.html
или
2) использовать gmirror для gpt-партиций:
http://www.wonkity.com/~wblock/docs/html/gmirror.html

прим: Тратить SSD на gmirror... Я Вас умоляю...

Если у Вас уже стоит система, к примеру на ada0 (gpt), делается так:

- создается зеркало из одного диска, ВТОРОГО (ada1)
a) зачищаем ada1 от всего
# kldload gmirror
# gpart destroy -F ada1
# gmirror clear ada1
# zpool labelclear -f ada1

b) создаем зеркало geom

# gmirror label -v -n -b [load|prefer|round-robin] [gm0|имя] ada1

получили geom зеркало gm0 ну или как Вы назовете (какое имя будете использовать в верхней команде)

# ls -la /dev/mirror/gm0

- вот ЕГО и нужно размечать gpart

# gpart create -s GPT /dev/mirror/gm0

размечаете так же как и Ваш ada0 (только gm0 будет на один сектор меньше)

важное: не забываем про TRIM в newfs для /dev/mirror/gm0pX (этого тоже не пробовал, не делал gmirror на SSD)

далее на выбор dump/restore или pax или rsync с ada0[pX] на gm0[pX]

- правите fstab на gm0 и загрузку делаете с него или с ESP уже на нем

- перезагружаетесь и добавляете ada0 в gmirror

Все (и да, все это проделано с BIOS/GPT, с UEFI не пробовал - так что виртуальный стенд в руки и вперед)