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:
- FreeBSD Manual Pages: GPART(8)
- FreeBSD Manual Pages: ZPOOL(8)
- The FreeBSD Forums: [Solved] ZFS expandsize?
- Stephen Foskett, Pack Rat: Add a Mirror to an Existing ZFS Drive
- The FreeBSD Forums: Clone a zfs disk
- The FreeBSD Forums: New SSD, best way to move OS from old disk to new one?
- The FreeBSD Forums: How to clear the swap?
- Installing FreeBSD Root on ZFS using GPT
- The FreeBSD Forums: Labelling existing partitions with glabel
Dodaj komentarz