reset boot flag und disable geli für zusätzliche Platte?

holm

Well-Known Member
Ich war hier schon mal etwas weiter unten mit einem Bootproblem zu gange, es stellte sich heraus das das OS von einer Platte booten wollte, auf der gar nix Bootbares drauf war.. Irgendwie hatte ich den Schranz dann umsortiert so das es wieder funktionierte.

Ich habe doch nun einen neuen Rechner gebastelt, 4 SAS Platten mit GELI als raidz1. Nun möchte ich nachträglich 2 SATA Platten dem System hinzufügen, die eine enthält in 2 500GB Partitionen meine "Datenhalde" ..minderwertige und doch aufhebenswerte Dateien, u.A. Distfiles, irgendwelche Videos, Schaltpläne von RobotronZeuchs und solch einen Kram.
Die 2. enthält eine zu FreeBSD 13 geupdatete Testinstallation, das Zeuch kann weg.

Mein Problem nach Einbau ist nun das trotz im Bios vereinbahrter Bootreihenfolge für Platten Geli als erstes nach einer Passphrase für ada0p3 fragt, also ausgerechnet die Datenhaldenplatte ..und die ist überhaupt nicht mit GELI eingerichtet (noch nicht).
Mein Plan war den Inhalt temporär ins raidz1 Array umzulagern, die Platte platt zu machen und irgendwie mit der 2. 1TB Platte zusammen zu knoten, dann unter GELI.
Eine mögliche Ursache dafür könnte sein, das die erste Partition das Bootflag mit 0x80 als aktiv gesetzt hat, ok dachte ich, setzt Du das halt man zurück.
Das scheint gar nicht so einfach zu sein, fdisk funktioniert nicht mehr und verweigert die Mitarbeit, mal ganz davon abgesehen das es mir genauso wie gpart nur die Auswahl zuläßt eine der 4 möglichen Partitionen aktiv zu setzen..heyhey, was ist denn mit der Auswahl "gar Keine der 4)? Seit wann muß denn eine Platte unbedingt bootbares Zeug enthalten das mich der Kram zwingt eine der Partitionen als bootbar zu kennzeichnen?

Nächste Frage, wie halte ich Geli davon ab nach einer Passphrase für Slices zu fragen die überhaupt nicht verschlüsselt sind?

Sata ist hotplugfähig, dieser Tatsache verdanke ich es das durch Anstöpseln des SATA Steckers während des Bootprozesses aber nach GELI die Platte nun trotzdem gemounted ist und derIhnalt gerade umkopiert wird. Das kann doch nicht die vorgesehene Verfahrensweise sein? Bei der 2. Platte muß ich das wohl genauso machen und den Anfang mit Nullen überbügeln, seltsam.


Übernächste Frage: Wie schaffe ich es die beiden Platten nachträglich beispielsweise als ZFS Stripe hinter GELI anzuknoten so das die die selbe Passphrase verwenden?

Gruß,
Holm
 
Datentenhalde" ..minderwertige und doch aufhebenswerte Dateien
Das erstmal wegsichern auf eine andere Platte, am besten doppelt und dreifach während Umbauten. Einmal zur Sicherheit und zum anderen weil man ZFS nicht flexibel disks geben und wegnehmen kann (nur beim mirror).

Im Detail weiß ich jetzt nicht, warum die Platte abgefragt wird, wenn du sagst, dass da keine Verschlüsselung existierte.
geli configure -b entfernt das normalerweise, -B aktiviert es.

Das Problem insgesamt dürfte sich aber erledigen, wenn du den Krams weggesichert hast und du einmal drübernullst. Ja, die lieben Umbauten. :)

Wie schaffe ich es die beiden Platten nachträglich beispielsweise als ZFS Stripe hinter GELI anzuknoten so das die die selbe Passphrase verwenden?
Stripe und nachträglich: gar nicht, geht nicht.
Ansonsten aber sowas: geli init -b -l 256 -s 4096 da0p1
 
Das erstmal wegsichern auf eine andere Platte, am besten doppelt und dreifach während Umbauten. Einmal zur Sicherheit und zum anderen weil man ZFS nicht flexibel disks geben und wegnehmen kann (nur beim mirror).

Wieso? Ich muß doch einen zusätzliche Pool erstellen können?
Im Detail weiß ich jetzt nicht, warum die Platte abgefragt wird, wenn du sagst, dass da keine Verschlüsselung existierte.
geli configure -b entfernt das normalerweise, -B aktiviert es.

Das Problem insgesamt dürfte sich aber erledigen, wenn du den Krams weggesichert hast und du einmal drübernullst. Ja, die lieben Umbauten. :)
Ist halt Käse, weil man die Daten ja irgendwie "aufheben" möchte. Hier wars eine Platte mit 2 UFS2 Partitions, als Solches ist das ja auch kein Problem.
(Ich habe das auf den aktuellen Pool in meinem $Home kopiert, genug Platz ist da ja, zumindest temporär.
"Nullen" ist auch so ein Ding Irgend ein Vor-sich-selbst-Schützer hat da mal ne Sicherheitsmimik eingebaut, das man den Bootsector nicht einfach überbügeln kann. Das kann man mit einem Sysctl aufheben, ich hab vergessen welchem.. Suchmaschinen haben nix gefunden, wahrscheinlich muß man das "UTSL" in Gpart oder fdisk machen. In bsdlabel hab ichs nicht gefunden, obwohl es wegen "dangerously dedicated" dort ma drin gewesen sein muß. Möglicherweise hab ich auch Tomaten auf den Augen.

Stripe und nachträglich: gar nicht, geht nicht.
Ansonsten aber sowas: geli init -b -l 256 -s 4096 da0p1
Verstehischni, aber Danke für die GELI Geschichten. Mal sehen wie weit ich damit komme. Ich habe die Platten jetzt mit gpart delete -i x und gpart destroy leer gemacht, danach kann man auch wieder Nullen....

Gruß,
Holm
 
Wieso? Ich muß doch einen zusätzliche Pool erstellen können?
Einen neuen pool zusätzlich erstellen geht natürlich. Ich hatte das so verstanden, dass du einem bestehenden pool nachträglich Platten hinzufügen wolltest. Exakt dies geht nur mit mirror-vdevs, nicht mit raidz$ oder stripe.

Als Beispiel kannst du deinem 4-disk raidz1 keine fünfte disk hinzufügen. Da müsste man den pool killen und neu mit diesen fünf disks erstellen (und natürlich vorher die Daten nochmal gesondert wohin zwischenlagern) :)

gpart destroy -F reguliert normalerweise fürstlich durch.

Offtopic: Für Schweinkram advanced bei Festplatten kommt man mit https://www.hdat2.com/ recht weit. Da kann man auch vom Hersteller Hindernisse überwinden.
 
Ich habe jetzt rebootet und beide SATA Platten mit einer noch glaenzenden FreeBSd PArtition versehen:
st: 40
entries: 128
scheme: GPT
Providers:
1. Name: ada0p1
Mediasize: 999653638144 (931G)
Sectorsize: 512
Stripesize: 4096
Stripeoffset: 0
Mode: r0w0e0
efimedia: HD(1,GPT,09832863-5b7b-11ec-9fd8-00d861a1c3ea,0x28,0x74600000)
rawuuid: 09832863-5b7b-11ec-9fd8-00d861a1c3ea
rawtype: 516e7cba-6ecf-11d6-8ff8-00022d09712b
label: (null)
length: 999653638144
offset: 20480
type: freebsd-zfs
index: 1
end: 1952448551
start: 40
Consumers:
1. Name: ada0
Mediasize: 1000204886016 (932G)
Sectorsize: 512
Stripesize: 4096
Stripeoffset: 0
Mode: r0w0e0

Geom name: ada1
modified: false
state: OK
fwheads: 16
fwsectors: 63
last: 1953525127
... das Selbe..

Jetzt komme ich erst mal ins Gruebeln, wie weiter?
Eigentlich gaenge es ja mit geli init weiter, aber:

"Initialize providers which need to be encrypted. If
multiple providers are listed as arguments, they will all
be initialized with the same passphrase and/or User Key.
A unique salt will be randomly generated for each provider
to ensure the Master Key for each is unique. Here you can
set up the cryptographic algorithm to use, Data Key
length, etc. The last sector of the providers is used to
store metadata. The init subcommand also automatically
writes metadata backups to /var/backups/<prov>.eli file.
The metadata can be recovered with the restore subcommand
described below."

Ok, will ich, will ich aber nicht.

Ich moechte die bereits fuer die 4 aktiven geli disks benutzten credentials fuer die zusaetzlichen 2 Diswks mit benutzen, weil ich nicht bei jedem Booten erst den ganzen Koran einhebeln moechte. Nun kann man ja geli beim init allerhand Kram mit angeben, aber offensichtlich landet das wohl bei einer zusaetzlichen Abfrage des Passphrase..
Einerseits moechte ich natuerl;ich die alten Provider nicht neu initailisieren (ist danach noch was drauf? wohl eher nicht) andererseits entnehme ich dem Manual das ich alle zusammen initialisieren muss..wie komme ich da drum herum? Mehrere Pools scheinen mir dagegen nicht das Problem zu sein..

Gruss,
Holm



"

Einen neuen pool zusätzlich erstellen geht natürlich. Ich hatte das so verstanden, dass du einem bestehenden pool nachträglich Platten hinzufügen wolltest. Exakt dies geht nur mit mirror-vdevs, nicht mit raidz$ oder stripe.

nein..das wollte ich nicht, ich will doch keinen Stripe mit einem Raidz1 zusammenknoten :-)
Das soll schon ein extra Pool werden.
Als Beispiel kannst du deinem 4-disk raidz1 keine fünfte disk hinzufügen. Da müsste man den pool killen und neu mit diesen fünf disks erstellen (und natürlich vorher die Daten nochmal gesondert wohin zwischenlagern) :)


gpart destroy -F reguliert normalerweise fürstlich durch.
Ja, das habe ich im Endeffekt auch gemacht, aber das Ding machts ja auch irgendwie.. es gab Zeiten da habe ich das auch schon zu Fuss ausgeschaltet weils notwendig war. Man musste das irgendwie sogar doppelt machen damit es erlaubt wurde.. ich habe das mal gewusst, aber ich werde alt...

Offtopic: Für Schweinkram advanced bei Festplatten kommt man mit https://www.hdat2.com/ recht weit. Da kann man auch vom Hersteller Hindernisse überwinden.
THX, den Tab ziehe ich mir morgen mal rein, offen ist er schon.

Gruss,
Holm
 
Nun kann man ja geli beim init allerhand Kram mit angeben, aber offensichtlich landet das wohl bei einer zusaetzlichen Abfrage des Passphrase..
Da gibts die flags GELIBOOT sowie BOOT

Code:
Geom name: ada0p3.eli
State: ACTIVE
EncryptionAlgorithm: AES-XTS
KeyLength: 256
Crypto: accelerated software
Version: 7
UsedKey: 0
Flags: BOOT, GELIBOOT
KeysAllocated: 75
KeysTotal: 75
Providers:
1. Name: ada0p3.eli
   Mediasize: 318997786624 (297G)
   Sectorsize: 4096
   Mode: r1w1e1
Consumers:
1. Name: ada0p3
   Mediasize: 318997790720 (297G)
   Sectorsize: 512
   Stripesize: 4096
   Stripeoffset: 0
   Mode: r1w1e1

Einerseits moechte ich natuerl;ich die alten Provider nicht neu initailisieren (ist danach noch was drauf? wohl eher nicht) andererseits entnehme ich dem Manual das ich alle zusammen initialisieren muss..wie komme ich da drum herum?
Deine vier bereits initialisierten (geli init) und entschlüsselt/geöffneten geli provider (geli attach) bleiben unangetastet. Die neue Platte/Partition wird mit geli init initialisiert und vorbereitet und ja, das putzt Daten weg (genaugenommen erst beim Überschreiben des Sektors, aber andererseits wurden die Partitionen eh mit gpart schon gelöscht). Daher ja mein anfänglicher Rat vor allem anderen: sicher alles weg, damit nichts schiefgehen kann. :)

aber ich werde alt
Altheit bringt Weisheit. ;)
 
Da gibts die flags GELIBOOT sowie BOOT

Code:
Geom name: ada0p3.eli
State: ACTIVE
EncryptionAlgorithm: AES-XTS
KeyLength: 256
Crypto: accelerated software
Version: 7
UsedKey: 0
Flags: BOOT, GELIBOOT
KeysAllocated: 75
KeysTotal: 75
Providers:
1. Name: ada0p3.eli
   Mediasize: 318997786624 (297G)
   Sectorsize: 4096
   Mode: r1w1e1
Consumers:
1. Name: ada0p3
   Mediasize: 318997790720 (297G)
   Sectorsize: 512
   Stripesize: 4096
   Stripeoffset: 0
   Mode: r1w1e1

Du meinst es läßt sich beeinflussen hinter welches Device sich Geli klemmt und hinter welches nicht? Ok..

Deine vier bereits initialisierten (geli init) und entschlüsselt/geöffneten geli provider (geli attach) bleiben unangetastet. Die neue Platte/Partition wird mit geli init initialisiert und vorbereitet und ja, das putzt Daten weg (genaugenommen erst beim Überschreiben des Sektors, aber andererseits wurden die Partitionen eh mit gpart schon gelöscht). Daher ja mein anfänglicher Rat vor allem anderen: sicher alles weg, damit nichts schiefgehen kann. :)
Ich mache mir keine Gedanken um den Inhalt der beiden hinzuzufügenden Platten (die sind jetzt leer) und eigentlich auch nicht um das existierende Raid, das würde ich gar nicht anfassen wollen. In dem System steckt ne Woche Arbeit an Installation und "einziehen", ich installiere doch das Meiste aus den Ports wegen der Konfiguration der Pakete. Des Weiteren liegt mein Home da drauf, ok das kann ich ja nochmal per Tar aufs Ultrium Drive schaffen.
Mir geht es hauptsächlich um die Frage ob ich die Keys von den bereits installierten Platten irgendwie auf die zusätzlichen Neuen kopiert bekomme, damit ich nicht 2 Mal die Passphrase einhebeln muß.
Ich habe dazu auch noch zusätzlich bei forums.freebsd.org nachgefragt...eventuelle Ergebnisse würde ich hier freilich breit treten.

Altheit bringt Weisheit. ;)

Na dann kann ja nix mehr schief gehen, ich bin knapp 59...

Gruß,
Holm
 
Du meinst es läßt sich beeinflussen hinter welches Device sich Geli klemmt und hinter welches nicht? Ok..
Jep. Der Unterschied ist, wann entsperrt/attached wird bzw. wann die PW-Abfrage kommt (vor oder nach dem Kernel). Spätere PW-Abfragen verstecken sich gern in den boot-messages, aber man merkt es, weil es nicht weiter geht.

Mir geht es hauptsächlich um die Frage ob ich die Keys von den bereits installierten Platten irgendwie auf die zusätzlichen Neuen kopiert bekomme, damit ich nicht 2 Mal die Passphrase einhebeln muß.
Also wenn du das gleiche Passwort wie bei den anderen verwendest und überall Flags: BOOT, GELIBOOT setzt, sollte das passen mit einmaliger Eingabe (und mehr braucht du imho nicht). Key ist hier in dem Sinne auch nicht mit PW zu verwechseln und auch nicht mit keyfiles. Die kann man zusätzlich oder standalone ohne PW verwenden, damit habe ich allerdings keine Erfahrung und weiß daher nicht, wie genau das zusammenspielt.

Du kannst ja auch mal die Bootläufe durchtesten, welche Kombination passt. Davon ausgehend, dass der erste pool deine Platten ada0-ada3 sind, da die Fingerchen weglassen. Die zusätzlichen Platten mit den neuen Partitionen dann ada4p1 und ada5p1, was entsperrt ada4p1.eli und ada5p1.eli wird. Darauf dann geli configure, -b / -B und/oder -g / -G und testen.

geli configure ist ungefähr in der Mitte: https://www.freebsd.org/cgi/man.cgi?geli(8)
 
Ich habe das entsprechend probiert, geli init -b auf ata0p1 und ata1p1, danach pool auf den beiden .eli devices als stripe gebaut.
Selbe Passphrase verwendet wie fuer die zrpool sas disks. Die Platten werden als BIOS disk 0..5 aufgelistet, Eingabe passphrase da0p3 blabla enter.

Danach 4 mal generating geli Irgendwas, kernel boot. Nachdem der Kernel alle Platten gefunden hat, kommt die 2. Abfrage der Passphrase fuer die beiden SATA disks.
geom_eli_passphrase_prompt="YES" in /boot/loader.conf verschiebt die Abfrage unmittelbar vor die Anzeige des (graphischen) FreeBSD Bootmenues nach vorne, d.h. die bleibt nicht im Sauerkraut der bootmessages des Kernel versteckt. Sinnvoll, aber hilft nicht.
Das sieht fuer mich nach einer Sackgasse im Design aus. geli configure -B auf den root pool erschiesst wahrscheinlich die Daten, so das ich die Passphrase fuer den root Pool nicht gemeinsam mit dem Datenpool andern kann.

Faellt Jemandem noch was ein?

Gruss,
Holm
 
Zurück
Oben