0 Persons are tagged with #proxmox

#proxmox

ws01@diasp.org
Wolfgang Strobl

Basteleien an meiner privaten Wolke - hier: der Stromausfall

Eine Fortsetzung dieser Schilderung

  • Zusammenfassung: wir hatten einen Stromausfall, eine Phase war weg. Als der Strom wieder da war, kam eines von zwei mit Proxmox betriebenen DeskMini 110-Kistchen nicht wieder hoch: mausetot. Ursache: CMOS fehlerhaft, so dass sich das BIOS mutmaßlich noch vor dem Initialisieren der Peripherie (incl. Displayschnittstellen) aufhängte.

Nach dem manuellen Löschen des CMOS, wozu das Mainboard ausgebaut werden muss, lief's wieder. Aaaber - die 2017 gekauften Kistchen sind jetzt schon knapp sechs Jahre alt, sehr wahrscheinlich, dass der Pufferakku (oder, wie hier, die CR2032-Lithiumzelle) nicht mehr genügend Spannung hat. Gemessen hatte ich nicht bzw. nur flüchtig, weil das nur mit Verrenkungen möglich ist: es gibt da nicht die übliche Fassung, sondern die mit angeschweissten Crimpfahnen und per Schrumpfschlauch isolierte Zelle wird mit einem winzigen Molexstecker mit dem Mainboard verbunden und ist ansonsten mit einem Stück zweiseitigem Klebeband auf einer freien Fläche auf der Rückseite des Mainboards festgeklebt. Man braucht zwei Stecknadeln, zwei Krokodilklemmen und einiges an Vorsicht, um das mit einem Vielfachmessinstrument messen zu können. Abgesehen davon, solche Teile habe ich nicht im Hause, wollte aber nicht ohne Infrastruktur bleiben. Und solange die Maschinchen am Netzteil hängen, bedarf es der Pufferung nicht.

Da keiner der von mir sonst bevorzugten Lieferanten diese Bauform anbot, habe aus dem wie üblich konfusen Angebot von Amazon einen Anbieter rausgesucht und fünf Stück bestellt und mich heute an die Arbeit gemacht. Da in einigen Reviews darüber gemeckert wurde, die gelieferten Batterien hätten verpolte Anschlüsse, habe ich vorsichtshalber das abgezogene Original von Asrock mit den gelieferten Batterien verglichen.

Schwarz ist das Original, gelb eine der gelieferten Zellen, nach dem Kürzen und Vertauschen der Anschlüsse. Der Stecker war in der Tat falsch herum angecrimpt, die Farben der Kabel stimmen, rot ist plus, schwarz minus. Wobei unklar ist, ob es hier einfach keinen Standard gibt, was allerdings auch nicht viel helfen würde, da weder Asrock in den Unterlagen überhaupt mehr verrät, als in einer Zeichnung zu zeigen, wo sich die Batterie befindet, noch die Anbieter umfangreiche Kompatibilitätslisten führen. Immerhin passt der Stecker. Also: ein Stück rausgeschnitten, passende Schrumpfschläuche rausgesucht, abisoliert und verlötet. Wie man so sagt, passt, wackelt und hat Luft. :-)

Vor dem Einbau der neuen Batterie

Nach dem Einbau der modifzierten neuen Batterie

Nach dem Umbau

Als vorsichtiger Mensch habe ich erst die Ersatz- und Testmaschine bestückt, geprüft, ob die Pufferbatterie auch tatsächlich puffert und dann eine zweite Zelle vorbereitet, eingebaut und auch da getestet. Immerhin hängt hier mein ganzer Flohzirkus dran, interner Webserver (ein Hybrid aus Zope und Plone, dessen Workspace bis 2008 zurückreicht), Telefonlog nebst Telefonbuch (eine kleine Django-Anwendung) noch aus ISDN-Zeiten, der bis Anfang 2000 zurückreicht, Proxy, ein OSM-Tileserver, ein paar verwaiste VM für Entwicklungszwecke, aus der Zeit, als ich noch mehr mit Microcontrollern herumgebastelt habe, ein CVS aus uralten Zeiten als Archiv, ein Mercurial-Host, den ich immer noch heftig nutze (Git mag ich nicht), usw. usf. Ich habe mich schon lange daran gewöhnt, dass das alles mehr oder weniger ohne Unterbrechungen zur Verfügung steht.

Und der Stromausfall?

Nun, die erste geplante Stromabschaltung wurde angekündigt, ich hab' morgens alles brav heruntergefahren, auf die Abschaltung gewartet und dann eine halbe Stunde nach Ende des maximalen Zeitintervalls angerufen. Nichts war, die Reparatur des defekten Hausanschlusses bei einem der Nachbarn musste offenbar verschoben werden. Also neues Spiel, neues Glück in ein paar Tagen. :-/

Und ich hab' immer gelästert, dass wir hier in der Stadt wenigstens einen Vorteil gegenüber den Kollegen auf dem Lande hätten: eine stabile Stromversorgung, die nicht bei jedem Gewitter die Grätsche macht.

#proxmox #heimwolke #deskmini #bastelkram

root@truenas[~]# uptime 6:05AM up 585 days, 14:33, 1 user, load ave...

root@truenas[~]# uptime 6:05AM up 585 days, 14:33, 1 user, load averages: 0.39, 0.26, 0.24 Und gleich muss ich auch diesen Dauerläufer runterfahren, weil eine der hier extrem seltenen Stromausfälle ansteht 🙁. Genauer gesagt, eine zwecks...

2 Likes
1 Comments
ws01@diasp.org
Wolfgang Strobl 
root@truenas[~]# uptime
 6:05AM  up 585 days, 14:33, 1 user, load averages: 0.39, 0.26, 0.24

Und gleich muss ich auch diesen Dauerläufer runterfahren, weil eine der hier extrem seltenen Stromausfälle ansteht 🙁. Genauer gesagt, eine zwecks Reparatur angekündigte geplante Stromabschaltung legt das nahe. Eine marode Leitung - oder ein maroder Hausanschluss in der Nähe, so genau weiß man das nicht - hatte vor ein paar Tagen eine Phase lahmgelegt, aber nicht die, an der mein NAS hängt.

Eines von zwei kleinen Kistchen, die hier als Proxmox-Host dienen, hatte es beim unangekündigten Ausfall schlimmer erwischt: das hing im Keller an der einen ausgefallenen Phase und war nachher dem Anschein nach mausetot, kein Bild, kein Ton. Nun, nicht ganz, den CMOS-RAM hatte es auf eine Weise gehimmelt, dass nicht mal die VIdeo-Interfaces initialisiert wurden. Um den zu löschen, müssen beim DeskMini 110 auf der Rückseite des Mainboards direkt hinter dem Batterie zwei Lötstellen mit dem Schraubenzieher kurzgeschlossen werden, dazu mussten beide auf der Unterseite des Einschubs festgegeschraubten 2.5-Platten nacheinander entfernt und das Mainboard ausgebaut werden - das ist halt der Preis für Kompaktheit. Danach liefe das Maschinchen wieder wie geschmiert.

EInmal musste ich es allerdings doch noch herunterfahren: beim Default "Standard" für den CPU-Kühler lärmt der Blower der Boxed-Version der CPU ziemlich, ich hab's wieder auf Silent gestellt. Das andere Kistchen steht auf meinem Schreibtisch, da habe ich einen passenden Noctua-Kühler verbaut, der ist leiser.

Ansonsten tun die beiden kleinen Kistchen hier seit über fünf Jahren ihren Dienst, ohne zu mucken. Einer dient als Host für alle essentiellen VM, der andere gewissermassen als Backup und als Testsystem.

#truenas #proxmox #heimwolke

One person like that
nbuechner@pod.haxxors.com
Nils

Find the LUKS encryption key in a memory dump file of a Proxmox VM

  • Get the partitions from the VM's qcow2 file

ls -alh
-rw-r----- 1 root root 33G Jan 3 19:17 vm-102-disk-0.qcow2
-rw-r----- 1 root root 448M Jan 3 18:05 vm-102-state-luks.raw

modprobe nbd max_part=8
qemu-nbd --connect=/dev/nbd0 vm-102-disk-0.qcow2
fdisk -l

Device        Start      End  Sectors Size Type
/dev/nbd0p1    2048     4095     2048   1M BIOS boot
/dev/nbd0p2    4096  4198399  4194304   2G Linux filesystem
/dev/nbd0p3 4198400 67106815 62908416  30G Linux filesystem
  • Find the master key in the memory state dump of the VM with findaes

findaes vm-102-state-luks.raw
Searching vm-102-state-luks.raw
Found AES-256 key schedule at offset 0xb1428dc:
23 02 57 16 22 c1 d4 4f 13 09 00 fa 6c 63 e7 4c 84 91 e1 a3 c5 99 c9 ee 6a 17 cc c7 1f 01 21 f5
Found AES-256 key schedule at offset 0xb142cdc:
22 d2 a6 2e 48 b4 13 d9 4e 1b ed 0c 0b d0 ec 13 e6 39 02 ea 8f b1 dc 70 78 71 89 3f 67 76 a4 2f
Found AES-256 key schedule at offset 0xd97da7a:
38 f3 74 9a 2e 31 92 b0 b4 95 3f 91 c0 cf a7 b9 8b 3e e8 7e bd a0 88 c8 18 4d 8a b0 ee 83 76 66
Found AES-256 key schedule at offset 0xd97dc4a:
38 f3 74 9a 2e 31 92 b0 b4 95 3f 91 c0 cf a7 b9 8b 3e e8 7e bd a0 88 c8 18 4d 8a b0 ee 83 76 66
Found AES-256 key schedule at offset 0xd97deda:
00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f
Found AES-256 key schedule at offset 0xd97e4ba:
d0 b1 91 2f 5b e4 1a c2 7b 96 2f 61 ad bd 25 7d 8a b7 fc 58 f6 99 07 77 dc bd bd b6 fa 18 5a 79
Found AES-256 key schedule at offset 0xd97f69a:
d0 b1 91 2f 5b e4 1a c2 7b 96 2f 61 ad bd 25 7d 8a b7 fc 58 f6 99 07 77 dc bd bd b6 fa 18 5a 79
Found AES-256 key schedule at offset 0xd97f92a:
00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f
Found AES-256 key schedule at offset 0xd9898ac:
31 31 1a 7b 47 92 f6 b8 d5 a4 c2 fb f7 cb a5 ff 5a 28 4d 3b d5 d8 7e 63 fa 8a d0 73 86 79 e3 15
Found AES-256 key schedule at offset 0xd989a7c:
31 31 1a 7b 47 92 f6 b8 d5 a4 c2 fb f7 cb a5 ff 5a 28 4d 3b d5 d8 7e 63 fa 8a d0 73 86 79 e3 15
Found AES-256 key schedule at offset 0xd989d0c:
00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f

  • In this case the first 2 matches combined are the master key (2x 256 bits = 512 bits key length)

This may not always be the case. Your best bet is to find two 256 bit keys with successive memory addresses.

  • Copy the combined key to a textfile

echo "2302571622c1d44f130900fa6c63e74c8491e1a3c599c9ee6a17ccc71f0121f522d2a62e48b413d94e1bed0c0bd0ec13e63902ea8fb1dc707871893f6776a42f"
> masterkey.txt

  • Convert masterkey to binary format

xxd -r -p masterkey.txt masterkey.bin

  • Open luks volume

cryptsetup --master-key-file masterkey.bin luksOpen /dev/nbd0p3 myluks

  • Open LVM and mount the VM's filesystem

mkdir /mnt/myluks
vgscan --mknodes
Found volume group "ubuntu-vg" using metadata type lvm2

mount /dev/mapper/ubuntu--vg-ubuntu--lv /mnt/myluks
ls -alh /mnt/myluks/
total 2,1G
drwxr-xr-x 19 root root 4,0K Jan 3 18:03 .
drwxr-xr-x 6 root root 4,0K Jan 3 19:15 ..
lrwxrwxrwx 1 root root 7 Aug 9 13:53 bin -> usr/bin
drwxr-xr-x 2 root root 4,0K Jan 3 17:57 boot
drwxr-xr-x 4 root root 4,0K Aug 9 13:56 dev
drwxr-xr-x 78 root root 4,0K Jan 3 18:04 etc
drwxr-xr-x 3 root root 4,0K Jan 3 18:04 home
lrwxrwxrwx 1 root root 7 Aug 9 13:53 lib -> usr/lib
lrwxrwxrwx 1 root root 9 Aug 9 13:53 lib32 -> usr/lib32
lrwxrwxrwx 1 root root 9 Aug 9 13:53 lib64 -> usr/lib64
lrwxrwxrwx 1 root root 10 Aug 9 13:53 libx32 -> usr/libx32
drwx------ 2 root root 16K Jan 3 17:57 lost+found
drwxr-xr-x 2 root root 4,0K Aug 9 13:53 media
drwxr-xr-x 2 root root 4,0K Aug 9 13:53 mnt
drwxr-xr-x 2 root root 4,0K Aug 9 13:53 opt
drwxr-xr-x 2 root root 4,0K Apr 18 2022 proc
drwx------ 4 root root 4,0K Jan 3 18:41 root
drwxr-xr-x 9 root root 4,0K Aug 9 13:57 run
lrwxrwxrwx 1 root root 8 Aug 9 13:53 sbin -> usr/sbin
drwxr-xr-x 2 root root 4,0K Jan 3 18:04 snap
drwxr-xr-x 2 root root 4,0K Aug 9 13:53 srv
-rw------- 1 root root 2,0G Jan 3 17:58 swap.img
drwxr-xr-x 2 root root 4,0K Apr 18 2022 sys
drwxrwxrwt 8 root root 4,0K Jan 3 18:59 tmp
drwxr-xr-x 14 root root 4,0K Aug 9 13:53 usr
drwxr-xr-x 13 root root 4,0K Aug 9 13:57 var

#proxmox #luks #encryption #linux #opensource #virtualization #security

6 Likes
1 Comments
tux@anonsys.net
Tuxi ⁂

#til Auf einer meiner #Proxmox VM mit #Ubuntu ist mir der Speicherplatz vollgelaufen. Also die VM runtergefahren, die die Festplatte vergrößert und mit #GParted den neuen leeren Speicherplatz der Partition zugewiesen.
Allerdings habe ich mich gewundert, dass nach einem Neustart der VM immer noch zu wenig Speicherplatz in der VM angezeigt wurde und die neuen zusätzlichen 20 GB nicht angezeigt wurden.
Nach einer Recherche im Forum von Proxomox war mir dann klar warum. Ich musste noch mit sudo lvresize --extents +100%FREE --resizefs /dev/mapper/ubuntu--vg-ubuntu--lv den neuen freien Speicherplatz der Partition zuweisen.
Jetzt läuft wieder alles so wie es soll. 👍
#Linux #Admin #til

One person like that
6 Comments
5 Likes
canoodle@nerdpol.ch
SilouettE

How to disassemble Harddisk Upgrade - Inside a Lenovo ThinkCentre M92p - 1962 error : No operation system found fixed by 2018 bios update

they are fast, they are small, they use very little energy (less than 30W), the Lenovo ThinkCentre M92p despite being also pretty old (2012) it still rocks, the naming ain’t sexy, but they work very well.

now let’s look inside:

it meassures:

  • width: 18cm
  • “depth”: 18.5cm
  • height: 3.5cm

extremely compact.

this opening procedure was done to upgrade the ssd harddisk.

what is special about the M92p: it still has a tiny tiny speaker inside 🙂

for all those beep code symphonies

How to disassemble Harddisk Upgrade – Inside a Lenovo ThinkCentre M92p – 1962 error : No operation system found

this happens, when trying to install Proxmox like in this how to article.

in order to fix this

windows 10 (yes argh) needs to be installed & BIOS update applied:

Intel ME almost no BIOS without it… with t440 it was able to “disable it permanently”

[video width=”502″ height=”492″ mp4=”https://dwaves.de/wp-content/uploads/2022/05/Lenovo-ThinkCentre-M92p-1962-error-No-operation-system-found-update-bios-to-version-2018-flash-process.mp4″\]\[/video\]

  • let it sit for a while… when the blinking cursor comes up… let it blink for a while…
  • remove all usb drives…
  • Ctrl+Alt+Del…
  • it should reboot fine
  • re-apply all bios settings

so updated from BIOS 2012 to 2018 version and now proxmox boots up fine.

#linux #gnu #gnulinux #opensource #administration #sysops #lenovo #hardware #bios #upgrades #upgrade #proxmox

Originally posted at: https://dwaves.de/2022/05/25/how-to-disassemble-harddisk-upgrade-inside-a-lenovo-thinkcentre-m92p-1962-error-no-operation-system-found-fixed-by-2018-bios-update/