Geli & warning

bsdagent

Auch im #bsdforen.de Chat
Hi

Ich habe mit FreeBSD 6.2 & 7.0 Release und GELI ein problem auf allen Speichermedien:

- IDE Festplatte
- SCSI Festplatte
- Externe Festplatte (USB Interface)
- USB Stick

Ich habe alle Speichermedien wie folgt mit geli erstellt

Code:
# dd bs=1m count=1 if=/dev/urandom of=[I]Pfad[/I]/[I]ad[/I]0s3.key
# geli init -b -e Blowfish -K [I]Pfad[/I]/[I]ad[/I]0s1.key -l 448 -s 4096 [I]ad[/I]0s1
[I]...[/I]

und jedesmal wenn ich diese mittels

Code:
# geli attach [I]ad[/I]0s1

einhänge, erhalte ich in /var/messages folgende Warnung

WARNING: Expected rawoffset Zahl, found Zahl

Bei manchen Speichermedien nur eine WARNUNG und bei anderen mehrere. Selbst beim wechseln des Algorithmus, also AES bekomme ich immer das gleiche Resultat.

Weis jemand, was diese Meldung bedeutet? Ist diese Meldung gefährlich? Was kann man dagegen tun?

Gruss
bsdagent
 
Also ich kann Dir nur soviel sagen, daß ich diese Meldung nicht bekomme (FreeBSD 6.2 stable, GELI Blowfish-448). Hier definitiv nicht und auf dem anderen Rechner m.E. auch nicht. (Jetzt allerdings auf dem zweiten Rechern nicht überprüft, aber ich denke das wüßte ich andernfalls.)

Gruß
Wasp
 
Soweit ich das beurteilen kann (Recherche) ist das eine Meldung von GEOM, welches versucht das Label zu finden. Es findet das Label an einem abweichenden Ort. Deswegen diese Meldung. Es hat nicht unbedingt etwas mit der Veschlüsselung zu tun, sondern mit dem BSD-Label. Die Struktur der BSD-Partitionen wird damit beschrieben.

Kritisch ist das nicht, aber sauber ist das ganze auch nicht. Aus Warnungen können bei Updates evtl. Probleme entstehen. Auch Disk-Recovery-Tools etc. können Schaden anrichten, wenn sie mit unerwarteten Dingen konfrontiert werden. Schätze das Risiko am besten selbst ab.
 
Ich kriege jetzt dieselben Errors, egal wie oft ich meine Platte neuformatiere / labele.
Die Platte ist intern und hängt an einem SATA-Controller.

Hab versucht die Warnung zu ignorieren, kriege aber beim bespielen der Platte Panics.

Genauergesagt sind es sogar zwei Platten auf denen das Problem auftritt.

Was nu?
 
Sche*ße, was mach ich denn jetzt. Im Quellcode ist die Überschrift zu dem Absatz der diese Warnung generiert:
Code:
/* Historical braindamage... */
:(

Ich melde mich mal auf freebsd-geom....
 
Musst du nicht. Das ist ganz einfach. Früher(tm) in den tiefsten 80er Jahren hatte irgendein Vollidiot die geniale Idee, dass man das Label doch einfach direkt in den Beginn der ersten Partition schreiben könnte. Das ist natürlich extrem gefährlich, denn in den Bereichen können diverse Tools schreiben (Dateisysteme!) und dir damit alles zerschnoddern. Um dies zu Umgehen, hat Poul-Henning Kamp bei der Einführung von GEOM das "Offset" eingebaut. Das BSDLabel lässt Partition "a" nicht mehr bei Null beginnen, sondern später. 16 Blöcke bleiben meines Wissens nach frei. Bis hierhin war noch alles in Ordnung.
Nun werden Computer aber anspruchvoller und die 16 Blöcke sind inzwischen hart an der Grenze (BSDLabel wurde auf 24 Partitionen erweitert). Als Marcel Moolenaar neue Partitionsklassen für GEOM schrieb, gab er daher 63 Blöcke frei. Das führt zu folgenden Problem: Wenn du partitionierst, schreibt dies die GEOM_PART Klasse von Marcel, es bleiben 63 Blöcke frei. In 7.1 werden BSDLabel aber noch durch die alte GEOM_BSD Klasse gelesen, da ein Umstellen als zu problematisch gesehen wurde (POLA und so). Die alte Klasse erwartet aber nicht ein so großes Offset und nörgel. Dazu kommt ihre eher bescheidene Integration mit anderen GEOM-Klassen deren Metadaten.

Es gibt drei Lösungen:
- Wenn es funktioniert, die Warnung ignorieren. Ist nicht weiter schlimm.
- /usr/src/sys/$ARCH/conf/DEFAULTS editieren und die alten Partitionsklassen durch GEOM_PART_BSD und GEOM_PART_MBR ersetzen. Kernel neubauen und es tut.
- GPT-Partitionen nutzen.
 
Musst du nicht. Das ist ganz einfach. Früher(tm) in den tiefsten 80er Jahren hatte irgendein Vollidiot die geniale Idee, dass man das Label doch einfach direkt in den Beginn der ersten Partition schreiben könnte. Das ist natürlich extrem gefährlich, denn in den Bereichen können diverse Tools schreiben (Dateisysteme!) und dir damit alles zerschnoddern. Um dies zu Umgehen, hat Poul-Henning Kamp bei der Einführung von GEOM das "Offset" eingebaut. Das BSDLabel lässt Partition "a" nicht mehr bei Null beginnen, sondern später. 16 Blöcke bleiben meines Wissens nach frei. Bis hierhin war noch alles in Ordnung.
Nun werden Computer aber anspruchvoller und die 16 Blöcke sind inzwischen hart an der Grenze (BSDLabel wurde auf 24 Partitionen erweitert). Als Marcel Moolenaar neue Partitionsklassen für GEOM schrieb, gab er daher 63 Blöcke frei. Das führt zu folgenden Problem: Wenn du partitionierst, schreibt dies die GEOM_PART Klasse von Marcel, es bleiben 63 Blöcke frei. In 7.1 werden BSDLabel aber noch durch die alte GEOM_BSD Klasse gelesen, da ein Umstellen als zu problematisch gesehen wurde (POLA und so). Die alte Klasse erwartet aber nicht ein so großes Offset und nörgel. Dazu kommt ihre eher bescheidene Integration mit anderen GEOM-Klassen deren Metadaten.
Danke für die Erklärungen! Habe aber gerade schon ein PR geschrieben...
Es gibt drei Lösungen:
- Wenn es funktioniert, die Warnung ignorieren. Ist nicht weiter schlimm.
Wie gesagt, ich hatte GELI-writeerrors und eine panic...
- /usr/src/sys/$ARCH/conf/DEFAULTS editieren und die alten Partitionsklassen durch GEOM_PART_BSD und GEOM_PART_MBR ersetzen. Kernel neubauen und es tut.
Kernel neubauen würde ich ungern, da das ganze auf ein miniserver soll, der per freebsd-update aktualisiert werden soll und keine Resourcen zum bauen hat.
- GPT-Partitionen nutzen.
Ui, Neuland! Gibt es dazu weitere Doku als man gpart / man gpt? Kann ich eine normale slice zum booten anlegen, eine slice mit eli verschlüsseln und dann in der eli-slice mit gpt/gpart ufs und swap-unterpartitionen erstellen?
 
Also Panics sollten nicht passieren. Da frage ich mich eher selbst wie Deine Vorgehensweise ist. Wahrscheinlich liegt das auch an der Art und Weise wie Du partitionstechnisch mit den Platten umgehst. Link zum PR wäre hier hilfreich.

Eine Sache ist noch, dass GEOM anscheinend versucht die Dateisysteme in MBR-Slices zu erkennen. GEOM sucht dazu nach "Magic Numbers".

Jetzt stell Dir vor, dass Du die Platte verschlüsselst und da potenziell "Random Data" steht. GEOM kann hier so reagieren, dass es irgendetwas fälschlicherweise auf der verschlüsselten Partition erkennt und zwar als ein Dateisystem und versucht im nächsten Schritt die weiteren Meta-Daten zur Struktur zu analysieren. Manchmal ist so etwas nicht robust genug gestaltet und es gibt dann einen Panic. So etwas in der Art habe ich schon gesehen.

Was hier helfen kann (im Falle einer Slice im MBR) ist, dass Du zuerst ein Pseudo-Label anlegst, dass die ganze Slice umfasst und dann erst in der BSD-Partition drin geli benutzt. Das hat bei mir bis jetzt immer gut geklappt.

GPT mit gpart benutze ich nur dort, wo ich mir sicher bin, dass ich da nur FreeBSD installieren würde (kein Dual-Boot oder sowas).
 
Also Panics sollten nicht passieren.
:(
Da frage ich mich eher selbst wie Deine Vorgehensweise ist. Wahrscheinlich liegt das auch an der Art und Weise wie Du partitionstechnisch mit den Platten umgehst. Link zum PR wäre hier hilfreich.
http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/131037

Eine Sache ist noch, dass GEOM anscheinend versucht die Dateisysteme in MBR-Slices zu erkennen. GEOM sucht dazu nach "Magic Numbers".
Magic numbers sollten aber AFAICT nur für die Erkennung der Platte eine Rolle spielen und nicht zu Schreibfehlern führen.

Was hier helfen kann (im Falle einer Slice im MBR) ist, dass Du zuerst ein Pseudo-Label anlegst, dass die ganze Slice umfasst und dann erst in der BSD-Partition drin geli benutzt. Das hat bei mir bis jetzt immer gut geklappt.
Ich habe bis jetzt auch gut damit gelebt, garkein label zu erzeugen und direkt geli auf eine slice anzuwenden, und darauf dann ein Dateisystem zu erzeugen. Ich will jetzt aber mehrere Partitionen innerhalb eines verschlüsselten Containers unterbringen.

GPT mit gpart benutze ich nur dort, wo ich mir sicher bin, dass ich da nur FreeBSD installieren würde (kein Dual-Boot oder sowas).
Naja, alles was "auf" geli erzeugt wird kann nur von FreeBSD gelesen werden. Insofern spielt das hier keine Rolle (reiner FreeBSD-Server).

gpt habe ich vorhin noch kurz ausprobiert. Sieht gut aus. Ich verstehe allerdings einige Sachen noch nicht.
ZB.
* Wann benutze ich gpart, wann gpt? - Whats the difference?
* Wie kann ich größen in menschenlesbaren Formaten angeben, also MiB oder GiB?
* Wie kann ich sagen, dass er den restlichen freien Platz in dem GPT für die neue Partition nehmen soll?
 
Ich sehe gerade aus dem PR, dass Du ein Soft-RAID benutzt. Wegen der Schreibfehler würde ich eher auf den Treiber tippen, weil GEOM so einen groben Unfug eher selten macht. Hast Du das ganze RAID mal gründlich getestet?

Ich will jetzt aber mehrere Partitionen innerhalb eines verschlüsselten Containers unterbringen.

Man müsste eigentlich die bsdlabels ineinander schachteln können. Aber probiert habe ich es noch nicht.

* Wann benutze ich gpart, wann gpt? - Whats the difference?

Ich weiß nicht was "gpt" ist. Bei mir gibt es sowas nicht. Ich benutze gpart, um GPT-Festplattenlayout zu initialisieren und um zu partitionieren.

* Wie kann ich größen in menschenlesbaren Formaten angeben, also MiB oder GiB?

Ich glaube nicht, dass es geht. Die erstellten Größen sieht man aber hinten in Klammern bei "gpart show".

* Wie kann ich sagen, dass er den restlichen freien Platz in dem GPT für die neue Partition nehmen soll?

Gib einfach keine Größe ein, bei gpart add.

Hier noch ein kleines HowTo.
 
Wann benutze ich gpart, wann gpt? - Whats the difference?
gpt(8) ist das alte Tool, welches seinerzeit für den FreeBSD/IA64 Port geschrieben wurde. Ist überholt und sollte nicht mehr verwendet werden. in FreeBSD 8.0 wird es verschwunden sein. gpart(8) hingegen ist ein neues, universelles Partitionstools, was bsdlabel(8), fdisk(8), gpt(8) und noch ein paar mehr ersetzt.
 
Ich sehe gerade aus dem PR, dass Du ein Soft-RAID benutzt. Wegen der Schreibfehler würde ich eher auf den Treiber tippen, weil GEOM so einen groben Unfug eher selten macht. Hast Du das ganze RAID mal gründlich getestet?
Also das soft-raid wird einfach mittels ata-control realisiert. Augiebig getestet habe ich das nicht. Ich brauch das aber auch nur zum erstmaligen bespielen der beiden Platten.
Ich weiß nicht was "gpt" ist. Bei mir gibt es sowas nicht. Ich benutze gpart, um GPT-Festplattenlayout zu initialisieren und um zu partitionieren.
Dein Tutorial verwendet auch gpt ;)

Ich glaube nicht, dass es geht. Die erstellten Größen sieht man aber hinten in Klammern bei "gpart show".
Trotz deiner Info und Yamagis Tipp habe ich gpt verwendet. Da muss man wenigstens nicht den startsektor manuell eingeben, nur die Größe der Partition.

Ich hoffe mal das gpart zu gpt kompatibel sein wird (obwohls nicht so wichtig ist, hauptsache es läuft erstmal).
Insgesamt aber sehr unkomfortabel die Sache mit den Größen. Verstehe ich nicht warum das Programm nicht einfach Multiplikationen für mich machen kann - sowas erhöht doch nur sinnlos die chance für tip- oder copy'n'paste Fehler die dann ein falsches Layout erzeugen :rolleyes:

Naja, gerade kopier ich ein paar Daten drauf und hoffe jetzt keine Panics zu kriegen!
 
Zurück
Oben