Brauche mal Hilfe ..."Invalid Partition" beim booten...

holm

Well-Known Member
ich habe einen ältlichen Desktop Rechner..einen Core2Quad, drin sind 4 Platten, 3 147G SAS Disks und eine 1TB SATA.
Ich habe das Ding erst die Woche von 12.1-stable auf 12.2-stable geupdated..soweit keine Probleme.
Der Rechner kennt kein EFI, ist also noch plain BIOS und das macht wohl einen Teil des Problems aus.
Die 3 147G Platten enthalten ein ZFS raidz1 und sind zu allem Überfluß auch noch mir Geli verschlüsselt.
..keine Panik..alle Daten sind lesbar, ich habe, nachdem der Rechner heute wohl wegen Überlast abgekratzt ist,
"nur" ein Bootproblem.: "Invalid Partition Table" und zwar auf dem 3 SAS Platten die da booten können sollten.

Auf jeder der 3 Platten befindeet sich jeweils eine freebsd-boot, eine freebsd-swap und eine freebsd-zfs Partition
Eigentlich sollte die boot Partition einfach nur 3 mal vorhanden und "gefüllt" sein, der Swap als Stripe konfiguriert und
das ZFS halt als raidz1.

Angesichts der Tatsache das der Rechner kein UEFI Bios hat, sollte wohl ein Master Boot Record samt Fdisk-Partitionstabelle
notwendig sein. fdisk da0 zeigt mir aber eine EFI GPT Partition mit Sysid 238 an...kann der normale mbr überhaupt davon booten?
(die anderen Platten sind identisch). Bsdlabel da0 meint "no valid label found".

Ich habe den Rechner mit einem 12.2 USB Stick gebootet, das Ding fragt nach dem GELI Passwd und bootet dann halt weiter.
Die /dev/gpt Einträge gptboot[0..2], swap[0..2] und zfs[0..2] werden angelegt, geom_eli_load="YES" in loader.conf erzeugt die
da[0,1,2]p3.eli Einträge auf die ich dann auch ein zpool import -R ansetzen kann und auch noch zroot/ROOT nachmounten.
Alles gut, Alles da.
Due Frage ist jetzt: Wie repariere ich das, bzw was. genau fehlt der Mühle? soll ich mit bsdlabel -B den bootcode neu installieren?
Achja..die fdisk-Partitionen sind aktiv (0x80).
Irgendwann mal habe ich die Übersicht verloren wie 'FreeBSD bootet, früher mal war ganz ohne Partitionstabelle (ja ich weiß,
Slice-Tabelle) nur Label im "dangerous dedicated mode" das fand ich am praktischsten..



Gruß,
Holm
 

Andy_m4

Well-Known Member
Also ganz grundsätzlich ist der Bootvorgang im Handbuch beschrieben:
https://docs.freebsd.org/de/books/handbook/boot/

Für Deinen Fall, also BIOS mit GPT-partitionierter Disk mit ZFS-Dateisystem (wenn ich Deinen Beitrag richtig interpretiert hab; mit nem gpart list könnte man noch mal nachgucken) erfolgt das booten über gptzfsboot:
GPTZFSBOOT(8)

Dort ist auch beschrieben, wie man den Bootcode neu schreibt (unbedingt dazu auch die gpart-Manpage konsultieren).
 

holm

Well-Known Member
Ich habe das gestern schon gemacht:

gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 da0

macht er, Nichts desto trotz schaue ich mir dann beim boot an:

Invalid partition
Invalid partition
Invalid partition
No /boot/loader

FreeBSD/x86 boot
Default: 0:ad(0,a)/boot(kernel/'kernel
...

gpart list sieht ordentlich aus, ich müßte aber für ne Kopie erst mal das Netzwerkinterface hoch ziehen und mich mit ssh einloggen..

Gruß,
Holm
 

holm

Well-Known Member
gpart list:

Geom name: da0
modified: false
state: OK
fwheads: 255
fwsectors: 63
last: 286749447
first: 40
entries: 128
scheme: GPT
Providers:
1. Name: da0p1
Mediasize: 524288 (512K)
Sectorsize: 512
Stripesize: 0
Stripeoffset: 20480
Mode: r0w0e0
efimedia: HD(1,GPT,0e6e9ba7-b288-11e8-b5ea-00187d0a3367,0x28,0x400)
rawuuid: 0e6e9ba7-b288-11e8-b5ea-00187d0a3367
rawtype: 83bd6b9d-7f41-11dc-be0b-001560b84f0f
label: gptboot0
length: 524288
offset: 20480
type: freebsd-boot

index: 1
end: 1063
start: 40
2. Name: da0p2
Mediasize: 2147483648 (2.0G)
Sectorsize: 512
Stripesize: 0
Stripeoffset: 1048576
Mode: r0w0e0
efimedia: HD(2,GPT,0efb3c21-b288-11e8-b5ea-00187d0a3367,0x800,0x400000)
rawuuid: 0efb3c21-b288-11e8-b5ea-00187d0a3367
rawtype: 516e7cb5-6ecf-11d6-8ff8-00022d09712b
label: swap0
length: 2147483648
offset: 1048576
type: freebsd-swap
index: 2
end: 4196351
start: 2048
3. Name: da0p3
Mediasize: 144666787840 (135G)
Sectorsize: 512
Stripesize: 0
Stripeoffset: 2148532224
Mode: r1w1e1
efimedia: HD(3,GPT,0f7e6ee6-b288-11e8-b5ea-00187d0a3367,0x400800,0x10d76800)
rawuuid: 0f7e6ee6-b288-11e8-b5ea-00187d0a3367
rawtype: 516e7cba-6ecf-11d6-8ff8-00022d09712b
label: zfs0
length: 144666787840
offset: 2148532224
type: freebsd-zfs
index: 3
end: 286748671
start: 4196352
Consumers:
1. Name: da0
Mediasize: 146815737856 (137G)
Sectorsize: 512
Mode: r1w1e2

Geom name: da1
modified: false
state: OK
fwheads: 255
fwsectors: 63
last: 286749447
first: 40
entries: 128
scheme: GPT
Providers:
1. Name: da1p1
Mediasize: 524288 (512K)
Sectorsize: 512
Stripesize: 0
Stripeoffset: 20480
Mode: r0w0e0
efimedia: HD(1,GPT,109237e4-b288-11e8-b5ea-00187d0a3367,0x28,0x400)
rawuuid: 109237e4-b288-11e8-b5ea-00187d0a3367
rawtype: 83bd6b9d-7f41-11dc-be0b-001560b84f0f
label: gptboot1
length: 524288
offset: 20480
type: freebsd-boot
index: 1
end: 1063
start: 40
2. Name: da1p2
Mediasize: 2147483648 (2.0G)
Sectorsize: 512
Stripesize: 0
Stripeoffset: 1048576
Mode: r0w0e0
efimedia: HD(2,GPT,1123c17d-b288-11e8-b5ea-00187d0a3367,0x800,0x400000)
rawuuid: 1123c17d-b288-11e8-b5ea-00187d0a3367
rawtype: 516e7cb5-6ecf-11d6-8ff8-00022d09712b
label: swap1
length: 2147483648
offset: 1048576
type: freebsd-swap
index: 2
end: 4196351
start: 2048
3. Name: da1p3
Mediasize: 144666787840 (135G)
Sectorsize: 512
Stripesize: 0
Stripeoffset: 2148532224
Mode: r1w1e1
efimedia: HD(3,GPT,11a54932-b288-11e8-b5ea-00187d0a3367,0x400800,0x10d76800)
rawuuid: 11a54932-b288-11e8-b5ea-00187d0a3367
rawtype: 516e7cba-6ecf-11d6-8ff8-00022d09712b
label: zfs1
length: 144666787840
offset: 2148532224
type: freebsd-zfs
index: 3
end: 286748671
start: 4196352
Consumers:
1. Name: da1
Mediasize: 146815737856 (137G)
Sectorsize: 512
Mode: r1w1e2

Geom name: da2
..ist nicht anders.

Gruß,
Holm
 

holm

Well-Known Member
die gpart partition zeigt einen offset von 20480 für die freebsd-boot partition, die fdisk partition sagt 2 sektoren offset:

******* Working on device /dev/da0 *******
parameters extracted from in-core disklabel are:
cylinders=17849 heads=255 sectors/track=63 (16065 blks/cyl)

Figures below won't work with BIOS for partitions not in cyl 1
parameters to be used for BIOS calculations are:
cylinders=17849 heads=255 sectors/track=63 (16065 blks/cyl)

Media sector size is 512
Warning: BIOS sector numbering starts with sector 1
Information from DOS bootblock is:
The data for partition 1 is:
sysid 238 (0xee),(EFI GPT)
start 1, size 286749487 (140014 Meg), flag 80 (active)
beg: cyl 0/ head 0/ sector 2;
end: cyl 441/ head 84/ sector 11
The data for partition 2 is:
<UNUSED>
The data for partition 3 is:
<UNUSED>
The data for partition 4 is:
<UNUSED>

..kann das die Ursache für Invalid Partition sein?

Gruß,
Holm
 

mr44er

moderater Moderator
Teammitglied
Zieh' dir mal zunächst ein Backup von den Daten, falls nicht schon geschehen.

Kannst du denn booten, wenn du im BIOS umstellst, dass er von da1 oder da2 booten soll? Ist die Knopfzelle auf dem Board ok oder ist sie leer und BIOS-Einstellungen wurden zurückgesetzt, sodass deswegen nicht mehr gebootet werden kann?

Hast du das 'bootme attribute' gesetzt?

Hast du auf allen elis das bootflag?
Code:
geli list | grep Flags
Flags: BOOT

gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 da0 sollte schon richtig gewesen sein...
 

holm

Well-Known Member
Backup ist nicht lustig... ich weiß nicht recht wohin seit das Tandberg LTO parity errors macht (muß wahrscheinlich ein BGA nachlöten).
Alle 3 Disks haben "Flags: BOOT, GELIBOOT".

Das BIOS weiß nichts Wesentliches, der SAS Controller brings ein eigenes BIOS mit und verwaltet seine Daten selbst. Alle Platten kommen als "single Device" wieder hinten raus (ZFS ist mir lieber als jeder RAID Controller den ich kenne).

Ich habe die Kiste wieder oben und ich hab Dir zu danken. Die Ursache scheint die beim booten eigentlich überhaupt nicht involvierte 4. Disk (Sata) zu sein, auf der offensichtlich der normale bootcode installiert ist, der aber nie benutzt wurde.
# gpart show
=> 63 1953525105 ada0 MBR (932G)
63 1048574961 1 freebsd [active] (500G)
1048575024 904950144 2 freebsd (432G)

=> 0 1048574961 ada0s1 BSD (500G)
0 33554432 2 freebsd-swap (16G)
33554432 1015020529 4 freebsd-ufs (484G)

=> 0 904950144 ada0s2 BSD (432G)
0 16 - free - (8.0K)
16 904950128 1 freebsd-ufs (432G)

Das Ding habe ich offensichtlich mal mit sysinstall eingerichtet oder so.. den Swap habe ich auch noch nie benutzt...

Das Teil ist nun in der Bootreihenfolge auf unerklärliche Weise vor die SAS Platten gerutscht, hat den mbr botcode geladen und sich etwas weinerlich über die verfügbaren Partitionstabellen der Laufwerke geäußert. Die Partition auf der ada0 selbst hat ja auch keine als bootbar gesetze Partition..also habe ich die "Invalid partition" vor dieFüße geworfen bekommen. Unklar ist mir warum ich das nur 3 und nicht 4 mal zu sehen bekommen habe, 2 mal in kurzem Abstand, das 3. Mal einige Sekunden später...
Ich werde der Einfachheit habe einen Sektor Nullen über diesen mbr schreiben damit mir das nicht wieder passiert.

Der Rechner ist gestern abgekratzt als ich in virtualbox ein älteres debian installiert habe und nebenbei Telegram, viel Firefox und ein Video laufen hatte. 'KiCad auch noch offen, da kam bei den 8GB Ram der Maschinist mir der weißen Flagge raus.

Wie das zu Änderungen der Bootreihenfolge im Setup führen kann, ist mir schleierhaft. Datum usw. war ok und ich habe auch nichts
von Checksum bad oder so zu lesen bekommen.


Gruß,
Holm
 

mr44er

moderater Moderator
Teammitglied
ZFS ist mir lieber als jeder RAID Controller den ich kenne
Auf jeden Fall. Wobei man da ganz genau gucken muss, ob der Controller/HBAwhatever echtes passthrough mit den disks macht (so will man das für ZFS) vs. controllderdisk0-controllerdisk2 o.ä. rausreicht (unschön, Schachtel Pralinen mit Überraschung).

Wie das zu Änderungen der Bootreihenfolge im Setup führen kann, ist mir schleierhaft.
Evtl. Eigenart vom BIOS, Fehler in der Matrix, who knows. Da du Core2Quad schrubst, könnte man auch mal über den beginnenden Tod der Mainboardteile nachdenken...
Du kannst das ja testen, indem du runterfährst und den Netzstecker mal ein Minütchen gezogen lässt, damit sich alles entlädt. Ob die Batterie schwächelt, bekommt man bei einem warmcrashreset nicht mit. :)
 

holm

Well-Known Member
Auf jeden Fall. Wobei man da ganz genau gucken muss, ob der Controller/HBAwhatever echtes passthrough mit den disks macht (so will man das für ZFS) vs. controllderdisk0-controllerdisk2 o.ä. rausreicht (unschön, Schachtel Pralinen mit Überraschung).

Nein, der Controller ist ok, ich habe damals explizit den gelieferten Raid Controller gegen eine "plain" Variante getauscht.
mps0: <Avago Technologies (LSI) SAS2008> port 0xc000-0xc0ff mem 0xfe9fc000-0xfe9fffff,0xfe980000-0xfe9bffff irq 16 at device 0.0 on pci2
mps0: Firmware: 20.00.07.00, Driver: 21.02.00.00-fbsd
mps0: IOCCapabilities: 1285c<ScsiTaskFull,DiagTrace,SnapBuf,EEDP,TransRetry,EventReplay,HostDisc>

Das Ding kann gar kein Raid.

da0 at mps0 bus 0 scbus2 target 0 lun 0
da0: <HP DG146BABCF HPD5> Fixed Direct Access SPC-3 SCSI device
da0: Serial Number BS05P8402PCR0817
da0: 300.000MB/s transfers
da0: Command Queueing enabled
da0: 140014MB (286749488 512 byte sectors)
da2 at mps0 bus 0 scbus2 target 2 lun 0
da2: <HP DG146BABCF HPD6> Fixed Direct Access SPC-3 SCSI device
da2: Serial Number BS05P8B0LU1A0846
da2: 300.000MB/s transfers
da2: Command Queueing enabled
da2: 140014MB (286749488 512 byte sectors)
da1 at mps0 bus 0 scbus2 target 1 lun 0
da1: <HP DG146BABCF HPD5> Fixed Direct Access SPC-3 SCSI device
da1: Serial Number BS05P8402KAF0817
da1: 300.000MB/s transfers
da1: Command Queueing enabled



Evtl. Eigenart vom BIOS, Fehler in der Matrix, who knows. Da du Core2Quad schrubst, könnte man auch mal über den beginnenden Tod der Mainboardteile nachdenken...
Du kannst das ja testen, indem du runterfährst und den Netzstecker mal ein Minütchen gezogen lässt, damit sich alles entlädt. Ob die Batterie schwächelt, bekommt man bei einem warmcrashreset nicht mit.

Nee, da ist nix. Auch das das "Board" demnächst ablebt ist nicht in Sicht, da sind nur Polymer-Cs drauf und es handelt sich um ein IEI Slot-Industrieboard mit einer passiven Backplane. (zugelaufen) Ich bin Elektroniker, bei mir hält solches Zeug immer viel zu lange...

Gruß,
Holm
 

pit234a

Well-Known Member
das hatte ich aber genauso auch bei einem älteren PC und damals dann im Netz einige Beiträge gefunden, dass FreeBSD nicht über diese speziellen Controller (mit ZFS?) gebootet werden kann.
Damals habe ich mir dann einen Bootloader (mbr, boot0) auf einen USB-Stick gelegt und das System davon gestartet. Das wäre ja genau die Situation mit der zusätzlichen SATA, die nicht am Controller hängt und womöglich hattest du dann den gleichen Grund, das damals auch so zu machen.
 

holm

Well-Known Member
..verstehe ich nicht Pit.. Der Rechner ist ja nicht neu und der hat mit exakt diesem Controller auch schon ein Vinum Array gebootet, bis ich ihn mal auf ZFS umgestellt habe. Vorher waren das SCSI 70GB Platten an irgend einem Adaptec (29160?), Die SATA ist als Müllhalde später dazu gekommen.

Gruß,
Holm
 

Yamagi

Possessed With Psi Powers
Teammitglied
Es gibt da noch ein weiteres, sehr bescheidenes und durchaus mögliches Problem: Das ist ja noch ein echtes BIOS. Viele echte BIOSe können nicht unbegrenzt weit in eine Festplatte hineinlesen, sondern nur bis zu einer gewissen Anzahl Blöcke. Wenn durch das Update der /boot/loader und die anderen, für den Boot benötigten Dateien, zu weit nach hinten ins Dateisystem geschrieben wurden, können sie daher nicht mehr gelesen werden. Das würde zumindest erklären, weshalb er den Pool findet und erst am /boot/loader scheitert. Leider ist der einzige wirksame Würg-Around das ganze /boot auf eine eigene Partition zu legen, natürlich so weit wie möglich am Anfang der Platte. Was eine eher größere Operation wird.
 

holm

Well-Known Member
Yamagi das ist doch aber so gemacht, es existiert auf jeder Platte eine extra Partition für freebsd-boot in der gptzfsboot liegt "ganz vorne dran". Offensichtlich war aber das Problem, das der auf der SATA Platte enthaltene primäre boot zu doof (alt) war mit der gpt partition table und der ID 238 (oder so) überhaupt umzugehen.
Auf den Platten ist doch auch jeweils auch eine gefakte alte Partitionstabelle drauf, die eine einzige Partition (über die ganze Platte ..also 1023/255/63) enthält, damit das BIOS dort /boot/pmbr finden und laden kann. Die Operation habe ich also früher schon mal so gemacht.

@CommanderZed: Vorige Woche ging die Batterie noch, vorgestern und gestern nicht, heute geht sie wieder ...

Halte ich für unwahrscheinlich. Ich muß erst mal ne buildroot für einen Allwinner A20 auf einem Linux unter Virtualbox durchleiern, dann reboote ich nochmal und gucke ins "Bios". das zeigt mir die Spannung der Batterie an.
"Speicher nicht mehr der Beste" ...Das ist ein statische CMOS Ram und ne Prüfsumme liegt auch drüber..Du erszählst einem Elektroniker was vom blauen Pferd...

Ich vermute aber eher "Erdstrahlen" oder wie mr44er "Fehler in der Matrix" als Ursache, also Shit happens..oder wissenschaftlich Gammastrahlen aus dem Kosmos gibts auch, ECC RAM war früher mal..

Gruß,
Holm
 

Yamagi

Possessed With Psi Powers
Teammitglied
Yamagi das ist doch aber so gemacht, es existiert auf jeder Platte eine extra Partition für freebsd-boot in der gptzfsboot liegt "ganz vorne dran".
Nicht die Bootpartition. Die liest er anscheinend einwandfrei, schließlich läuft die erste Loader-Stufe und kann eine sinnvolle Fehlermeldung geben. Die erste Loader-Stufe versagt beim Lesen des /boot/loader aus dem ZFS. Was eine deutlich längere Partition ist. :) Ich sage ja auch nicht, dass das Problem (gewesen) sein muss. Nur, dass es ein Problem sein kann. Ich habe noch in der letzten reinen BIOS-Generation mit Westmere-CPUs Systeme gehabt, die nicht über 128 Gigabyte hinauslesen konnten. Was alle möglichen interessanten Probleme nach sich ziehen konnte.
 
Oben