GELI-devices - kein automount mehr unter 11.2-RELEASE

[mr44er]

Das System ist ein frisch aufgesetztes 11.2-RELEASE
Seitdem klappt der automount von geli-devices nicht mehr wie es sollte.

Das Passwort für zroot und die anderen geli-devices ist gleich. (mehrfach vergewissert, keine Sonderzeichen) Beim Booten werde ich dann nach dem PW für da0 gefragt. Das tippe ich dann 1x erneut ein und da0-da7 werden dann attached und das System startet durch.
Vorher (11.1-RELEASE) brauchte ich es nur 1x am Anfang eintippen und zwar ohne Eintrag in der rc.conf. Mit dem Eintrag in der rc.conf ändert sich das Verhalten auch nicht.

boot_passcache ist zu meiner Verwunderung aktiviert...

sysctl -a | grep geom.eli
kern.features.geom_eli: 1
kern.geom.eli.key_cache_misses: 0
kern.geom.eli.key_cache_hits: 0
kern.geom.eli.key_cache_limit: 8192
kern.geom.eli.boot_passcache: 1
kern.geom.eli.batch: 0
kern.geom.eli.threads: 0
kern.geom.eli.overwrites: 5
kern.geom.eli.visible_passphrase: 0
kern.geom.eli.tries: 3
kern.geom.eli.debug: 0
kern.geom.eli.version: 7

...und das boot-flag auf den devs ebenfalls

geli list -a da0.eli
Geom name: da0.eli
State: ACTIVE
EncryptionAlgorithm: AES-XTS
KeyLength: 256
Crypto: hardware
Version: 7
UsedKey: 0
Flags: BOOT
KeysAllocated: 466
KeysTotal: 466
Providers:
1. Name: da0.eli
   Mediasize: 2000398929920 (1.8T)
   Sectorsize: 4096
   Mode: r1w1e2
Consumers:
1. Name: da0
   Mediasize: 2000398934016 (1.8T)
   Sectorsize: 512
   Stripesize: 4096
   Stripeoffset: 0
   Mode: r1w1e1

Hab ich einen Bug gefunden oder soll das so?

 

[mr44er]

root@aserver:/usr/home/mr44er # freebsd-version
11.2-RELEASE-p1

Problem besteht immer noch, gleiches PW auf allen Platten muss 2x eingegeben werden.
Die 2te PW-Anfrage verschwimmt wie von früher bekannt zwischen den Bootzeilen, direkt nachdem der Controller alle Platten weckt und abfragt.
Danach werden aber da0-da7 automatisch eingebunden.

Hat keine ne Idee oder nutzt das so wie ich?

 

[[KB]]

Hast Du in deiner loader.conf auch folgendes gesetzt?:

geom_eli_passphrase_prompt="YES"

Ich habe drei verschlüsselte Partionen und das PW muss ich nur einmal eingeben.
Und wie Du nun bereits weißt, bin ich nun auch mit 11.2 unterwegs ...

 

[mr44er]

Hast Du in deiner loader.conf auch folgendes gesetzt?:

geom_eli_passphrase_prompt="YES"

Nein, ich habe das 11.2 frisch installiert und mein Stand der Dinge ist, dass das bereits und 'nur' mit geom_eli_load="YES" abgedeckt ist.

Ich habs eben mal fix ausprobiert. Er fragt trotzdem 2x nach dem PW, aber die zweite Abfrage ist früher, direkt nachdem die 3 Bootplatten entschlüsselt wurden.

 

[mr44er]

https://github.com/HardenedBSD/hardenedBSD/issues/285

Rausnehmen hab ich auch mal probiert...dann ist das System logischerweise nicht mehr hochgefahren und ich musste frickeln.
Ich habs nun mal in den Kernel kompiliert und auskommentiert, aber das Verhalten ist immer noch so.

 

[[KB]]

Magst Du mal den Output von 'gpart show' hier reinstellen?

 

[mr44er]

Spoiler: gpart show+rest

root@aserver:/usr/home/mr44er # gpart show
=> 40 625142368 ada0 GPT (298G)
40 1024 1 freebsd-boot (512K)
1064 984 - free - (492K)
2048 67108864 2 freebsd-swap (32G)
67110912 558030848 3 freebsd-zfs (266G)
625141760 648 - free - (324K)

=> 40 625142368 ada1 GPT (298G)
40 1024 1 freebsd-boot (512K)
1064 984 - free - (492K)
2048 67108864 2 freebsd-swap (32G)
67110912 558030848 3 freebsd-zfs (266G)
625141760 648 - free - (324K)

=> 40 625142368 ada2 GPT (298G)
40 1024 1 freebsd-boot (512K)
1064 984 - free - (492K)
2048 67108864 2 freebsd-swap (32G)
67110912 558030848 3 freebsd-zfs (266G)
625141760 648 - free - (324K)

root@aserver:/usr/home/mr44er # camcontrol devlist
<HGST HUS726020AL5210 AD05> at scbus0 target 0 lun 0 (pass0,da0)
<HGST HUS726020AL5210 AD05> at scbus0 target 1 lun 0 (pass1,da1)
<HGST HUS726020AL5210 AD05> at scbus0 target 2 lun 0 (pass2,da2)
<HGST HUS726020AL5210 AD05> at scbus0 target 3 lun 0 (pass3,da3)
<HGST HUS726020AL5210 AD05> at scbus0 target 4 lun 0 (pass4,da4)
<HGST HUS726020AL5210 AD05> at scbus0 target 5 lun 0 (pass5,da5)
<HGST HUS726020AL5210 AD05> at scbus0 target 6 lun 0 (pass6,da6)
<HGST HUS726020AL5210 AD05> at scbus0 target 7 lun 0 (pass7,da7)
<HGST HTS545032A7E680 GRBOA3N0> at scbus1 target 0 lun 0 (ada0,pass8)
<HGST HTS545032A7E680 GRBOA3N0> at scbus2 target 0 lun 0 (ada1,pass9)
<HGST HTS545032A7E680 GRBOA3N0> at scbus3 target 0 lun 0 (ada2,pass10)
<SanDisk Cruzer Blade 1.26> at scbus7 target 0 lun 0 (pass11,da8)
root@aserver:/usr/home/mr44er # zpool status
pool: atank
state: ONLINE
scan: scrub canceled on Wed Aug 15 22:35:14 2018
config:

NAME STATE READ WRITE CKSUM
atank ONLINE 0 0 0
raidz3-0 ONLINE 0 0 0
label/K5GWGJVA-hd1 ONLINE 0 0 0
label/K5GWGN5A-hd2 ONLINE 0 0 0
label/K5GW31WA-hd3 ONLINE 0 0 0
label/N4G2N9AY-hd4 ONLINE 0 0 0
label/K5GWAZTA-hd5 ONLINE 0 0 0
label/N4G1XV1K-hd6 ONLINE 0 0 0
label/K5GW6SGA-hd7 ONLINE 0 0 0
label/K5GWGL2A-hd8 ONLINE 0 0 0
cache
label/sandisk4GB ONLINE 0 0 0

errors: No known data errors

pool: zroot
state: ONLINE
scan: none requested
config:

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

errors: No known data errors
root@aserver:/usr/home/mr44er # geli list
Geom name: da0.eli
State: ACTIVE
EncryptionAlgorithm: AES-XTS
KeyLength: 256
Crypto: hardware
Version: 7
UsedKey: 0
Flags: BOOT
KeysAllocated: 466
KeysTotal: 466
Providers:
1. Name: da0.eli
Mediasize: 2000398929920 (1.8T)
Sectorsize: 4096
Mode: r1w1e2
Consumers:
1. Name: da0
Mediasize: 2000398934016 (1.8T)
Sectorsize: 512
Stripesize: 4096
Stripeoffset: 0
Mode: r1w1e1

Geom name: da1.eli
State: ACTIVE
EncryptionAlgorithm: AES-XTS
KeyLength: 256
Crypto: hardware
Version: 7
UsedKey: 0
Flags: BOOT
KeysAllocated: 466
KeysTotal: 466
Providers:
1. Name: da1.eli
Mediasize: 2000398929920 (1.8T)
Sectorsize: 4096
Mode: r1w1e2
Consumers:
1. Name: da1
Mediasize: 2000398934016 (1.8T)
Sectorsize: 512
Stripesize: 4096
Stripeoffset: 0
Mode: r1w1e1

Geom name: da2.eli
State: ACTIVE
EncryptionAlgorithm: AES-XTS
KeyLength: 256
Crypto: hardware
Version: 7
UsedKey: 0
Flags: BOOT
KeysAllocated: 466
KeysTotal: 466
Providers:
1. Name: da2.eli
Mediasize: 2000398929920 (1.8T)
Sectorsize: 4096
Mode: r1w1e2
Consumers:
1. Name: da2
Mediasize: 2000398934016 (1.8T)
Sectorsize: 512
Stripesize: 4096
Stripeoffset: 0
Mode: r1w1e1

Geom name: da3.eli
State: ACTIVE
EncryptionAlgorithm: AES-XTS
KeyLength: 256
Crypto: hardware
Version: 7
UsedKey: 0
Flags: BOOT
KeysAllocated: 466
KeysTotal: 466
Providers:
1. Name: da3.eli
Mediasize: 2000398929920 (1.8T)
Sectorsize: 4096
Mode: r1w1e2
Consumers:
1. Name: da3
Mediasize: 2000398934016 (1.8T)
Sectorsize: 512
Stripesize: 4096
Stripeoffset: 0
Mode: r1w1e1

Geom name: da4.eli
State: ACTIVE
EncryptionAlgorithm: AES-XTS
KeyLength: 256
Crypto: hardware
Version: 7
UsedKey: 0
Flags: BOOT
KeysAllocated: 466
KeysTotal: 466
Providers:
1. Name: da4.eli
Mediasize: 2000398929920 (1.8T)
Sectorsize: 4096
Mode: r1w1e2
Consumers:
1. Name: da4
Mediasize: 2000398934016 (1.8T)
Sectorsize: 512
Stripesize: 4096
Stripeoffset: 0
Mode: r1w1e1

Geom name: da5.eli
State: ACTIVE
EncryptionAlgorithm: AES-XTS
KeyLength: 256
Crypto: hardware
Version: 7
UsedKey: 0
Flags: BOOT
KeysAllocated: 466
KeysTotal: 466
Providers:
1. Name: da5.eli
Mediasize: 2000398929920 (1.8T)
Sectorsize: 4096
Mode: r1w1e2
Consumers:
1. Name: da5
Mediasize: 2000398934016 (1.8T)
Sectorsize: 512
Stripesize: 4096
Stripeoffset: 0
Mode: r1w1e1

Geom name: da6.eli
State: ACTIVE
EncryptionAlgorithm: AES-XTS
KeyLength: 256
Crypto: hardware
Version: 7
UsedKey: 0
Flags: BOOT
KeysAllocated: 466
KeysTotal: 466
Providers:
1. Name: da6.eli
Mediasize: 2000398929920 (1.8T)
Sectorsize: 4096
Mode: r1w1e2
Consumers:
1. Name: da6
Mediasize: 2000398934016 (1.8T)
Sectorsize: 512
Stripesize: 4096
Stripeoffset: 0
Mode: r1w1e1

Geom name: da7.eli
State: ACTIVE
EncryptionAlgorithm: AES-XTS
KeyLength: 256
Crypto: hardware
Version: 7
UsedKey: 0
Flags: BOOT
KeysAllocated: 466
KeysTotal: 466
Providers:
1. Name: da7.eli
Mediasize: 2000398929920 (1.8T)
Sectorsize: 4096
Mode: r1w1e2
Consumers:
1. Name: da7
Mediasize: 2000398934016 (1.8T)
Sectorsize: 512
Stripesize: 4096
Stripeoffset: 0
Mode: r1w1e1

Geom name: da8.eli
State: ACTIVE
EncryptionAlgorithm: AES-XTS
KeyLength: 256
Crypto: hardware
Version: 7
UsedKey: 0
Flags: BOOT
KeysAllocated: 8
KeysTotal: 8
Providers:
1. Name: da8.eli
Mediasize: 4004511232 (3.7G)
Sectorsize: 512
Mode: r1w1e2
Consumers:
1. Name: da8
Mediasize: 4004511744 (3.7G)
Sectorsize: 512
Mode: r1w1e1

Geom name: ada0p3.eli
State: ACTIVE
EncryptionAlgorithm: AES-XTS
KeyLength: 256
Crypto: hardware
Version: 7
UsedKey: 0
Flags: BOOT, GELIBOOT
KeysAllocated: 67
KeysTotal: 67
Providers:
1. Name: ada0p3.eli
Mediasize: 285711790080 (266G)
Sectorsize: 4096
Mode: r1w1e1
Consumers:
1. Name: ada0p3
Mediasize: 285711794176 (266G)
Sectorsize: 512
Stripesize: 4096
Stripeoffset: 0
Mode: r1w1e1

Geom name: ada1p3.eli
State: ACTIVE
EncryptionAlgorithm: AES-XTS
KeyLength: 256
Crypto: hardware
Version: 7
UsedKey: 0
Flags: BOOT, GELIBOOT
KeysAllocated: 67
KeysTotal: 67
Providers:
1. Name: ada1p3.eli
Mediasize: 285711790080 (266G)
Sectorsize: 4096
Mode: r1w1e1
Consumers:
1. Name: ada1p3
Mediasize: 285711794176 (266G)
Sectorsize: 512
Stripesize: 4096
Stripeoffset: 0
Mode: r1w1e1

Geom name: ada2p3.eli
State: ACTIVE
EncryptionAlgorithm: AES-XTS
KeyLength: 256
Crypto: hardware
Version: 7
UsedKey: 0
Flags: BOOT, GELIBOOT
KeysAllocated: 67
KeysTotal: 67
Providers:
1. Name: ada2p3.eli
Mediasize: 285711790080 (266G)
Sectorsize: 4096
Mode: r1w1e1
Consumers:
1. Name: ada2p3
Mediasize: 285711794176 (266G)
Sectorsize: 512
Stripesize: 4096
Stripeoffset: 0
Mode: r1w1e1

 

[[KB]]

Hm, das Einzige was mir in deiner geli-Liste aufgefallen ist, dass für ada0 - ada3 folgende Flags gesetzt sind:

Flags: BOOT, GELIBOOT

Kann das evtl. das 2-malige Abfragen des PW verursachen?

Und nur mal so zum Verständnis ada0 - ada3 sind SATA-Platten?
Und da0 -da7? USB???

 

[mr44er]

Flags: BOOT, GELIBOOT

Das BOOT-Flag ist dafür da, dass geli mitgeteilt bekommt, dass das beim booten 'attached' werden soll. GELIBOOT weist an, davon zu booten. Ist offiziell so beschrieben und mit der 11.1-RELEASE ging das auch wie es sollte. Musste das damals auch nachlesen, weil mein datenpool nicht automatisch mitentschlüsselt wurde.

ada0-ada2 sind SATA-Platten am Mainboard.
da0-da7 sind SAS-Platten am HBA
da8 ist ein USB-Stick

 

[[KB]]

Also bei meiner geli-verschlüsselten Platte (von der auch gebootet wird) ist nur das BOOT-Flag gesetzt ...

 

[Yamagi]

Das "GELIBOOT"-Flag ist, damit der Bootloader das Geli-Volume öffnet, das "BOOT"-Flag damit der Kernel das Volume öffnet. Wer GELIBOOT sagt, muss in normalen Setups auch BOOT sagen. Aber nicht umgekehrt.

 

[[KB]]

Wenn ich https://ftfl.ca/blog/2016-09-17-zfs-fde-one-pool-conversion.html richtig verstanden habe, benötigt man das geliboot-Flag jedoch nur, wenn kein separater bootpool verwendet wird, sondern die Partionen vom Bootloader direkt angesprochen werden.
Habe ich es falsch verstanden?
Und wenn ich die Logs von mr44er richtig deute, haben seine Boot-Platten separate bootpools.

Ich nehme es zurück, habe mich bezüglich meiner letzten Aussage wahrscheinlich geirrt.

 

[mr44er]

Nein, habe keinen Bootpool. Das wird seit einigen Versionen nicht mehr benötigt, allenfalls noch, wenn man efi booten will oder muss.
Da ich 11.2 frisch installiert habe und das der zfsautoinstaller so verbrochen hat, gehe ich davon aus, dass das so richtig ist.

Das "GELIBOOT"-Flag ist, damit der Bootloader das Geli-Volume öffnet, das "BOOT"-Flag damit der Kernel das Volume öffnet. Wer GELIBOOT sagt, muss in normalen Setups auch BOOT sagen. Aber nicht umgekehrt.

Ich hab die letzte Nacht noch damit verbracht, meine kleineren Problemchen zu googlen und mich einzulesen, daher bin ich etwas tüdelig und kann nicht ganz folgen aufgrund der Müdigkeit.
Hab ich die flags so richtig gesetzt? Unter 11.1 ging das nämlich noch wie gewünscht.

 

[[KB]]

Also, ich bin da raus ...

 

[mr44er]

Zusammengefasst, ich hab rumgepopelt:
in rc.conf: geli_devices="da0 da1 usw" -> Je Platte wird das Passwort 1x abgefragt -> nervig!
da0-da7 nur mit BOOT-flag -> IST-Zustand -> PW muss beim Booten ein zweites Mal eingegeben werden, aber alle werden entschlüsselt
da0-da7 nur mit GELIBOOT-flag -> boot läuft durch, da0-da7 wird ignoriert
da0-da7 mit GELIBOOT- und BOOT-flag -> Verhalten wie gehabt, PW muss beim Booten ein zweites Mal eingegeben werden, aber alle werden entschlüsselt

geom_eli_passphrase_prompt="YES" <- Das nutze ich jetzt in der loader.conf, dann muss ich nicht so lange auf die zweite PW-Abfrage warten und es verschwimmt nicht zwischen den bootmeldungen.

 

[Yamagi]

Ich weiß ehrlich gesagt nicht, ob ich hier helfen kann. Ich habe kein Setup mit mehreren Geli-Devices, die durch das gleiche Passwort entsperrt werden und in den letzten Monaten zwischen den über 1000 Commits in die Bootloader den Überblick verloren, welche Änderung nun welcher Branch ist. Ich tippsel trotzdem mal was...

Grundsätzlich muss jemand das Kennwort entgegennehmen, durch die Key Derivation Funktion jagen und dem geom_eli.ko Kernelmodul zum Cachen übergeben. Das geom_eli.ko Modul wendet sie dann auf die einzelnen GELI-Provider an, um sie zu öffnen. Dafür gibt es zwei Wege:

• Der ältere Weg ist, dass der Kernel selbst nach dem Passwort fragt. Das hat den Nachteil, dass der Boot-Loader nicht von GELI-Providern lesen kann, man braucht also eine unverschlüsselte Boot-Partition. Außerdem war die Passworteingabe während des Kernelboots immer sehr problematisch, das FreeBSDs Kernel erst mit dem Aufruf von /sbin/init volle Interrupts bereitstellen kann. Das ist aber zu spät, um das Passwort abzufragen.
• Daher hat man in 11.0 den BIOS Boot-Loader mit GELI-Unterstützung ausgestattet. Vor einigen Wochen haben in 12-CURRENT auch endlich alle anderen Boot-Loader die Funktion bekommen. Also UEFI, UBOOT, OpenFirmware und was es noch so gibt. Der Boot-Loader fragt das Passwort ab und öffnet für sich den GELI-Provider mit dem Kernel und co. Er lädt den Kernel, schreibt ihm das Passwort in GELIs Cache und startet ihn. GELI kann das gecachte Kennwort dann nutzen um die GELI-Provider für sich zu öffnen.

Man hat diskutiert den ersten Weg in 12.0 zu entfernen, weil er sowieso nicht zuverlässig funktioniert. Passiert ist das nicht, da man alte Setups nicht brechen will. Für Neusetups sollte man aber tunlichst den zweiten Weg nehmen, was in 11.2 leichter gesagt als getan ist, da der UEFI Boot-Loader eben kein GELI spricht.

Damit der zweite Weg, den du ja einsetzt, funktioniert muss ich nicht viel gegeben sein. Man braucht einen aktuellen Boot-Loader in der freebsd-boot Partition, sonst klappt die Übergabe des Passworts an den Kernel eventuell nicht. Den also mal neuschreiben, kostet ja nichts:

gpart bootcode -b /boot/pmbr -p /boot/$LOADER -i $PARTNUM $DEVICE

In der /boot/loader.conf muss nichts eingetragen werden. Vor allem darf 'kern.geom.eli.boot_passcache' nicht auf 0 gesetzt werden. SOnst funktioniert es nicht. 'geom_eli_passphrase_prompt="YES"' sollte nicht notwendig sein. Zumindest in Setups mit nur einem GELI-Provider ist es das nicht.

Alle GELI-Provider, die durch den Boot-Loader und den Kernel geöffnet werden sollen, brauchen die Flags BOOT (-b) und GELIBOOT (-g). Provider, die nur durch den Kernel geöffnet werden sollen, brauchen nur BOOT (-b). Mein Tipp ist Boot-Loader und Kernel nur die Provider öffnen zu lassen, die für das Mounten von / benötigt werden. Alle anderen macht man besser in der rc.conf durch Keys, die auf dem verschlüsselten / liegen. Schon alleine, da man dort bessere Kontrolle hat ob, wann und wie die Provider geöffnet werden.

 

[schorsch_76]

Ähm .. ich hab da mal ne dumme Frage ......

Bei EFI boot lädt das UEFI den bootloader von der EFI Partition. Was macht in dem Fall

gpart bootcode -b /boot/pmbr -p /boot/$LOADER -i $PARTNUM $DEVICE

?

-b /boot/pmbr würde ja den MBR bootcode nach $PARTNUM $DEVICE schreiben.

Unter [1] schreibt der FreeBSD Blogger

# gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ada0
# gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ada1

Bei ihm ist ada0p1/ada1p1 freebsd-boot Partition. Auch mit GPT Partitionierung......

Wie bootet @mr44er den Server, MBR Boot mit GPT Partition oder UEFI Boot?

[1] https://ftfl.ca/blog/2016-09-17-zfs-fde-one-pool-conversion.html

man gpart hab ich gelesen und ich versuch das gerade zu verstehen ....

bootcode Embed bootstrap code into the partitioning scheme's metadata on
the geom(using -b bootcode) or write bootstrap code into a
partition (using-p partcode and-i index). Notall partition-
ing schemes haveembedded bootstrap code, so the-b bootcode
option is scheme-specific in nature (seethe section entitled
BOOTSTRAPPING below). The -b bootcode option specifies a file
that contains the bootstrap code. The contents and sizeof the
file aredetermined by the partitioning scheme.The -p
partcodeoption specifies a filethat contains the bootstrap
code intended tobe written to apartition. Thepartition is
specified by the-i index option. The size of the file must be
smaller than thesize ofthe partition.

Additional options include:

-f flags Additional operational flags. See the section
entitled OPERATIONALFLAGS below fora discussion
about its use.

 

[Yamagi]

gpart bootcode -b /boot/pmbr -p /boot/$LOADER -i $PARTNUM $DEVICE

Das ist für BIOS-Boot von GPT-Partitionen. Es schreibt /boot/pmbr in den Protective MBR des GPT-Partitionsschema. Das BIOS lädt den Protective MBR, der Code darin liest die GPT und sucht die freebsd-boot Partition. Deren Inhalt (das ist /boot/$LOADER) wird in den RAM geladen und ausgeführt. Der Code sucht dann je nach Variante die erste UFS oder ZFS Partition, liest /boot/loader von ihr und führt den wiederum aus.
Das ist ein Hack, ja. Aber zumindest FreeBSD und Linux nutzen das seit Jahren um auf BIOS-Systemen von GPT-Partitionen booten zu können. Nur Microsoft verweigert das aus politischen Gründen, da braucht man für GPT zwingend ein UEFI.

FreeBSDs UEFI-Boot in den 11.x Release etwas verworren. Es ist mit jedem Release kontinuierlich besser geworden aber am Besten verschwendet man trotzdem keine Zeit mehr drauf es im Detail zu verstehen. Denn das demnächst kommende 12.0 wird endlich das Bootloader-Protokoll unterstützen, d.h. man kopiert ganz normal /boot/loader.efi auf seine EFI-Partition, setzt mit einem efibootmgr(8) einen Eintrag im NVRAM und es funktioniert. Also genau das gleiche Prozedere wie unter Linux und Windows.

 

[mr44er]

Männers, ich hab mal die heiße Stelle aus der install.log rauskopiert:

DEBUG: zfs_create_diskpart: zpool labelclear -f "/dev/ada0"
DEBUG: zfs_create_diskpart: retval=1 <output below>
failed to read label from /dev/ada0
DEBUG: zfs_create_diskpart: gpart create -s gpt "ada0"
DEBUG: zfs_create_diskpart: retval=0 <output below>
ada0 created
DEBUG: zfs_create_diskpart: gpart destroy -F "ada0"
DEBUG: zfs_create_diskpart: retval=0 <output below>
ada0 destroyed
DEBUG: zfs_create_diskpart: Creating GPT layout...
DEBUG: zfs_create_diskpart: gpart create -s gpt "ada0"
DEBUG: zfs_create_diskpart: retval=0 <output below>
ada0 created
DEBUG: zfs_create_diskpart: gpart add -a 4k -l gptboot0 -t freebsd-boot -s 512k "ada0"
DEBUG: zfs_create_diskpart: retval=0 <output below>
ada0p1 added
DEBUG: zfs_create_diskpart: gpart bootcode -b "/boot/pmbr" -p "/boot/gptzfsboot" -i 1 "ada0"
DEBUG: zfs_create_diskpart: retval=0 <output below>
partcode written to ada0p1
bootcode written to ada0
DEBUG: zfs_create_diskpart: gpart add -a 1m -l swap0 -t freebsd-swap -s 34359738368b "ada0"
DEBUG: zfs_create_diskpart: retval=0 <output below>
ada0p2 added
DEBUG: zfs_create_diskpart: zpool labelclear -f "/dev/ada0p2"
DEBUG: zfs_create_diskpart: retval=1 <output below>
failed to read label from /dev/ada0p2
DEBUG: zfs_create_diskpart: gpart add -a 1m -l zfs0 -t freebsd-zfs "ada0"
DEBUG: zfs_create_diskpart: retval=0 <output below>
ada0p3 added
DEBUG: zfs_create_diskpart: zpool labelclear -f "/dev/ada0p3"
DEBUG: zfs_create_diskpart: retval=1 <output below>
failed to read label from /dev/ada0p3

@Yamagi
Mit 11.1 funktionierte das auch einwandfrei (1x Passwort, GPT-Boot, BOOT-flag da0-da7), habe dann auf die 11.2 gehoben und ab da kam dann die zweite PW-Abfrage, was mich irritiert hatte.
Das 11.2 wurde daher frisch am 5.8.18 installiert und definitiv mit Methode2. Die Änderung mit dem bootloader hab ich mitbekommen, ist einfach praktischer ohne bootpool.

root@aserver:/var/log # sysctl -a | grep kern.geom.eli.boot_passcache
kern.geom.eli.boot_passcache: 1
root@aserver:/var/log #

In der /boot/loader.conf muss nichts eingetragen werden.

Spoiler: loader.conf

#aesni_load="YES" #in kernel kompiliert
#geom_eli_load="YES" #in kernel kompiliert

geom_eli_passphrase_prompt="YES" #fuer vorherige zweite pw-abfrage

kern.geom.label.disk_ident.enable="0"
kern.geom.label.gptid.enable="0"
zfs_load="YES"

vfs.zfs.arc_max="8G"

hw.mps.enable_ssu=3

###net/mpd5###
ng_ether_load="YES"
###net/mpd5###

###sysutils/ipmitool###
ipmi_load="YES"
###sysutils/ipmitool###

Da ist auch nichts mehr drin. 'geom_eli_passphrase_prompt' -> Ist jetzt nur aus der Bequemlichkeit heraus drin, damit die Abfrage ganz am Anfang kommt und nicht verschwimmt. Wusste mir nicht weiter zu helfen und das ist der Zustand, der meinem Wunsch am nächsten kommt...unter 11.1 ging es ja ohne wie gewünscht.

Alle anderen macht man besser in der rc.conf durch Keys, die auf dem verschlüsselten / liegen. Schon alleine, da man dort bessere Kontrolle hat ob, wann und wie die Provider geöffnet werden.

Ich bin leider kein Freund von keys, da ich die nicht im Kopf haben kann.

Spoiler: gpart list ada0

root@aserver:/var/log # gpart list ada0
Geom name: ada0
modified: false
state: OK
fwheads: 16
fwsectors: 63
last: 625142407
first: 40
entries: 152
scheme: GPT
Providers:
1. Name: ada0p1
Mediasize: 524288 (512K)
Sectorsize: 512
Stripesize: 4096
Stripeoffset: 0
Mode: r0w0e0
efimedia: HD(1,GPT,e4b16547-98d4-11e8-b321-a0423f0086d7,0x28,0x400)
rawuuid: e4b16547-98d4-11e8-b321-a0423f0086d7
rawtype: 83bd6b9d-7f41-11dc-be0b-001560b84f0f
label: gptboot0
length: 524288
offset: 20480
type: freebsd-boot
index: 1
end: 1063
start: 40
2. Name: ada0p2
Mediasize: 34359738368 (32G)
Sectorsize: 512
Stripesize: 4096
Stripeoffset: 0
Mode: r1w1e0
efimedia: HD(2,GPT,e4eb7fd0-98d4-11e8-b321-a0423f0086d7,0x800,0x4000000)
rawuuid: e4eb7fd0-98d4-11e8-b321-a0423f0086d7
rawtype: 516e7cb5-6ecf-11d6-8ff8-00022d09712b
label: swap0
length: 34359738368
offset: 1048576
type: freebsd-swap
index: 2
end: 67110911
start: 2048
3. Name: ada0p3
Mediasize: 285711794176 (266G)
Sectorsize: 512
Stripesize: 4096
Stripeoffset: 0
Mode: r1w1e1
efimedia: HD(3,GPT,e5209289-98d4-11e8-b321-a0423f0086d7,0x4000800,0x2142e000)
rawuuid: e5209289-98d4-11e8-b321-a0423f0086d7
rawtype: 516e7cba-6ecf-11d6-8ff8-00022d09712b
label: zfs0
length: 285711794176
offset: 34360786944
type: freebsd-zfs
index: 3
end: 625141759
start: 67110912
Consumers:
1. Name: ada0
Mediasize: 320072933376 (298G)
Sectorsize: 512
Stripesize: 4096
Stripeoffset: 0
Mode: r2w2e3

Wie bootet @mr44er den Server, MBR Boot mit GPT Partition oder UEFI Boot?

Das Board hat keine UEFI-Unterstützung, daher wählte der Installer von sich aus die GPT-Variante.

 

[Yamagi]

Das 11.2 wurde daher frisch am 5.8.18 installiert und definitiv mit Methode2. Die Änderung mit dem bootloader hab ich mitbekommen, ist einfach praktischer ohne bootpool.

Das waren so verdammt viele Änderungen am Boot-Loader: https://svnweb.freebsd.org/base/stable/11/sys/boot/?view=log Das kann also auch gut ein Bug sein. Ich würde mal auf freebsd-stable@ fragen. Da hast du ein viel größeres Publikum und mehr als keine Antwort geben kann es auch nicht.

 

[schorsch_76]

@mr44er: In dem Install Log Ausschnitt ist aber nur ZFS drin und kein GELI. Soweit ich man 8 geli verstanden habe, sollte das geli Device ja etwa ada0p3.eli heißen.

 

[mr44er]

Stimmt....ich bin nicht ausgeschlafen.

incoming:

Spoiler

DEBUG: zfs_create_diskpart: printf "$FSTAB_FMT" "/dev/ada2p2" "none" "swap" "sw" "0" "0" >> "/tmp/bsdinstall_etc/fstab"
DEBUG: zfs_create_diskpart: retval=0 <no output>
DEBUG: zfs_create_boot: kldload aesni
DEBUG: zfs_create_boot: retval=0 <no output>
DEBUG: f_dialog_max_size: dialog --print-maxsize = [MaxSize: 30, 80]
DEBUG: f_getvar: var=[height1] value=[8] r=0
DEBUG: f_getvar: var=[width1] value=[80] r=0
DEBUG: f_dialog_max_size: dialog --print-maxsize = [MaxSize: 30, 80]
DEBUG: f_getvar: var=[height2] value=[8] r=0
DEBUG: f_getvar: var=[width2] value=[54] r=0
DEBUG: f_dialog_max_size: dialog --print-maxsize = [MaxSize: 30, 80]
DEBUG: f_getvar: var=[height] value=[4] r=0
DEBUG: f_getvar: var=[width] value=[46] r=0
DEBUG: zfs_create_boot: geli init -bg -e AES-XTS -J - -l 256 -s 4096 "ada0p3"
DEBUG: zfs_create_boot: retval=0 <output below>

Metadata backup can be found in /var/backups/ada0p3.eli and
can be restored with the following command:

# geli restore /var/backups/ada0p3.eli ada0p3
DEBUG: zfs_create_boot: geli attach -j - "ada0p3"
DEBUG: zfs_create_boot: retval=0 <no output>
DEBUG: f_dialog_max_size: dialog --print-maxsize = [MaxSize: 30, 80]
DEBUG: f_getvar: var=[height] value=[4] r=0
DEBUG: f_getvar: var=[width] value=[46] r=0
DEBUG: zfs_create_boot: geli init -bg -e AES-XTS -J - -l 256 -s 4096 "ada1p3"
DEBUG: zfs_create_boot: retval=0 <output below>

Metadata backup can be found in /var/backups/ada1p3.eli and
can be restored with the following command:

# geli restore /var/backups/ada1p3.eli ada1p3
DEBUG: zfs_create_boot: geli attach -j - "ada1p3"
DEBUG: zfs_create_boot: retval=0 <no output>
DEBUG: f_dialog_max_size: dialog --print-maxsize = [MaxSize: 30, 80]
DEBUG: f_getvar: var=[height] value=[4] r=0
DEBUG: f_getvar: var=[width] value=[46] r=0
DEBUG: zfs_create_boot: geli init -bg -e AES-XTS -J - -l 256 -s 4096 "ada2p3"
DEBUG: zfs_create_boot: retval=0 <output below>

Metadata backup can be found in /var/backups/ada2p3.eli and
can be restored with the following command:

# geli restore /var/backups/ada2p3.eli ada2p3
DEBUG: zfs_create_boot: geli attach -j - "ada2p3"
DEBUG: zfs_create_boot: retval=0 <no output>
DEBUG: zfs_create_boot: Creating root pool...
DEBUG: zfs_create_boot: zpool create -o altroot=/mnt -O compress=lz4 -O atime=off -m none -f "zroot" mirror ada0p3.eli ada1p3.eli ada2p3.eli
DEBUG: zfs_create_boot: retval=0 <no output>
DEBUG: zfs_create_boot: Creating ZFS datasets...
DEBUG: zfs_create_boot: zfs create -o mountpoint=none "zroot/ROOT"
DEBUG: zfs_create_boot: retval=0 <no output>
DEBUG: zfs_create_boot: zfs create -o mountpoint=/ "zroot/ROOT/default"
DEBUG: zfs_create_boot: retval=0 <no output>
DEBUG: zfs_create_boot: zfs create -o mountpoint=/tmp -o exec=on -o setuid=off "zroot/tmp"
DEBUG: zfs_create_boot: retval=0 <no output>
DEBUG: zfs_create_boot: zfs create -o mountpoint=/usr -o canmount=off "zroot/usr"
DEBUG: zfs_create_boot: retval=0 <no output>
DEBUG: zfs_create_boot: zfs create "zroot/usr/home"
DEBUG: zfs_create_boot: retval=0 <no output>
DEBUG: zfs_create_boot: zfs create -o setuid=off "zroot/usr/ports"
DEBUG: zfs_create_boot: retval=0 <no output>
DEBUG: zfs_create_boot: zfs create "zroot/usr/src"
DEBUG: zfs_create_boot: retval=0 <no output>
DEBUG: zfs_create_boot: zfs create -o mountpoint=/var -o canmount=off "zroot/var"
DEBUG: zfs_create_boot: retval=0 <no output>
DEBUG: zfs_create_boot: zfs create -o exec=off -o setuid=off "zroot/var/audit"
DEBUG: zfs_create_boot: retval=0 <no output>
DEBUG: zfs_create_boot: zfs create -o exec=off -o setuid=off "zroot/var/crash"
DEBUG: zfs_create_boot: retval=0 <no output>
DEBUG: zfs_create_boot: zfs create -o exec=off -o setuid=off "zroot/var/log"
DEBUG: zfs_create_boot: retval=0 <no output>
DEBUG: zfs_create_boot: zfs create -o atime=on "zroot/var/mail"
DEBUG: zfs_create_boot: retval=0 <no output>
DEBUG: zfs_create_boot: zfs create -o setuid=off "zroot/var/tmp"
DEBUG: zfs_create_boot: retval=0 <no output>
DEBUG: zfs_create_boot: Setting mountpoint for root of the pool...
DEBUG: zfs_create_boot: zfs set "mountpoint=/zroot" "zroot"
DEBUG: zfs_create_boot: retval=0 <no output>
DEBUG: zfs_create_boot: Modifying directory permissions...
DEBUG: zfs_create_boot: mkdir -p "/mnt/tmp"
DEBUG: zfs_create_boot: retval=0 <no output>
DEBUG: zfs_create_boot: chmod 1777 "/mnt/tmp"
DEBUG: zfs_create_boot: retval=0 <no output>
DEBUG: zfs_create_boot: mkdir -p "/mnt/var/tmp"
DEBUG: zfs_create_boot: retval=0 <no output>
DEBUG: zfs_create_boot: chmod 1777 "/mnt/var/tmp"
DEBUG: zfs_create_boot: retval=0 <no output>
DEBUG: zfs_create_boot: Setting bootfs property...
DEBUG: zfs_create_boot: zpool set bootfs="zroot/ROOT/default" "zroot"
DEBUG: zfs_create_boot: retval=0 <no output>
DEBUG: zfs_create_boot: Configuring zpool.cache for zroot...
DEBUG: zfs_create_boot: mkdir -p "/mnt/boot/zfs"
DEBUG: zfs_create_boot: retval=0 <no output>
DEBUG: zfs_create_boot: zpool set cachefile="/mnt/boot/zfs/zpool.cache" "zroot"
DEBUG: zfs_create_boot: retval=0 <no output>
DEBUG: zfs_create_boot: Set canmount=noauto for the root of the pool...
DEBUG: zfs_create_boot: zfs set "canmount=noauto" "zroot/ROOT/default"
DEBUG: zfs_create_boot: retval=0 <no output>
DEBUG: zfs_create_boot: Configuring rc.conf(5)/loader.conf(5) additions...
DEBUG: zfs_create_boot: echo "zfs_enable=\"YES\"" >> "/tmp/bsdinstall_etc/rc.conf.zfs"
DEBUG: zfs_create_boot: retval=0 <no output>
DEBUG: zfs_create_boot: echo "kern.geom.label.disk_ident.enable=\"0\"" >> "/tmp/bsdinstall_boot/loader.conf.zfs"
DEBUG: zfs_create_boot: retval=0 <no output>
DEBUG: zfs_create_boot: echo "kern.geom.label.gptid.enable=\"0\"" >> "/tmp/bsdinstall_boot/loader.conf.zfs"
DEBUG: zfs_create_boot: retval=0 <no output>
DEBUG: zfs_create_boot: echo "vfs.zfs.min_auto_ashift=12" >> "/tmp/bsdinstall_etc/sysctl.conf.zfs"
DEBUG: zfs_create_boot: retval=0 <no output>
DEBUG: zfs_create_boot: Configuring disk encryption...
DEBUG: zfs_create_boot: echo "aesni_load=\"YES\"" >> "/tmp/bsdinstall_boot/loader.conf.aesni"
DEBUG: zfs_create_boot: retval=0 <no output>
DEBUG: zfs_create_boot: echo "geom_eli_load=\"YES\"" >> "/tmp/bsdinstall_boot/loader.conf.geli"
DEBUG: zfs_create_boot: retval=0 <no output>
DEBUG: dialog.subr: DEBUG_SELF_INITIALIZE=[]
DEBUG: UNAME_S=[FreeBSD] UNAME_P=[amd64] UNAME_R=[11.2-RELEASE]
DEBUG: common.subr: Successfully loaded.
DEBUG: f_debug_init: ARGV=[mount] GETOPTS_STDARGS=[dD:]
DEBUG: f_debug_init: debug=[1] debugFile=[/tmp/bsdinstall_log]
DEBUG: Running installation step: mount
DEBUG: dialog.subr: DEBUG_SELF_INITIALIZE=[]
DEBUG: UNAME_S=[FreeBSD] UNAME_P=[amd64] UNAME_R=[11.2-RELEASE]
DEBUG: common.subr: Successfully loaded.
DEBUG: f_debug_init: ARGV=[distfetch] GETOPTS_STDARGS=[dD:]
DEBUG: f_debug_init: debug=[1] debugFile=[/tmp/bsdinstall_log]
DEBUG: Running installation step: distfetch
DEBUG: dialog.subr: DEBUG_SELF_INITIALIZE=[]
DEBUG: UNAME_S=[FreeBSD] UNAME_P=[amd64] UNAME_R=[11.2-RELEASE]
DEBUG: common.subr: Successfully loaded.
DEBUG: f_debug_init: ARGV=[checksum] GETOPTS_STDARGS=[dD:]
DEBUG: f_debug_init: debug=[1] debugFile=[/tmp/bsdinstall_log]
DEBUG: Running installation step: checksum
DEBUG: dialog.subr: DEBUG_SELF_INITIALIZE=[]
DEBUG: UNAME_S=[FreeBSD] UNAME_P=[amd64] UNAME_R=[11.2-RELEASE]
DEBUG: common.subr: Successfully loaded.
DEBUG: f_debug_init: ARGV=[distextract] GETOPTS_STDARGS=[dD:]
DEBUG: f_debug_init: debug=[1] debugFile=[/tmp/bsdinstall_log]
DEBUG: Running installation step: distextract
DEBUG: dialog.subr: DEBUG_SELF_INITIALIZE=[]
DEBUG: UNAME_S=[FreeBSD] UNAME_P=[amd64] UNAME_R=[11.2-RELEASE]
DEBUG: common.subr: Successfully loaded.
DEBUG: f_debug_init: ARGV=[rootpass] GETOPTS_STDARGS=[dD:]
DEBUG: f_debug_init: debug=[1] debugFile=[/tmp/bsdinstall_log]

Ich würde mal auf freebsd-stable@ fragen.

Sicher stable und nicht release?
Hab das noch nie gemacht und keine Ahnung wie das abläuft.
Einfach ne Email schicken an freebsd-stable@freebsd.org ? In the best fall in english?

 

[Yamagi]

Sicher stable und nicht release?

Ja, freebsd-stable@. Das ist pauschal alles, was nicht -CURRENT ist.

Einfach ne Email schicken an freebsd-stable@freebsd.org ? In the best fall in english?

Jepp. Idealerweise vorher noch registrieren, damit man auch Antworten bekommt, die nur an die Liste und nicht an dich gehen: https://lists.freebsd.org/mailman/listinfo/freebsd-stable

 

[mr44er]

Done bin ich mal gespannt.

 

[schorsch_76]

Schau mal was passiert wenn du das zweite Passwort falsch eingiebst. Das passiert in meiner Test VM (bhyve)

Das zweite Mirror Device wird nicht eingebunden.