1 Tag nach Installation Root-Partition (80GiB) voll - kein login möglich

[geppino]

Hallo Leute!

Gestern habe ich openSUSE Leap 15.2 installiert, wobei die home-Partition (aus Leap 15.1 mit Plasma) und die mit "Documents" ohne Neuformattierung angebunden habe.

Ehrlich gesagt, schon seit Jahren nicht so viele und gravierende Probleme gehabt, wie bei dieser Version.

Das wichtigste im Moment ist es sicher, dass die Dateien messages und warn unter /var/log so schnell "wachsen", dass sie die Root-Partition (80 GiB) nach weniger als 12 Stunden Betrieb voll gemacht haben und kein Login mehr möglich war: messages ca. 33 Gib / warn ca. 32 GiB.

Mittels einer openSUSE Live-DVD habe ich die 2 gelöscht. Dann das System wieder gestartet und nach 10 Minuten wieder:
messages 2,2 GiB / warn genau so groß.

Natürlich habe ich nicht versucht die über 30 GiB Dateien zu öffnen. In die kleineren habe ich reingeschaut und dabei das System einige Minuten lang lahm gelegt !
Was steckt in diesen Dateien?
Ich bin kein Expert, aber soweit ich verstehe, gibt es ein paar wichtige Meldungen, bei denen ich etwas unternehmen kann oder gar muss. Aber meistens geht es um KDE und Plasma. Und tatsächlich, wenn ich mich in KDE-Plasma-Ambiente einlogge, kann ich nicht länger als 15 Minuten frei arbeiten. Danach belagert KDE (besonders akonadi & Co) CPU und Arbeitsspeicher (8 GB) und braucht sogar die SWAP-Partition (vor ein paar Stunden fast 2 GB) !!

FRAGE:
Abgesehen davon, dass ich in den nächsten Tagen versuchen werde, KDE zu downgraden, und wenn es nicht geht zurück zu Leap 15.1 zu fahren. Wie kann ich hindern dass die Dateien warn und message bereits morgen das Login wieder verhindern?
Gibt es viellecht Einstellungen - möglich in Sysconfig Editor ? - die das ermöglichen?

Vielen Dank im voraus für die Hilfe

[Sauerland]

Abgesehen davon, dass ich in den nächsten Tagen versuchen werde, KDE zu downgraden, und wenn es nicht geht zurück zu Leap 15.1 zu fahren. Wie kann ich hindern dass die Dateien warn und message bereits morgen das Login wieder verhindern?
Gibt es viellecht Einstellungen - möglich in Sysconfig Editor ? - die das ermöglichen?

In die Dateien hineinschauen, was da so aus dem Ufer läuft.
Wobei diese Dateien bei mir nicht benutzt werden.

Installierst du syslog (rsyslog, syslog-ng)?
Oder installierst du nachträglich irgendwelche Programme, die syslog benutzen?

Poste mal:

zypper se -si syslog

[geppino]

Hi Sauerland,

vielen Dank für die schnelle Antowort!

In die Dateien hineinschauen, was da so aus dem Ufer läuft.
Wobei diese Dateien bei mir nicht benutzt werden.

Na ja, wenn ein System frisch installiert ist und besonders wenn Einiges (in diesem Fall bei KDE) nicht richtig läuft, schuae ich eigentlicht nicht, ob die Root-Partition noch genug Platz hat ... sie ist ja eher überdimensioniert! In die Dateien hineinzuschauen ist sicher richtig, aber 3 Gigabyte große Textdateien zu öffnen, legt - wie gesagt - das System lahm!

I Installierst du syslog (rsyslog, syslog-ng)?
Oder installierst du nachträglich irgendwelche Programme, die syslog benutzen?

Poste mal:

zypper se -si syslog

In der Regel und wenn ich mich richtig erinnere, installiere das alte Benarichtigungsystem (syslog oder?) nach und deinstalliere das Neuere - hatte aber diesmal noch nicht getan, weil mir den Namen der Pakete nicht einfiel.

# zypper se -si syslog
Repository-Daten werden geladen...
Installierte Pakete werden gelesen...

S | Name           | Typ   | Version          | Arch   | Repository
--+----------------+-------+------------------+--------+---------------------
i | rsyslog        | Paket | 8.39.0-lp152.2.7 | x86_64 | openSUSE-Leap-15.2-1
i | rsyslog        | Paket | 8.39.0-lp152.2.7 | x86_64 | Haupt-Repository
i | syslog-service | Paket | 2.0-lp152.4.7    | noarch | openSUSE-Leap-15.2-1
i | syslog-service | Paket | 2.0-lp152.4.7    | noarch | Haupt-Repository

Soll ich die beide deinstallieren?
Was nehme ich dann als Warn-System-Ersatz?

[susejunky]

... Gestern habe ich openSUSE Leap 15.2 installiert,

Welches Dateisystem hast Du dabei für die "/"-Partition gewählt (btrfs, ext4, ...)?

... wobei die home-Partition (aus Leap 15.1 mit Plasma) und die mit "Documents" ohne Neuformattierung angebunden habe.

Um auszuschließen, dass Konfigurationseinstellungen aus openSUSE Leap 15.1 mit openSUSE Leap 15.2 nicht kompatibel sind, könntest Du einen neuen Benutzer anlegen und prüfen, ob mit diesem Benutzer die Probleme immer noch auftreten.

... Das wichtigste im Moment ist es sicher, dass die Dateien messages und warn unter /var/log so schnell "wachsen", dass sie die Root-Partition (80 GiB) nach weniger als 12 Stunden Betrieb voll gemacht haben und kein Login mehr möglich war: messages ca. 33 Gib / warn ca. 32 GiB.
...
Natürlich habe ich nicht versucht die über 30 GiB Dateien zu öffnen. In die kleineren habe ich reingeschaut und dabei das System einige Minuten lang lahm gelegt ! Was steckt in diesen Dateien? Ich bin kein Expert, aber soweit ich verstehe, gibt es ein paar wichtige Meldungen, bei denen ich etwas unternehmen kann oder gar muss.

Korrekt! Ohne zu wissen, welche Fehlermeldungen in diesen Dateien festgehalten werden, ist es kaum möglich das Problem zu lösen.

... Aber meistens geht es um KDE und Plasma. Und tatsächlich, wenn ich mich in KDE-Plasma-Ambiente einlogge, kann ich nicht länger als 15 Minuten frei arbeiten. Danach belagert KDE (besonders akonadi & Co) CPU und Arbeitsspeicher (8 GB) und braucht sogar die SWAP-Partition (vor ein paar Stunden fast 2 GB) !!

Tritt diesbezüglich eine "Besserung" ein, wenn Du in KDE die Dateiindizierung abschaltest (Standardeinstellung ist "aktiviert")?

..., dass ich in den nächsten Tagen versuchen werde, KDE zu downgraden,

Das dürfte ein beliebig schwieriges Unterfangen werden. Der Wechsel zurück zu openSUSE Leap 15.1 dürfte da der einfachere Weg sein. Allerdings ist das keine echte "Problemlösung", denn bei mir (und wahrscheinlich auch bei vielen anderen Benutzern) funktioniert openSUSE Leap 15.2 problemlos.

Viele Grüße

susejunky

[Sauerland]

S | Name           | Typ   | Version          | Arch   | Repository
--+----------------+-------+------------------+--------+---------------------
i | rsyslog        | Paket | 8.39.0-lp152.2.7 | x86_64 | openSUSE-Leap-15.2-1
i | rsyslog        | Paket | 8.39.0-lp152.2.7 | x86_64 | Haupt-Repository
i | syslog-service | Paket | 2.0-lp152.4.7    | noarch | openSUSE-Leap-15.2-1
i | syslog-service | Paket | 2.0-lp152.4.7    | noarch | Haupt-Repository

Die würde ich mal deinstallieren, sind überflüssig, macht alles systemd mit:

man journalctl

Wenn die deinstalliert sind, könntest du ja auch mal in die Dateien schauen.

PS:
Wenn du kmail benutzt, wird ein downgrade ohne alter!!! Datensicherung kaum möglich sein, die Datenformate haben sich geändert.

[geppino]

Hallo susejunky,

hier die AW auf die Fragen:

Welches Dateisystem hast Du dabei für die "/"-Partition gewählt (btrfs, ext4, ...)?

-> ext4
...

Um auszuschließen, dass Konfigurationseinstellungen aus openSUSE Leap 15.1 mit openSUSE Leap 15.2 nicht kompatibel sind, könntest Du einen neuen Benutzer anlegen und prüfen, ob mit diesem Benutzer die Probleme immer noch auftreten.

-> nein, ich habe es nicht mit einem neuen (leeren) User probiert und wette, dass keine Probleme auftauchen werden, solange ich den neuen User mit meinen KDE-PIM Daten futtere.
...

Korrekt! Ohne zu wissen, welche Fehlermeldungen in diesen Dateien festgehalten werden, ist es kaum möglich das Problem zu lösen.

-> mmhh... und wie kann ich die Dateien öffnen (die neuen seit 8:45 bis 9:40 Uhr jeweils 9,4 und 8,9 Gib), ohne das System lahm zu legen?
Vielleicht zurück zum Leap 15.1 ...
...

Tritt diesbezüglich eine "Besserung" ein, wenn Du in KDE die Dateiindizierung abschaltest (Standardeinstellung ist "aktiviert")?

-> meinst Du Folgendes? Gestern habe ich in Systemeinstellungen / Suchen / Dateisuche sämtliche Partitionen (bis auf die "/") in die Liste "Nicht in diesen Orte suchen" eingetragen. Gerade jetzt sicherheitshalber nachgeschaut und diese Einstelölung war verschwunden.
Jetzt habe ich allgemein die Dateisuche deaktiviert - schauen wir mal, was es bringt - werde ich später benachrichtigen.
...

Das dürfte ein beliebig schwieriges Unterfangen werden. Der Wechsel zurück zu openSUSE Leap 15.1 dürfte da der einfachere Weg sein. Allerdings ist das keine echte "Problemlösung", denn bei mir (und wahrscheinlich auch bei vielen anderen Benutzern) funktioniert openSUSE Leap 15.2 problemlos.

-> Das kann ich verstehen. Ein alternativer Weg wäre auch, eben einen neuen User anzulegen, aber das ist auch viel Arbeit, bis alles wie gewünscht funktioniert. Denn ich mag die Default-Einstellungen von KDE sehr selten.

Bis später und Danke!

[susejunky]

... und wie kann ich die Dateien öffnen (die neuen seit 8:45 bis 9:40 Uhr jeweils 9,4 und 8,9 Gib), ohne das System lahm zu legen?

Ich kann Dir nicht sagen, ob man journalctl nutzen kann, wenn rsyslog installiert ist, aber ich denke es ist ein Versuch wert

# journalctl -b 0 -p 3

als Administrator in einer Konsole ausgeführt sollte "nur echte Fehler" (keine Warnungen etc.) seit dem letzten Start anzeigen.

Wenn die Menge überschaubar ist, kannst Du sie hier zeigen ansonsten auf https://susepaste.org/ hochladen und hier den Link angeben.

Wenn ein neu angelegter Benutzer tatsächlich fehlerfrei funktioniert, ist dessen Nutzung der sinnvollste Weg. Zurück zu openSUSE Leap 15.1 ist keine zukunftsträchtige Lösung. Wenn Deine 15.1-Konfiguration mit 15.2 nicht funktioniert, ist kaum zu erwarten, dass sich das mit der auf 15.2 folgenden Version ändert.

Viele Grüße

susejunky

[geppino]

Hallo susejunky udn Sauerland,

vielen Dank für Eure Beiträge!

Also, Folgendes kann ich jetzt berichten:
1. syslog und rsyslog habe ich deinstalliert. Daher gibt es die Dateien messages und warn nicht mehr (Mehr dazu: lese weiter). Noch keine großen Dateien mehr unter /var/log.

2. nachdem ich die Dateiindizierung deaktiviert habe läuft das System ziemlich ruhig: bei Kontact, Firefox, KAlarm, Audacious (im Stream-Betrieb) und einigen Diensten im Hintergrund wird die CPU 5 - 10 % beansprucht; RAM nur ca. 2 GiB. Das ist normal. Im Leap 15.1 gab allerdings es fast dieselben Werte bei aktivierter Dateiindizierung. Auch das Akonadi-System ist mittlererweile viel ruhiger geworden.

3. Zum Inhalt der Warnmeldungen beim Hochfahren.
Hier die (von mir kommentierte) Ausgabe von journalctl nach den Schritten 1. und 2.:

# journalctl -b 0 -p 3
-- Logs begin at Fri 2020-09-04 12:57:01 CEST, end at Fri 2020-09-04 14:56:57 CEST. --
Sep 04 14:56:55 localhost kernel: pnp 00:01: can't evaluate _CRS: 12311  
Sep 04 14:56:55 localhost kernel: ima: Error Communicating to TPM chip
Sep 04 14:56:55 localhost kernel: ima: Error Communicating to TPM chip
Sep 04 14:56:55 localhost kernel: ima: Error Communicating to TPM chip
Sep 04 14:56:55 localhost kernel: ima: Error Communicating to TPM chip
Sep 04 14:56:55 localhost kernel: ima: Error Communicating to TPM chip
Sep 04 14:56:55 localhost kernel: ima: Error Communicating to TPM chip
Sep 04 14:56:55 localhost kernel: ima: Error Communicating to TPM chip
Sep 04 14:56:55 localhost kernel: ima: Error Communicating to TPM chip
Sep 04 12:57:02 localhost systemd-udevd[489]: Specified group 'plugdev' unknown
    # KOMMENT: diese Gruppe gibt es jedenfalls nicht unter users@localhost (Veraltung von Bewnutzern und Gruppe in YAST)
    #
Sep 04 12:57:12 localhost kernel: blk_update_request: I/O error, dev sr0, sector 8506880 op 0x0:(READ) flags 0x84700 phys_seg 31 prio class 0
Sep 04 12:57:19 localhost kernel: blk_update_request: I/O error, dev sr0, sector 8507136 op 0x0:(READ) flags 0x80700 phys_seg 31 prio class 0
Sep 04 12:57:27 localhost kernel: blk_update_request: I/O error, dev sr0, sector 8507024 op 0x0:(READ) flags 0x0 phys_seg 2 prio class 0
Sep 04 12:57:27 localhost kernel: Buffer I/O error on dev sr0, logical block 2126756, async page read
Sep 04 12:57:27 localhost kernel: Buffer I/O error on dev sr0, logical block 2126757, async page read
    # KOMMENT: ich denke, die vorigen 5 Zeilen betreffen eine angelegte DVD (openSUSE Leap 15.1 Live). Ich sie entfernt und nach dem Neuboot erscheint sie nicht mehr.
    #
Sep 04 12:57:56 localhost akonadi_kalarm_dir_resource[2145]: parse error from icalcomponent_new_from_string. string= "im Verzeichnis \"privat-Erinnerungen\" gespeicherte KArlarm-Dateien sind es >
Sep 04 12:57:56 localhost akonadi_kalarm_dir_resource[2145]: parse error from icalcomponent_new_from_string. string= "im Verzeichnis \"privat-Erinnerungen\" gespeicherte KArlarm-Dateien sind es >
Sep 04 12:57:56 localhost akonadi_kalarm_dir_resource[2146]: parse error from icalcomponent_new_from_string. string= "im Verzeichnis \"Tagebuch-Erinnerungen\" gespeicherte KAlarm-Dateien sind es>
Sep 04 12:57:56 localhost akonadi_kalarm_dir_resource[2146]: parse error from icalcomponent_new_from_string. string= "im Verzeichnis \"Tagebuch-Erinnerungen\" gespeicherte KAlarm-Dateien sind es>
Sep 04 12:57:57 localhost akonadi_kalarm_dir_resource[2147]: parse error from icalcomponent_new_from_string. string= "im Verzeichnis \"betrieblich\" gespeicherte Erinnerungen sind es solche,\ndi>
Sep 04 12:57:57 localhost akonadi_kalarm_dir_resource[2147]: parse error from icalcomponent_new_from_string. string= "im Verzeichnis \"betrieblich\" gespeicherte Erinnerungen sind es solche,\ndi>
lines 1-22/22 (END)
    # KOMMENTAR: die vorigen 6 Zeilen bezihen sich auf einen Fehler, den ich mittlerweile behoben habe und erscheinen nach dem Neuboot nicht mehr.
    # 

nach dem letzten Boot sieht es so aus

# journalctl -p 3
-- Logs begin at Fri 2020-09-04 13:46:42 CEST, end at Fri 2020-09-04 15:46:38 CEST. --
Sep 04 15:46:36 localhost kernel: pnp 00:01: can't evaluate _CRS: 12311
Sep 04 15:46:36 localhost kernel: ima: Error Communicating to TPM chip
Sep 04 15:46:36 localhost kernel: ima: Error Communicating to TPM chip
Sep 04 15:46:36 localhost kernel: ima: Error Communicating to TPM chip
Sep 04 15:46:36 localhost kernel: ima: Error Communicating to TPM chip
Sep 04 15:46:36 localhost kernel: ima: Error Communicating to TPM chip
Sep 04 15:46:36 localhost kernel: ima: Error Communicating to TPM chip
Sep 04 15:46:36 localhost kernel: ima: Error Communicating to TPM chip
Sep 04 15:46:36 localhost kernel: ima: Error Communicating to TPM chip
Sep 04 13:46:44 localhost systemd-udevd[478]: Specified group 'plugdev' unknown
Sep 04 13:52:53 localhost kalarm[2415]: No text-to-speech plug-ins were found.

Sind diese Fehlermeldungen ernst zu nehmen?
5. Die alten Warn-Dateien sind zu groß, um sie hier her zu posten. Auch jetzt bei niedrigem Ressoursen-Nutzung hatt kwrite warn (2,2 GiB) nach 10 Minuten noch nicht voll geladen, das system ging aber gleich in die Knien und es ging praktisch nichts mehr.
Ich habe allerdings den Eindruck, dass Leap 15.2 ziemlich langsamer läuft und "empfindlicher" ist als der Vorgenger, obwohl ich ihn vergleichsweiser weniger beansprüche

6. Bezüglich Downgrading (als PS zu verstehen ... )
Es stimmt, das wäre eher eine kurzfristige Lösung, denn Leap 15.1 ist keine LTS-Version. Andererseits bin ich seit Suse 9.x nie alle Versionen durchlaufen. Upgradet habe ich das System erst nachdem keine Sicherheitsupdates mehr zur Verfügung gestellt waren.
Darüber hinaus habe ich noch die intakte /home-Partition von Leap 15.1 auf einer anderen Festplatte und das System könnte ich "parallel" (sozusagen als tri-boot, Win 10 / Leap 15.2 / Leap 15.1) mit unterschiedlichen /home-Partitionen installieren. Die notwendigen Partitionen wurden beim Formatieren der Festplatte aus Sicherheitsgründen bereits angelegt.Vielleicht habe Zeit und Lust am nächsten Wochenende ...

Ciao, geppino

[Sauerland]

Dann nimm less:
als root:

less /var/log/messages

Und mit copy/paste kannst du hier ein paar Zeilen in Code-Tags einfügen

Abbrechen mit q

[geppino]

Dann nimm less:
als root:

less /var/log/messages

Und mit copy/paste kannst du hier ein paar Zeilen in Code-Tags einfügen

Abbrechen mit q

Sauerland, die "messages" besteht aus 13.811.570 Zeilen!
Welche soll ich nehmen ... ! Vielleicht besser aus warn ("nur" 1.380.679 Zeilen) .
Ist vielleicht irgendwie die Priorität durch Ziffern oder Schriftfarbe gekennzeichnet?

hier auf jeden Fall die ersten 52 Zeilen von warn

020-09-04T00:24:28.183411+02:00 localhost systemd[1]: systemd 234 running in system mode. (+PAM -AUDIT +SELINUX -IMA +APPARMOR -SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4
 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN2 -IDN default-hierarchy=hybrid)
2020-09-04T00:24:28.183589+02:00 localhost systemd[1]: Detected architecture x86-64.
2020-09-04T00:24:28.183419+02:00 localhost kernel: [    0.000000] microcode: microcode updated early to revision 0x28, date = 2019-11-12
2020-09-04T00:24:28.183600+02:00 localhost kernel: [    0.000000] Linux version 5.3.18-lp152.36-default (geeko@buildhost) (gcc version 7.5.0 (SUSE Linux)) #1 SMP Tue Aug 18 17:09:44 UTC 2020 (885
251f)
2020-09-04T00:24:28.183599+02:00 localhost systemd[1]: haveged.service: Service RestartSec=100ms expired, scheduling restart.
2020-09-04T00:24:28.183603+02:00 localhost kernel: [    0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-5.3.18-lp152.36-default root=UUID=fcf037a3-9658-4ac2-af19-4f316a8add45 splash=silent resum
e=/dev/disk/by-uuid/4726a7d4-e505-447b-be2b-e8ece5ca886b quiet mitigations=auto
2020-09-04T00:24:28.183603+02:00 localhost kernel: [    0.000000] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers'
2020-09-04T00:24:28.183604+02:00 localhost systemd[1]: Stopped Entropy Daemon based on the HAVEGE algorithm.
2020-09-04T00:24:28.183606+02:00 localhost kernel: [    0.000000] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
2020-09-04T00:24:28.183607+02:00 localhost kernel: [    0.000000] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
2020-09-04T00:24:28.183607+02:00 localhost kernel: [    0.000000] x86/fpu: xstate_offset[2]:  576, xstate_sizes[2]:  256
2020-09-04T00:24:28.183608+02:00 localhost kernel: [    0.000000] x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, using 'standard' format.
2020-09-04T00:24:28.183609+02:00 localhost kernel: [    0.000000] BIOS-provided physical RAM map:
2020-09-04T00:24:28.183609+02:00 localhost kernel: [    0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009dbff] usable
2020-09-04T00:24:28.183610+02:00 localhost kernel: [    0.000000] BIOS-e820: [mem 0x000000000009dc00-0x000000000009ffff] reserved
2020-09-04T00:24:28.183612+02:00 localhost kernel: [    0.000000] BIOS-e820: [mem 0x00000000000e0000-0x00000000000fffff] reserved
2020-09-04T00:24:28.183612+02:00 localhost kernel: [    0.000000] BIOS-e820: [mem 0x0000000000100000-0x00000000d9ffafff] usable
2020-09-04T00:24:28.183607+02:00 localhost systemd[1]: Started Entropy Daemon based on the HAVEGE algorithm.
2020-09-04T00:24:28.183612+02:00 localhost kernel: [    0.000000] BIOS-e820: [mem 0x00000000d9ffb000-0x00000000da001fff] ACPI NVS
2020-09-04T00:24:28.183614+02:00 localhost kernel: [    0.000000] BIOS-e820: [mem 0x00000000da002000-0x00000000da450fff] usable
2020-09-04T00:24:28.183615+02:00 localhost kernel: [    0.000000] BIOS-e820: [mem 0x00000000da451000-0x00000000da7f9fff] reserved
2020-09-04T00:24:28.183615+02:00 localhost kernel: [    0.000000] BIOS-e820: [mem 0x00000000da7fa000-0x00000000daeb6fff] usable
2020-09-04T00:24:28.183615+02:00 localhost systemd[1]: Started Load Kernel Modules.
2020-09-04T00:24:28.183617+02:00 localhost kernel: [    0.000000] BIOS-e820: [mem 0x00000000daeb7000-0x00000000daf3afff] ACPI NVS
2020-09-04T00:24:28.183617+02:00 localhost kernel: [    0.000000] BIOS-e820: [mem 0x00000000daf3b000-0x00000000dafc4fff] usable
2020-09-04T00:24:28.183618+02:00 localhost kernel: [    0.000000] BIOS-e820: [mem 0x00000000dafc5000-0x00000000db045fff] reserved
2020-09-04T00:24:28.183618+02:00 localhost kernel: [    0.000000] BIOS-e820: [mem 0x00000000db046000-0x00000000db04bfff] usable
2020-09-04T00:24:28.183618+02:00 localhost systemd[1]: Starting Apply Kernel Variables...
2020-09-04T00:24:28.183619+02:00 localhost kernel: [    0.000000] BIOS-e820: [mem 0x00000000db04c000-0x00000000db063fff] ACPI data
2020-09-04T00:24:28.183620+02:00 localhost kernel: [    0.000000] BIOS-e820: [mem 0x00000000db064000-0x00000000db0bafff] usable
2020-09-04T00:24:28.183621+02:00 localhost kernel: [    0.000000] BIOS-e820: [mem 0x00000000db0bb000-0x00000000db0c7fff] reserved
2020-09-04T00:24:28.183621+02:00 localhost systemd[1]: Mounted Kernel Debug File System.
2020-09-04T00:24:28.183624+02:00 localhost kernel: [    0.000000] BIOS-e820: [mem 0x00000000db0c8000-0x00000000dbe64fff] usable
2020-09-04T00:24:28.183624+02:00 localhost kernel: [    0.000000] BIOS-e820: [mem 0x00000000dbe65000-0x00000000dbea4fff] reserved
2020-09-04T00:24:28.183624+02:00 localhost systemd[1]: Mounted Huge Pages File System.
2020-09-04T00:24:28.183625+02:00 localhost kernel: [    0.000000] BIOS-e820: [mem 0x00000000dbea5000-0x00000000dbef3fff] usable
2020-09-04T00:24:28.183626+02:00 localhost kernel: [    0.000000] BIOS-e820: [mem 0x00000000dbef4000-0x00000000dbf23fff] reserved
2020-09-04T00:24:28.183627+02:00 localhost kernel: [    0.000000] BIOS-e820: [mem 0x00000000dbf24000-0x00000000dbf27fff] ACPI data
2020-09-04T00:24:28.183627+02:00 localhost kernel: [    0.000000] BIOS-e820: [mem 0x00000000dbf28000-0x00000000dbf2ffff] ACPI NVS
2020-09-04T00:24:28.183627+02:00 localhost systemd[1]: Mounted POSIX Message Queue File System.
2020-09-04T00:24:28.183629+02:00 localhost kernel: [    0.000000] BIOS-e820: [mem 0x00000000dbf30000-0x00000000dbf3dfff] reserved
2020-09-04T00:24:28.183629+02:00 localhost kernel: [    0.000000] BIOS-e820: [mem 0x00000000dbf3e000-0x00000000dbf4efff] ACPI NVS
2020-09-04T00:24:28.183630+02:00 localhost kernel: [    0.000000] BIOS-e820: [mem 0x00000000dbf4f000-0x00000000dbf4ffff] reserved
2020-09-04T00:24:28.183630+02:00 localhost kernel: [    0.000000] BIOS-e820: [mem 0x00000000dbf50000-0x00000000dbf60fff] ACPI NVS
2020-09-04T00:24:28.183631+02:00 localhost kernel: [    0.000000] BIOS-e820: [mem 0x00000000dbf61000-0x00000000dbf8cfff] reserved
2020-09-04T00:24:28.183631+02:00 localhost kernel: [    0.000000] BIOS-e820: [mem 0x00000000dbf8d000-0x00000000dbf93fff] ACPI NVS
2020-09-04T00:24:28.183631+02:00 localhost kernel: [    0.000000] BIOS-e820: [mem 0x00000000dbf94000-0x00000000dbfe3fff] reserved
2020-09-04T00:24:28.183630+02:00 localhost systemd[1]: Started Remount Root and Kernel File Systems.
2020-09-04T00:24:28.183633+02:00 localhost kernel: [    0.000000] BIOS-e820: [mem 0x00000000dbfe4000-0x00000000dbffcfff] usable
2020-09-04T00:24:28.183633+02:00 localhost kernel: [    0.000000] BIOS-e820: [mem 0x00000000dbffd000-0x00000000dbffefff] reserved
2020-09-04T00:24:28.183634+02:00 localhost kernel: [    0.000000] BIOS-e820: [mem 0x00000000dbfff000-0x00000000dbffffff] usable
2020-09-04T00:24:28.183634+02:00 localhost kernel: [    0.000000] BIOS-e820: [mem 0x00000000dd000000-0x00000000df1fffff] reserved