Beiträge von Igel1954

    Ich hab die Virtualbox-Pakete gegen Updates gesperrt, so dass mein nächtlicher Update diese Pakete nicht anpackt.

    Wenn Updates für VBox vorliegen, werde diese dann manuell aktualisieren.


    Mit dem Kernel selberbauen, habe ich mich bei SuSE 9 mal beschäftigt, als ich noch OS/2 und Linux parallel instaliert hatte.


    Leider ist die EÜR nur in der Windows-Version von WISO Steuer enthalten, nicht aber in WISO Steuer Web. Und nach Aussage vom Kundenservice wird sich da wohl auch erstmal nix ändern.

    Das funktioniert so auch nicht.


    Nach su -und der Passworteingabe fällt die Bash anschliessend wieder in die User-Umgebung.


    Der alias sollte aber so funktionieren:

    Code
    #alias
    alias update='su -c\'zypper up && flatpak update\''


    man su hilft für Erläuterungen.

    Ja, die Extension hatte ich installiert. Als ich anschließend die virtuelle Maschinen (W10 und GeckoLinux 153) starten wollte, brach der Startvorgang kommentarlos ab - das Fenster der VM verschwand einfach. Im VirtualBox Manager stand danach bei beiden Maschinen nur der Hinweis "abgebrochen" .


    Nach der in #2 beschrieben Aktion konnte ich dann beide Maschinen wieder starten. Das GeckoLinux startet (für mich sichtbar) normal, nur W10 brauchte etwas länger, da liefen irgendwelche M$- und W10-internen Reparaturabläufe. Die Guest-Extensions konnte ich dann endlich auch in beiden VMs aktualisieren. Danach hab ich die W10 Maschine mehrmals heruntergefahren und jedes Mal problemlos neu gestartet.


    Wer weiß, welcher der vielen kleinen grünen Bitfresser mich da ärgern wollte. ;)

    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.

    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. :(

    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.

    - 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: