Noch ein kleiner Nachtrag vom Wochenende: Die Entwickler des Debian-Projekts haben nach knapp über zwei Jahren ein neues Release dieser Linux-Distribution freigegeben. Seit dem 9. August 2025 ist Debian 13 (trixie) veröffentlicht.
Anzeige
Debian 13 trixie enthält zahlreiche aktualisierte Softwarepakete (es wurden 44.326 Pakete aktualisiert). Die Gesamtzahl beträgt nun 69.830 Pakete, wobei 14.100 neu hinzugekommen sind, während über 8.840 Pakete als veraltet entfernt wurden. Aber das Wichtigste in diesem Kontext: Wir reden nicht von Gigabyte an Platz, der gesamte Speicherplatzbedarf für trixie beträgt schlappe 403 GByte (403.854.660 kB). Gemäß Ankündigung wurden folgende Pakete in trixie aktualisiert.
- Apache 2.4.64
- Bash 5.2.37
- BIND DNS Server 9.20
- Cryptsetup 2.7
- curl/libcurl 8.14.1
- Emacs 30.1
- Exim (default email server) 4.98
- GNUcash 5.10
- GNU Compiler Collection 14.2
- GIMP 3.0.4
- GnuPG 2.4.7
- Inkscape 1.4
- the GNU C Library 2.41
- LibreOffice 25.2
- Linux kernel 6.12 LTS series
- LLVM/Clang toolchain 19 (default), 17 and 18 available
- MariaDB 11.8
- Nginx 1.26
- OpenJDK 21
- OpenLDAP 2.6.10
- OpenSSH 10.0p1
- OpenSSL 3.5
- Perl 5.40
- PHP 8.4
- Postfix 3.10
- PostgreSQL 17
- Python 3, 3.13
- Rustc 1.85
- Samba 4.22
- Systemd 257
- Vim 9.1
Debian 13 läuft auf verschiedenen Prozessor-Architekturen (erstmals auch auf riscv64). Dafür wurde die 32-Bit-Unterstützung für Intel/AMD-Prozessoren entfernt. Weitere Informationen finden sich auf der Debian-Website in den Release Notes und in den Abschnitten zu den Live-Installations-Images .
Anzeige
Mal sehen wann die auf Debian basierenden Distributionen nachziehen. In meinem Fall wären das raspi os und mxlinux. Schön wäre auch mal eine offiziell unterstützte Upgrademöglichkeit auf die nächste Version also ein Programm bzw. Script um das Upgrade durchzuführen. Die Empfehlung einer sauberen Neuinstallation ist zwar an sich empfehlenswert aber die Übernahme von Einstellungen und Daten ist dann eben mehr oder weniger umfangreich. Das manuelle Upgrade kann funktioniern wie von Buster zu Bullseye aber auch schiefgehen wie von Bullseye zu Bookworm.
Proxmox PVE9 und der PBS4 sind jedenfalls schon auf Trixie.
hab 20 Server auf proxmox basis umgestellt. keine Probleme.
auch Debian lxc Container hab ich migriert. nextcloud hat mit dem PHP update lästige nacharbeiten erfordert.
Ich werde die ersten Produktiv-Server (nur Single-Nodes) ab 01.09. upgraden und dann 3 – 4 Wochen live testen. Erst danach werde ich die HA-PVE-Cluster upgraden.
Aber gerade für HA-Cluster ist PVE9 sehr von interesse.
Zitat:
"Die neuen HA-Affinitätsregeln in Proxmox ermöglichen eine gezielte Verteilung von VMs und HA-Ressourcen in Hochverfügbarkeits-Clustern. Administratoren können definieren, welche VMs oder Dienste gemeinsam oder getrennt auf Knoten laufen sollen"
Und der PBS4 unterstützt nun nativ S3-kompatible Objektspeicher als Backup-Backend.
Ich nehme es als chance das System wieder mal neu aufzusetzen. Freiwillige tut man es ja nicht, weil das Mist Linux hier so unaufhörlich ohne Probleme funktioniert ;-)
Ich (er)warte (auf) die Debian Edition 7 von MINT, obwohl MX auch eine Lösung für mich wäre. UBUNTU, das ja auch auf DEBIAN fußt, kommt für mich aufgrund der immer restriktiveren und völlig den Grundgedanken von LINUX (FOSS, KISS, …) entgegenlaufenden Gebahren nicht mehr in Frage – da könnt' ich auch gleich bei MICROSOFT bleiben…
Warum nicht einfach direkt Debian mit einer DE deiner Wahl installieren?
Habe ich bereits: auf einer SSD läuft sozuschreiben als Zweitsystem ein SPARKY-LINUX auf dem testing-Zweig, der nun bereits anfangen sollte, Pakete aus dem forky-Bereich einzuspielen.
Hintergedanke war, in Zukunft ein sicherheitstechnisch "besseres/ausgereifteres" stable-DEBIAN zu wechseln und da ich bereits Erfahrungen mit LMDE 5 habe, warte ich hier bis in einigen Wochen/Monaten die frische Version 7 erscheint und ich dann so nach und nach auf diese stable-Version umschwenken kann ->
https://blog.linuxmint.com/?p=4860
Proxmox und PBS Cluster in der Testumgebung auf Trixie umgestellt.
Umstellung lief ohne Probleme, Umgebung ist stabil.
Beim ersten Pointrelease kommt dann die Liveumgebung dran.
Ich dachte Proxmox würde praktisch ausschliesslich als Typ-1-Hypervisor eingesetzt. Ist das bei Dir nicht der Fall? Falls nein: Hast Du per Inplace-Upgrade auf Trixie anheben können?
Nein. Proxmox ist – sehr vereinfacht gesagt – eine bunte Oberfläche für das in Linux integrierte KVM. Damit kommt es eher VMware ESX nahe als ESXi. Zusätzlich werden Container unterstützt und die Oberfläche managed HA (im selben Sinne wie bei VMware, d.h. mit Neustart des Hosts, kein FT).
>> Proxmox ist – sehr vereinfacht gesagt – eine bunte Oberfläche für das in Linux integrierte KVM.
Bunte Oberfläche trifft es nicht ganz.
Als bunte KVM Oberfläche würde ich eher das "Cockpit" bezeichnen, eine minimal WebUI zum lokalen starten/stoppen von 1,2,3 handvoll VMs. Dafür funktionierts ausreichend, mehr will, und kann man aber damit nicht gross machen.
Proxmox ist eher eine prof. WebGUI Management-Oberfläche wie ESXi, und wird abweichend nicht wie das klassische KVM via commandline "virt-install/virsh" verwaltet, sondern ausschliesslich via die WebGUI. Man kann die Proxmox-Maschinen mit Bordwerkzeugen sichern, und mit etwas Aufwand auf einer KVM Maschine 1:1 wieder starten. Der große Vorteil von Proxmox ist das VMs sehr einfach zusammengeklickt sind, und Out-Of-Box bestmöglich Performant laufen. Clonen, Snapshots, etc. alles via Mausklick. Backup-Server können einfach gekoppelt werden, und externer Support ist einkaufbar.
Bei direktem KVM/virt-install/virsh kann man sich erst stundenlang mit der CLI, Optimierung etc.pp. anfreunden und darf sich mit dem editieren der XML-Files der VMs beschäftigen. Optional gibts für den Desktop noch den "virt-manager" der einen dabei unterstützt – ist aber halt ein Desktop-Tool.
Eine weitere WebGUI Management-Oberfläche die fürs Enterprise-Umfeld geeignet ist, ist "ovirt": Hier können x Virtualisierungs-Server in Cluster, x Cluster in Datenzentren, und dann x Datencentren gebündelt in einer WebUI verwalten werden. Das ganze passiert im Backend via Java. Manuelles eingreifen via REST. oVirt ist allerdings gerade wohl etwas wackelig: Redhat wohl hat nach der IBM-Übernahmen die federführende Weiterentwicklun auf Eis gelegt.
OLVM ist ein auf ovirt basierter Virtualisierungs-Manager von Oracle, und die einzigste Virtualisierungs-Plattform für x86/x64 bei der man offiziell supported seine CPU HARD PARTITIONIEREN kann, sprich 1 CPU-Lizenz einem Kern fest Zuweisen kann. Das kann zwar im Grunde auch via ESX/HyperV/KVM etc.pp. selbst, aber das wird Oracle-Typisch nicht anerkannt.
Deswegen schrieb ich "sehr vereinfacht gesagt".
Den Anspruch an ein professionell nutzbares System hat Proxmox natürlich und auch die dahinterstehende Supportinfrastruktur.
Aber letztendlich wird alles, was ich mir in der Oberfläche "zusammenklicke" in entsprechende CLI-Befehle (quemu, virsh…) umgesetzt, die auch in den Logs stehen und sich ebenfalls manuell ausführen ließen.
Bestimmte sehr "tief ins Eingemachte" gehende Konfigurationen (z.B. Multipath) lassen sich derzeit sogar ausschließlich an der CLI machen, da es kein Dialogfenster dazu gibt. Das ist aber auch dokumentiert.
Auch die Konfiguration wird (obwohl des HA wegen in einer Datenbank abgelegt) an allen relevanten Stellen in textleserliche Steuerdateien übersetzt, diese XMLs würden sich dann ebenfalls in einer anderen Umgebung nutzen lassen.
Darum ja auch der etwas präzisere Vergleich ESX vs. ESXi.
Zum OLVM: diese harte Partitionierung wird von Oracle nur auf Oracle/Sun Hardware (also etwa ODA oder Exadata) anerkannt, da diese schon im BIOS jede Änderung an der Partitionierung der CPU mitmonitoren (ist auch nur nach bestimmten Regeln machbar) und ist auch nur für per Core lizensierte Software (etwa die Oracle Datenbank) relevant.
Oracle auf VMware ist sowieso ein Tretminenfeld, hier mal zum Einlesen eine halbwegs verständliche Handreichung von der DOAG: https://www.doag.org/de/home/news/alle-fragen-zu-oracle-vlan-approval-und-die-antworten/
>> https://www.doag.org/de/home/news/alle-fragen-zu-oracle-vlan-approval-und-die-antworten/
Das geht wenn man "sehr, sehr gut" aufpasst:
* Vollkommen getrenntes Netzwerk rein nur für Oracle-Virtualisierungs-Server.
* Physisch richtige CPU-Dimensionierung.
* Oracle-Datenbank-Lizenzen: ESXi
* Oracle-Application-Lizenzen: HyperV
* so ist keine Life-Migration möglich
Und dann … dann sollte man tunlichst noch die ganzen Out-Of-Box installierten kostenpflichtigen Oracle-Features sicher deaktivieren, und sicherstellen das man mit Standard-Lizenzen keine vorinstallierten Enterprise-Features nutzt.
So sind wir sicher durch ein Audit gekommen.
>> Zum OLVM: diese harte Partitionierung wird von Oracle nur auf Oracle/Sun Hardware (also etwa ODA oder Exadata) anerkannt, da diese schon im BIOS jede Änderung an der Partitionierung der CPU mitmonitoren (ist auch nur nach bestimmten Regeln machbar) und ist auch nur für per Core lizensierte Software (etwa die Oracle Datenbank) relevant.
Hast Du da weiterführende Informationen?
Nach meinem Verständnis geht auch x86/x64:
====================================
google: Hard Partitioning with Oracle Linux KVM
Oracle-Typischerweise ist das mal wieder maximal verwirrend beschrieben: Die reden von KVM, virsh, und setzen "olvm-vmcontrol" aus ovirt vorraus:
virsh geht KVM only, olvm-vmcontrol ist ovirt only:
Heist in der Praxis: Zum HARD-PARTITIONING wird ovirt genutzt, kein klassisches KVM only.
Solche Verwirrungen findet man überall in den Oracle-Dokumenten … und der örtliche Admin ist für die korrekte Lizenzierung zuständig … und wenn da was schief geht, Mio-Schaden.
Jeder Admin der mit Oracle-Administration in Berührung kommt, sollte sich den "Oracle-Lizenzguide" von der DOAG "gründlich verinnerlichen". Der ist Gold Wert.
Upgrade from 8 to 9:
https://pve.proxmox.com/wiki/Upgrade_from_8_to_9
Ja, Proxmox ist effektiv in erster Linie ein Baremetal-Hypervisor – also Type-1.
Und man kann da ohne Weiteres Inplace-Upgrades durchführen. Bis jetzt noch nie ein Problem gehabt.
Proxmox ist so gesehen nur ein normales Debian mit angepasstem Kernel, ein paar Zusatzkommandos und einer mehr oder minder hübschen Weboberfläche.
Inplace von Bookworm auf Trixie geht problemlos, wenn man sich an das Guide vom Hersteller hält. (Wiki: Upgrade_from_8_to_9)
Wichtig sind aktuelle Backups der VM, alle VM heruntergefahren, und ein Testlauf mit 'pve8to9 –full'.
Mögliche Fehlerquellen die einem Upgrade im Wege stehen werden angezeigt.
Edit: Da waren die Kollegen bei der Beantwortung deiner Frage schneller als ich.
Happy Birthday Trixie!
Vielen Dank an die Entwickler – Debian ist einfach Klasse!
Stabil, und Langzeit-Verlässlich!
ACHTUNG: Proxmox 9 ist NICHT mit Veeam B&R 12.3 kompatibel. Wer also darauf angewiesen ist, sollte noch nicht upgraden.