Beiträge von Igel1954

Meine "heilenden Hände" haben es repariert bekommen.

Ich hatte über YAST meine installierte Virtualbox auf 6.1.36 zurückgesetzt, aber die Maschinen sind trotzdem kommentarlos abgestürzt.

Ich hab dann über Yast wieder auf die Version 6.1.38 upgedatet. Danach ließ sich zumindest die Windows10-Maschine wieder starten und nach den Meldungen auf dem virtuellen Bildschirm "Automatische Reparatur", "PC wird überprüft" und "Reparatur wird durchgeführt" ist das Windows wieder nutzbar.

Ich hab nur keine Ahnung, was da nach dem "automatischen" Update per zypper passiert ist. Das Problem hat sich jetzt erst mal erledigt und ich kann meine Buchhaltung durchführen.

Nach dem Update auf Virtualbox 6.1.38 bekomme ich meine beiden virtuellen Maschinen (Windows10 und GekoLinux) nicht mehr gestartet.

Kurt nach dem Starten der Systeme verabschiedet sich das VBOX-Fenster kommentarlos vom Desktop.

Im Log finde ich am Ende die Meldung über einen Hardware-Reset. Für den finde ich aber keinen Grund.

Ich häng das letzte Log mal als Textfile an.

VBoxSVC_log.txt

Ich setz die VBox jetzt aber erst mal auf 6.1.36 zurück, damit ich meine Buchführung machen kann.

SCH****, unter 6.1.36 brechen sie jetzt auch kommentarlos ab.

Zitat von Sauerland

Das war jetzt nur grob zusammengestrickt, das Script schreibt dann nur per ssh ne Datei auf meinen Desktop Rechner....

Code

[Unit]
Description=Start at shutdown, reboot, halt
Before=shutdown.target reboot.target halt.target

[Service]
Type=oneshot
ExecStart=/home/stephan/bin/fahren

[Install]
RequiredBy=shutdown.target reboot.target halt.target

Das Problem ist, das beim starten des Services die Datei schon geschrieben wird, also beim Rechnerstart.

Beim Herunterfahren wird die Datei auch geschrieben.......

Bei mir hätte es ähnlich ausgesehen. Wenn ich dich richtig verstehe, dann wird das Script in der Service-Unit auch schon beim Rechnerstart ausgeführt? Was mich jetzt etwas verwirrt.

EVtl. müsste in dem Abschnitt [Unit] noch Requires=shutdown.target reboot.target halt.target

Ich müsste das mal selber ausprobieren, aber ich komme in dieser Woche nicht mehr dazu.

Zitat von Sauerland

selbst bei systemd hat es nicht funktioniert

Kannst du den Unit-file mal posten? Ich hab in etwa eine Vorstellung wie die Service-Unit aussehen sollte/müsste.

Zitat von freestylz

openSUSE bietet drei Optionen das Skript auszuführen:

1.) Beim Laden des Profils

2.) Beim Entladen des Profils

3.) Nach xx Minuten

Ich würde das so interpretieren:

#1 erfolgt beim grafischen Login des Users

#2 beim Logout/Logoff des Users

Wenn der Akku im Betrieb einen definierten niedrigen Ladezustand erreicht, wird der Nutzer ausgeloggt, dabei das Profil entladen (aus dem Speicher geschmissen) und dabei das Script ausgeführt.

Ob meine Interpretation so stimmt, kann ich nicht testen, weil mein Desktop dauerhaft ohne USV an der Steckdose hängt und ich auch kein NAS betreibe.

Zitat von shepheard67

- warum gibt es kein Tutorial zur Verwendung alternativer Kernels explizit für Leap15.4 ?

- warum gibt es so viele opensuse-Tutorials, die auf leere oder nicht-existente Repositories zeigen ?

- warum gibt es ein opensuse kernel:stable Repository, wenn ich es für Leap15.4 nicht nutzen kann, weil dieses eine veraltete glibc-Version verwendet ?

- warum bietet das das funktionierende 'backport' Repository nur *einen* Kernel an (5.19) ?

- warum nutzt Leap15.4 überhaupt eine veraltete glibc ?

Diese Fragen können dir nur die Entwickler von OpenSUSE beantworten, die in diesem reinen Benutzerforum aber nicht mitlesen. Hier findest du nur Benutzer von OpenSUSE, die versuchen mit ihrem Wissen anderen Benutzern weiter zu helfen.

Deine Fragen sollteste vielleicht über einen Bugreport an OpenSUSE stellen, bzw. deine Fragen im Forum von opensuse.org stellen.

Upps. da war Sauerland schneller im tippen

Und hier ist noch als Beispiel die Units für den Backup mit fsarchiver und borg in einer Service-Unit:

[Unit]
Description=BackupFS --timer
After=network.target network-online.target local-fs.target remote-fs.target
Wants=network-online.target  

[Timer]
OnCalendar=Sun
Persistent=true     
Unit=BackupFS.service

[Install]
WantedBy=multi-user.target

[Unit]
Description=BackupFS --service
#
# Sonntägliche Sicherung der Filesysteme der 2. und 3. HDD mit fsarchiver
# und anschliessend noch mit BorgBackup
# Die Beschreibung des Scriptes ist im Header des Scripts
#
Documentation=man:fsarchiver(8)
Documentation=man:borg 
After=network.target network-online.target local-fs.target remote-fs.target
Wants=network-online.target

[Service]
Type=oneshot
NotifyAccess=all 
ExecCondition=-/bin/rm /var/log/BackupFS.log
Environment="SHELL=/bin/bash" "PATH=/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/sbin:/bin:/usr/lib/news/bin" 
User=root
Group=root 
WorkingDirectory=~
StandardOutput=append:/var/log/BackupFS.log
StandardError=inherit
ExecStart=/bin/bash -lc '/usr/local/bin/BackupFS.rex  '
ExecStart=/bin/bash -lc '/usr/local/bin/BorgBackup.rex  '

Eine Auflistung der Systemd-Unit-Pfade mit Beschreibung: https://www.freedesktop.org/so…Unit%20File%20Load%20Path

Durch diese Tabelle war ich der Meinung, dass es reicht, wenn meine eigenen Systemd-Units in dem Pfad /usr/local/lib/systemd/system liegen. Dem ist aber scheinbar nicht so. Ich hatte zudem vorher in meinen Timer-Units im [Unit] Abschnitt noch Fehler, die zwar dem systemd-analyze verify standhielten, aber die AKtivierung verhinderten.

Und hier ist jetzt als Beispiel eine Timer- und die zugehörige Service-Unit für den Backup mit BORG:

[Unit]
Description=BorgBackup --timer
After=network.target network-online.target local-fs.target remote-fs.target
Wants=network-online.target  

[Timer]
OnCalendar=Mon,Wed,Fri *-*-* 07:00:00
Persistent=true     
Unit=BorgBackup.service

[Install]
WantedBy=multi-user.target

[Unit]
Description=BorgBackup --service
#
# Sicherungen mit Borg 
# erstellt werden 3 Archive (igel01-system-.. igel01-home-.. und igel01-server-.. im BorgRepo auf externer USB-Platte
# Die Beschreibung des Scriptes ist im Scriptheader vorhanden
#
Documentation=man:borg 
After=network.target network-online.target local-fs.target remote-fs.target
Wants=network-online.target

[Service]
Type=oneshot
NotifyAccess=all 
ExecCondition=-/bin/rm /var/log/BorgBackup.log
Environment="SHELL=/bin/bash" "PATH=/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/sbin:/bin:/usr/lib/news/bin"
User=root
Group=root 
WorkingDirectory=~
StandardOutput=file:/var/log/BorgBackup.log 
StandardError=inherit
ExecStart=/bin/bash -lc '/usr/local/bin/BorgBackup.rex  '

Eine Beschreibung der einzelnen Parameter gibt es ja per man systemd.service bzw. man systemd.timer.

Mittlerweile hab ich den "Fehler" gefunden, weshalb meine Systemd-Units nach einem Neustart nicht gestartet wurden.

Obwohl /usr/local/lib/systemd/system in der Suchreihenfolge der Pfade auftritt, verweigert systemd den Start der Timer-Units.

igel01:~ # systemd-analyze unit-paths
/etc/systemd/system.control
/run/systemd/system.control
/run/systemd/transient
/run/systemd/generator.early
/etc/systemd/system
/etc/systemd/system.attached
/run/systemd/system
/run/systemd/system.attached
/run/systemd/generator
/usr/local/lib/systemd/system
/usr/lib/systemd/system
/lib/systemd/system
/run/systemd/generator.late
igel01:~ # 

Die Timer-Units hatte ich schon nach /etc/systemd/system kopiert und trotzdem bekam ich beim Booten eine Fehlermeldung:

igel01:~ # journalctl -u BackupFS.timer
-- Reboot --
Sep 12 09:33:06 igel01 systemd[1]: BackupFS.timer: Refusing to start, unit BackupFS.service to trigger not loaded.
Sep 12 09:33:06 igel01 systemd[1]: Failed to start BackupFS --timer.

Ich hatte bei der Recherche im Netz nach dieser Fehlermeldung einen Eintrag gefunden, dass jemand auch dieses Problem, Timer- und Service-Units in /usr/local/lib/systemd/system abgelegt, hatte. Sein Problem löste sich, nachdem er diese Files nach /etc/systemd/system kopiert hatte.

Es müssen demnach Timer- und zugehörige Service-Unit zusammen in /etc/systemd/system abgelegt sein.

Ich habe jetzt auch die Service-Units nach /etc/systemd/system kopiert und jetzt funktioniert es. Habe aber aus Backupgründen die Unit-Files zusätzlich in /usr/local/lib/systemd/system belassen.

Ich hab in Youtube den Channel tutorialLinux gefunden.

Hier gibt es eine Playlist mit 5 Videos zum Thema systemd: https://www.youtube.com/playli…QaMKPbuVpGuqUQYRiTwTAmqeI

tutorialLinux benutzt eine wohl eine Distri namens minibuntu. Hier sind die Pfade für systemd anders als unter openSUSE, ansonsten ist die Playlist ein guter Einstieg in systemd.