openSuse42.3: ( x of X ) A start job is running for ...

Hallo,

eben noch die Virtualisierung empfohlen, nun hab ich selbst ein Problem damit, evtl liegt es auch an Linux selbst.

Beim Booten eines meiner virtuellen openSuse Systeme häng ich jetzt häufig bei ' .. running for Load Apparmor'. Es können aber auch für 'X' 4,5, oder 9 Jobs betroffen sein. Problematisch ist weiterhin, dass der Host (OSX) so derart davon beeinträchtigt ist, dass dieser auch unbedienbar wird.
Für das betroffene Linux selbst hab ich noch keine Möglichkeit gefunden eine Console zu bekommen um mich überhaupt aufzuschalten und etwas beeinflussen/ansehen zu können. Einzigste Möglichkeit ist, einen Shutdown zu triggern, der nicht funktioniert (via VirtualBox), und dann per Aktivitätsanzeige die VirtualBox-Prozesse hart abzuschießen.

Ich kann die virtuelle Disk über ein weiteres Linux einhängen und darauf ein fsck (btrfs) durchführen, was erst mal keine Fehler auflistet. (Screenshot/Ausgabe davon ist problematisch)

Es gibt hier 3 Threads zu dem Thema und einen Verweis nach linux-club, die mich nicht weitergebracht haben.
z.B. lsblk -o NAME,TYPE,TRAN,FSTYPE,SIZE,LABEL,MOUNTPOINT,UUID,PARTUUID /dev/sda
liefert eine ansehnliche Darstellung aber keine Fehler- oder ähnliche Meldungz.B. cat /proc/cmdlinedürfte nicht helfen, weil ich ja das andere Linux dann gebootet und die Disk gemountet habebei der Eingabe von F<1,2,3..> wird der komplette log nochmals geflusht, teilweise erscheinen Meldungen der Art[ xxx.xxx] ata1.00 ... CMD READ ..teilweise auch: ... exception Emask .. frozenund Meldungen die auf btrfs Fehler hindeuten. ( wie geschrieben ein 'btrfs check /dev/sda2' unter der anderen Installation liefert 'keine Fehler')So richtig einen Screenshot kann ich nicht anfertigen, weil der Host dann auch 'steht'/nicht reagiert ... deswegen sind die Meldungen etwas aus dem Gedächtnis wiedergegeben.Hab ich eine Chance das noch gerettet zu bekommen?Wie vorgehen?Grüße,

scheint nicht so einfach zu sein:
ich habe in die Zeile mit splash=silent ... showopts die '3' hinten angefügt, .... hat den Bootvorgang erst mal nicht beeindruckt.

Beim letzten der angefügten Bilder sind die Meldungen sichtbar die sukzessive 'reinspucken'

Danke,
zum Teil ähnliche Beiträge bzgl Hardware hatte ich im Vorfeld auch schon entdeckt.

nur:
das Ganze läut auf einer Samsung Evo Pro und die ist noch nicht so alt.
mein Host (OSX) liegt auf/bootet von dieser Platte (läuft stabil)
.. die anderen VMs sind auch nur als 'File' auf dieser Platte und laufen problemlos unter VirtualBox. Nur diese eine Installation macht jetzt Probleme. Vor kurzem hatte ich noch einen 'zypper patch' durchgeführt und das Herunterfahren lief auch problemlos ..
Evtl ist das jetzt der erste richtige Bootvorgang nach dem 'zypper patch', kann mich nicht erinnern ob ich ein Probebooten nach der Aktualisierung durchgeführt habe.

Umstellung der Platten von sata-0 -> sata-1 und sata-1 -> sata-2 in VirtualBox hat keine Besserung gebracht.

Könnte VirtualBox noch auf die aktuellste Version 5.2.12 updaten und hoffen dass das Problem veschwindet.

Zitat von Sauerland

Platte voll?

zuletzt waren über 10GB noch frei.

Zitat von Sauerland

Einen Schnappschuss starten?

einen snapshot bin ich schon zurückgegangen, mehr dürften auch nicht mehr vorhanden sein, hatte einen cleanup gemacht.
Auch der Snapshot hing an derselben Stelle/Meldung.

Zitat von Sauerland

Versuch eine 2. Platte einzuhängen, dort ein Betriebssystem drauf zu installieren und dann die "kaputte " Platte anzuschauen

den Versuch hatte ich ja u.a. mit Leap15 vor.

zunächst hatte ich die Platte unter openSuse13.2 nicht eingehängt aber per fsck oder btrfs check ... überprüft, Fehlermeldungen sind mir keine ins Auge gesprungen, schien ok zu sein.
Ein Einbinden unter 13.2 könnte ich noch versuchen, aber wenn die Platte an sich per fsck als ok gekennzeichnet ist - wie und wo soll ich händisch einen Fehler finden?

Einbinden mit Leap15:
da hatte ich ja einen neuen Thread aufgemacht.
Nagelneu installiert ud geupdated heute morgen. Mit fdisk -l die Partitionen anzeigen lassen, anschließend einen "mount /dev/sdb2 /mnt/sdb2" aufgerufen. Keinen weiteren Zugriff auf die gemountete Platte durchgeführt und Leap15 ging sofort auf 100% Auslastung hoch, ein ll bzw. ls auf das lokale Verzeichnis wurde mit input/outpur error quittiert, und nichts ging mehr. auch mein Host / OSX hing teilweise, war nicht mehr bedienbar ???

irgendwelche Vermutungen woran das liegen kann?

Solange ich den mount nicht ausführe kann ich mit Leap15 'normal' arbeiten.

Leap15 ist auf dieser HW keine Option für mich, kann ich anderweitig noch Stellung beziehen, nicht mehr performant!!!

Wollte mein Problem nochmals nach vorne bringen:

Meine aktuellsten Versuche:
Ich habe eine 42.3er-DVD-iso datei heruntergeladen und damit eine VM komplett neu installiert, anschließend alle Updates per icon und 'zypper patch' ausgeführt, ... ge-rebootet etc.
Alles somit auf dem aktuellsten Stand, es werden keine weiteren Updates angeboten.
Die Installation erfolgte wieder alles in eine Partition, keine extra home. Somit ist alles unter sda2 als btrfs, sda1 ist swap.
Durch den Vorgang konnte ich jetzt das 'Namensschema' für die subvolumes wie sie von openSuse vergeben werden 'ermitteln'.

Also folglich im xterm eingegeben:

mkdir tmpdir
mount -o subvol=@/home /dev/sdb2 tmpdir

/dev/sdb2 ist die problematische Partition mit btrfs die nicht mehr bootet. Mehrere fscks haben aber 'Fehlerfreiheit' für die Partition bestätigt, sollte an sich ok sein.

ich konnte anschließend problemlos ein

ll tmpdir <tab> <tab> <ret>

eingeben und der inhalt des dort liegenden home-Verzeichnisses wurde ohne erkennbare Fehler und Fehlermeldungen aufgelistet.

Anschließend ging die CPU (angezeigt per Widget für system und cpu0) wieder auf 100% (wie bei Leap15, kubuntu18.04), eine weitere 'ls' Eingabe im xterm hing und lies sich auch durch Ctrl-C nicht beenden.
Letztendlich hing auch mein Host-OS, so dass ich nicht mal Screenshots anfertigen konnte.
Nach einiger Zeit ging zumindest die Last für CPU auf 0, während die für SYSTEM weiter bei 100% blieb, danach wurden auch die Widgets nicht mehr geupdated, waren eingefroren.
Nur noch der Mauszeiger hat reagiert, im Guest und Host System.
Diesmal hatte ich noch ein weiteres Widget auf dem Desktop, für die Festplattenein-/ausgabe. Dies zeigte mir Aktionen auf sdb2 und sda1 (swap) an ???.
Warum wurde hier eifrig geswapt, auch während die CPU auf 100% war fanden somit reichlich und permanent Zugriffe statt?

Letztendlich:
Ich habe reichlich Aufwand in Installationen und Daten reingesteckt. Zumindest die Daten unter home würde ich gerne retten können. Der restliche Aufwand und know-how dürfte weg sein.
Wie kann ich noch irgendwas retten (von /home)
?? irgendwelche Vorschläge ??

<btw, weil es auch einen anderen Thread hierzu gibt>
die Grundlast bei Leap42 ist >=20%, bei Leap15>=30% und war bei 13 noch unter 10%. ( nix am Laufen, leerer Desktop mit CPU Widget)
--> ärgerlich
</btw>

Grüße