Beiträge von Suelkun

kurzer Zusatz:

das geschilderte Verhalten ereignet sich nicht nur nach dem Booten. Es ereignet sich auch nach dem Abmelden und dem neu Anmelden.

z.B. Ich melde mich an. Dann kommt die Meldung:, daß eine Legimitierung zum Mounten der Partition /dev/sdb11 notwendig ist. (das ist eine Partition mit dem Attribut noauto in der fstab.) . Spaßeshalber gebe ich das root-Paßwort ein. Danach ist die Partition gemountet., lt. Ausgabe des Befehls mount. Der Mountpoint ist der in der entsprechenden fstab-Zeile genannte.

Wenn ich mich dann abmelde und neu anmelde, kommt die Meldung, daß eine Legimitierung zum Mounten von /dev/sda3 notwendig ist. (Das ist eine Partition, die gar nicht in der fstab steht und die die Daten zum Pfad /var einer anderen Installation enthält). Wenn ich das root-Paßwort eingebe, wird /dev/sda3 nach /run/media/<Benutzername>/... gemounted. /dev/sdb11 ist nach wie vor gemounted..

Melde ich mich nochmal ab und wieder an, dannkommt die Meldung, daß eine Legimitierung zum Mounten von /dev/sdb3 notwendig ist. (Das ist eine Partition, die gar nicht in der fstab steht und die die Daten zum Pfad /var einer anderen weiteren Installation enthält). Wenn ich das root-Paßwort eingebe, wird /dev/sdb3 nach /run/media/<Benutzername>/... gemounted.

/dev/sdb11, /dev/sda3 sind nach wie vor gemounted.

Für mich sieht es schon wie ein Fehler im System aus, der mit einem der letzten Updates reingekommen ist.

Hallo,

ich habe vor einigen Wochen openSUSE 15.3 auf meinem Rechner eingerichtet. Es war ein update von 15.2. auf 15.3. Das upgrade verlief fehlerfrei und ich benutze 15.3 seither ohne Probleme.

Auf dem Rechner habe ich mehrere Installationen von openSUSE, die aber säuberlich voneinander getrennt sind. D.h. ich kann eine Installation anbooten und Änderungen daran vornehmen, ohne daß eine andere Installation davon tangiert ist. Das ist dadurch realisiert, daß die fstab einer Installation andere Partitionen anzieht als die fstab einer anderen Installation.

Seit ein paar Tagen habe ich nun ein kleines Problem.

Nach dem Booten von 15.3 und nach Anmelden kommt ein Fenster hoch, verursacht vom policity-KDE-Agent, mit dem mir dieser mitteilt, daß die Legimitierung zum Einhängen einer Partition notwendig sei. Einer Partition, die zwar vorhanden, aber in fstab nicht genannt ist.

Verursacher dieser Meldung ist der udiskd-Daemon. (Ermittelt über die pid, die in den Details der Meldung genannt wird).

Ich kann diese Meldung ohne Paßworteingabe weggklicken, das System läuft dann schon, genauso, wie es läuft,wenn ich das root-Paßwort eingebe.

Ich wüßte jetzt gerne, in welcher Einrichtungsdatei ich da nachschauen kann. Hat mir jemand einen Hinweis?

Lieber Heinz-Peter,

vielen Dank für Deinen Beitrag. Ich habe es inzwischen anders gelöst:

Ich habe das nicht funktionierende System angebootet, Blieb natürlich mit der og. Fehlermeldung hängen.

Aber: man kann mit Eingabe von "E" den fehlerhaften Eintrag editieren. Das habe ich getan und den Eintrag linuxefi ersetzt durch linux und den Eintrag initrdefi ersetzt durch initrd.

Mit diesen Änderungen kam das System hoch.

Danach habe ich mir mit Yast den Bootloader-Eintrag angeschaut. Dabei habe ich festgestellt, daß ich in der Auswahlbox zwar "GRUB2 FÜR EFI" eingestellt hatte, aber die Checkbox "secure Boot Unterstützung" nicht gecheckt habe.

Das habe ich korrigiert und damit kommt das System ohne Handeingriff hoch.

Hallo,

ich habe auf meinem Desktop-Rechner 2 unterschiedliche, voneinander unabhängige Installationen von openSUSE. Bis vor ein paar Tagen waren das Installationen von openSUSE 15.2. Ich konnte wahlweise das eine System starten oder das andere.

Seit ca. 1/2 Woche habe ich nun die CD von SUSE 15.3 und habe mich nun daran gemacht, die beiden Systeme auf 15.3 umzustellen. Bei dem ersten dieser beiden Systeme funktionierte diese Umstellung einwandfrei (ich schreibe diese Meldung unter 15.3).

Nachdem die erste Installation störungsfrei ablief, habe ich mich auch daran gemacht, die zweite Installation auf 15.3 umzustellen. Das upgrade selbst lief fehlerfrei durch. Als es aber an das Starten ging, bekam ich eine Fehlermeldung und ich komme gegenwärtig nicht weiter.

Grub meldet sich beim Starten mit folgenden Meldungen:

loading linux 5.3.18-59.5-default

error: ../../grub-core/script/function.c: 119: can't find command 'linuxefi'

can't find command 'initrdefi'

press any key to continue.

Wenn ich dann eine Taste betätige, dann kommt die Meldung wieder. Es geht also nicht weiter.

Probiert habe ich zuerst, das laufende System dazu zu überreden, daß es wahlweise beide Systeme anstarten kann. Dies, indem ich per Yast für den Bootloader die Checkbox "Fremdes OS testen" markiert habe. Dies in der Hoffung, daß ich das zweite System damit Starten und dann bei laufendem zweiten System reparieren kann. Das Markieren der betreffenden Checkbox war leider ohne Auswirkung.

Ich habe im Internet nach diesem Fehler gesucht und gefunden, daß (manchmal) in der Datei /etc/default/grub der Eintrag GRUB_USE_LINUXEFI="true" fehlen würde. Das ist bei mir nicht der Fall. Der betreffende Eintrag ist da.

Ich könnte natürlich das ganze System neu aufsetzen, möchte das aber erst einmal nicht tun, weil das wirklich viel Aufwand wäre.

Hat jemand eine Idee, wie ich weiterkommen kann?

Stimmt.

Habe inzwischen auch mein Startscript so erweitert, daß das System bei Start nachschaut, ob die Datei

/lib/modules/<aktueller Kernel>-default/kernel/drivers/gpu/drm/radeon/radeon.ko

wirklich da ist. Wenn nicht, dann werden die alten, noch vorhandenen Kernel nach der Datei durchsucht, die oben geschilderten 4 Befehle ausgeführt und daraufhin der Rechner gleich neu gestartet.

Mal sehen, ob die Mimik mal zuschlagen muß.

Ich habe das Problem jetzt kurzzeitig so gelöst:

Zitat von Hidalgo

Da ich von einem Freund einen Laptop zur Verfügung gestellt bekommen habe

konnte ich von diesem via ssh auf den Linux-Rechner mit dem 60er Kernel zugreifen

und diesen dazu veranlassen, die Grafiktreiber für meine AMD-Karte korrekt

zu laden, mit folgenden Schritten als SuperUser (su):

Einen extra Laptop habe ich auch, aber mir war kurzfristig nicht (mehr) geläufig, wie ich in dem 60-iger System den Port 22 öffnen kann.

Zur Ausführung der ersten beiden Befehle der zitierten Lösung muß das 60-iger System ja nicht laufen. Es muß nur da sein. Also habe ich unter dem 57-iger System die Befehle

mkdir /lib/modules/5.3.18-lp152.60-default/extra
cp /lib/modules/5.3.18-lp152.57-default/kernel/drivers/gpu/drm/radeon/radeon.ko /lib/modules/5.3.18-lp152.60-default/extra/

eingegeben.

In mein Skript, welches die Start Tonfolge ausgibt, habe ich die Befehle

depmod 5.3.18-lp152.60-default
mkinitrd

eingebaut und darauf das 60-iger System gestartet und wieder beendet (mit dem Aus-Knopf halt). Danach habe ich das 60-iger System erneut neu gestartet. Die Grafik kam hoch, ich habe mein Skript mit dem Start Ton wieder in den Orginalzustand zurück versetzt und das wars. Ich schreibe diese Antwort unter dem 60-iger System.

Vielen Dank für die Hilfe.

Es tut mir leid, aber ich muß das Thema wiederbeleben.

Ich habe bis heute Nachmittag zuletzt den Kernel 5.3.18-lp152.57-default benutzt.

Heute nachmittag kam über die automatische Aktualisierung die neue Version 5.3.18-lp152.60-default.

Ich nicke die Installation ab, auch den erforderlichen Neustart und: meine og. 08/15 Grafikkarte läuft nicht mehr. Erscheinungsbild wie zuvor:

Rechner läuft hoch (mein Sicherungs-systemd- Dienst meldet über einen Start-sound, daß er gestartet wurde), splash screen fehlt, keinerlei optische Anzeige. Wenn ich ein paarmal kurz den Ausknopf drücke, dann fährt der Rechner runter, macht die Datensicherung (die HDD-Led flackert entsprechend) und zum Schluß kommt der Stop Sound meines Sicherungs-Dienstes.

Für mich sieht es so als, als wäre der im vergangenen Oktober beseitigte Fehler wieder eingebaut worden.

An der Hardware wurden keinerlei Änderungen vorgenommen.

An Systemänderungen habe ich vor 4 Monaten nur eingebaut, daß ich 3 Kernelversionen behalten will. Ich schreibe diese Meldung nun unter dem Kernel 5.3.18-lp152.57-default, denich problemlos anstarten kann.

Zitat von Trekkie00

Installiere dir virt-manager. Das funktioniert tadellos und zieht nicht viele Abhängigkeiten mit. Ich glaube nicht, dass du viele Leute findest, die gnome-boxes nutzen.

gut, probiere ich aus. Könnte aber sein, daß es jetzt mehr wird mit Fragen zu gnome-boxes., nachdem die c't in ihrer jüngsten Ausgabe gnome-boxes für diesen Einsatz währmstens empfiehlt.

Hallo und ein gutes neues Jahr an alle.

Ich habe vor ein paar Tagen gelesen, daß Linux in der Regel die nötigen Bordmittel für Virtualisierung mitbringt.

Nachdem ich virtualle Maschinen (auf der Basis VMWare) nutze, habe ich beschlossen auszuprobieren, ob ich auch eine virtuelle Maschine mit den Bordmitteln von openSuse aufbauen kann und wie sich diese virtuelle Maschine dann gegenüber VMWare schlägt.

Ich nutze Leap 15.2. Meine Hardware unterstützt Virtualisierung, lt. Ausgabe des Befehls

ls -al /dev/kvm

Ich habe ebenfalls beschlossen, eine neue virtuelle Windows10x64-Maschine auf der Basis des entsprechenden ISO-Abbilds zu erstellen.

Wenn ich nun gnome-boxes starte, dort eingebe, daß ich eine neue virtuelle Maschine aus dem Abbild des entsprechenden Systems erstellen will, im aufpoppenden FileDialog zum ISO-Image von Windows10x64 navigiere und darauf klicke, dann stürzt gnome-boxes ab.

Ich habe darauf gnome-boxes nochmals vom Terminal aus gestartet, um genauer zu ermitteln, was da falsch läuft. Das Ergebnis:

Mozart:~> G_MESSAGES_DEBUG=all gnome-boxes
...

(gnome-boxes:4612): dconf-DEBUG: 17:59:41.150: change_fast
(gnome-boxes:4612): dconf-DEBUG: 17:59:41.150: change_notify: /org/gtk/settings/file-chooser/
(gnome-boxes:4612): Boxes-DEBUG: 17:59:41.290: unattended-installer.vala:694: matched de_DE
(gnome-boxes:4612): dconf-DEBUG: 17:59:41.290: watch_fast: "/org/gnome/desktop/input-sources/" (establishing: 0, active: 0)


(gnome-boxes:4612): GLib-CRITICAL **: 17:59:41.291: g_variant_get_child_value: assertion 'index_ < g_variant_n_children (value)' failed
Speicherzugriffsfehler (Speicherabzug geschrieben)

Ich bin (u.a.) Mitglied der Gruppe kvm und libvirt.

Hat jemand Erfahrung mit gnome-boxes und kann sagen, wie man da weiterkommt?

Wie gesagt: Es geht mir erst einmal um einen Versuch.

Nein, direkt ein akonadictl stop vor dem Abbruch der Prozesse hatte ich nicht eingegeben.

Die Mail RFC's sind mir natürlich unbekannt. Normalerweise sende ich keine Mails ohne Betreff und Body. Wenn es aber klemmt und ich nach einer Änderung ausprobieren will, ob es immer noch klemmt, dann sende ich schon mal eine Mail ohne Body, dann halt an mich selbst. RFC hin oder her.

Was benutzt du für ein Mailsystem? Ich klebe nicht an KMail, Allerdings sollte die Migration der Kontakte halbwegs problemlos möglich sein.