Mama (92) denkt da anders. Sie klappt einfach den Deckel zu. Der Rechner legt sich blitzschnell schlafen. Wenn sie ihn wieder braucht, macht sie den Deckel auf und der Rechner wacht blitzschnell auf. Sie schaltet nie aus, weil ihr das zu umständlich ist. Lieber steckt sie das Netzgerät an und lässt ihn durchlaufen.
Mein Desktop i7-6700K läuft auch andauernd. Ich lege ihn schlafen (2 Watt Stromverbrauch) und wecke ihn, wenn ich ihn brauche.
erlangen:~ # journalctl -b -2 -u systemd-suspend.service --output short-monotonic
-- Logs begin at Wed 2019-07-31 16:03:01 CEST, end at Sat 2019-08-24 06:16:07 CEST. --
[16302.588769] erlangen systemd[1]: Starting Suspend...
[16302.593658] erlangen systemd-sleep[10016]: INFO: running /usr/lib/systemd/system-sleep/grub2.sleep for
[16302.593658] erlangen systemd-sleep[10016]: INFO: Running prepare-grub ..
[16302.836104] erlangen systemd-sleep[10016]: running kernel is grub menu entry openSUSE Tumbleweed (vmlinuz-5.2.8-1-default)
[16302.836104] erlangen systemd-sleep[10016]: preparing boot-loader: selecting entry openSUSE Tumbleweed, kernel /boot/5.2.8-1-default
[16302.857669] erlangen systemd-sleep[10016]: Suspending system...
[16304.189378] erlangen systemd-sleep[10016]: System resumed.
[16304.193331] erlangen systemd-sleep[10016]: INFO: running /usr/lib/systemd/system-sleep/grub2.sleep for
**16304.19**3331] erlangen systemd-sleep[10016]: INFO: Running grub-once-restore ..
[16315.166124] erlangen systemd-sleep[10016]: INFO: Done.
[16315.168925] erlangen systemd[1]: systemd-suspend.service: Succeeded.
[16315.170165] erlangen systemd[1]: Started Suspend.
erlangen:~ #
Das Aufwachen funktioniert immer. Es dauert keine 2 Sekunden. Bis die HDD in Schwung kommt dauert es noch einmal 11 Sekunden. Benutzbar ist er trotzdem nach 2 Sekunden. Ich schätze das sehr.
Bei mir ist es so, dass es alles aufgerüstete Desktop-Rechner sind, wo ich einen höheren Standby-Verbrauch vermuten würde.
Die sind auch alle so konfiguriert, dass sie sehr schnell booten und wieder runter fahren.
Des Weiteren hängen die PCs zusammen mit weiteren Multimedia-Geräten an Steckdosenleisten, die ich vor Benutzung ein- und nach Benutzung abschalte.
Ich denke, dass es in meinem Fall so vertretbar ist, bei einem Klapprechner ist unter Umständen ein Standby-Modus sinnvoller.
(Ich habe übrigens einen 93-jährigen Vater, der zu seinem 70. Geburtstag seinen ersten PC bekam und wo ich jetzt immer wieder staune, was der mit seinem jetzigen PC so alles treibt… teilweise krudes Zeug, aber es hält ihn geistig fit).
Bei Gelegenheit kann ich mal schauen, was journalctl sagt, bei einer Leap 15.1 Installation mit LVM-Paketen, wo das Herunterfahren NICHT bis zum Poweroff führt.
Was muss ich tun, um hier die Passagen aus journalctl posten zu können, die jetzt interessant wären?
Ich habe ehrlich gesagt keine Erfahrung mit journalctl und mit Code raus kopieren und solchen Sachen.:sarcastic:
Das ist hier mein erstes IT-Forum, wo ich angemeldet bin.
Den Verbrauche messe ich direkt am Stecker der Geräte mit einem Energiemessgerät (0,2 - 3.680 Watt). Das System analysiert inxi (Code-Tags mit # im Editor Menü einfügen):
Bei Gelegenheit kann ich mal schauen, was journalctl sagt, bei einer Leap 15.1 Installation mit LVM-Paketen, wo das Herunterfahren NICHT bis zum Poweroff führt.
Was muss ich tun, um hier die Passagen aus journalctl posten zu können, die jetzt interessant wären?
Schau nach welche Units vorhanden sind:
erlangen:~ # systemctl list-unit-files 'lvm*'
UNIT FILE STATE
lvm2-lvmetad.service static
lvm2-lvmpolld.service static
lvm2-monitor.service disabled
lvm2-pvscan@.service static
lvm2-lvmetad.socket enabled
lvm2-lvmpolld.socket enabled
6 unit files listed.
erlangen:~ #
Die Aktivitäten listet journalctl:
erlangen:~ # journalctl -u 'lvm*' --since '2019-08-23'
-- Logs begin at Wed 2019-07-31 16:03:01 CEST, end at Sat 2019-08-24 12:52:44 CEST. --
Aug 23 06:01:07 erlangen systemd[1]: lvm2-lvmpolld.socket: Succeeded.
Aug 23 06:01:07 erlangen systemd[1]: Closed LVM2 poll daemon socket.
Aug 23 06:01:07 erlangen systemd[1]: lvm2-lvmetad.socket: Succeeded.
Aug 23 06:01:07 erlangen systemd[1]: Closed LVM2 metadata daemon socket.
-- Reboot --
Aug 24 07:30:16 erlangen systemd[1]: lvm2-lvmpolld.socket: Succeeded.
Aug 24 07:30:16 erlangen systemd[1]: Closed LVM2 poll daemon socket.
Aug 24 07:30:16 erlangen systemd[1]: lvm2-lvmetad.socket: Succeeded.
Aug 24 07:30:16 erlangen systemd[1]: Closed LVM2 metadata daemon socket.
erlangen:~ #
Bei Leap 15.1 auf dem USB-Stick sieht es so aus:
erlangen:~ # journalctl -b -u 'lvm*' --directory /run/media/karl/cow/rw/var/log/journal/
-- Logs begin at Thu 2019-08-15 15:16:49 CEST, end at Sat 2019-08-24 07:36:57 CEST. --
Aug 24 07:30:44 localhost systemd[1]: Started LVM2 metadata daemon.
Aug 24 07:30:46 localhost systemd[1]: Started Monitoring of LVM2 mirrors, snapshots etc. using dmeventd or progress polling.
Aug 24 07:36:49 localhost.localdomain systemd[1]: Closed LVM2 poll daemon socket.
Aug 24 07:36:57 localhost.localdomain systemd[1]: Stopping Monitoring of LVM2 mirrors, snapshots etc. using dmeventd or progress polling...
erlangen:~ #
Der LVM2 metadata daemon läuft zwar. Aber bei mir tut er nichts und darum kümmere ich mich nicht darum.
In meinem Leap 15.1 - Testsystem habe ich die 3 zuvor entfernten LVM - Pakete wieder installiert.
Danach funktionierte das Herunterfahren MIT Poweroff noch einmalig, nach Neustart und zweitem Herunterfahren kam das Poweroff erst nach der langen Wartezeit, wie schon bekannt.
Dann habe ich nochmals einen Reboot durchgeführt und im Anschluss Folgendes ermittelt:
**linux-40il:/home/test1 #** systemctl list-unit-files 'lvm*'
UNIT FILE STATE
lvm2-lvmetad.service static
lvm2-lvmpolld.service static
lvm2-monitor.service **enabled**
lvm2-pvscan@.service static
lvm2-lvmetad.socket **enabled**
lvm2-lvmpolld.socket **enabled**
6 unit files listed.
**linux-40il:/home/test1 #**
Die “Aktivitätenliste”
**linux-40il:/home/test1 #** journalctl -u 'lvm*' --since '2019-08-24'
-- Logs begin at Sat 2019-08-24 19:44:57 CEST, end at Sat 2019-08-24 20:19:09 CEST. --
Aug 24 19:45:01 linux-40il systemd[1]: Started LVM2 metadata daemon.
Aug 24 19:45:01 linux-40il lvm[421]: /dev/sda: open failed: Kein Medium gefunden
Aug 24 19:45:01 linux-40il lvm[421]: /dev/sda: open failed: Kein Medium gefunden
Aug 24 19:45:01 linux-40il systemd[1]: Started Monitoring of LVM2 mirrors, snapshots etc. using dmeventd or progress polling.
**linux-40il:/home/test1 #**
lvm2-monitor macht offensichtlich Käse. Wenn du nur schnell herunterfahren willst und die Funktionalität nicht brauchst reicht es das Kommando ‘systemctl disable lvm2-monitor.service’ auszuführen.
Wenn du neugierig bist nimmst du ‘systemctl edit lvm2-monitor.service’ und fügst die folgenden Zeilen ein:
[Service]
Environment=SYSTEMD_LOG_LEVEL=debug
Mich wundert es, dass lvm bei mir funktioniert und bei dir nicht. Läuft der Rechner etwa im BIOS Modus?
erlangen:~ # ll /sys/firmware/efi/
total 0
-r--r--r-- 1 root root 4096 Aug 24 20:50 config_table
drwxr-xr-x 2 root root 0 Aug 24 17:04 efivars
-r--r--r-- 1 root root 4096 Aug 24 20:50 fw_platform_size
-r--r--r-- 1 root root 4096 Aug 24 20:50 fw_vendor
-r--r--r-- 1 root root 4096 Aug 24 20:50 runtime
drwxr-xr-x 12 root root 0 Aug 24 20:50 runtime-map
-r-------- 1 root root 4096 Aug 24 17:04 systab
drwxr-xr-x 60 root root 0 Aug 24 20:50 vars
erlangen:~ #
**linux-40il:/home/test1 #** ll /sys/firmware/efi/
ls: Zugriff auf '/sys/firmware/efi/' nicht möglich: Datei oder Verzeichnis nicht gefunden
**linux-40il:/home/test1 #**
Ich kann mit dem Begriff BIOS-Mode nichts anfangen, aber der PC läuft eigentlich ganz prima.
Bitte entschuldige meine partielle Unwissenheit.
Was mir aufgefallen ist:
Irgendwie bringt der PC eventuell möglicherweise die Laufwerksbezeichnungen mal durcheinander, kann das sein?
LVM wollte bei mir doch irgendwas bei sda machen (siehe mein vorheriges Posting), aber im Moment zeigt er kein sda an im Partitioner:sarcastic:
Die erste SDD nennt er sdb, die zweite SSD nennt er sdc und wenn ich die externe Platte an usb dran stöpsel, nennt er es sdd.
Grübel.:sarcastic:
(Aber ansonsten funktioniert die Kiste fein)
Was mir aufgefallen ist: Irgendwie bringt der PC eventuell möglicherweise die Laufwerksbezeichnungen mal durcheinander, kann das sein?
Sein kann (fast) alles. Siinnvoll ist es wahrscheinlich nicht. Was kommt hier:
heute hat er die externe Platte als sda angezeigt, zumindest die Bezeichnungen sind also halbwegs schlüssig.
sdb1 ist Windows 10 Home (das brauche ich 2 bis 3 mal im Jahr, ich halte das OS aber aktuell, man weiß ja nie…)
sdb2 ist root von meinem 15.0-System, womit ich momentan (wieder) arbeite
sdb3 ist extended
sdb4 ist irgend so’n Dings, was bei der Installation von Windows automatisch angelegt wurde (enthält wahrscheinlich Microsoft-Schadsoftware)
sdc1 ist ein Datenspeicher, habe ich in dem 15.0-System mit eingebunden
Mit dem UEFI ist das so eine Sache…
Ich wollte sowohl 15.0 als auch 15.1 mit EFI-Bootloader installieren, aber das wurde immer mit Fehler abgebrochen.
Nun läuft es mit Grub2 ohne EFI.
Einstellung im BIOS ist:
UEFI und Legacy,
UEFI first.
Wie kann ich, ohne ganz viele Artikel und Anleitungen zu lesen, die ich vielleicht nicht ganz verstehe und wofür mir Zeit und Geduld fehlt, den PC optimieren?
Kann ich auf UEFI umstellen, ohne meine installierten Betriebssysteme zu zerschießen? Das 15.0 und das Windows sollten zumindest bootbar bleiben.
lsblk berichtet erfreuliches. Windows und Linux haben jeweils eine eigene Platte. /home auf sdb5 macht keine Probleme. Für die Diskussion wären die Partitionstabellen hilfreich:
erlangen:~ # fdisk -l
Disk /dev/nvme0n1: 477 GiB, 512110190592 bytes, 1000215216 sectors
Disk model: Samsung SSD 950 PRO 512GB
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: A84F222E-0177-499B-A7EA-BDA6F31E2196
Device Start End Sectors Size Type
/dev/nvme0n1p1 206848 67102719 66895872 31.9G Linux filesystem
/dev/nvme0n1p2 67102720 134207487 67104768 32G Linux filesystem
/dev/nvme0n1p3 134207488 1000214527 866007040 413G Linux filesystem
/dev/nvme0n1p4 2048 206847 204800 100M EFI System
Partition table entries are not in disk order.
Disk /dev/sda: 3.7 TiB, 4000787030016 bytes, 7814037168 sectors
Disk model: WDC WD40EZRX-22S
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 27C8C52A-8091-403C-ADF1-E9C791667D40
Device Start End Sectors Size Type
/dev/sda1 67119104 134223871 67104768 32G Linux filesystem
/dev/sda2 16384 67119103 67102720 32G Linux filesystem
/dev/sda4 134223872 7814035455 7679811584 3.6T Linux filesystem
Partition table entries are not in disk order.
Disk /dev/sdb: 465.8 GiB, 500107862016 bytes, 976773168 sectors
Disk model: Samsung SSD 850
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 90C1973B-4A41-4E96-85BA-B7358EA77CCC
Device Start End Sectors Size Type
/dev/sdb1 2048 208895 206848 101M EFI System
/dev/sdb2 208896 63119359 62910464 30G Linux filesystem
/dev/sdb3 63119360 126033919 62914560 30G Linux filesystem
/dev/sdb4 126033920 894033919 768000000 366.2G Linux filesystem
/dev/sdb5 894033920 976773134 82739215 39.5G Linux filesystem
erlangen:~ #
Deine Festplatten haben alle dos Partitionstabellen, UEFI braucht aber gpt.
Die gute Nachricht: Eine Umwandlung dos > gpt und zurück ist ohne Datenverlust möglich.
Die schlechte Nachricht: Die Umwandlung macht den Bootlader kaputt.
Windows und Leap 15.0 auf einer Platte sind knifflig zu bearbeiten. sdb sollte also nicht angefasst werden.
Leap 15.1 auf einer eigenen Platte kann einfach umgestellt werden.
UEFI braucht eine Systempartition.
Bei meinem Rechner habe ich /dev/nvme0n1 erfolgreich konvertiert. Wenn ich mich recht erinnere war ich tapfer und habe das adhoc gemacht: sgdisk -g /dev/nvme0n1, bei dir also: sgdisk -g /dev/sdc. Bei Leuten ohne ausreichendes Karma kann das auch schief gehen. Deine Installation von Leap 15.1 benötigt sdc1 nicht unbedingt. Du kannst mit ‘YaST > Partitioner’ die Partition schrumpfen und eine UEFI Systempartition hinzufügen. Sie muss unter /boot/efi eingehängt werden. In ‘YaST Boot Loader’ wählst du ‘GRUB2 für EFI’ aus und klickst OK.
Der aufgezeigte Weg scheint machbar.
sdc1 ist reiner Datenspeicher. Ich lagere den Inhalt auf meine externe Platte aus, bis die PC-Umstrukturierung mit der neuen Partition und dem UEFI-Bootloader fertig ist.
Bevor ich anfange:
Ich gehe davon aus, das mein neuer UEFI-Bootloader auf sdc dann das Windows und das 15.0 - System von sdb auch booten kann?
(wenigstens sollte der Bootloader auf sdb nicht kaputt gehen, denn dann kommt man immer noch ans Windows ran, wenn man im BIOS die Bootpriorität der Devices ändert und UEFI ausstellt)
Ich habe durch Schrumpfen von sdc1 Platz gewonnen.
Beim Anlegen einer neuen Partition für efi will er diese dann sdc3 nennen - das habe ich aber erst einmal aufgeschoben.
**linux-40il:/home/test1 #** sgdisk -g /dev/sdc
***************************************************************
Found invalid GPT and valid MBR; converting MBR to GPT format
in memory.
***************************************************************
Warning! Secondary partition table overlaps the last partition by
33 blocks!
You will need to delete this partition or resize it in another utility.
Warning! Secondary partition table overlaps the last partition by
33 blocks!
You will need to delete this partition or resize it in another utility.
Aborting write of new partition table.
**linux-40il:/home/test1 #**
Es ist noch einmal alles gut gegangen. sgdisk hat bemerkt, dass am Ende der Platte nicht genügend freier Platz vorhanden ist um die Kopie der gpt unterzubringen. sdc2 muss also verkleinert werden. Dazu darf sie nicht gemountet sein. Am besten nimmst du ein Live System und verkleinerst sdc2 um ein weniges. Dann führst du wieder sgdisk -g /dev/sdc aus.
@karlmistelberger
Gestern Abend waren nach einander aufgrund der “Aktionen” zuerst das 15.0-System, danach auch das 15.1-System nicht mehr zum vollständigen Hochfahren zu bewegen;)
Nun habe ich wieder ein provisorisches 15.1-System neu installiert.
Aber mit dem EFI-Bootloader hat es (noch) nicht geklappt - obwohl ich die Rootpartiton zwischenzeitlich auf 10 GB verkleinert hatte und vermutlich genug Platz für die EFI-Partition gewesen wäre.
Die Leap 15.1-Installationsroutine brachte eine Meldung, dass meine “Plattform” nicht passt (sinngemäß).
Statt der EFI-Partition wurde mir eine BIOS-Bootpartition präsentiert - wozu auch immer, so etwas brauchte ich bisher nie.
Alle Daten aus Linux, die ich auf jeden Fall behalten muss, befinden sich als Backup außerhalb des PCs.
Auf dem PC ist jetzt nur noch die Windows-Partition wichtig.
(Windows sollte sich zukünftig auch noch starten lassen, tut es jetzt auch).
Wenn ich es bisher richtig verstanden habe, geht es darum, den PC vom BIOS-Modus in den UEFI-Modus zu bringen.
Da würde ich heute Abend weiter “basteln” wollen.
Wie geht es jetzt weiter?
Achso, ich glaube, wir sind schon eine Weile “Off-Topic” - macht das was?;):sarcastic:
Mir macht das nichts aus. Immerhin bist du schon einen Schritt weiter: sdc hat nun eine Partitionstabelle im gpt Format. Ich schlage vor, den Bootlader von Linux 15.1 auf sdc3 auf UEFI umzustellen. Dann wärest du fertig.
Ich zitiere von #31:
Deine Installation von Leap 15.1 benötigt sdc1 nicht unbedingt. Du kannst mit ‘YaST > Partitioner’ die Partition schrumpfen und eine UEFI Systempartition hinzufügen. Sie muss unter /boot/efi eingehängt werden. In ‘YaST Boot Loader’ wählst du ‘GRUB2 für EFI’ aus und klickst OK.
linux-3kj7:/home/test1 # fdisk -l
Festplatte /dev/sdb: 238,5 GiB, 256060514304 Bytes, 500118192 Sektoren
Disk model: TOSHIBA THNSNJ25
Einheiten: Sektoren von 1 * 512 = 512 Bytes
Sektorgröße (logisch/physikalisch): 512 Bytes / 512 Bytes
E/A-Größe (minimal/optimal): 512 Bytes / 512 Bytes
Festplattenbezeichnungstyp: gpt
Festplattenbezeichner: D69E436E-E358-41BE-801C-328702738CB8
Gerät Anfang Ende Sektoren Größe Typ
/dev/sdb1 2048 471445537 471443490 224,8G Linux-Dateisystem
/dev/sdb2 471447552 471463935 16384 8M BIOS boot
/dev/sdb3 471463936 472487935 1024000 500M EFI-System
/dev/sdb4 472487936 500118158 27630223 13,2G Linux-Dateisystem
Festplatte /dev/sda: 119,2 GiB, 128035676160 Bytes, 250069680 Sektoren
Disk model: M4-CT128M4SSD2
Einheiten: Sektoren von 1 * 512 = 512 Bytes
Sektorgröße (logisch/physikalisch): 512 Bytes / 512 Bytes
E/A-Größe (minimal/optimal): 512 Bytes / 512 Bytes
Festplattenbezeichnungstyp: dos
Festplattenbezeichner: 0x0009d0d8
Gerät Boot Anfang Ende Sektoren Größe Kn Typ
/dev/sda1 2048 104879578 104877531 50G 7 HPFS/NTFS/exFAT
/dev/sda2 104880128 176560127 71680000 34,2G 83 Linux
/dev/sda3 * 176560128 248242175 71682048 34,2G f W95 Erw. (LBA)
/dev/sda4 248242176 250060799 1818624 888M 27 Verst. NTFS WinRE
/dev/sda5 176562176 244035175 67473000 32,2G 83 Linux
/dev/sda6 244035584 248242175 4206592 2G 82 Linux Swap / Solaris
Partitionstabelleneinträge sind nicht in Festplatten-Reihenfolge.
linux-3kj7:/home/test1 #
Ich habe das 15.1 noch ein weiteres Mal installieren müssen, weil außerhalb der Installationsroutine die efi-Bootpartition nicht zu erstellen war, da führte kein mir bekannter Weg hin.
Warum das so ist:
Mein 15.0 lässt sich ja nun nicht mehr starten und von einer live-CD aus (z.B. SUSE Krypton) ging es auch nicht.
Die Funktion add bzw. hinzu fügen wurde im Partioner nicht angeboten für sdb.
Ebenfalls nicht mehr booten lässt sich nun das Windows auf sda1 - das taucht in der Boot-Optionsliste nicht mehr auf.
Gibt es eine Möglichkeit, das Windows jetzt irgendwie startbar zu machen oder bleibt nur eine Neuinstallation?
Falls ja, wie sollte ich es anstellen, dass es sich mit dem UEFI verträgt?
Ich habe hier ein Gigabyte Z77-D3H-Board, da ist jetzt “openSUSE secureboot” als oberste Bootpriorität eingestellt.
Nochmal zusammen gefasst:
Der Bootloader startet das 15.1 (da ist soweit alles OK), das 15.0 wird gelistet (aber es hängt sich beim Start auf, dies ist nicht schlimm, ich werde jetzt sowieso das 15.1 weiter einrichten), aber das Windows wird nicht gelistet (wie schon erwähnt nutze ich es selten, möchte es aber eigentlich schon auf dem PC starten können).
Alles gut!
Mein Board bzw. das BIOS bietet die Möglichkeit, beim Durchlauf des BIOS-Screens mittels F12-Taste ein BIOS-eigenes Menü mit Bootoptionen aufzurufen, ohne das man ins BIOS direkt rein muss.
Da kann ich nun bequem umschalten:
Entweder EFI-Bootloader (openSUSE secureboot) für das gpt-System oder Windows Loader für die DOS-Platte.
Somit bin jetzt fertig mit den UEFI-Umbauarbeiten und zufrieden das es läuft.
Ich danke Dir für die Hilfestellung, ohne die ich mich momentan nicht an ein solches Projekt ran getraut hätte.
Gern geschehen. Es führen alle Wege nach Rom, auch die langen.
Wenn die UEFI Installation scheitert muss es nicht an der Hauptplatine liegen. Es kann auch die Festplatte sein, die sich bei gpt sträubt. Das Booten eines Systems von einem USB Stick schafft Klarheit ohne viel Arbeit zu machen: How To Try openSUSE Without Making Any Changes To Your PC - openSUSE Wiki
