[SOLVED] So - erstmal alles in die Luft geflogen

[MoxProxxer]

Einfach nur Wow.

Bisher:

• 2 nodes (A & B), Supermicro, jeweils 128GB RAM, liefen auf Debian
• 2 x Proxmox installiert, auch ein paarmal gebootet - tat alles wunderbar (laufen nicht als Cluster, sondern jede für sich, schubsen sich ein wenig NFS hin und her)

So vor 4 Stunden:

• BIOS Update auf node A -> exitus, bootet nicht mehr.
• Gut, denke ich mir, siehste nach wie Node B im BIOS konfiguriert ist... OK

Node A weiterhin tot, findet nix mehr zu booten.
Node B findet weiterhin Grub ABER

1. kommt sie nicht mehr ins BIOS, obwohl ich DEL wie ein Wilder drücke und "Entering Setup..." erscheint - lande ich immer wieder im Grub
2. Wenn ich den Proxmox Kernel/Eintrag boote dann kommt nur "loading initial ramdisk" und das war's dann
3. Glücklicherweise(?) ist da noch ein alter 4.9.0 Kernel (und zugehörige ramdisk) mit drauf. Wenn ich den boote, kommt Proxmox zwar hoch, aber sage und schreibe mit EINEM CPU Kern und stolzen 1.8GB RAM

Jo... damit läuft erstmal Node B mit ach und Krach. grub-update läuft ohne Probleme/Fehler durch, ein reboot-Versuch -> bleibt wieder im "loading initial ramdisk" stecken.

Viertel zwei - ich gehe jetzt schlafen. Morgen, ach ne ist ja heute, ist auch noch ein Tag um sich aufzuregen bzw. zu sorgen.

 

[MoxProxxer]

Nächster Morgen - weiter geht's. Ich halte hier erstmal einen Monolog was alles geht und was nicht geht, was ich versucht habe und als abschreckendes Beispiel wie tief man in den Sumpf sinken kann. Wenn dann einer meint irgendwo einen Strohhalm zu sehen, den ich übersehen habe, darf er sich gerne einklinken.

Also:

Node B - momentan mit Kernel 4.9.0, 1 CPU Kern und 1.8GB RAM, lasse ich erstmal laufen, da dieses - sozusagen - Limbische System so das einzige ist, was derzeit funktioniert.

Wenden wir uns Node A zu:

• Virtual Media Proxmox VE 5.3-2 iso gemounted und davon gebootet.
• Der Versuch "Rescue boot" wird mit "error: no such device: rpool" quitiert. Gefolgt von "Unable to find boot disk automatically". Das war wohl nix.

Was mir nicht ganz einleuchtet, der sollte doch zumindest in ein Rescue-System booten können. Also sehe ich mir mit "e" an was er da eigentlich versucht. Öh. Alles klar.

Das ist in etwa, wie wenn die Feuerwehr zu einem brennenden Haus kommt und dann aber anstatt zu löschen den Bewohnern darin ein Cheerleader-Tänzchen aufführt mit dem Slogan "Wir drücken euch die Daumen".

Ich hatte jetzt echt angenommen ein Rescue Boot würde wenigstens Kernel und Initramdisk von dem ISO image laden um so wenigstens ein laufendes Linux zu haben - und dann sähe man weiter. Aber er versucht irgendwie herumzustochern ob er ein vorhandenes OS findet?

Ja dann bräuchte ich keine Rescue.

 

[MoxProxxer]

So, Hosanna! Wo samma?

Node A läuft, sogar mit allen Hirnfunktionen (= alle Kerne + Speicher)!

Nachdem ich also SystemRescueCD verwendet habe, folglich erst einmal Arch Linux gebootet wurde, ich dann mittels fdisk -l und lsblk mich etwas orientiert habe wo was ist:

/dev/sda ist ein HW Raid aus zwei SSDs
/dev/sda1 -> EFI
/dev/sda2 -> Root

Und ich dann dieser Anleitung gefolgt bin, mich 5x vergewissert habe was eigentlich gebootet wird - meine efi partition ist nämlich irgendwie komisch:

/boot/efi
# ls -R
.:
EFI  grub
./EFI:
debian  proxmox
./EFI/debian:
fbx64.efi  grubx64.efi  mmx64.efi  pvex64.efi  shimx64.efi
./EFI/proxmox:
grubx64.efi
./grub:
grub.cfg  unicode.pf2

Zunächst einmal erstaunt es mich, dass es erstmal ein EFI Unterverzeichnis gibt. Der "debian" eintrag kann von der vorhergehenden Installation stammen, proxmox sicher neu. Das haben beim Umdate auch ide Timestamps der *.efi Dateien bestätigt. Das debian Zeug ist somit Altlast. (das pvex64.efi habe ich hinkopiert das ist der proxmox/grubx54.efi - war aber nicht nötig).

Also wenn jemand einen Tipp hat, wie ich das in "ein Standardformat" bringe, so dass sich Proxmox bei künftigen Updates nicht auskotzt - wäre ich sehr dankbar.

So ... wenden wir uns Node B zu. Ich bin ja zuversichtlich.

 

[MoxProxxer]

Node B muss noch warten, Node A will noch nicht so recht netzwerktechnisch.

Ums Verrecken (meinerseits, so die letzten 5,5 Stunden) kommen die VMs nicht raus ins Netz.

Auf dem vmhost, ping 8.8.8.8: tut.
ping/ssh auf eine (mit interner IP) VM: tut
auf VM ping auf host (auch seine externe IP): tut
ping von VM auf 8.8.8.8: nope

/proc/sys/net/ipv4/ip_forward ist natürlich auf 1

NAT/Policy gleiches Regewerk "was schon einmal tat".

Node Firewall war auf Yes - warum auch immer. Habe ich wieder aus. Eigentlich will ich nicht, dass bei Proxmox irgendwelche Schlümpfe was hinter meinem Rücken einstellen.

Und corosync spamt auch wieder fleissig.

 

[MoxProxxer]

Mittlerweile verdächtige ich den Proxmox Kernel 4.15.18-12-pve.

Wenn der nur ein wenig schlechter bei NAT/MASQUERADING ist, als copy&paste in diesem Forum, dann gute Nacht.

Besagte nodes A&B liefen ja vorher unter Debian mit einer libvirt Frickellösung. Die Installation von proxmox auf diese Maschinen klappte, allerdings liefen da andere Kernel als von proxmox mitgeliefert. Auf der einen 4.17, auf der anderen 4.19.

Nun läuft ja auf der lobotomierten Node B ein 4.9er Kernel - und da funktioniert das Netz auch so wie es soll.

Kurze Analyse:

Bei dem 4.15.18-12-pve gab es ein Problem mit dem starten der systemd-modules-load.service.
Bei genauerer Betrachtung ist das Laden der nvidia driver fehlgeschlagen. Das hatte offensichtlich kein Skript bei der Installation des Kernels gestört, dass die neu compiliert werden müssen.

Also ok, neu compiliert - nachdem ich "pve-headers"

https://forum.proxmox.com/threads/kernel-headers-for-kernel-4-15-18-10-pve-cannot-be-found.50972/

installiert, und

http://www.linuxandubuntu.com/home/how-to-install-latest-nvidia-drivers-in-linux

befolgt habe. Nun habe ich also einen proxmox Kernel mit den richtigen Nvidia Treibern, aber immer noch kein funktionierendes Masquerading

Nach - zugegeben mit Pausen - 10 Stunden trial & error und Mobilisierung diverser kompetenter Kollegen, kommt immer mehr der 4.15er Kernel in den Fokus.

Die Frage lautet nun, was haben alle diese nicht-Pve Kernel was PVE nicht hat? Da werde ich wohl ein wenig Fleißarbeit in den Vergleich der Modullisten stecken müssen.

So auf den ersten Blick ist nämlich im 4.9er Kernel "ipt_MASQUERADE" geladen, im 4.15.pve nicht.

tcpdump bringt das Problem relativ klar

Maschine ok (4.9):
tcpdump -nni eth0 dst host 8.8.8.8
20:21:07.429392 IP <extip>.41920 > 8.8.8.8.53: 34077+ A? 102-72-87-41-phase3telecom.com. (48)
20:21:07.441685 IP <extip>.45198 > 8.8.8.8.53: 42445+ A? 102-72-87-41-phase3telecom.com. (48)
20:28:53.289652 IP <extip>.38486 > 8.8.8.8.53: 19238+ PTR? 254.39.169.193.in-addr.arpa. (45)
20:28:53.300889 IP <extip>.46820 > 8.8.8.8.53: 25874+ A? netup.yugt.ru. (31)

Maschine nicht ok (4.15-pve)
# tcpdump -nni eth0 dst host 8.8.8.8
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
20:40:23.193646 IP <intip> 8.8.8.8: ICMP echo request, id 2793, seq 3, length 64
20:40:24.217613 IP <intip> 8.8.8.8: ICMP echo request, id 2793, seq 4, length 64
20:40:25.241756 IP <intip> 8.8.8.8: ICMP echo request, id 2793, seq 5, length 64

Das war ein Ping auf den 8.8.8.8 DNS von einer VM in internen Netz aus.

Die interne IP der VM wird einfach nicht übersetzt. Ich werde wohl nicht drum herum kommen mal eine gegenprobe mit einem Non-Proxmox Kernel zu machen ... bibber ... , hofentlich zerschiesst mir das nicht wieder mein EFI.

 

[fireon]

Hallo @MoxProxxer

mich würde ein genaues Festplatten/SSD Setup interessieren. Du schreibst ja /dev/sda ist ein HW Raid aus zwei SSDs. Gut was gibt es sonst noch? Sprich von wo sollte der Server booten? ZFS? Softwareraid...? Wichtig wäre mal zu wissen wie der Server überhaupt aufgesetzt wurde und die die ganze Filesystemstruktur gedacht war.

 

[MoxProxxer]

Also von den Platten her gibt es pro Node folgenden Kessel Buntes:

LSI 3108 MegaRAID
2 x SSD -> RAID 1 "OS Platte" (/dev/sda)
6 x HDD -> RAID 5 "Daten Platte" (/dev/sdb)

Aber das bootproblem wurde ja bereits gelöst. Das OS hat ja nichts anderes als /dev/sda zu interessieren.

1 x mSATA 250GB "Die kleine SSD für zwischendurch"
1 x SataDOM 64GB "Swapspace Bitch"
4 x HDD Software RAID (mdadm) "Grab für unwichtige Daten"

------------

Aufgesetzt wurden die Server 2015 mit Debian, damals noch Jessie, glaube ich. Dann eben Update auf Stretch, dann auf Buster, dann zurück auf Stretch ;-) dann Proxmox drauf.

Das muss man sich vorstellen wie die Schichten von Wandfarben, die sich im laufe der Jahre ansammeln. ;-)

 

[MoxProxxer]

Mein Problem ist ja ein ganz anderes momentan. Node A macht kein vernünftiges SNAT. Bzw. überhaupt kein SNAT.

Da bin ich jetzt schon über einen Tag lang dahinter. Mein Verdacht mit dem 4.15.er Proxmox Kernel hat sich nicht bestätigt, gleiches Problem auch mit einem 4.9er. Ich komme mir vor, wie der erste Mensch.

Ich gehe natürlich ergebnisoffen an die Sache ran, aber es muss ja definitiv an Proxmox liegen. Kann ja gar nicht anders sein. ;-)

Nun, jedenfalls habe ich nach reiflicher forensischer Analyse auf dem Problemserver - und nur auf diesem - das Paket

ifupdown2 1.2.2-1+pvetest1 all Network Interface Management tool similar to ifupdown

ausfindig gemacht. Muss mal schauen was das soll.

edit:

Problem nach 36 Stunden "ich oder der computer" gefunden!

iptables 1.6.0+snapshot2016...
iptables 1.8.2

Auf dem Server, der tat war? ... Ersteres
Downgrade iptables 1.8.2 -> 1.6.0blah: tut

Magie!

Auch interessant, dass beide Server durch die gleiche Installations-Genesis, zumindest seit stretch -> buster -> stretch -> Proxmox gegangen sind, und dennoch...

edit2:

1.8.2 war wohl ein Überbleibsel aus der vorherigen Buster installation und hat sich wohl erfolgreich einem Downgrade entzogen. die 1.6.0+snapshot scheint die offizielle stretch version zu sein.

Andererseits scheint die 1.8.2 unter Buster auch funktioniert zu haben.

Na wie dem auch sei, Node A läuft auf vollen Touren.
Hallo Node B...

 

[MoxProxxer]

Node B:

Und Ende Legende. Nicht gut. Nicht. Gut.

Insbesondere deswegen nicht gut, weil ich extra nochmal wie folgt vorgegangen bin:
https://wiki.debian.org/GrubEFIReinstall
Natürlich ein update-initramfs vorher, nirgends auch nur die Spur einer Fehlermeldung.

Ich verstehe diesen ganzen initial ramdisk Schrott eh nicht. Zu meiner Zeit(tm) hat man einfach einen monolithischen Kernel gehabt, der das System "hochgebracht" hat und für den ganzen optionalen "nice to have" Firlefanz gab es eben Kernelmodule.

Aber nein, die Jungspunte heutzutage müssen alles modern machen. Modern und fragil.

Also das übliche, mit dem 4.9.0er Kernel fährt die Node hoch, aber mit 1.8GB RAM und nur einem CPU Kern. Das wird wieder ein Klasse Sonntag.

edit:

Holy Shit. Holy Shit!
Das träume ich doch alles nur.

Der 4.15.xxx-pve Kernel+initramfs kommt nicht richtig hoch, weil ... keine Ahnung. Könnte aber damit zusammenhängen, dass das BIOS auf der Maschine echt Asbach Uralt ist.

Will ich also BIOS updaten. Geht nicht, weil mir SUM (Supermicro Update Manager) um die Ohren fliegt, weil

"SMBIOS Anchor String can't found" (Genau so und ich tippe den ganzen Dreck ab, weil dieses Forum immer noch kein copy&paste kann, langsam habe ich da echt keinen Bock)

Naja lange Story kurz:

Der Kernel 4.9 zeigt diesen SMBIOS Anchor string noch nicht. Klasse deadlock:
Kein (in.-band) Bios update wegen altem Kernel. Kein neuer Kernel wegen altem BIOS - vielleicht.

Also welche Optionen habe ich

* wieder SystemRescueCD - von da aus hoffen, dass vielleicht ein BIOS update klappt
* PVE initram debuggen, warum das Dingens partout unwillig ist
* Eigenen Kernel wie es halt echte Männer machen

 

[MoxProxxer]

Das ist alles wie ein schlechter Traum

Ok, BIOS ist auf 3.1 upgedated - out of band. Nach VIEL Mühe.
Trotzdem kommt immer wieder das PVE Grub2 - keine Chance ins Bios zu gelangen

Folglich ist die RescueCD Option Essig, weil ich kann das ISO zwar remote mounten, aber es wird einfach ignoriert. Ich kann DEL drücken, es erscheint sogar "Entering System Setup..." -> WIEDER im Grub.
Selbst wenn ich im Grub "System Setup" auswähle - kommt er wieder in den SCH** Grub.

Ich denke, da muss jetzt der Supermicro Support ran.

Aber das alles wäre evtl. nicht so tragisch gewesen, wenn das Proxmox team es schaffen würde ein Rescue mode zu basteln, der den Namen auch verdient.

Nein, "single" in die Kernel Commandline zu schreiben ist kein Rescue mode. Das ist mehr wie "Ich pewerfe das Proplem mit Fatte und hoffe, dass es weg geht."

Feierabend.

edit:

Neue Woche, neues Glück. Ich habe zumindest keine Halluzinationen:

https://ahelpme.com/servers/supermi...-del-or-other-when-uefi-mode-os-is-installed/

 

[MoxProxxer]

Zwischensieg!

4.15.18-12-(08/15,4711)-pve bootet.

Nachdem ich einen diff über die Inhalte der initrds 4.9 <-> 4.15 gemacht habe und es irgendwie 570 vs. 940 module stand, habe ich unter /etc/initramfs-tools/initramfs.conf

modules=dep

eingetragen (statt modules=all). Ich hatte es irgendwie so im Pipi, dass "Viel hilft viel" eben doch nicht immer stimmt.
Und tatsächlich: Erstelle ich wieder ein initrd mit modules=all -> Exitus.

Da wäre doch die Frage angebracht, welche Motivation das Proxmox team hatte das modules=all beizubehalten. Gibt es negative Erfahrungen mit modules=dep?

Leider hören damit die guten Nachrichten schon wieder auf.

• Immer noch komme ich nicht ins BIOS
• Immer noch kommt die maschine nur mit 1 Kern und 1.8GB RAM hoch

Die "Lösung" im o.g. Link (ahelpme.com) sich das EFI mutwillig zu zerschiessen... ich zaudere noch.
Hatte versucht im MegaRAID Bios die Bootplatte zu deaktivieren.

Naja - versucht - erfolgreich durchgeführt, aber man glaubt es kaum: Das Ding bootet trotzdem!
Franz Kafka hätte seine Freude dran.

Irgendjemand irgendwelche Tipps? (Selbstmord und Maschine neu aufsetzen sind keine Optionen - nur am Rande bemerkt)

 

[MoxProxxer]

Ich komme ins BIOS! Yay! Und zwar ohne mir das EFI zerschiessen zu müssen. Yay!

Was habe ich gemacht? Nach einigem Zaudern habe ich das BIOS des RAID Controllers deaktiviert.
Immerhin bietet er dann noch die Möglichkeit in sein Setup zu gehen und es zu reaktiviere - da hatte ich Angst dass ich nicht mehr hinkomme.

Also RAID Controller BIOS deaktiviert, der Server hat ein paar Ehrenrunden gedreht, ich immer mal wieder "Del" gedrückt, irgendwann hat er dann eingesehen, dass sein schönes EFI Grub nicht mehr erreichbar ist und ich kam ins BIOS setup.

Tja. Alles da, CPUs, Speicher VT enabled ... Friede Freude Eierkuchen.

RAID Controller BIOS enabled -> Grub -> Proxmox (4.15.12) -> Linux ... UUUND:

1 Kern + 1.8GB RAM

Das ist ein Fall für die Tischkante. Mit anderen Worten:

Hat irgendjemand irgendeine Idee warum Linux mit nur einem Kern und gerade dieser Menge an Speicher hochkommt?

Beide Maschinen gleicher Kernel, neueste intel microcode firmware...

Node A ist während des Bootvorgangs wesentlich gesprächiger was SMP anbelangt

(journalctl | grep -i smp)

bei nodeB ... Stille.

 

[MoxProxxer]

Endsieg!

https://bbs.archlinux.org/viewtopic.php?id=211994
(also: https://forums.gentoo.org/viewtopic-p-7849822.html)

=> 1:1 was ich hier beobachtet habe.


Man glaubt es kaum, aber /EFI/boot anstelle von /EFI/proxmox hat geholfen.


Damit könnte man natürlich eine wundervolle Diskussion lostreten über den Alkoholkonsum in der IT-Branche.
Zunächst bei den Programmierern, die Systeme im Vollrausch koten.
Dann bei den Anwendern dieser Systeme, die darin ihre Sorgen ertränken.

Aber ich bin müde und belasse es jetzt dabei.

 

[scaa]

Trotz Deiner Probleme... selten so einen amüsant geschriebenen Thread gelesen.

 

[Da-Tex]

Meine Reaktionen zu deinem Thread:
Uff, viel Spaß beim Troubleshoot.
Hä? Was hast du gemacht?
Bruder, ich fühle mit dir!
Wie jetzt? Selbstmord und neu aufsetzen willst du nicht? Hm.
Made my day!

Ich ziehe meinen Hut vor dir!

 

[MoxProxxer]

@scaa - "amüsant" ... Galgenhumor ist der Fachbegriff - glaube ich. ;-)

@Da-Tex danke für die vielen likes, Ich muss gestehen, dass ich zeitweise überhaupt nicht zum Spaßen aufgelegt war. Es gab da mehrere Personengruppen, denen ich mein "verlängertes Wochenende" über schon die Pest an den Hals gewünscht habe.

Euphemistisch gesprochen.

Da wäre zum einen Supermicro, Eine Firma mit - wieviel ? - 5 oder 6 tausend Mitarbeitern und dann, ich könnte ja erzählen, trifft man auf eine Mauer nach der anderen.

Den Abschuss liefern sie echt mit ihren "Webseiten". ASP Gefrickel wie aus den 90ern. eShop - nur für die USA, d.h. wenn man ein OOB BIOS update machen will über das IPMI und man sitzt in Europa, ist man erstmal am Arsch - mit Verlaub. (man könnte eine OOB Lizenz - für $30 - kaufen und diese via Email bekommen. Weil sie liefern diesen ~25 Zeichen langen Lizenzschlüssel via Email aus. Aber nein "Lieferung nur an eine postalische US Adresse). Naja - jetzt kann ich mir meine eigenen OOB Lizenzen machen. Auch was wert.

Dann empfehle ich mal jedem deren FAQ zu besuchen: https://www.supermicro.com/support/faqs/faq.cfm?faq=28033

und "Feedback zu geben" zu versuchen das Captcha da zu lösen. Nur zur Erinnerung: Wir schreiben das Jahr 2019

Ich meine: ich verstehe sehr gut, dass es bei jeder Systementwicklung Constraints gibt. Nicht genügend Zeit, Subsysteme von denen man abhängig ist, tun nicht wie sie sollen ... naja und das Endergebnis ist leider oft matschige Software.

Ich mache Linux seit 1994. Fakt ist, dass ich mir ohne entsprechendes Fachwissen solche Stunts nicht erlauben könnte. Und das schockiert mich, weil eigentlich mache ich ganz andere Sachen als bis zum Ellbogen in HW/OS-Administration Innereien zu wühlen. Solche Sachen sollten "einfach tun".

Wenn ich mir jetzt einen "Newbie" vorstelle, der erstmal draufkommen muss, dass der Unterschied zwischen "24 CPUs + 128GB RAM" und "1 CPU + 1.8GB RAM" ein grub in /boot/efi/EFI/boot stat in /boot/efi/EFI/proxmox ist...

Und das auch nur bei einer von 2 identischen Maschinen.

Dann war der Pest-an-Hals-Wunsch auch schon mal jeweils an die EFI und Kernelentwickler gerichtet. Das ist eigentlich das Frustrierendste an diesen Sachen. Die Systeme sind so komplex, man kann ja nicht einmal einen Schuldigen ausfindig machen. Wahrscheinlich sind alle schuld, weil sie nur in Ihre Teller gucken.

Naja und ich bin nicht 100% unschuldig. Ich meine die Maschinen waren schon ziemlich nonstandard aufgesetzt. Damit rechnet wohl niemand.

 

[AST]

Was SM angeht: Die liefern auch gerne die Kisten mit antiken Bios aus.
Das bedeutet, dass ich per default das Softwareraid für das PVE System booten konnte.
Nach dem Biosupdate lief es. Vergleichsweise simpel zu fixen, aber ich finde das auch .... seltsam.

Trotzdem bin ich nicht bereit horrende Summen für Hardware auszugeben nur weil da ein Markenname draufsteht.