Instalacja FreeBSD na macierzy RAID zarządzanej przez ZFS

Instalacja:

Załóżmy, że mamy maszynę bez obsługi RAID. Albo z jakiegoś powodu nie chcemy z tego korzystać. W takiej sytuacji można zainstalować system i w trakcie instalacji skonfigurować odpowiednią macierz RAID:

Można wybrać mirror albo jeden z trybów raidz:

Po zrobieniu powyższych zrzutów ekranu postawnowiłem jednak przetestować raidz1 i kolejne informacje trochę nie pasują do powyższych ekranów. Nie zmienia to sposobu działania całości i użyteczności poniższych opisów.

Po instalacji sytuacja przedstawia się następująco:

# zpool status
  pool: zroot
 state: ONLINE
config:

        NAME        STATE     READ WRITE CKSUM
        zroot       ONLINE       0     0     0
          raidz1-0  ONLINE       0     0     0
            ada0p3  ONLINE       0     0     0
            ada1p3  ONLINE       0     0     0
            ada2p3  ONLINE       0     0     0

errors: No known data errors
# gpart show
=>       40  335544240  ada0  GPT  (160G)
         40       1024     1  freebsd-boot  (512K)
       1064        984        - free -  (492K)
       2048   33554432     2  freebsd-swap  (16G)
   33556480  301985792     3  freebsd-zfs  (144G)
  335542272       2008        - free -  (1.0M)

=>       40  335544240  ada1  GPT  (160G)
         40       1024     1  freebsd-boot  (512K)
       1064        984        - free -  (492K)
       2048   33554432     2  freebsd-swap  (16G)
   33556480  301985792     3  freebsd-zfs  (144G)
  335542272       2008        - free -  (1.0M)

=>       40  335544240  ada2  GPT  (160G)
         40       1024     1  freebsd-boot  (512K)
       1064        984        - free -  (492K)
       2048   33554432     2  freebsd-swap  (16G)
   33556480  301985792     3  freebsd-zfs  (144G)
  335542272       2008        - free -  (1.0M)

# gpart show -l
=>       40  335544240  ada0  GPT  (160G)
         40       1024     1  gptboot0  (512K)
       1064        984        - free -  (492K)
       2048   33554432     2  swap0  (16G)
   33556480  301985792     3  zfs0  (144G)
  335542272       2008        - free -  (1.0M)

=>       40  335544240  ada1  GPT  (160G)
         40       1024     1  gptboot1  (512K)
       1064        984        - free -  (492K)
       2048   33554432     2  swap1  (16G)
   33556480  301985792     3  zfs1  (144G)
  335542272       2008        - free -  (1.0M)

=>       40  335544240  ada2  GPT  (160G)
         40       1024     1  gptboot2  (512K)
       1064        984        - free -  (492K)
       2048   33554432     2  swap2  (16G)
   33556480  301985792     3  zfs2  (144G)
  335542272       2008        - free -  (1.0M)

# swapinfo
Device          1K-blocks     Used    Avail Capacity
/dev/ada0p2      16777216        0 16777216     0%
/dev/ada1p2      16777216        0 16777216     0%
/dev/ada2p2      16777216        0 16777216     0%
Total            50331648        0 50331648     0%

Z powyższego należy odnotować, że:

  • na wszystkich 3 dyskach utworzono partycję freebsd-boot i można uruchomić system startując z dowolnego z nich;
  • przestrzeń wymiany w tym przypadku składa się z 3 partycji freebsd-swap (razem 48G);
  • system plików umieszczony jest na puli zroot rozłożonej pomiędzy 3 partycje freebsd-zfs.

Odłaczamy dysk, który figurował jako ada0 i restartujemy system. Uruchamia się a macierz jest w trybie DEGRADED:

# zpool status
  pool: zroot
 state: DEGRADED
status: One or more devices could not be used because the label is missing or
        invalid.  Sufficient replicas exist for the pool to continue
        functioning in a degraded state.
action: Replace the device using 'zpool replace'.
   see: https://openzfs.github.io/openzfs-docs/msg/ZFS-8000-4J
config:

        NAME        STATE     READ WRITE CKSUM
        zroot       DEGRADED     0     0     0
          raidz1-0  DEGRADED     0     0     0
            ada0p3  FAULTED      0     0     0  corrupted data
            ada0p3  ONLINE       0     0     0
            ada1p3  ONLINE       0     0     0

errors: No known data errors

Podłączamy dysk z powrotem i macierz automatycznie się naprawia:

# zpool status
  pool: zroot
 state: ONLINE
  scan: resilvered 920K in 00:00:01 with 0 errors on Tue Sep  5 19:32:33 2023
config:

        NAME        STATE     READ WRITE CKSUM
        zroot       ONLINE       0     0     0
          raidz1-0  ONLINE       0     0     0
            ada0p3  ONLINE       0     0     0
            ada1p3  ONLINE       0     0     0
            ada2p3  ONLINE       0     0     0

errors: No known data errors

Bardziej interesujące jest pewnie podłączenie nowego dysku zamiast uszkodzonego, co zostało opisane poniżej w Problemie 2.

Problem 1: FreeBSD zostało zainstalowane na pojedynczym dysku z systemem plików ZFS i chcemy stworzyć macierz RAID 1 (mirror).

Aktualnie w systemie jest aktywny jeden dysk:

# gpart show -l                                                                     
=>       40  335544240  ada0  GPT  (160G)
         40       1024     1  gptboot0  (512K)
       1064        984        - free -  (492K)
       2048   33554432     2  swap0  (16G)
   33556480  301985792     3  zfs0  (144G)
  335542272       2008        - free -  (1.0M)

Mój opis powstał już po testach z RAIDem w trybie mirror w wyniku czego mam nazwy (gpt label) z numerem 0. Nazwy partycji nie powinny się powtarzać na dyskach i można je zmienić następująco:

# gpart modify -i 1 -l gptboot0 ada0
# gpart modify -i 2 -l swap0 ada0
# gpart modify -i 3 -l zfs0 ada0

Ale do maszyny podłączono kolejny dysk:

# dmesg | grep ada                                                         
ada0 at ahcich0 bus 0 scbus2 target 0 lun 0
ada0: <VBOX HARDDISK 1.0> ATA-6 SATA 2.x device
ada0: Serial Number VB50c7ccb9-7fcb925b
ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes)
ada0: Command Queueing enabled
ada0: 163840MB (335544320 512 byte sectors)
ada1 at ahcich1 bus 0 scbus3 target 0 lun 0
ada1: <VBOX HARDDISK 1.0> ATA-6 SATA 2.x device
ada1: Serial Number VB10ec6440-290449b1
ada1: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes)
ada1: Command Queueing enabled
ada1: 163840MB (335544320 512 byte sectors)

Najpierw utworzymy na nim partycje, na bazie istniejącego dysku:

# gpart backup ada0 > ada0.backup
# cp ada0.backup ada1.backup
# edit ada1.backup
# cat ada1.backup
GPT 128
1   freebsd-boot        40      1024 gptboot1
2   freebsd-swap      2048  33554432 swap1
3    freebsd-zfs  33556480 301985792 zfs1
# gpart restore -l ada1 < ada1.backup
root@zfs-raid-test:/home/marcinkk # gpart show -l
=>       40  335544240  ada0  GPT  (160G)
         40       1024     1  gptboot0  (512K)
       1064        984        - free -  (492K)
       2048   33554432     2  swap0  (16G)
   33556480  301985792     3  zfs0  (144G)
  335542272       2008        - free -  (1.0M)

=>       40  335544240  ada1  GPT  (160G)
         40       1024     1  gptboot1  (512K)
       1064        984        - free -  (492K)
       2048   33554432     2  swap1  (16G)
   33556480  301985792     3  zfs1  (144G)
  335542272       2008        - free -  (1.0M)

W tym momencie mamy dysk podzielony na partycje, ale nic na nim nie ma. W trakcie zostały zmienione nazwy (gpt label) partycji, aby były różne na dyskach – przy tworzeniu macierzy podczas instalacji dzieje się to samo.

Tworzymy mirror w ramach macierzy ZFS:

# zpool status
  pool: zroot
 state: ONLINE
  scan: none requested
config:

        NAME          STATE     READ WRITE CKSUM
        zroot         ONLINE       0     0     0
          ada0p3      ONLINE       0     0     0

errors: No known data errors
# zpool attach zroot ada0p3 ada1p3
# zpool status
  pool: zroot
 state: ONLINE
status: One or more devices is currently being resilvered.  The pool will
        continue to function, possibly in a degraded state.
action: Wait for the resilver to complete.
  scan: resilver in progress since Tue Sep  5 14:38:23 2023
        765M scanned at 84.9M/s, 228K issued at 25.3K/s, 3.42G total
        0B resilvered, 0.01% done, no estimated completion time
config:

        NAME          STATE     READ WRITE CKSUM
        zroot         ONLINE       0     0     0
          mirror-0    ONLINE       0     0     0
            ada0p3    ONLINE       0     0     0
            ada1p3    ONLINE       0     0     0

errors: No known data errors

Jak widać rozpoczął się proces kopiowania danych na drugi dysk (resilver). Po zakończeniu zobaczymy:

# zpool status
  pool: zroot
 state: ONLINE
  scan: resilvered 3.69G in 00:04:02 with 0 errors on Tue Sep  5 14:42:25 2023
config:

        NAME          STATE     READ WRITE CKSUM
        zroot         ONLINE       0     0     0
          mirror-0    ONLINE       0     0     0
            ada0p3    ONLINE       0     0     0
            ada1p3    ONLINE       0     0     0

errors: No known data errors

Operacja ta dotyczy tylko ZFSa. A co będzie jeżeli awaria będzie dotyczyła dysku ada0, z którego aktualnie wystartował system?

# gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ada1
partcode written to ada1p1
bootcode written to ada1

Można też inaczej:

# gpart bootcode -b /boot/pmbr ada1
bootcode written to ada1
# dd if=/dev/ada0p1 of=/dev/ada1p1
1024+0 records in
1024+0 records out
524288 bytes transferred in 24.306828 secs (21570 bytes/sec)

Jak chodzi o partycję wymiany (swap), to aktywuje się po restarcie systemu. Ale możemy zadziałać od razu:

# swapinfo
Device          1K-blocks     Used    Avail Capacity
/dev/ada0p2      16777216        0 16777216     0%
# swapoff -a
swapoff: removing /dev/ada0p2 as swap device
# swapon -a
swapon: adding /dev/ada0p2 as swap device
swapon: adding /dev/ada1p2 as swap device
# swapinfo
Device          1K-blocks     Used    Avail Capacity
/dev/ada0p2      16777216        0 16777216     0%
/dev/ada1p2      16777216        0 16777216     0%
Total            33554432        0 33554432     0%

Odłączamy pierwszy dysk i restartujemy system. Startuje bez problemu

# zpool status
  pool: zroot
 state: DEGRADED
status: One or more devices could not be used because the label is missing or
        invalid.  Sufficient replicas exist for the pool to continue
        functioning in a degraded state.
action: Replace the device using 'zpool replace'.
   see: https://openzfs.github.io/openzfs-docs/msg/ZFS-8000-4J
  scan: resilvered 3.69G in 00:04:02 with 0 errors on Tue Sep  5 14:42:25 2023
config:

        NAME          STATE     READ WRITE CKSUM
        zroot         DEGRADED     0     0     0
          mirror-0    DEGRADED     0     0     0
            ada0p3    FAULTED      0     0     0  corrupted data
            ada0p3    ONLINE       0     0     0

Problem 2: Padł jeden z dysków w macierzy i podłączamy nowy w miejsce uszkodzonego.

Sytuacja początkowa jest taka jak pokazano na ostatnim zrzucie ekranu powyżej, czyli macierz jest w stanie DEGRADED. Dodatkowo mamy podłączony dysk:

# gpart show -l
=>       40  335544240  ada0  GPT  (160G)
         40       1024     1  gptboot1  (512K)
       1064        984        - free -  (492K)
       2048   33554432     2  swap1  (16G)
   33556480  301985792     3  zfs1  (144G)
  335542272       2008        - free -  (1.0M)

# dmesg | grep ada
ada0 at ahcich0 bus 0 scbus2 target 0 lun 0
ada0: <VBOX HARDDISK 1.0> ATA-6 SATA 2.x device
ada0: Serial Number VB10ec6440-290449b1
ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes)
ada0: Command Queueing enabled
ada0: 163840MB (335544320 512 byte sectors)
ada1 at ahcich1 bus 0 scbus3 target 0 lun 0
ada1: <VBOX HARDDISK 1.0> ATA-6 SATA 2.x device
ada1: Serial Number VB396cc14c-efd0019d
ada1: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes)
ada1: Command Queueing enabled
ada1: 163840MB (335544320 512 byte sectors)

Mamy trochę zamieszania w nazwach dysków, bo „padł” dysk 0 więc dysk 1 został podłączony do kanału 0 (można zmienić sekwencję startową) a nowy do kanału 1. Po zakończeniu można przełączyć dyski. Odtwarzamy tablicę partycji na podstawie plików utworzonych przy opisie Problemu 1:

# gpart restore -l ada1 < ada0.backup
# gpart show -l
=>       40  335544240  ada0  GPT  (160G)
         40       1024     1  gptboot1  (512K)
       1064        984        - free -  (492K)
       2048   33554432     2  swap1  (16G)
   33556480  301985792     3  zfs1  (144G)
  335542272       2008        - free -  (1.0M)

=>       40  335544240  ada1  GPT  (160G)
         40       1024     1  gptboot0  (512K)
       1064        984        - free -  (492K)
       2048   33554432     2  swap0  (16G)
   33556480  301985792     3  zfs0  (144G)
  335542272       2008        - free -  (1.0M)

Zacznijmy od naprawy macierzy ZFS RAID. Ponieważ status pokazywał, że macierz składa się z dwóch ada0p3, to może warto je rozróżnić wyświetaljac GUIDs:

# zpool status -g
  pool: zroot
 state: DEGRADED
status: One or more devices could not be used because the label is missing or
        invalid.  Sufficient replicas exist for the pool to continue
        functioning in a degraded state.
action: Replace the device using 'zpool replace'.
   see: https://openzfs.github.io/openzfs-docs/msg/ZFS-8000-4J
  scan: resilvered 3.69G in 00:04:02 with 0 errors on Tue Sep  5 14:42:25 2023
config:

        NAME                      STATE     READ WRITE CKSUM
        zroot                     DEGRADED     0     0     0
          9494211164689973071     DEGRADED     0     0     0
            11762694215069195788  FAULTED      0     0     0  corrupted data
            1316388257020887904   ONLINE       0     0     0

errors: No known data errors
# zpool replace zroot 11762694215069195788 ada1p3
# zpool status
  pool: zroot
 state: DEGRADED
status: One or more devices is currently being resilvered.  The pool will
        continue to function, possibly in a degraded state.
action: Wait for the resilver to complete.
  scan: resilver in progress since Tue Sep  5 15:17:53 2023
        1.21G scanned at 77.3M/s, 316K issued at 19.8K/s, 3.42G total
        0B resilvered, 0.01% done, no estimated completion time
config:

        NAME             STATE     READ WRITE CKSUM
        zroot            DEGRADED     0     0     0
          mirror-0       DEGRADED     0     0     0
            replacing-0  DEGRADED     0     0     0
              ada0p3     FAULTED      0     0     0  corrupted data
              ada1p3     ONLINE       0     0     0
            ada0p3       ONLINE       0     0     0

errors: No known data errors

Po zakończeniu:

# zpool status
  pool: zroot
 state: ONLINE
  scan: resilvered 3.69G in 00:03:54 with 0 errors on Tue Sep  5 15:21:47 2023
config:

        NAME          STATE     READ WRITE CKSUM
        zroot         ONLINE       0     0     0
          mirror-0    ONLINE       0     0     0
            ada1p3    ONLINE       0     0     0
            ada0p3    ONLINE       0     0     0

errors: No known data errors

Można przepiąć kable dysków i będzie już po kolei. Dodatkowo tym razem swap nie był konfigurowany w trakcie pracy i jak widać obydwie partycje zostały podłączone po restarcie:

# zpool status
  pool: zroot
 state: ONLINE
  scan: resilvered 3.69G in 00:03:54 with 0 errors on Tue Sep  5 15:21:47 2023
config:

        NAME          STATE     READ WRITE CKSUM
        zroot         ONLINE       0     0     0
          mirror-0    ONLINE       0     0     0
            ada0p3    ONLINE       0     0     0
            ada1p3    ONLINE       0     0     0

errors: No known data errors
# swapinfo
Device          1K-blocks     Used    Avail Capacity
/dev/ada0p2      16777216        0 16777216     0%
/dev/ada1p2      16777216        0 16777216     0%
Total            33554432        0 33554432     0%

Problem 3: Podmieniamy dyski na większe i chcemy aby zasób zroot zajmował całą dostępną przestrzeń.

Ogólnie należy wykonać procedurę jak w opisie Problemu 2. Pomijajac komunikaty na ekranie i zakładając, że jako pierwszy podmieniamy dysk podłączony do kanału 1 procedura zaczyna się nastepująco:

# gpart restore -l ada1 < ada1.backup
# zpool replace zroot ada1p3 ada1p3
# gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ada1
# shutdown -p now
# gpart restore -l ada1 < ada0.backup
# zpool status -g
  pool: zroot
 state: DEGRADED
status: One or more devices could not be used because the label is missing or
        invalid.  Sufficient replicas exist for the pool to continue
        functioning in a degraded state.
action: Replace the device using 'zpool replace'.
   see: https://openzfs.github.io/openzfs-docs/msg/ZFS-8000-4J
  scan: resilvered 3.69G in 00:03:51 with 0 errors on Tue Sep  5 15:42:29 2023
config:

        NAME                      STATE     READ WRITE CKSUM
        zroot                     DEGRADED     0     0     0
          9494211164689973071     DEGRADED     0     0     0
            5649427590071053008   FAULTED      0     0     0  corrupted data
            14505667721022648959  ONLINE       0     0     0

errors: No known data errors
# zpool replace zroot 5649427590071053008 ada1p3
# gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ada1

Po przełączeniu dysków status jest następujący:

# zpool status
  pool: zroot
 state: ONLINE
  scan: resilvered 3.69G in 00:03:48 with 0 errors on Tue Sep  5 16:13:37 2023
config:

        NAME          STATE     READ WRITE CKSUM
        zroot         ONLINE       0     0     0
          mirror-0    ONLINE       0     0     0
            ada0p3    ONLINE       0     0     0
            ada1p3    ONLINE       0     0     0

errors: No known data errors
root@zfs-raid-test:/home/marcinkk # gpart show -l
=>       40  671088560  ada0  GPT  (320G)
         40       1024     1  gptboot0  (512K)
       1064        984        - free -  (492K)
       2048   33554432     2  swap0  (16G)
   33556480  301985792     3  zfs0  (144G)
  335542272  335546328        - free -  (160G)

=>       40  671088560  ada1  GPT  (320G)
         40       1024     1  gptboot1  (512K)
       1064        984        - free -  (492K)
       2048   33554432     2  swap1  (16G)
   33556480  301985792     3  zfs1  (144G)
  335542272  335546328        - free -  (160G)

# gpart show
=>       40  671088560  ada0  GPT  (320G)
         40       1024     1  freebsd-boot  (512K)
       1064        984        - free -  (492K)
       2048   33554432     2  freebsd-swap  (16G)
   33556480  301985792     3  freebsd-zfs  (144G)
  335542272  335546328        - free -  (160G)

=>       40  671088560  ada1  GPT  (320G)
         40       1024     1  freebsd-boot  (512K)
       1064        984        - free -  (492K)
       2048   33554432     2  freebsd-swap  (16G)
   33556480  301985792     3  freebsd-zfs  (144G)
  335542272  335546328        - free -  (160G)

Czyli mamy dwa dyski na których jest 160G wolnego. Trzeba powiększyć partycję z ZFSem:

# gpart resize -i 3 ada0
ada0p3 resized
root@zfs-raid-test:/home/marcinkk # gpart resize -i 3 ada1
ada1p3 resized
root@zfs-raid-test:/home/marcinkk # gpart show -l
=>       40  671088560  ada0  GPT  (320G)
         40       1024     1  gptboot0  (512K)
       1064        984        - free -  (492K)
       2048   33554432     2  swap0  (16G)
   33556480  637532120     3  zfs0  (304G)

=>       40  671088560  ada1  GPT  (320G)
         40       1024     1  gptboot1  (512K)
       1064        984        - free -  (492K)
       2048   33554432     2  swap1  (16G)
   33556480  637532120     3  zfs1  (304G)

To nie zwiększa rozmiary puli zroot:

# zpool list
NAME    SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP    HEALTH  ALTROOT
zroot   143G  3.42G   140G        -         -     0%     2%  1.00x    ONLINE  -

Za powiększanie puli do obszaru wolnej przestrzeni odpowiedzialny jest parametr autoexpand:

# zpool get autoexpand zroot
NAME   PROPERTY    VALUE   SOURCE
zroot  autoexpand  off     default
# zpool set autoexpand=on zroot
# zpool online -e zroot ada0p3 ada1p3

I ostatecznie otrzymujemy oczekiwany rezultat:

# zpool list
NAME    SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP    HEALTH  ALTROOT
zroot   303G  3.42G   300G        -         -     0%     1%  1.00x    ONLINE  -

Podsumowanie:

Powyższy opis powstał aby pokazać, że instalując FreeBSD na systemie plików ZFS można nawet na komputerze bez sprzętowej obsługi macierzy RAID. Instalator tworzy macierz na starcie a dyski partycjonuje w taki sposób, że dane uruchamiające (sektor startowy i partycja freebsd-boot) znajdują się na każdym z nich, więc z każdego można uruchomić system. To czy system uruchomi się poprawnie zależy tylko od tego, czy ilość dostępnych partycji freebsd-zfs jest wystarczająco dla danego typu macierzy.

A co kiedy komputer będzie korzystał z UEFI? Może kiedyś sprawdzę taki przypadek i dopiszę zestawy poleceń, które wymagają modyfikacji 🙂

Uzupełnienie:

No i przyszedł taki dzień kiedy zainstalowałem FreeBSD na macierzy RAID-1 zarządzanej przez ZFS. Problemy zauważyłem już w BIOSie bo mogłem wybrać EFI tylko z dysku 0. To zobaczmy jak to wygląda:

# gpart show -l
=>        40  1562824288  ada0  GPT  (745G)
          40      532480     1  efiboot0  (260M)
      532520        1024     2  gptboot0  (512K)
      533544         984        - free -  (492K)
      534528     8388608     3  swap0  (4.0G)
     8923136  1553899520     4  zfs0  (741G)
  1562822656        1672        - free -  (836K)

=>        40  1562824288  ada1  GPT  (745G)
          40      532480     1  efiboot1  (260M)
      532520        1024     2  gptboot1  (512K)
      533544         984        - free -  (492K)
      534528     8388608     3  swap1  (4.0G)
     8923136  1553899520     4  zfs1  (741G)
  1562822656        1672        - free -  (836K)

No niby wszystko ok, ale:

# file -s /dev/gpt/efiboot0
/dev/gpt/efiboot0: DOS/MBR boot sector, code offset 0x3c+2, OEM-ID "BSD4.4  ", sectors/cluster 32, root entries 512, sectors/FAT 65, sectors/track 63, heads 16, sectors 532480 (volumes > 32 MB), serial number 0x45bd12ff, unlabeled, FAT (16 bit)
# file -s /dev/gpt/efiboot1
/dev/gpt/efiboot1: data

Czyli na drugim dysku partycja EFI jest, ale nawet nie sformatowana. To lecimy dalej:

# newfs_msdos -F 16 /dev/gpt/efiboot1
/dev/gpt/efiboot1: 532288 sectors in 16634 FAT16 clusters (16384 bytes/cluster)
BytesPerSec=512 SecPerClust=32 ResSectors=1 FATs=2 RootDirEnts=512 Media=0xf0 FATsecs=65 SecPerTrack=63 Heads=16 HiddenSecs=0 HugeSectors=532480
# file -s /dev/gpt/efiboot1
/dev/gpt/efiboot1: DOS/MBR boot sector, code offset 0x3c+2, OEM-ID "BSD4.4  ", sectors/cluster 32, root entries 512, sectors/FAT 65, sectors/track 63, heads 16, sectors 532480 (volumes > 32 MB), serial number 0x7fb7170a, unlabeled, FAT (16 bit)

To już sformatowane i czas przekopiować dane:

# mkdir /mnt/efi1
# mount_msdosfs /dev/gpt/efiboot1 /mnt/efi1
# cp -R /boot/efi/* /mnt/efi1/
# efibootmgr --create --label "FreeBSD" --loader /mnt/efi1/efi/boot/bootx64.efi

Sprawdźmy jak to wygląda:

# efibootmgr -v
Boot to FW : false
BootCurrent: 0000
Timeout    : 1 seconds
BootOrder  : 0001, 0000
 Boot0001  FreeBSD HD(1,GPT,a717bd96-4391-11f0-896b-d45d64afabe8,0x28,0x82000)/File(\efi\boot\bootx64.efi)
                      gpt/efiboot0:/efi/boot/bootx64.efi /boot/efi//efi/boot/bootx64.efi
+Boot0000* FreeBSD HD(1,GPT,a747ecba-4391-11f0-896b-d45d64afabe8,0x28,0x82000)/File(\EFI\BOOT\BOOTX64.EFI)
                      ada1p1:/EFI/BOOT/BOOTX64.EFI (null)

To powyżej to wynik jeszcze kilku poleceń. Ogólnie działa, ale właściwie odwołanie do /efi/boot/bootx64.efi to odwołanie nazwane po instalacji UEFI OS (wykryte i dodane przez BIOS?). FreeBSD było (chyba, bo mi zniknęło) odwołaniem do pliku /efi/freebsd/loader.efi, który jest przy konfiguracji z jednym systemem operacyjnym na dysku dokładnie tym samym plikiem co /efi/boot/bootx64.efi. Jednak loader.efi to plik ładujący dodany przez FreeBSD, bootx64.efi może być plikiem z Windows, Ubuntu czy też z rEFInd.

Po co to wszystko? Powiedzmy, że dysk, który był ada0 padł. Mamy mirror, to trzeba jako wystartować … to na drugim dysku też powinna być partycja EFI i wszystkie pliki na niej (warto po aktualizacji systemu sprawdzić, czy pliki się nie zmieniły i czy nie trzeba zmodykidkować kopii). Co jeszcze, w sumie drobnostka: Kiedy odłaczymy ada0 i wystartujemy z jedynej kopii na ada1, to system nie uruchomi się, bo w fstabie jest odwołanie do /dev/gpt/gptboot0. Kiedy awaria już wystąpiła, to startujemy w single user mode (nie mamy innego wyjścia) i poprawiamy /etc/fstab. Tylko wcześniej trzeba wyłaczyć read only mode z partycji zroot:

# zfs readonly=off zroot/ROOT/default

Literatura:


Opublikowano

w

przez

Tagi:

Komentarze

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *