Beiträge von Igel1954

    Das Überschreiben der Codecs aus dem Packman-Repo geschieht wohl nur beim Einspielen der Patches.


    1. zypper --gpg-auto-import-keys --non-interactive ref 
      geht hier etwas schief, schläft das Script für 1800 Sekunden. Nach dem 5. vergeblichen Refreshes wird das Script abgebrochen
    2. zypper -vvv pchk --with-optional
      gibt es Patches bekomme ich von Zypper den Exitcode 100 oder 101 gemeldet.
      und mit zypper -vvv patch -y -l --with-optional --with-interactive --with-updates werden die Patches installiert.
      Hier werden dann leider die Packman-Pakete mit denen aus dem OSS-Repo überschrieben.

      Die Patch-Anweisung von Zypper ist aber die einzige Möglichkei, den Returncode 102 zu bekommen, um am Ende der Verarbeitung einen automatischen Neustart des Systems zu veranlassen.
    3. Bei RC=0 liegen keine Patches vor und mit zypper -vvv up -y -l --details --with-interactive, update ich die geänderten Pakete aus dem Packman- Printing- und Mozilla-Repo.
      Hier bleiben die Packman-Codecs unangetastet.

    Habe eben mit den entsprechenden Dry-Run-Versuchen herausgefunden, dass nur beim Einspielen der Patches die Packman-Pakete überschrieben werden.


    Ich finde bisher nur keine Möglichkeit, das Überschreiben der Codecs mit den "falschen" Paketen beim Einspielen der Patches zu verhindern.

    Ich habe seit dem Upgrade auf LEAP 15.4 immer das Problem, dass beim Einspielen von Patches und/oder Updates die Codecs immer mit den Paketen aus den OSS-Repositories ersetzt werden, obwohl ich das Packman-Repo mit 20 priorisiert habe.


    Da ich meine Updates ja automatisiert durchführe, stelle ich dass dann immer erst an den dann nicht mehr funktionierenden Videos im Fratzenbuch bzw. Instagram fest. Komischerweise funktionieren die Youtube-Videos immer.


    Repariert bekomme ich das natürlich immer mit zypper dup --allow-vendor-change --from Packman. Das ist aber auf Dauer nervig. :smilie_pc_057:


    Hat noch jemand das Problem und evtl. einen Tipp, wie sich das Problem abstellen oder umgehen läßt?

    JRK

    Wenn du die Bilder beim Umwandeln verkleinern willst:

    Code
    for i in *.JPG; do echo $i; gm convert "$i" -resize 30% "${i%%.JPG}.pdf"|; done

    Der Befehl erwischt aber nur Files deren File-Extension in Großbuchstaben vorhanden sind.


    Ich verkleinere regelmäßig die Fotos von den Fahrzeugen, die überführe, um sie an meinen Disponenten (gepackt als ZIP) per E-Mail zu verschicken. Ich wandel sie dabei aber nicht in ein anderes Format um:


    Code
     for a in *.jpg; do gm mogrify -resize 30% "$a"; done

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