Beiträge von Chartwalker

Es sind alle Pakete auf dem Level des 18.4.2021 - bis auf arpack-ng-devel - das lässt sich einfach nicht installieren.

Das Deinstallieren, um wieder ein konsistentes System zu erhalten, entfernte armadillo-devel 2x und o2scl-devel - ok kein Verlust.

.. dann aber kam das erhoffte "Nothing to do"

Ich habe gerade mal die verbliebenen Kernel im Grub2 durchprobiert.

- der neue kernel-*15.1 Kernel vom Stand 18.4.21 lief nicht.

- der kernel-*12-1-default, vom Stand 14.4.21 geht, aber nicht mit dem favorisierten graphischen Login, was beim Versuch es zu nutzen aus der Auswahl verschwand und der Kde-Update Link zum Nachladen von alternativen graphischen Logins funktionierte nicht.

- der Vorgängerkernel lief nicht mit X

Das wäre schon mal ein workaround, ABER dazu müsste ich den 12-1 Kernel permanent machen und da kenne ich mich nicht gut genug aus.

Nach dem dup vom 18.3.2021 hat es bei mir die graphische Benutzeranmeldung und vermutlich auch den X-Server zerschossen, da sich die Auflösung danach nicht mehr auf 1920px einstellen lässt.

Google fand zu diesem Problem im engl. Forum von Opensuse daß ein zypper package lock auf die kernel-defaults anzulegen sei und dann erst das dup auszuführen, also so was...

zypper al kernel-def*

zypper dup

Desweiteren wurde sddm für die Probleme verantwortlich gemacht und man solle den kdm statt den sddm verwenden.

Das package lock hat aber nun mal - wenn es grundsätzlich zielführend wäre - nach dem festgestellten dup Fehler keinen wirklichen Sinn mehr, also wurde es wieder entfernt.

zypper rl kernel-def*

Zunächst wurde untersucht ob Xorg.bin mit suid läuft - tat es nicht, sollte es aber

ll /usr/bin/Xorg.bin

chmod u+s /usr/bin/Xorg.bin

der default-windowanager ist ein Symlink nach /etc/alternatives und dieser zeigt von dort wieder nach /usr/lib/X11/displaymanagers, vermutlich um das /usr-Filesystem readonly exportieren zu können. kdm fehlt aber dort auf meinem System. Das ist mir noch garnicht aufgefallen - ging aber bis gestern.

Ich gehe mal davon aus daß ein Rücksetzen auf den Stand vom 14.4.2021 die Problem lösen könnte - die Frage ist nur woher weiß Opensuse was am 14.4.2021 installiert war und wie geht das Rücksetzen ohne das Problem zu verschlimmbessern?

Gekaperter Beitrag eines anderen Users!

Alero

Wichtig:Vor dem Posten bitte erst Lesen!

Resultat nach vielen Stunden "Retrieving.." es geht so nicht - zumindest nicht sauber!

Es erscheint "Checking for file conflicts" und am Ende bekommt man ein inkonsistentes System mit der fatalen Auswahl aus mehreren Paketen Files gleichen Namens mit unterschiedlichem Inhalt überschrieben zu bekommen.

Als SuSE von tgz-Tarballs (force = last tgz wins) zu RPM wechselte und diese Paketinkompatibiläten anfingen einem dem letzten Nerv zu rauben, da hatte ich gesagt:

"RPM ist prinzipiell eine gute Idee, aber diese Idee wurde nicht zu Ende gedacht, da es keinen automatischen Prozeß gibt, der Paketabhänigkeiten ohne Zutun des Nutzers in jedem Fall automatisch auflöst, notfalls an den Punkt zurückkehrt wo es das letzte mal 100% funktioniert hat."

Das KI-Problem dahinter hat damals keiner verstanden, aber ich habe damit Recht behalten - RPM ist halbrussisch solange das Thema nicht streng deterministisch gelöst ist ohne manuellen Pflegeaufwand und das geht nicht ohne interne automatische Prüfung durch den Paketmanager auf der Linker-Ebene welche Datei zu welchen Symbolen oder Hardware Beziehungen in welcher passfähigen Version aufbaut.

Das muss bereits beim Linken für den Paketbau automatisch erfasst werden, denn später geht es nicht mehr aufzudröseln ohne manuellen Eingriff weil die dafür nötige Information nach dem Linken nicht mehr vorhanden ist. Es geht dann irgendwie oder es kracht und genau dann sind wir wieder auf dem Level von tgz.

Das noch schwierigere Unterproblem dazu wäre (bei debian-System massives Problem): Wie kann der Nutzer mit wenigen EIngaben eine für bestimmten Zuschnitt (reiner Server, Desktop, Entwicklerarbeitsplatz usw) eine 100% funktionierende Grundinstallation bekommen, die mindestens die Pakete enthält, die er im vorherigen System bei sich auch manuell nachinstalliert hat (mc, fte, emiclock usw) die aber nicht zwingend einer Kategorie zugeordnet werden können, ebenso wieder ohne Paketkonflikte und wieder alles ohne manuellen Pflegeaufwand.

Nach einer gefühlten Stunde (in der Miitagspause) und bereits der Verzweiflung nahe - kommen die ersten Ausgaben Retrieving ...

Ich lasse es mal weiterlaufen und "cross the finger" hoffe es zerschiest mir nicht die einigermaßen mit Krücken lauffähige 15.1.

Ändert nichts an der Tatsache, daß hier eine generelle und saubere Lösung gebraucht wird, die Abhängigkeiten nach dem "Haufenprinzip" untereinander passfähiger rpm's auflöst und dann eine Plane drüber auf der steht "Alles warm, trocken, sicher und in Ordnung mit der 15.2" - der Rest unter der Plane wird gemacht wenn das nächste Update kommt. Bei "akuter Gefahr" wird die Gefahrstellestelle gefixt (minor update 15.2.1) und wieder eine Plane drüber. So muss das laufen - nicht so arbeiten wie die Bundesregierung, alles blind anfassen und dann nichts sauber fertig kriegen.

Zitat von tux93

Um den Repocache für die neue Version zu bauen

Code

zypper --releasever 15.2 dist-upgrade

Teil 1 funktioniert wunderbar, Respekt!

ABER nach manueller Behebung der Abhängigkeiten und maximal den Benutzer nerven (ist eine ganz üble Linuxkrankheit aus den rpm-Anfangszeiten SuSE6.0++) - es fehlt da die Auswahloption "FUS&Quit"

dann kommt "Note: System reboot required" (bin ich jetzt Engländer?) und dann "agree license bla bla" - sagt er trotz "yes" GARNICHTS mehr, keine Fortschrittsanzeige, keine Fehlermeldung, aber er blockiert heftig die Paketverwaltung und zwar dermaßen, daß man auch mit Yast nicht mehr weiterkommt nur mit kill und pid und - arrrgh

Wieso kann man nicht einfache und nachvollziehbare Lösungen mit Eingabefeld und Fortschrittsanzeige vorsehen und im Yast eine Pfadeinstellung vorsehen, notfalls mit warnender Quittung "Expertenmodus bla bla"? Das ist alles halbrussisch. Schon nach dem ständigen gesudoe hab ich Puls.

Wir alle wissen, die Linux und Windows kennen, daß auch wenn im Innern von Windows die Hölle tobt und nichts wirklich 100% sauber abläuft - der Windowsprogrammierer hütet sich davor den Nutzer zu nerven oder etwa mitzuteilen, daß es ein Problem gibt - eher wird im Hintergrund ein Speicherauszug erstellt und dem Entwickler heimlich ein Bugreport gesendet als das irgendwo ein Fenster aufgeht wo was anderes draufstehlt als "OK" oder "Abbrechen" - aber das ist schon grenzwertig.

Irgendwo zwischen den Linuxfehlerromanen und dem "Schweigen von Windows" (Oscar-verdächtig) liegt das gewollte Optimum.

Zitat von Berichtigung

Lerne ansible.

Kannte ich noch nicht, aber der Kommentar von Schroeffu17. April 2016 um 09:43 lässt ahnen, daß es wieder eine "Einbahnstraße" wird - d.h. um das Cleanup-Paket kommt man bei ansible nach diesem Nutzer nicht drumrum.

Ich dachte da eher so an [url]https://cfengine.com/product/[/url] Community Edition sollte dafür reichen und dann eine Hierarchie von Paketen. Cfengine bringt sed-Unterstützung gleich mit. Erst Mist raus, dann das Gewünschte rein, dann Datei/Verzeichnisrechte und die Systemdienste kontrollieren und so gleichzeitig das System gegen Intruder härten.

Ich sehe gerade die 3.12-er CFE-Version ist bereits portiert - FREU!

Ich sehe gerade der URZ-Kurs ist noch im Netz - link CFE-Kurs

Zitat von Chartwalker

Dabei kam raus, daß die billig gekaufte SD-Karte vermutlich ein Fake ist und das ist immer eine gute Gelegenheit für die Methode "Echtes vom Faker als Betatester" - also Originalaktikel ohne Aufwand der Rücksendung des Fakes exakt zu dem Preis vorher mit H2testw getestet sonst Kripo knock knock und Händleraccount futsch, so bekommt man gut ausgebildete Betatester zum Nulltarif - nimmt man die KP China als Aufsichtsbehörde, dann wirkt das auch in China Wunder. Auserdem hat man dabei einen SD-Adapter übrig, die Lieferzeiten sind halt länger.

Nachtrag: Der Händler hat die Anzahl auf Null gesetzt - jetzt hat er ein Problem korrekte Ware zu liefern ohne Verlust zu machen.

Der Timer lässt wieder mal keine Nachbearbeitung zu :-|

Bis die neuen Karten da sind werde ich mal das Grundsystem abspecken und alles löschen was für die Programmierei eh nicht von Nutzen ist, wobei ich beim Paketbau sed als Handschwein für die Konfigurationsbearbeitung nutzen würde, allen voran bei doxygen. Es muss ja eh vieles noch passend gemacht werden. Also besorge ich mir eine zweite 32GB SD-Sim damit ich die letzte Änderung noch habe und dann Git noch einspannen für die Branches.

Wir brauchen also ein Cleanup-RPM-Paket und schreiben alles uninstall zum Grundpaket rein, was wir nicht in einem Developerminimalsystem haben wollen und das ist dann die Grundkonfiguration für ein 32GB-Optimal-System. Anschließend kann man das dann als ein neues 32GB-Grundsystem definieren und von dort aus in Richtung Maximalsystem weitermachen.

Die Frage wo kriege ich eine tagesaktelle Paketliste des OpenSuse-Grundpaketes her? Diese würde ich mit sed bearbeiten und dann als Ausgangspunkt nehmen.

Es fehlten gegenüber der Pristine-Version IMHO

• mc
• einige verhasste, aber notwendige X-Biliotheksbauwerkzeuge (ua. xlib header xmkmf, autoconf)
• emiclock (never miss a good alarm clock)
• fte (unendlich lange Files mit syntax, tools und guter hex/bin-Statusleiste)
• GTK-Toolchain
• samba modifkation wegen Cygwin, um von Win7 aus das Cygwin-Repository zu updaten (es ist noch etwas krank das über Win7 zu machen - funktioniert aber gut, später muss dann noch eine saubere Lösung her)
• Compilerbauwerkzeuge (bison, flex, awk)
• was vergessen?

Ich habe dd nehmen wollen, um nicht mein Win7System jedes mal runterkrachen zu müssen mit den hundert aktiven Fenstern.

Obwohl im Netz steht, daß man bei dd unter Linux keine Blockgroße angeben braucht, habe ich festgestellt, daß es ohne Angabe langsamer geht - warum auch immer. Jedenfalls meint man bei dd wird der Bootsektor immer sauber kopiert - ich hoffe mal das stimmt so. Also war dann folgendes zu machen.

dd if=/dev/dev/mmcblk0 of=/dev/sda bs=1M

Dabei kam raus, daß die billig gekaufte SD-Karte vermutlich ein Fake ist und das ist immer eine gute Gelegenheit für die Methode "Echtes vom Faker als Betatester" - also Originalaktikel ohne Aufwand der Rücksendung des Fakes exakt zu dem Preis vorher mit H2testw getestet sonst Kripo knock knock und Händleraccount futsch, so bekommt man gut ausgebildete Betatester zum Nulltarif - nimmt man die KP China als Aufsichtsbehörde, dann wirkt das auch in China Wunder. Auserdem hat man dabei einen SD-Adapter übrig, die Lieferzeiten sind halt länger.