Hallo zusammen,
Proxmox 9 ist seit kurzer Zeit verfügbar. Ist es ratsam, Proxmox 9 zu installieren. Fhem läuft auf einer VM in Proxmox.
Viele Grüße Gisbert
Ich würde ruhig noch bis 9.2 oder 9.3 warten.
Läuft bei mir in meine 4 node Cluster sehr stabil seit ca 2 Wochen.
Warten ist nicht nötig. Läuft hier absolut stabil seit zwei Wochen. RaspberryMatic in VM, FHEM in Ubuntu-lxc, mehrere andere lxc drum herum mit bspw. Homebridge usw.
Hallo CoolTux, carlos und Ralli,
vielen Dank für eure Einschätzungen und Erfahrungen. Das Risiko eines Updates scheint demnach klein bzw. nicht vorhanden zu sein, aber ich werde dem Rat von CoolTux folgen und erst mal meine Füße (und Finger) still halten.
Viele Grüße Gisbert
Mach erst einmal ein
apt update && apt dist-upgrade -y && apt auto-remove -y
um die aktuelle Version auf den letzten Stand zu bringen und dann lass doch mal das Prüfscript "pve8to9 --full" laufen.
Hallo Ralli,
pve8to9 liefert bis auf eine Warnung nichts weiter, der Rest ist mir klar:
INFO: Checking if matching CPU microcode package is installed.
WARN: The matching CPU microcode package 'intel-microcode' could not be found! Consider installing it to receive the latest security and bug fixes for your CPU.
Ensure you enable the 'non-free-firmware' component in the apt sources and run:
apt install intel-microcode
Eine Installation von Intel-Microcode schlägt jedoch fehl.
Viele Grüße Gisbert
Dazu findest du Hinweise im Proxmox-Forum - und es steht schon da, was das Problem ist. Die musst die sources erweitern.
Zitat von: Ralli am 03 September 2025, 20:29:57Dazu findest du Hinweise im Proxmox-Forum - und es steht schon da, was das Problem ist. Die musst die sources erweitern.
Hallo Ralli,
nachdem ich non-free in sources list angehängt hatte, bekomme ich folgendes:
root@FutroS740:/var/log# apt install intel-microcode
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Package intel-microcode is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source
E: Package 'intel-microcode' has no installation candidate
root@FutroS740:/var/log#Ein apt update hatte ich vorher auch gemacht - auch da stand für mich etwas unverständliches drin:
...
All packages are up to date.
N: Repository 'Debian bookworm' changed its 'non-free component' value from 'non-free' to 'non-free non-free-firmware'
N: More information about this can be found online in the Release notes at: https://www.debian.org/releases/bookworm/amd64/release-notes/ch-information.html#non-free-splitGibt es eine Schritt-für-Schritt-Anleitung, die ich befolgen kann?
Viele Grüße Gisbert
Hallo Gisbert
Im besten Fall sind die Microcode Updates schon im BIOS-Update vom Januar enthalten. Hab aber auf die Schnelle nix auf der Supportseite von Fujitsu gefunden.
Laut der angegebenen Info-Seite wurde "non-free" und der Teil "non-free-firmware" getrennt. Du müsstest also "non-free-firmware" in die Sources eintragen.
Gruß Ralf
Zitat von: RalfRog am 04 September 2025, 10:53:22Hallo Gisbert
Im besten Fall sind die Microcode Updates schon im BIOS-Update vom Januar enthalten. Hab aber auf die Schnelle nix auf der Supportseite von Fujitsu gefunden.
Laut der angegebenen Info-Seite wurde "non-free" und der Teil "non-free-firmware" getrennt. Du müsstest also "non-free-firmware" in die Sources eintragen.
Gruß Ralf
Hab's so gemacht, damit läuft ein update und install intel-microcode durch.
Ich hab den Proxmox-Server mal neu gestartet, die Fhem-VM musste ich separat neu booten.
Jetzt läuft pve8to9 ohne nennenswerte Warnungen, lediglich 2 erwartbare Warnungen sind vorhanden:
1) VMs laufen noch.
2) Ein abgeschalteter PBS ist nicht erreichbar.
Viele Grüße Gisbert
Na prima geht doch ;D
Aber wo du gerade die Microcodes eingespielt hast folgende Frage:
(mein S740 läuft mit BIOS Update vom Januar <BIOS V5.0.0.13 R1.14.0> und MicroCodeVersion 0x40)
Laut Intel ist 0x40 die letzte Aktuelle Version für den J4105
(https://www.intel.com/content/www/us/en/developer/topic-technology/software-security-guidance/processors-affected-consolidated-product-cpu-model.html#tab-blade-1-0).
Interessant wäre mal, ob bei dir nun etwas anders ist. Frag doch mal auf dem Host ab:
cat /proc/cpuinfo | grep microcode
Gruß Ralf
Zitat von: RalfRog am 04 September 2025, 12:01:25Na prima geht doch ;D
Aber wo du gerade die Microcodes eingespielt hast folgende Frage:
(mein S740 läuft mit BIOS Update vom Januar <BIOS V5.0.0.13 R1.14.0> und MicroCodeVersion 0x40)
Laut Intel ist 0x40 die letzte Aktuelle Version für den J4105
(https://www.intel.com/content/www/us/en/developer/topic-technology/software-security-guidance/processors-affected-consolidated-product-cpu-model.html#tab-blade-1-0).
Interessant wäre mal, ob bei dir nun etwas anders ist. Frag doch mal auf dem Host ab:
cat /proc/cpuinfo | grep microcode
Gruß Ralf
Hallo Ralf,
ich bekomme folgende Antwort:
root@FutroS740:~# cat /proc/cpuinfo | grep microcode
microcode : 0x42
microcode : 0x42
microcode : 0x42
microcode : 0x42
root@FutroS740:~#Was sagt dir das?
Muss/soll ich ein BIOS- Update einspielen und wo finde ich das ggf.?
Viele Grüße Gisbert
Hast Du in Deinen Debian apt source files none-free-firmware mit drin stehen? Darin sollten sich die Intel Microcode Packete befinden.
Checken kannst Du mit
journalctl -k | grep -E "microcode" | head -n 1
Zitat von: Gisbert am 04 September 2025, 18:07:13....
Muss/soll ich ein BIOS- Update einspielen und wo finde ich das ggf.?
Finden: https://support.ts.fujitsu.com/IndexDownload.asp
Soll/Muss: ich hatte das BIOS eine Version hochgezogen, als ich den S740 Anfang des Jahres in Betrieb genommen habe. Deiner läuft ja schon ein wenig länger.
Das steht in den RealeasNotes (sagt mir ehrlicherweise nicht wirklich viel bzw. wie relevant z.B. die INTEL PLATFORM UPDATE (IPU) sind):
ZitatBIOS R1.14.0 for D3544-A1:
20/Dec/2024
· New GLK Microcodes implemented: M01706A1_00000040
· New Intel TXE FW: 4.0.55.2201
· FIX: TXE FW is not updated with normal update by DeskFlash or Binary Flash by EfiBinFlash.
· FIX: EFI Shell USB stick is not detected as boot device if FUJITSU Update Utility is present on USB
· FIX: GLK - FWHunt - potential security issue - BIOS R1.13
· Update: Security Advisory for GeminiLake
· Component Updates
· IPU 2022.3 implemented.
· IPU 2023.3 implemented.
· IPU 2024.1 implemented.
· IPU 2024.3 implemented.
Zitat von: Gisbert am 04 September 2025, 18:07:13Was sagt dir das?
Dass, das Microcode Paket aus "none-free-firmware" eine neuere Revision 0x42 enthält. Hat mich einfach mal interessiert, ob mit der Installation des Paketes etwas passiert.
Gruß Ralf
Zitat von: CoolTux am 02 September 2025, 18:29:57Ich würde ruhig noch bis 9.2 oder 9.3 warten.
Für mich werde ich es wohl so halten. Bis dahin gibt es vielleicht noch den ein oder anderen Beitrag über Fallstricke ;)
Zitat von: CoolTux am 04 September 2025, 18:17:44Hast Du in Deinen Debian apt source files none-free-firmware mit drin stehen? Darin sollten sich die Intel Microcode Packete befinden.
Checken kannst Du mit
journalctl -k | grep -E "microcode" | head -n 1
Hier ist die Antwort:
root@FutroS740:~# journalctl -k | grep -E "microcode" | head -n 1
Sep 04 11:16:20 FutroS740 kernel: microcode: Current revision: 0x00000042
root@FutroS740:~#Bei mir steht in den apt sources files jetzt an 3 Stellen none-free-firmware drin:
deb http://ftp.debian.org/debian bookworm main contrib non-free-firmware
deb http://ftp.debian.org/debian bookworm-updates main contrib non-free-firmware
# Proxmox VE pve-no-subscription repository provided by proxmox.com,
# NOT recommended for production use
deb http://download.proxmox.com/debian/pve bookworm pve-no-subscription
# security updates
deb http://security.debian.org/debian-security bookworm-security main contrib non-free-firmware
Wenn das non-free-firmware jetzt drin steht dann mach apt update und dann apt search nach firmware oder intel-firmware oder so.
Gisbert hat doch jetzt das letzte Microcode-Update drin 0x42. Ohne wäre er auf maximal 0x40 (über BIOS update Januar R1.14.0 wie bei mir).
Zitat von: Gisbert am 04 September 2025, 11:27:24Hab's so gemacht, damit läuft ein update und install intel-microcode durch.
Wenn das Paket installiert ist, stehen die Microcodefiles unter /lib/firmware/intel-ucode . Für den Intel(R) Celeron(R) J4105 (Family:6, Model:122 <7Ahex>, Stepping:1) ist es die Datei "/lib/firmware/intel-ucode/06-a7-01".
Intel stellt das zur Verfügung unter:
https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files bzw. https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/releases
von da wird es wohl in die Distri "wandern".
Gruß Ralf
Zitat von: RalfRog am 05 September 2025, 17:54:37Gisbert hat doch jetzt das letzte Microcode-Update drin 0x42. Ohne wäre er auf maximal 0x40 (über BIOS update Januar R1.14.0 wie bei mir).
Zitat von: Gisbert am 04 September 2025, 11:27:24Hab's so gemacht, damit läuft ein update und install intel-microcode durch.
Wenn das Paket installiert ist, stehen die Microcodefiles unter /lib/firmware/intel-ucode . Für den Intel(R) Celeron(R) J4105 (Family:6, Model:122 <7Ahex>, Stepping:1) ist es die Datei "/lib/firmware/intel-ucode/06-a7-01".
Intel stellt das zur Verfügung unter:
https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files bzw. https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/releases
von da wird es wohl in die Distri "wandern".
Gruß Ralf
Hallo Ralf,
ich hab mir das neueste BIOS-Update auf einen Stick gezogen und überlege, ob ich es aufspielen soll. Dazu muss ich die VMs und den Server runterfahren und dann nach Anleitung das BIOS updaten. Wie bei allem gibt es ein Rest-Risiko, dass etwas schief läuft.
Wie sinnvoll oder notwendig ist ein BIOS-Update?
Viele Grüße Gisbert
Zitat von: Gisbert am 05 September 2025, 20:26:02Wie sinnvoll oder notwendig ist ein BIOS-Update?
Gute Frage
Bei mir war die Entscheidung damals leicht, da der Futro noch nicht in Betrieb war.
Wie in #14 schon erwähnt sagen mir die ReleaseNotes nicht wirklich was und keine Ahnung wie relevant die Security Advisories sind.
Andererseits hat mich der Thread hier schauen lassen was im BIOS-Update meines PC mit GigabyteBoard drin ist und es aufgrund einiger Microcode Updates dann auch gemacht.
Gruß Ralf
Hallo zusammen,
auch ich werde wohl demnächst auf V 9 umsteigen wollen.
Mein pve8to9-Lauf reportet zunächst den Fehler:
FAIL: systemd-boot meta-package installed. This will cause problems on upgrades of other boot-related packages. Remove 'systemd-boot' ...
Soviel ich bisher eruiert habe wäre der Fehler so zu beseitigen:
- Entferne und purge das Paket:
apt remove --purge systemd-boot
- Verifiziere, dass es nicht mehr installiert ist:
dpkg -l | grep systemd-boot
- Proxmox VE setzt standardmäßig auf GRUB. Installiere ggf. die EFI-Variante neu und aktualisiere die Konfiguration:
apt update
apt install --reinstall grub-efi-amd64 grub-efi-amd64-signed
update-grub
- Falls das System im BIOS-Modus läuft, genügt:
apt install --reinstall grub-pc
update-grub
- System neu starten
Kann jemand diese Vorgehensweise bestätigen und hat diesen Fehler evtl. schon in seinem System beseitigt?
LG,
Heiko
Hallo Heiko,
darauf gibt es kein einfaches Ja oder Nein, sondern hier heißt es "Das kommt darauf an".
Siehe https://pve.proxmox.com/wiki/Host_Bootloader .
Grundsätzlich ist erst einmal nur das Paket systemd-boot zu de-installieren, danach das pve8to9 neu ausführen.
Zitat von: DS_Starter am 06 September 2025, 09:17:58- Proxmox VE setzt standardmäßig auf GRUB. Installiere ggf. die EFI-Variante neu und aktualisiere die Konfiguration:
Code Auswählen Erweitern
apt update
apt install --reinstall grub-efi-amd64 grub-efi-amd64-signed
update-grub
- Falls das System im BIOS-Modus läuft, genügt:
Code Auswählen Erweitern
apt install --reinstall grub-pc
update-grub
Hallo Heiko,
kannst du die Punkte mit GRUB noch etwas näher erläutern?
Bei mir erscheint bei jedem upgrade ein Kommentar/Warnung zu GRUB, dem ich aber bislang keine Bedeutung zugemessen hab. Falls demnächst ein Paket zu upgraden ist, dann kopiere ich mir den Passus raus.
Viele Grüße Gisbert
Hallo Gisbert,
ich stecke im Detail auch nicht tiefer drin.
Was ich weiß ist, dass der GRUB für Grand Unified Bootloader steht und ein freier Bootloader ist. Er übernimmt als erstes Programm nach BIOS oder UEFI die Kontrolle, lädt den Betriebssystemkernel in den Arbeitsspeicher und startet ihn.
Beim Systemstart zeigt GRUB ein Auswahlmenü aller installierten Betriebssysteme und Kernel-Versionen an. Du kannst dort interaktiv auswählen, was gebootet werden soll. GRUB lädt dann den gewählten Kernel mit den konfigurierten Startparametern und übergibt die Kontrolle an das Betriebssystem.
Ich werde wie von Ralli vorgeschlagen auf einem Knoten erstmal vorsichtig beginnen und berichte.
LG,
Heiko
Falls man das Paket systemd-boot nicht aus einem bestimmten Grund (den man dann ja kennt) selbst manuell installiert und konfiguriert hat, kann man das problemlos einfach löschen.
Zitat von: Gisbert am 06 September 2025, 10:48:12Bei mir erscheint bei jedem upgrade ein Kommentar/Warnung zu GRUB, dem ich aber bislang keine Bedeutung zugemessen hab.
Also wird bei Dir bereits grub verwendet und nicht systemd-boot.
Kurzes Update...
So wie Ralli und auch betateilchen mitgeteilt haben, konnte ich mit einem einfachen
apt remove systemd-boot
das Thema problemlos erledigen. Es war nichts nachträglich zu konfigurieren oder zu richten.
Reboot habe ich bei allen drei Knoten auch gemacht um sicher zu gehen dass alles noch funktioniert.
Nun kann ich mich den verbliebenen Warnungen widmen...
LG,
Heiko
Hallo zusammen,
bzgl. des UEFI-Modus vs. BIOS-Modus bin ich bei meinem Fujitsu Futro S740 auf folgende 2 Seiten gestoßen: Heise (https://www.heise.de/select/ct/2023/6/2301013201757655367)
Glaubt man dieser Seite, dann bootet der S740 im UEFI-Startmodus.
Auf diser Seite Proxmox Forum (https://forum.proxmox.com/threads/grub-bios-boot-packages.150769/) wird auf GRUB BIOS boot packages bei Proxmox eingegangen. Man benötigt nur die Variante, die beim Booten zuständig ist.
Demnach sollte ich dann folgendes bei meinem Futro S740 ausführen:
apt update
apt install --reinstall grub-efi-amd64 grub-efi-amd64-signed
update-grub
Ist das eine vernünftige Vorgehensweise, oder führt mich mein laienhaftes Verständnis in eine Sackgasse?
Eine Abfrage liefert folgendes, d.h. es sind wohl beide Methoden vorhanden:
root@FutroS740:~# dpkg --list | grep grub
ii grub-common 2.06-13+pmx7 amd64 GRand Unified Bootloader (common files)
ii grub-efi-amd64-bin 2.06-13+pmx7 amd64 GRand Unified Bootloader, version 2 (EFI-AMD64 modules)
ii grub-pc 2.06-13+pmx7 amd64 GRand Unified Bootloader, version 2 (PC/BIOS version)
ii grub-pc-bin 2.06-13+pmx7 amd64 GRand Unified Bootloader, version 2 (PC/BIOS modules)
ii grub2-common 2.06-13+pmx7 amd64 GRand Unified Bootloader (common files for version 2)
root@FutroS740:~#
Viele Grüße Gisbert
Um zu erkennen, ob dein Proxmox-Host im UEFI- oder im Legacy-(BIOS-)Modus läuft, kannst du ganz einfach prüfen, ob das EFI-Firmware-Verzeichnis existiert, oder entsprechende Tools abfragen:
Prüfen, ob das EFI-Verzeichnis gemountet ist:
if [ -d /sys/firmware/efi ]; then
echo "System läuft im UEFI-Modus"
else
echo "System läuft im Legacy-(BIOS-)Modus"
fi
Und
efibootmgr -v
zeigt die Bootreihenfolge, bei einem meiner Knoten:
root@pve1:~# efibootmgr -v
BootCurrent: 0002
Timeout: 1 seconds
BootOrder: 0002,0004,0003,0001
Boot0001* UEFI: Built-in EFI Shell VenMedia(5023b95c-db26-429b-a648-bd47664c8012)..BO
Boot0002* proxmox HD(2,GPT,64a8df98-8548-4cdf-a76c-91c87a2d120d,0x800,0x200000)/File(\EFI\PROXMOX\SHIMX64.EFI)
Boot0003* UEFI: PXE IPv4 Realtek PCIe GBE Family Controller PciRoot(0x0)/Pci(0x1,0x2)/Pci(0x0,0x0)/MAC(b0416f108110,0)/IPv4(0.0.0.00.0.0.0,0,0)..BO
Boot0004* UEFI OS HD(2,GPT,64a8df98-8548-4cdf-a76c-91c87a2d120d,0x800,0x200000)/File(\EFI\BOOT\BOOTX64.EFI)..BO
root@pve1:~#
Mein System läuft auch im UEFI-Modus wie man sieht. Deshalb glaubte ich auch
apt install --reinstall grub-efi-amd64 grub-efi-amd64-signed
ausführen zu müssen. War aber _bei mir_ nicht nötig.
Zitat von: DS_Starter am 06 September 2025, 20:42:04Mein System läuft auch im UEFI-Modus wie man sieht. Deshalb glaubte ich auch
apt install --reinstall grub-efi-amd64 grub-efi-amd64-signed
ausführen zu müssen. War aber nicht nötig.
So sieht es bei mir auch aus. Aber warum schreibst du, dass der install-Befehl nicht nötig war. Bei mir fehlt anscheinend grub-efi-amd64-signed - ich werde morgen den install-Befehl durchführen.
Viele Grüße Gisbert
Hallo zusammen,
ich hab's heute morgen versucht und folgendes ausgeführt.
apt install --reinstall grub-efi-amd64 grub-efi-amd64-signed
update-grub
Dann den Server runtergefahren und neu gestartet: es lief alles, also schon mal gut.
Auslesen:
root@FutroS740:~# dpkg --list | grep grub
ii grub-common 2.06-13+pmx7 amd64 GRand Unified Bootloader (common files)
ii grub-efi-amd64 2.06-13+pmx7 amd64 GRand Unified Bootloader, version 2 (EFI-AMD64 version)
ii grub-efi-amd64-bin 2.06-13+pmx7 amd64 GRand Unified Bootloader, version 2 (EFI-AMD64 modules)
ii grub-efi-amd64-signed 1+2.06+13+pmx7 amd64 GRand Unified Bootloader, version 2 (amd64 UEFI signed by Debian)
rc grub-pc 2.06-13+pmx7 amd64 GRand Unified Bootloader, version 2 (PC/BIOS version)
ii grub-pc-bin 2.06-13+pmx7 amd64 GRand Unified Bootloader, version 2 (PC/BIOS modules)
ii grub2-common 2.06-13+pmx7 amd64 GRand Unified Bootloader (common files for version 2)
root@FutroS740:~# efibootmgr -v
BootCurrent: 0009
Timeout: 1 seconds
BootOrder: 0009,0007,0002,0003,0000
Boot0000* Diagnostic Program FvVol(5c60f367-a505-419a-859e-2a4ff6ca6fe5)/FvFile(085e8cc2-8ec9-4666-bd2a-49d481e95fa7)
Boot0002* UEFI: PXE IP4 Realtek PCIe GBE Family Controller PciRoot(0x0)/Pci(0x13,0x2)/Pci(0x0,0x0)/MAC(4c52621f9eb8,0)/IPv4(0.0.0.00.0.0.0,0,0)..BO
Boot0003* UEFI: PXE IP6 Realtek PCIe GBE Family Controller PciRoot(0x0)/Pci(0x13,0x2)/Pci(0x0,0x0)/MAC(4c52621f9eb8,0)/IPv6([::]:<->[::]:,0,0)..BO
Boot0007* Linux Boot Manager HD(2,GPT,b9c56e57-139a-430a-b5c7-928dc5417276,0x800,0x200000)/File(\EFI\SYSTEMD\SYSTEMD-BOOTX64.EFI)
Boot0009* UEFI HD(2,GPT,b9c56e57-139a-430a-b5c7-928dc5417276,0x800,0x200000)/File(\EFI\BOOT\BOOTX64.EFI)..BO
root@FutroS740:~#
Viele Grüße Gisbert
Hier auch ein schönes Video Tutorial:
https://haus-automatisierung.com/software/proxmox/2025/08/22/proxmox-upgrade-version-9.html
Hallo Gisbert
Hab für ein zuküftiges Update meines S740 ein bischen Doku gesucht und gelesen.
Zitat von: Gisbert am 06 September 2025, 19:47:14bzgl. des UEFI-Modus vs. BIOS-Modus bin ich bei meinem Fujitsu Futro S740 auf folgende 2 Seiten gestoßen: Heise (https://www.heise.de/select/ct/2023/6/2301013201757655367)
Glaubt man dieser Seite, dann bootet der S740 im UEFI-Startmodus.
Das stimmt so, der Futro kann nur UEFI. Lt. BIOS-Handbuch des Futro gibt es keine Option für Legacy / CSM BIOS.
Zitat von: Gisbert am 05 September 2025, 20:26:02Ich hab mir das neueste BIOS-Update auf einen Stick gezogen und überlege, ob ich es aufspielen soll. Dazu muss ich die VMs und den Server runterfahren und dann nach Anleitung das BIOS updaten. Wie bei allem gibt es ein Rest-Risiko, dass etwas schief läuft.
Ebenfalls im BIOS-Handbuch ist ein "BIOS Recovery Update" mittels Jumper beschrieben falls was schief gegangen ist. Dazu wird übrigens der gleiche USB-Stick mit dem "Admin package" verwendet.
Es gibt auch ein "Auto BIOS Update" über den "Fujitsu Update-Server".
Zitat von: Gisbert am 07 September 2025, 09:37:13...root@FutroS740:~# efibootmgr -v
BootCurrent: 0009
Timeout: 1 seconds
BootOrder: 0009,0007,0002,0003,0000
Boot0000* Diagnostic Program FvVol(5c60f367-a505-419a-859e-2a4ff6ca6fe5)/FvFile(085e8cc2-8ec9-4666-bd2a-49d481e95fa7)
Boot0002* UEFI: PXE IP4 Realtek PCIe GBE Family Controller PciRoot(0x0)/Pci(0x13,0x2)/Pci(0x0,0x0)/MAC(4c52621f9eb8,0)/IPv4(0.0.0.00.0.0.0,0,0)..BO
Boot0003* UEFI: PXE IP6 Realtek PCIe GBE Family Controller PciRoot(0x0)/Pci(0x13,0x2)/Pci(0x0,0x0)/MAC(4c52621f9eb8,0)/IPv6([:: ]:<->[:: ]:,0,0)..BO
Boot0007* Linux Boot Manager HD(2,GPT,b9c56e57-139a-430a-b5c7-928dc5417276,0x800,0x200000)/File(\EFI\SYSTEMD\SYSTEMD-BOOTX64.EFI)
Boot0009* UEFI HD(2,GPT,b9c56e57-139a-430a-b5c7-928dc5417276,0x800,0x200000)/File(\EFI\BOOT\BOOTX64.EFI)..BO
root@FutroS740:~#...
Dein Booteintrag "Boot0007*" scheint noch auf "systemd-boot" in der EFI-Partition zu zeigen. Das Gewusele mit Remove/Purge - Reinstall - update-grub konfiguriert das anscheinend nicht weg.
Ist sicher unkritisch -funktioniert ja auch-, da nach deiner BootOrder der "Boot0009*" ausgewählt wird, der vermutlich die korrekten EFI Dateien enthält => "File(\EFI\BOOT\BOOTX64.EFI)".
Wenn die EFI-Partition dev/sda2 gemountet ist siehst du das unter /boot/efi/EFI/BOOT
bei mir:
ls -l /boot/efi/EFI/BOOT/
-rwxr-xr-x 1 root root 952384 31. Jul 22:02 BOOTx64.efi
-rwxr-xr-x 1 root root 88568 31. Jul 22:02 fbx64.efi
-rwxr-xr-x 1 root root 4192872 31. Jul 22:02 grubx64.efi
-rwxr-xr-x 1 root root 851368 31. Jul 22:02 mmx64.efiIn meiner Installation wird mit "efibootmgr -v" eine leicht andere Ausgabe angezeigt. Default "Boot0003*" ist der proxmox-Eintrag und "systemd-boot" gibt es nicht. Den Boot über Netzwerk hab ich wahrscheinlich unwissentlich im BIOS wegkonfiguruert.
$ efibootmgr -v
BootCurrent: 0003
Timeout: 1 seconds
BootOrder: 0003,0002,0000
Boot0000* Diagnostic Program FvVol(5c60f367-a505-419a-859e-2a4ff6ca6fe5)/FvFile(085e8cc2-8ec9-4666-bd2a-49d481e95fa7)
Boot0002* UEFI HD(2,GPT,0155dab0-30da-491c-b723-14e8eb6e18c4,0x800,0x200000)/File(\EFI\BOOT\BOOTX64.EFI)..BO
Boot0003* proxmox HD(2,GPT,0155dab0-30da-491c-b723-14e8eb6e18c4,0x800,0x200000)/File(\EFI\PROXMOX\SHIMX64.EFI)Gruß Ralf
Moin,
gestern gab es zwei Updates von PVE8 Komponenten. Im Changelog stand drin, dass im pve8to9 die Prüfung bzgl. systemd-boot verbessert wurde.
Vllt. ist es günstig zu patchen und das Script wieder auszuführen.
Mit meinen Vorbereitungen bin ich soweit durch, alle Fehler und Warnungen beseitigt. Suche jetzt nur noch einen Termin für den Cluster-Upgrade.
Btw. ...bei mir läuft ein Proxmox Backup Server in einer VM auf einem der Knoten. Den habe ich vorab von V3 auf V4 upgegradet. Er läuft nun bereits auf Trixie. Auch dafür gibt es ein Script bzw. Upgrade Doku: https://pbs.proxmox.com/wiki/Upgrade_from_3_to_4
LG,
Heiko
Moin,
nachdem ich gestern Probleme mit dem Update des PBS hatte, habe ich heute den PVE auf Release 9.0.6 hochgezogen. Soweit läuft alles gut.
Beste Grüße
Jürgen K.
Zitat von: DS_Starter am 09 September 2025, 08:35:46Btw. ...bei mir läuft ein Proxmox Backup Server in einer VM auf einem der Knoten.
Zitat von: juergen012 am 09 September 2025, 11:20:00nachdem ich gestern Probleme mit dem Update des PBS hatte,
...
Jetzt habe ich schon so oft von diesem Backup Server gelesen, dass ich ihn tatsächlich auch mal selbst installiert habe. Nettes Ding, insbesondere die (mögliche) Anbindung an S3 Speicher gefällt mir.
Dazu wünsche ich mir einen Client für macOS, dann bräuchte ich die obskure TimeMachine nicht mehr.
Das PVE Update von 8 auf 9 steht noch auf meiner ToDo-Liste.
Zitat von: betateilchen am 01 Oktober 2025, 15:51:06Das PVE Update von 8 auf 9 steht noch auf meiner ToDo-Liste.
Jetzt nicht mehr 8)
Bildschirmfoto 2025-10-01 um 17.43.16.png
Und zur Feier des Tages und des Upgrades habe ich mir heute tatsächlich eine Community-Lizenz für die Kiste gekauft.
Auch wenn man das privat kostenlos nutzen darf, unterstütze ich solche Dinge trotzdem gerne, wenn ich etwas gut finde.
--
Moin,
ich war auch neugierig. Habe ein Backup meines produktiven Systems (allerdings ohne den FHEM-LXC) auf einem anderen MiniPC installiert und gestartet. Dann PVE8to9 oder wie das heisst ausgeführt. Vorhandene Fehler beseitigt bis das Tool keine Fehler mehr ausgeworfen hatte. Update gestartet.... tusch, fehlgeschlagen. Bootet nicht mehr.
Dann Kiste "platt" gemacht, PVE9 frisch neu installiert, und Backups der LXCs eingespielt... läuft.
Also bleibt das laufende System erstmal bei PVE8. Vielleicht entschliesse ich mich mal nach einem NVME-Upgrade PVE9 zu installieren. Ist ja eigentlich schnell gemacht und konfiguriert, dann schleppt mal auch keine Altlasten mehr mit sich rum. Bei Windoof war ein Upgrade auch nie soo prickelnd.
Zitat von: Bartimaus am 02 Oktober 2025, 13:11:12... Update gestartet.... tusch, fehlgeschlagen. Bootet nicht mehr.
Überlege auch, ob ich update oder nicht gleich neu installiere (geht ja eigentlich zügig).
Worin der Fehlschlag bestand weisst du nicht, oder?
Gruß Ralf
Zitat von: RalfRog am 02 Oktober 2025, 14:01:40Worin der Fehlschlag bestand weisst du nicht, oder?
Gruß Ralf
Nein, habe ich auch nicht weiter eruiert. Da das produktive Update "damals" von PVE7to8 auch fehlgeschlagen ist, wurden meine Vorurteile gegen Updates bestätigt. Wie gesagt, dieses Prüftool hatte komplett grün signalisiert.
Hallo zusammen,
ich habe heute meinen 3-Node Cluster ebenfalls auf Proxmox 9 (9.0.10) hochgezogen.
Alles hat problemlos funktioniert.
Die beteiligte Rechnerhardware sieht so aus:
PVE1: TRIGKEY Mini PC 5800H AMD Ryzen 7
PVE2: Intel NUC BOXNUC6I5SYH Intel Core i5
PVE3: Lenovo ThinkCentre M910q Tiny Intel Core i5-7.Gen
Also ein kleiner Zoo der dennoch schön im Cluster spielt.
Ich hatte heute ebenfalls den Schritt zum Update gewagt, hatte aber im Anschluß ein Paar Hürden zu überwinden gehabt.
1. hat Docker in einem der LXCs nicht mehr funktioniert, da scheint Apparmor Änderungen mitgebracht zu haben, gelöst wurde das mithilfe von folgendem Betrag (https://forum.proxmox.com/threads/proxmox-ve-9-0-beta-lcx-docker-not-working.168626/page-2)
in aller Kürze: hat das hinzufügen von lxc.apparmor.raw: allow mqueue, /etc/pve/lxc/XXX.conf (das Kommata muss mit) geholfen.
2. gab es einige Fehlermeldungen beim apt update, hier war die Lösung "apt modernize-sources" und anschließend noch das setzen der benötigten und nicht benötigten Sources, wie hier (http://apt%20modernize-sources) beschrieben.
Ich habe mir eine 4TB-NVME gegönnt, darauf PVE9 installiert, und LXC/VM aus Backup wiederhergestellt. Produktivschaltung erfolgt irgendwann im Laufe der nächste Woche.
Die Neuinstallation incl. Konfiguration ging so schnell, da "schlage" ich mich nicht mit Updateproblemen rum
Hi
Hatte vom neuen Format (DEB822-STIL) für die Sources noch gar nichts gehört.
@Nighthawk: War die Fehlermeldung eher eine Warnung?
Lt. https://manpages.debian.org/trixie/apt/sources.list.5.de.html ist:
ZitatDieses Format ist veraltet und wird schließlich entfernt, aber frühestens 2029.
Ab Bullseye unterstützt und seit Trixie empfohlen.
Die Meldung kann man vermutlich erst mal ignorieren. Man muss halt akzeptieren, dass sie aufpoppt und kann die Sources Dateien in Ruhe ans neue Format anpassen.
Gruß Ralf
Zitat von: RalfRog am 16 Oktober 2025, 22:46:22und kann die Sources Dateien in Ruhe ans neue Format anpassen.
Wie oben schon geschrieben wurde, gibt es dafür sogar eine gute Unterstützung, die einem die Arbeit abnimmt:
Zitat von: Nighthawk am 16 Oktober 2025, 19:17:37hier war die Lösung "apt modernize-sources"
Damit werden die vorhandenen source Dateien automatisch durchforstet und die Inhalte in das neue Format übertragen.
@RalfRog
ja, es waren nur Warnungen wegen den Enterprise Sources, diese könne eingentlich ignoriert werden, aber ich habe es gerne clean ;-)