Beiträge von Suelkun

Ich habe gerade eine neue Version von pysvn (1.7.6-3.4.1) über die automatische Aktualisierung von 12.2 erhalten, die den von mir beschriebenen Fehler nicht mehr aufweist.

gerne,

hier sind die entsprechenden Outputs.

Es geht auch nicht um die Installation selbst (die funktioniert bei mir auch), sondern darum, daß ich bei dem python-Befehl "import pysvn" einen Fehler bekomme. Diesen Befehl muß ich aber benutzen, wenn ich pysvn nutzen will.

Na, ja:

Ich hätte ganz naiv erwartet, daß ich mit 12.2 eine in sich stimmige Installation bekomme.

pysvn kommt von Suse 12.2, python kommt von Suse 12.2, Qt kommt von Suse 12.2, alles ständig aktualisiert.
Nur halt mit dem Nachteil, daß ich das ausgelieferte pysvn gar nicht nutzen kann. Die angemeckerte Bibliothek kommt übrigens nicht von digia (d.h.Qt), sondern von tigris.org.

Dort wird die pysvn 1.7.6 -Version als passend zu python 2.7 beschrieben. Eine ältere Version gibts nur für python 2.5 und ich habe beides: python 2.7 und pysvn 1.7.6.
Es gibt bei tigris.org auch keine Paket für Suse, sondern nur eines für andere Distributionen, d.h. ich stehe vor dem ggf. zweifelhaften Weg der Neugenerierung von pysvn aus den Quellen: Dies mit ungewissem Ausgang.

Ausgehend davon ist die Frage dann doch erlaubt, ob jemand im Forum dieses Problem schon mal hatte und ob es ggf. viel einfachere Wege gibt, als den der Neugenerierung von pysvn aus den Quellen.

Ganz so trivial, wie von Dir dargestellt, ist mein Anliegen nicht.

Hallo,

ich benutze SUSE 12.2.

Im Zusammenhang mit der Entwicklung eines Softwarepakets setze ich Python ein und benötige dazu das Paket pysvn.

Ich benutze Python 2.7 und pysvn 1.7.6-3.1.2.

Wenn ich unter python den Befehl eingebe: import pysvn, dann erhalte ich die Meldung:

File "/usr/lib/qt4/lib/python2.7/site-packages/pysvn/__init__.py", line 109, in <module>
raise ImportError( 'pysvn was built against newer (svn, apr, etc.) libraries then the ones installed on this system. %s' % str(e) )
ImportError: pysvn was built against newer (svn, apr, etc.) libraries then the ones installed on this system. /usr/lib/qt4/lib/python2.7/site-packages/pysvn/_pysvn_2_7.so: undefined symbol: svn_sort_compare_items_as_paths

Ich wüßte nichts, was ich hier tun kann, damit die Meldung nicht kommt. Update bringt keine Änderung. Die Meldung kommt auch, wenn ich Python 3 benutze.

hat jemand eine Idee?

Erst mal vielen Dank, genau diese Informationen habe ich gebraucht.

Kurzer Zwischenstand: Ich boote mit grub, d.h. es gibt da eine menu.lst. Dort war es natürlich einfach, dem Kernel beim Starten weitere Parameter mitzugeben. Der Parameter init=/sbin/sysvinit hat dann sofort dazu geführt, daß mein script /etc/init.d/halt.local beim shutdown sauber ausgeführt wurde.

Nebeneffekt: Ich hatte als halt sound "Octave" angegeben. Hat unter systemd auch nicht getan. Tut jetzt auch (der sound wird in /etc/init.d/halt erzeugt).

Ich werde mein Problem aber wirklich über systemd lösen und dazu muß ich halt ein wenig lesen. Mein Thread ist hiermit aber gelöst.

Hallo,

ich bin seit einiger Zeit von SuSE 11.3 auf SuŚE 12.2 gewechselt. Das Betriebssystem SuSE 12.2 habe ich neu installiert (also kein Upgrade).

Ich hatte in 11.3 sowohl eigene start- wie halt-scripte, die in den Dateien /etc/init.d/boot.local und /etc/init.d/halt.local hinterlegt waren. Diese scripte habe ich in das 12.2 -System mit übernommen (d.h. eben nach /etc/init.d/ kopiert, Berechtigungen stimmen).

Bei der Installation von 12.2 habe ich (möglicherweise fehlerhaft) die Einstellung "Konfiguration automatisch erstellen" so belassen.

Nun sieht es so aus, daß /etc/init.d/boot.local richtig ausgeführt wird, aber /etc/init.d/halt.local wird nicht ausgeführt.
Das System führt beim Herunterfahren auch die Datei /etc/init.d/halt nicht aus (habe dort testhalber mal ein echo Kommando eingebaut, welches eine Datei mit mir bekanntem Inhalt erstellt. Diese Datei wurde nicht erstellt). Nachdem /etc/init.d/halt das Script /etc/init.d/halt.local aufruft, ist dann klar, daß auch letzteres Script nicht ausgeführt wird, weil eben /etc/init.d/halt nicht ausgeführt wird.

Ich vermute, daß dieses Verhalten damit zusammenhängt, daß ich mit systemd boote und halte. Meine Frage:
a) Kann ich das System (per Yast) umstellen von systemd auf initd? (einen entsprechenden Eintrag kann ich in Yast nicht finden) und /oder
b) Gibt es eine Möglichkeit, systemd ein Script zu übergeben, welches bei halt dann ausgeführt wird?

Vielleicht hat ja jemand eine Idee. Ich jedenfalls komme momentan nicht weiter.

Das Problem ist gelöst.

Es gab 2 Ursachen:
1. Habe ich eine Partition auf den Mount-Punkt /usr gemounted (das war keine so gute Idee)
2. Habe ich die Root Partition per cp kopiert (also alles, was da drin war).

1. hat dazu geführt, daß SUSE die Partition auch in der Initrd anzieht und
2. hat dazu geführt daß dann eine nicht passende initrd mit kopiert wurde und
3. Was mit der inird dann gemounted war, das überschreibt Einträge der fstab.

Maßnahmen:
a) rescue-System booten
b) mount Zielpartition1(/) nach /mnt
c) mount Zielparttition2(/usr) nach /mnt/usr
d) mount --bind /dev/ /mnt/dev
e) chroot /mnt
f) mount /proc
g) mount /sys
h) mkinitrd -B

damit wurde die richtige initrd erzeugt

Hallo Forum,

ich habe ein PC-System mit 3 Platten. Auf jeder dieser Platten befindet sich ein System SUSE 12.2.

Ich habe auf Platte /dev/sda GRUB als bootloader im MBR eingerichtet und wähle über (dev/sda5) /boot/grub/menu.lst eines von 6 verschiedenen Varianten zum Starten aus. Das funktioniert auch, bis auf das ug. Problem.

Die 2. Platte /dev/sdb) ist eine SSD-Platte, die ich eingerichtet habe, um schneller zu booten, die 3. Platte (dev/sdc) ist wieder eine normale Terabyteplatte.

Das System auf /dev/sda mounted (per /etc/fstab) die Partitionen sda5 als /, sda6 als /var, sda7 als /usr, sda8 als /opt.
Das System auf /dev/sdb soll mounten (ebenfalls per /etc/fstab) die Partitionen sdb5 als /, sdb6 als /var, sdb7 als /usr und /sdb8 als /opt.
System auf sdc ähnlich.

Wenn ich nun das System auf sdb oder sdc starte, dann sind alle Partitionen richtig gemountet (also so wie ich es will) mit Ausnahme von /dev/sdb7 (bzw. /dev/sdc7). Für /usr ist statt dessen immer /dev/sda7 gemounted, ohne daß ich einen Grund erkennen kann. Das ist natürlich dumm, weil gerade beim Start eine Menge von /usr gelesen wird und ich gerne dafür die SSD-Platte benutzen würde.

Beim Prüfen der jeweiligen fstab scheint mir alles ok.

Ich habe die jeweiligen Systeme hergestellt, indem ich zuerst SUSE 12.2 auf sda installiert habe und dann die jeweiligen Partitionen (also z.B. dev/sda5 auf /dev/sdb5 ) auf die anderen Partitionen kopiert habe (per cp -dpR).

Im Anhang unten die jeweiligen fstab (für 2 dieser Betriebssyteme 1. sda und 2. sdb)

Fazit: mir gehen jetzt langsam die Ideen aus. Das Startup-log enthält keinen Hinweis, das Systemlog nicht.

Hat jemand einen Hinweis?

Hallo,

ich benutze seit einiger Zeit Suse 12.2.

In mein System waren 2 Festplatten eingebaut, denen ich via device.map entsprechende Namen zugewiesen hatte. Die alte device.map im Anhang. Auf hd0 liegt dabei der Bootloader im MBR, Device.map liegt auf hd0 unter /boot/grub, menu.lst ebenfalls. Auf hd0 liegt ein Betriebssystem und auf hd1 auch. Beide konnte ich wahlweise anbooten.

Gestern habe ich mir eine neue (zus) Platte zugelegt, auf die ich das Betriebssystem (/,/var,/usr,/opt,swap) kopiert habe. die neue Platte habe ich ebenfalls per device.map bekannt gemacht. Neuinstallation des bootloaders nach Änderung device.map fand nicht statt. Auch die neue Platte enthält nun ein Betriebssystem. Ich wollte auch (zumindest temporär) alle 3 Platten wahlweise anbooten können, deshalb habe ich auch entsprechende Einträge in (hd0)/boot/menu.lst eingepflegt. Also Sollkonfiguration:
(hd0) = alte Platte mit Bootloader, device.map und menu.lst + 12.2
(hd1) = neue Platte mit 12.2
(hd2) = alte Platte mit 11.3

Das Problem: Ich konnte jetzt weder (hd1) noch (hd2) anbooten. Grub meldet Fehler 15, File not found, bei beiden. Neue device.map auch im Anhang.

Habe mir via Grub angeschaut, welche Dateien er auf (hd1) sieht und siehe da: Dies ist meine alte Platte (hd1), die jetzt eigentlich (hd2) sein sollte.

Nachdem ich die Bezeichnug in device.map und menu.lst umgedreht habe (d.h. jetzt:
hd0) = alte Platte mit Bootloader, device.map und menu.lst + 12.2
(hd2) = neue Platte mit 12.2
(hd1) = alte Platte mit 11.3
kann ich alles wieder anbooten. (device.map ebenfalls im Anghang) D.h. Grub scheint meine Angaben betreffs device.map komplett zu ignorieren. Wo ist mein Denkfehler?

Also:
Auch ich verstehe unter einem Makefile eine Textdatei, die meistens dazu benutzt wird, ein Anwenderprogramm aus mehreren Teilen zu kompilieren und zu linken.

Im konkreten Fall habe ich aber eine solche Textdatei dazu benutzt, um Photos aus einer Sammlung von Einzelphotos in eine tar.gz-Datei reinzuschieben. Die Einzelphotos liegen auf einem Laufwerk und die Tar-Datei auf einem anderen.

Das Makefile sollte die Sicherung meiner Photos beim Herunterfahren des Rechners (möglicherweise) etwas beschleunigen. Momentan geht mir das etwas zu langsam.

Das Makefile hat nichts mit dem Crash zu tun, außer daß es den Rechner ziemlich belastet: Unter 11.3 läuft dieses Makefile nämlich anstandslos durch und sichert mir meine Photos.

Auch ich verstehe unter einem Kernel crash genau das: Es geht gar nichts mehr. Der Kernel gibt noch ein paar Meldungen von sich und verabschiedet sich. Ich kann die Meldungen auf dem Bildschirm noch lesen, Maus + Tastatur tot, X11 tot, die Meldungen stehen noch auf dem Bildschirm und die kann ich noch anschauen. Mehr nicht. Wenn ich den Rechner wieder benutzen will, dann muß ich auf den Power-Knopf drücken. Wenn ich sage "Crash", dann glaubt mir bitte: Ich weiß, was ein Crash ist.

Und nein: Ich habe kein Modul auf die Blacklist gesetzt. Ich weiß, wo diese liegt und habe auch vor, später ein Modul auf die Blacklist zu setzen, damit ich meine Garmin-Laufuhr ansprechen kann. Aber so weit bin ich noch nicht.

Das Upgrade habe ich so durchgeführt, daß ich von der CD gebootet habe, im Menu ausgewählt habe, daß ich eine 32-Bit-Version herstellen will und daß die Installationssprache Deutsch sein soll. Dann habe ich die option upgrade einer bestehenden Installation ausgeführt.

Ich hatte auf dem Rechner die Version 11.3 und 12.1 (jeweils getrennte Partitionen für /,/var,/usr,/opt, swap) habe dann die 12.1-Version für den upgrade ausgewählt und das upgrade dann laufen lassen.

Gebootet werden beide Systeme (11.3 und 12.2) über den Grub der 12.2-er-Version.

Ich kann mit dem 12.2-er System auch ein bißchen arbeiten (die Meldung eben schreibe ich unter 12.2), aber einen System-Crash hatte ich bestimmt seit 10-15 Jahren nicht mehr und dann wundere ich mich schon. Und ich habe mich noch mehr gewundert, als ich den Crash wiederholen konnte.