von Ralf Schweiger | Mai 28, 2026 | Linux
Der Mensch ist ein Gewohnheitstier. Wer syslog oder syslogng gewohnt war und wusste, damit umzugehen, steht journalctl möglicherweise zuerst einmal etwas unfreundlich gegenüber.
Wie immer, ist es ein Know-How-Thema.
Die Standard-Aufgabe bei der Fehlersuche:
journalctl und nachfolgende Ausgaben beginnend ab einem bestimmten Zeitpunkt.
Wer bei Problemen auf Ursachenforschung geht, benötigt die Log-Einträgen aus „journalctl“ meist ab einem bestimmten Zeitpunkt.
Das Problem: Über den Standardaufruf ist die Ausgabe zuerst nicht hilfreich – die Standard-Tail-Ausgabe startete lange vor der „aktuellen Zeit“.
Die Suche im ausgegebenen Log dauert viel zu lange, weil sie vollständig ist.
Daher muss man das über Zeitangaben einschränken.
Dazu gibt es den Parameter „–since=XXX“, der z.B. konkret oder mit dem Befehl „date“ wie folgt verwendet wird:
Beispiel für einen Aufruf ab jetzt:
# journalctl --since="$(date +"%Y-%m-%d %H:%M:%S")" --no-tail --follow
Aufschlüsselung:
$(Datum +“%Y-%m-%d %H:%M:%S) : Das aktuelle Datum/die aktuelle Uhrzeit (kann auch „gestern“ oder andere pasable Datumszeichenfolgen sein).
–since=“XXX“ : Mit dem Befehl Datum nur auf neue Ereignisse beschränken.
–no-tail : Zeigen Sie alle gespeicherten Ausgabeleitungen an, auch im Follow-Modus. (Dies folgt den Live-Log-Einträgen)
–follow : Folge den Live-Logeinträgen.
Der Befehl „journalctl“ ist seit Jahren in vielen Linux-Distributionen verfügbar und mittlerweile Standard, aber durch seine Ungewohntheit ist für viele Graubärte, wie mich, immer erst einmal etwas Forschung in den Tiefen der manuals und howtos notwendig.
Daher erspare ich das anderen und stelle das hier ein.
journalctl
von Ralf Schweiger | Mai 23, 2026 | Allgemein, Linux, Raspberry
Wer telegraf auf einem Rapberry benötigt, hat unter Umständen das Problem, dass sich der GPG key geändert hat und daher ein apt update folgenden Fehler ausgibt:
Failed to fetch https://repos.influxdata.com/debian/dists/stable/InRelease The following signatures couldn’t be verified because the public key is not available: NO_PUBKEY DA61C26A0585BD3B
Die Lösung dazu ist diese:
curl -fsSL https://repos.influxdata.com/influxdata-archive_compat-exp2029.key | gpg --dearmor | sudo tee /usr/share/keyrings/influxdata-archive-keyring.gpg > /dev/null
echo "deb [signed-by=/usr/share/keyrings/influxdata-archive-keyring.gpg] https://repos.influxdata.com/debian stable main" | sudo tee /etc/apt/sources.list.d/influxdata.list
sudo rm -f /etc/apt/trusted.gpg.d/influxdata-archive_compat.gpg
sudo apt update
von Ralf Schweiger | Jan. 23, 2025 | Allgemein, Computers, Debian, Linux, Proxmox, Virtualsierung, Windows 11
Das Ende von Windows 10 ist der Beginn von Windows 11.
Nach dem 14. Oktober 2025 wird Microsoft keine Updates mehr für Windows 8.1 und Windows 10 mehr zur Verfügung stellen.
Quelle: Microsoft kündigt Windows 8.1 und Windows 10 EOL an.
Da es neben inkompatibler Hardware, auf dem Windows 10 läuft und das man virtualisieren möchte, auch bestehende virtuelle Windows 10 Maschinen auf Proxmox VE gibt, die auf Windows 11 upgedated werden sollen oder müssen, ist hier das Step-by-Step-Upgrade-How-To.
Die Systemvoraussetzungen für Windows 11 sind folgende:
- 4 GB RAM
- 64GB Disk
- TPM 2.0
- UEFI
- Kompatible CPU
- u.a.
Die vollständige Liste ist hier zu finden: Microsoft Windows 11 Systemanforderungen.
Teil 1: Proxmox VE Upgrade
Wir brauchen also zuerst einmal Proxmox VE in der Version 8, da hier erstmals TPM 2.0 verfügbar ist und auch UEFI vollständig Windows 11 -fähig unterstützt wird.
Hier ist die Upgrade-Prozedur beschrieben: Proxmox VE 7 to 8
Zusammengefasst durchlaufen wir folgende Schritte:
Shutdown sämtlicher VMs und Container.
Proxmox 7 noninteraktiv auf den neuesten Stand bringen und Version ausgeben:
export DEBIAN_FRONTEND=noninteractive; apt update
yes '' | apt-get -y -o DPkg::options::="--force-confdef" -o DPkg::options::="--force-confold" upgrade
yes '' | apt-get -y -o DPkg::options::="--force-confdef" -o DPkg::options::="--force-confold" dist-upgrade
apt autoremove
pveversion
Proxmox 7to8 Check:
pve7to8
Dieser Schritt darf keine Fehler ausgeben. Falls doch, sind diese erst einmal zu beheben. Uns ist noch keiner unter gekommen.
Falls bei euch einer auftritt, bitte hier einen Kommentar hinterlassen.
Proxmox 8 Repo Upgrade:
sed -i 's/bullseye/bookworm/g' /etc/apt/sources.list /etc/apt/sources.list.d/pve-enterprise.list
Refresh Repo Index:
apt update
Upgrade auf Proxmox 8:
apt dist-upgrade
Das war es erst mal für Proxmox. Nach reboot steht die Proxmox VE in der Version 8 zur Verfügung.
Wie man physikalische Windows 10 Hardware virtualisiert, um es auf Windows 11 upzugraden, erspare ich uns erst mal.
Gegebenenfalls wird es dafür noch einen weiteren Beitrag geben, falls das von Interesse ist und ihr das in den Kommentaren wünscht.
Teil 2: Windows 10 vorbereiten: Disk nach GPT konvertieren
Ein essentieller Schitt für die Umstellung zu UEFI ist die Umwandlung der Windows vDisk von MBR auf GPT.
Am einfachsten geschieht das unter Windows selbst.
1. Dazu ist ein Command-Fenster (cmd) als Administrator zu starten.
2. Im Command-Fenster ist folgender Validierungsbefehl auszuführen:
mbr2gpt /validate /allowFullOS
Falls dieser Befehl fehlerfrei beendet wurde, kann die Konvertierung der Disk nach GPT finalisiert werden durch folgenden Befehl:
mbr2gpt /convert /disk:0 /allowFullOS
Die VM kann nun herunter gefahren werden. Falls der Hypermode aktiv ist, einfach statt Herunterfahren, einen Neustart durchführen und die VM in dem Moment stoppen, wenn das Proxmox-Boot-Logo angezeigt wird.
Teil 3: Anpassungen der VM Hardware unter Proxmox VE
1. Umstellung der CPU auf [host]
2. Einfügen einer EFI Partition
3. Umstellen des BIOS auf UEFI
4. Einfügen des TPM 2.0 Chips
5. Booten der Windows 10 VM
Teil 4: Upgrade auf Windows 11
1. PC Health Check
Download PC Health Check unter https://aka.ms/GetPCHealthCheckApp, installieren und ausführen.
Wenn alles grün ist, kann das eigentliche Update beginnen.
2. Update auf Windows 11
Falls Windows Update nicht anbietet, auf Windows 11 upzudaten, kann man das auch manuell anstoßen.
Download von Windows 11 Updater hier: https://www.microsoft.com/software-download/windows11
Ausführen der Setup-Datei Windows11InstallationAssistant:
Nach dem Neustart steht Windows 11 zur Verfügung.
Voilà
von Ralf Schweiger | Jan. 21, 2025 | Allgemein, Linux, Proxmox, Virtualsierung
Nachfolgende Fehlermeldung führt dazu, dass die Backups für die Sync-Gruppe ct/110 auf einen Fehler laufen:
2025-01-20T18:37:35+01:00: sync group ct/110 failed - owner check failed (backupuser@pbs != root@pam)
Aus irgendeinem Grund stimmen die lokalen Berechtigungen nicht für die Sync-Gruppe.
Hier scheint sich das um einen Bug zu handeln, der bei Verbindungsabbrüchen von online Backups und VPN-Tunnel zum Tragen kommt.
Bei Proxmox haben einige User dieses Problem. Da gab es auch einen Bug dazu, der aber noch nicht nachgestellt werden konnte.
Ein Workaround, der bei uns funktionierte, ist einfach die ownership der Sync-Gruppe auf dem Sync-Server zu überschreiben:
Annahme: Das Backup-Repo soll backupstorage2 heißen, der lokale Benutzer mit entsprechenden Berechtigungen auf das Repo soll backupuser@pbs heißen, dann wäre der Befel folgender:
proxmox-backup-client change-owner ct/110 backupuser@pbs --repository backupstore2
Möchte man alle vorhandenen Sync-Gruppen in einem Rutsch bereinigen, kann das in das Script „/usr/local/bin/pbs-correct-sync-group-ownership.sh“ packen:
#!/bin/bash
storagepath="$(dirname $(grep path /etc/proxmox-backup/datastore.cfg | awk '{print $2}'))"
repository="$(grep datastore: /etc/proxmox-backup/datastore.cfg | awk '{print $2}')"
backupuser="$(grep -r owner /etc/proxmox-backup/sync.cfg | awk '{print $2}')"
type="ct host vm"
for t in $type
{
for s in $(ls $storagepath/$repository/$t)
{
printf "Changing ownership of sync group $t/$s...\n"
proxmox-backup-client change-owner $t/$s $backupuser --repository $repository
}
}
