[Manjaro] wie am besten fehlerverursachendes Update feststellen?

[Franklin Schiftan]

Hallo miteinander,

kürzlich wollte meine Manjaro(Arch-Linux)-VM - wie nahezu jede Woche
- mal wieder etliche Updates einspielen, diesmal 236 Stück.

Wie üblich ließ ich dies zu, konnte dann diesmal aber anschließend
nicht mehr wirklich mit der VM arbeiten, weil der X-Server nicht
mehr starten konnte. Im angebotenen Log stand dann zum Schluss, dass
er keinen Screen gefunden hätte.

Die aus dem Backup wieder hergestellte VM-Version vor diesen Updates
funktioniert natürlich nach wie vor noch einwandfrei. Nur wie kann
ich nun als Linux-Nichtkenner am besten herausfinden, welches der
236 Update-Pakete dafür verantwortlich ist?

Bei Problemen mit Browser-AddOns würde ich immer hälftig aktivieren,
um so relativ schnell den Verursacher einkreisen zu können ... ich
fürchte aber, dass ein solches Verfahren hier in dem Fall mit den
BS-Updates, einfach erstmal nur die eine Hälfte der Update-Pakete
zuzulassen etc., nicht praktikabel ist, oder?

--
..... und tschüss

Franklin

[Markus Grob]

Franklin Schiftan schrieb:

>
> Hallo miteinander,
>
> kürzlich wollte meine Manjaro(Arch-Linux)-VM - wie nahezu jede Woche
> - mal wieder etliche Updates einspielen, diesmal 236 Stück.
>
> Wie üblich ließ ich dies zu, konnte dann diesmal aber anschließend
> nicht mehr wirklich mit der VM arbeiten, weil der X-Server nicht
> mehr starten konnte. Im angebotenen Log stand dann zum Schluss, dass
> er keinen Screen gefunden hätte.

Da gibt es mehrere Möglichkeiten.

1. Zuerst Try -> alles nicht relevant scheinende installieren und neu
booten und testen.

2. Nach dem Update im Log schauen wo er meckert und kontrollieren, ob im
Update Pakete für Kernel, Grafikkarte, X und so weiter enthalten sind.
Wenn ja, diese einmal nicht installieren und sich so weiter vorarbeiten.

3. Alles installieren und dann von der Konsole aus reparieren. Was für
eine VM verwendest Du? Virtualbox? Je nach Konfiguration musst Du dann
die Kernelmodule aktivieren, damit die Grafik wieder läuft.

Gruss, Markus

[Franklin Schiftan]

Markus Grob schrieb am 10.05.2016 um 21:52 Uhr:

> Franklin Schiftan schrieb:
>>
>> Hallo miteinander,
>>
>> kürzlich wollte meine Manjaro(Arch-Linux)-VM - wie nahezu jede
>> Woche - mal wieder etliche Updates einspielen, diesmal 236
>> Stück.
>>
>> Wie üblich ließ ich dies zu, konnte dann diesmal aber
>> anschließend nicht mehr wirklich mit der VM arbeiten, weil der
>> X-Server nicht mehr starten konnte. Im angebotenen Log stand
>> dann zum Schluss, dass er keinen Screen gefunden hätte.
>
> Da gibt es mehrere Möglichkeiten.

Danke für die Hinweise ...

> 1. Zuerst Try -> alles nicht relevant scheinende

... aber da tu ich mich als Linux-Nichtkenner ja schon schwer ...

> installieren und neu booten und testen.
>
> 2. Nach dem Update im Log schauen wo er meckert und
> kontrollieren, ob im Update Pakete für Kernel, Grafikkarte, X
> und so weiter enthalten sind. Wenn ja, diese einmal nicht
> installieren und sich so weiter vorarbeiten.

Sofern das auch für Laien klar erkennbar ist - und die nicht
installierten Pakete dann nicht doch aufgrund irgendwelcher
Abhängigkeiten zu einem der anderen installierten Pakete notwendig
sind - wäre das auch meine Idee gewesen.

> 3. Alles installieren und dann von der Konsole aus reparieren.

Aber dazu braucht es vermutlich erst Recht richtige Linux-Kenntnisse
(,die hier eben nur rudimentär vorhanden sind ... es kommen zwar
immer wieder mal zu den verschiedenen Anlässen neue Erkenntnisse
hinzu, aber wenn ich die dann nicht laufend erneut brauche, vergesse
ich die doch auch recht schnell wieder.).

> Was für eine VM verwendest Du? Virtualbox?

Ja.

> Je nach Konfiguration musst Du dann die Kernelmodule aktivieren,
> damit die Grafik wieder läuft.

???

> Gruss, Markus

Danke trotzdem ...

[Gunter Gutzeit]

Franklin Schiftan schrieb am Di 10.05.2016 19:06:26 +0200:

> Die aus dem Backup wieder hergestellte VM-Version vor diesen Updates

> funktioniert natürlich nach wie vor noch einwandfrei. [...]

Also ist das Update der Virtualbox schiefgelaufen. Eine Fehlersuche in
den installierten Packeten der Virtualbox, den Manjaro-Zusatz-Pakten
hierzu (ggf. den installierten Virtualbox-Kernel-Modulen) oder den
möglichen Zusatz-Paketen aus dem AUR (je nach, was Du alles
im Zusammenhang mit der Virtualbox installiert hast) ist nicht einfach.

> [...] Nur wie kann

> ich nun als Linux-Nichtkenner am besten herausfinden, welches der
> 236 Update-Pakete dafür verantwortlich ist?

Der Fehler wäre zu suchen in der Schnittmenge der 236 Update-Pakte und
dem was Dir hiermit angezeigt wird:

| 11 - DEPENDENCIES TREE
| "pactree -s <PACKAGE NAME>"
|
| This command will display a complete tree of all dependencies -
| installed on your system - of <PACKAGE NAME>.
|
| Attention: The dependency tree can be quite long and complex for higher
| level packages such as "firefox".

Aber selbst, wenn Du die Ursache tatsächlich herausgefunden hast, hast
Du das eigentliche Problem einer zukünftig mit Manjaro stabil laufenden
Virtualbox damit noch immer nicht gelöst.

--
Gruß
Gunter
gepostet aus Puppy-Linux@32BitPc4GbRAM

[Franklin Schiftan]

Gunter Gutzeit schrieb am 11.05.2016 um 10:03 Uhr:

> Franklin Schiftan schrieb am Di 10.05.2016 19:06:26 +0200:
>
>> Die aus dem Backup wieder hergestellte VM-Version vor diesen
>> Updates funktioniert natürlich nach wie vor noch einwandfrei.
>> [...]
>
> Also ist das Update der Virtualbox schiefgelaufen.

Danke für Deine Antwort, aber ich glaube, hier missverstehen wir
uns. Virtualbox wurde nicht upgedatet, sondern Manjaro in der VM.

> Aber selbst, wenn Du die Ursache tatsächlich herausgefunden hast,
> hast Du das eigentliche Problem einer zukünftig mit Manjaro
> stabil laufenden Virtualbox damit noch immer nicht gelöst.

Nun ja, wenn ich mal viel Zeit habe, werde ich mal probieren, nach
Try-and-Error einzelne der 236 Update-Pakete zu installieren und
jeweils ausprobieren, wieweit es klappt. Nur kann ich dann
sinnvollerweise immer wieder erst nach dem nächsten Backup weiter
probieren ... :-(

[Gunter Gutzeit]

Franklin Schiftan schrieb am Mi 11.05.2016 13:47:17 +0200:

> Danke für Deine Antwort, aber ich glaube, hier missverstehen wir
> uns. Virtualbox wurde nicht upgedatet, sondern Manjaro in der VM.

Trotz des Mißverständnisses:

Wenn Du Dein Manjaro in der VM untersuchst, wirst Du trotzdem von
Manjaro installierte Virtualbox-Packages, mit entsprechenden
Abhängigkeiten, finden. Die werden von Manjaro (oder Arch-Linux)
benötigt, um in der Virtualbox zu laufen.

Selbst wenn Du das (die) ursächlichen Pakete gefunden hast, ist ein
Downgrade immer problematisch:

https://wiki.archlinux.de/title/%C3%84ltere_Paketversion_installieren_%28Downgrade%29

Manjaro hätte für so etwas ein eigenes Programm:

https://wiki.manjaro.org/index.php?title=Using_Downgrade

[Manuel Reimer]

On 05/10/2016 07:06 PM, Franklin Schiftan wrote:
> Wie üblich ließ ich dies zu, konnte dann diesmal aber anschließend
> nicht mehr wirklich mit der VM arbeiten, weil der X-Server nicht
> mehr starten konnte. Im angebotenen Log stand dann zum Schluss, dass
> er keinen Screen gefunden hätte.

Das passiert bei Arch Linux selbst auch.

Ich habe das am Arbeitsplatz bei meiner kleinen Linux-VM auch gehabt.
Dort hatte ich aber auch konkrete Fehlermeldungen und bin dann mit 5
Minuten Suche im Netz am Ziel gewesen.

Da ist wohl irgendwas mit Kernel und virtualbox-guest-utils in Konflikt.
Mit einem bestimmten Kernel-Parameter läuft dann alles wieder.

Gruß

Manuel

[Franklin Schiftan]

Danke, Manuel, fürs Mut-machen ... also bin ich offensichtlich schon
mal nicht der einzige, der in diesen Bug gelaufen ist. Mit den
vorgenannten Suchbegriffen hab ich nun z.B. gefunden "I use
iomem=relaxed kernel parameter as workaround.", habe allerdings
keinerlei Ahnung, wie und wo ich das anbringen sollte ....

Ganz abgesehen davon, dass hier ja inzwischen Vbox 5.0.20 läuft und
ein Stück später jemand schrieb "This option was added to the 4.5-1
kernel config: CONFIG_IO_STRICT_DEVMEM=y. According to this forum
post, once VirtualBox 5.0.17 is released the kernel parameter can be
removed." Das verstehe ich so, dass das Problem mit dieser
Vbox-Version hier eigentlich gar kein Problem mehr sein sollte.

Und ebenfalls ganz abgesehen davon, dass mein Manjaro mit Kernel
4.5.3.1 problemlos läuft und lief, bis ich die 236 Update-Pakete
zugelassen hatte - inzwischen sind es ja sogar schon 357
Update-Pakete ... :-( ... aber auch nach Download und Installation
dieser aktuell rd. 1,1 GB (ja, ich dachte, dass möglicherweise der
Fehler durch aktualisierte Update-Pakete behoben sein könnte)
startet der X-Server nach wie vor nicht. Und ehrlich gesagt kann ich
als Linux-Laie aus dem angezeigten Log nur erkennen, dass er in der
Konfiguration eben keinen Screen gefunden hat ... :-(

Ich wäre ja auch bereit einen Linux-Kenner hier per Teamviewer auf
meiner Kiste in der VM werkeln zu lassen, wenn sich dadurch der
nicht startende X-Server irgendwie wieder zum Leben erwecken ließe.

Und leider lässt sich der letztens von Gunter gepostete Link auf die
Manjaro-Wiki-Seite zum Downgrade wegen dort abgelaufenem
SSL-Zertifikat auch nicht öffnen.

> Manuel

[Michael Limburg]

Franklin Schiftan schrieb:

> startet der X-Server nach wie vor nicht. Und ehrlich gesagt kann ich
> als Linux-Laie aus dem angezeigten Log nur erkennen, dass er in der
> Konfiguration eben keinen Screen gefunden hat ... :-(

Für den Anfang täte es ja schon mal die Fehlermeldung, so
wie sie im Log steht.

MfG

[Franklin Schiftan]

Danke, Michael, für Deine Hilfsbereitschaft. Da ich nicht weiß, wie
ich an die Meldung in Textform kommen kann, konnte ich sie nur als
Screenshot festhalten <http://fraschi.net/temp/manjaro_fehler.jpg>
(Nach dem Verlassen dieser "Kurzmeldung" kann man sich dann übrigens
auch noch eine deutlich umfassendere Meldung anzeigen lassen, falls
benötigt.)
Ich fürchte nur, dass weitere Korrektur-Schritte für mich als
Linux-Nichtkenner schwierig durchführbar sind. Aber ich will gerne
alles versuchen, wenn ich genau weiß, was und wie. Nochmal danke.

> MfG

[Marc Haber]

Franklin Schiftan <fraschi...@arcor.de> wrote:
>Danke, Michael, für Deine Hilfsbereitschaft. Da ich nicht weiß, wie
>ich an die Meldung in Textform kommen kann, konnte ich sie nur als
>Screenshot festhalten <http://fraschi.net/temp/manjaro_fehler.jpg>

Das würde ich irgendwo unter /var/log/Xorg.log.* vermuten. Keine
Ahnung, wie das bei Deinem Exoten ist.

Interessant sind die ersten Zeilen, die mit (EE) markiert sind.

>Ich fürchte nur, dass weitere Korrektur-Schritte für mich als
>Linux-Nichtkenner schwierig durchführbar sind. Aber ich will gerne
>alles versuchen, wenn ich genau weiß, was und wie. Nochmal danke.

Warum nimmt man als Linux-Nichtkenner eine Distribution, mit der sich
kein Schwein auskennt?

Grüße
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

[Gert Link]

Am 10.05.2016 um 19:06 schrieb Franklin Schiftan:

> Wie üblich ließ ich dies zu, konnte dann diesmal aber anschließend
> nicht mehr wirklich mit der VM arbeiten, weil der X-Server nicht
> mehr starten konnte. Im angebotenen Log stand dann zum Schluss, dass
> er keinen Screen gefunden hätte.

In einem anderen Beitrag hast Du ja geschrieben, dass die VM unter
VirtualBox läuft.

Damit habe ich seit einiger Zeit in Arch-Linux dasselbe Problem, und
zwar immer, wenn ein neuer Kernel installiert wurde. Im neuen Kernel
fehlen dann die VBosGuestAdditions und die vorhandenen generischen
Treiber scheinen mit der VirtualBox-Version nicht mehr zu funktionieren.

Abhilfe bei mir ist immer, die VBoxGuestAdditions neu zu installieren.
sudo mount /dev/sr0 /mnt
cd /mnt
sudo ./VBoxLinuxAdditions.run

Dann die VM neu starten:
sudo shutdown -r now


--
Grüße
Gert

[Gert Link]

Am 13.05.2016 um 07:58 schrieb Marc Haber:

> Warum nimmt man als Linux-Nichtkenner eine Distribution, mit der sich
> kein Schwein auskennt?

Soo klein ist die Nutzerbasis von Arch-/Manjaro-Linux nun auch wieder nicht.


--
Grüße
Gert

[Markus Grob]

Franklin Schiftan schrieb:

Wie das geht, steht im Posting von Gert Link.

Gruss, Markus

[Franklin Schiftan]

Damit meinst Du jetzt aber nicht sein Posting von heute 09:34 Uhr, oder?

> Gruss, Markus

[Franklin Schiftan]

Gert Link schrieb am 13.05.2016 um 09:34 Uhr:

> Am 10.05.2016 um 19:06 schrieb Franklin Schiftan:
>
>> Wie üblich ließ ich dies zu, konnte dann diesmal aber
>> anschließend nicht mehr wirklich mit der VM arbeiten, weil der
>> X-Server nicht mehr starten konnte. Im angebotenen Log stand
>> dann zum Schluss, dass er keinen Screen gefunden hätte.
>
> In einem anderen Beitrag hast Du ja geschrieben, dass die VM
> unter VirtualBox läuft.
>
> Damit habe ich seit einiger Zeit in Arch-Linux dasselbe Problem,
> und zwar immer, wenn ein neuer Kernel installiert wurde.

Wie gesagt, läuft die VM hier im Prinzip unter dem neuesten Kernel.
Erst nach Einspielen der 200 bis 300 aktuellen Update-Pakete startet
der X-Server nicht mehr.

> Im neuen Kernel fehlen dann die VBosGuestAdditions und die
> vorhandenen generischen Treiber scheinen mit der
> VirtualBox-Version nicht mehr zu funktionieren.
>
> Abhilfe bei mir ist immer, die VBoxGuestAdditions neu zu
> installieren. sudo mount /dev/sr0 /mnt cd /mnt sudo
> ./VBoxLinuxAdditions.run

Danke für die konkreten Kommandos ... Zunächst mal musste ich ewig
suchen und ausprobieren, bis ich auf der Tastatur die völlig
woanders liegenden Zeichen gefunden hatte, dann habe ich die
Kommandos so eingegeben und anschließend das folgende Ergebnis in
der Konsole erhalten: <http://fraschi.net/temp/vbox_run.jpg>

> Dann die VM neu starten: sudo shutdown -r now

Auch das tat ich, wobei die VM anschließend mit dem folgenden
Ergebnis stehen blieb: <http://fraschi.net/temp/reboot.jpg>

Neben den vielen [ O.k. ]-Zeilen auf dem Bildschirm gab es aber
vorher auch eine rote Zeile mit "Failed to start Load Kernel
Modules". Und in dem umfangreichen Log gab's dann auch noch die
folgenden vbox-Fehler: <http://fraschi.net/temp/failed.jpg>

Ich bin gerade doch ziemlich ratlos ...

[Marc Haber]

Im Vergleich zu Ubuntu ist es ein Exot.

[Helmut Hullen]

Hallo, Marc,

Du meintest am 13.05.16:

>>> Warum nimmt man als Linux-Nichtkenner eine Distribution, mit der
>>> sich kein Schwein auskennt?

>> Soo klein ist die Nutzerbasis von Arch-/Manjaro-Linux nun auch
>> wieder nicht.

> Im Vergleich zu Ubuntu ist es ein Exot.

a) abends werfen auch Zwerge grosse Schatten,
b) im Vergleich zu Windows ist auch Debian ein Exot. Auch wenn es unter
Kleinen der Grösste sein will.

Aber es ist lobenswert, dass Du mal wieder einen Rat gibst, bei dem
Marktanteile Qualität ersetzen sollen.

Viele Gruesse
Helmut

"Ubuntu" - an African word, meaning "Slackware is too hard for me".

[Markus Grob]

Franklin Schiftan schrieb:
>
> Markus Grob schrieb am 13.05.2016 um 12:24 Uhr:
>
>> Franklin Schiftan schrieb:
>>>
>>> Markus Grob schrieb am 10.05.2016 um 21:52 Uhr:
>>
>>>> Je nach Konfiguration musst Du dann die Kernelmodule aktivieren,
>>>> damit die Grafik wieder läuft.
>>>
>>> ???
>>
>> Wie das geht, steht im Posting von Gert Link.
>
> Damit meinst Du jetzt aber nicht sein Posting von heute 09:34 Uhr, oder?

Doch, genau das Posting meine ich. Durch das Virtualbox Paket werden dem
Kernel die notwendigen Treiber zur Verfügung gestellt.

Gruss, Markus

[Markus Grob]

Franklin Schiftan schrieb:

>
> Gert Link schrieb am 13.05.2016 um 09:34 Uhr:
>
>> Am 10.05.2016 um 19:06 schrieb Franklin Schiftan:

>> Im neuen Kernel fehlen dann die VBosGuestAdditions und die
>> vorhandenen generischen Treiber scheinen mit der
>> VirtualBox-Version nicht mehr zu funktionieren.
>>
>> Abhilfe bei mir ist immer, die VBoxGuestAdditions neu zu
>> installieren. sudo mount /dev/sr0 /mnt cd /mnt sudo
>> ./VBoxLinuxAdditions.run
>
> Danke für die konkreten Kommandos ... Zunächst mal musste ich ewig
> suchen und ausprobieren, bis ich auf der Tastatur die völlig
> woanders liegenden Zeichen gefunden hatte, dann habe ich die
> Kommandos so eingegeben und anschließend das folgende Ergebnis in
> der Konsole erhalten: <http://fraschi.net/temp/vbox_run.jpg>

Du hast leider die zweitletzte Zeile nicht beachtet. Dort steht, dass
der Vorgang fehlgeschlagen ist. Das Problem hatte ich auch schon. Die
VirtualBox Module können nicht hineinkopiert werden.
Was auch noch wichtig ist. Er hat schon "non-DKMS" Module gehabt.
Wichtig ist hier, dass man mit DKMS dafür sorgen kann, dass die
notwendigen Module automatisch bei einem Update wieder gelinkt werden,
damit das System anschliessend wieder bootet.

>> Dann die VM neu starten: sudo shutdown -r now
>
> Auch das tat ich, wobei die VM anschließend mit dem folgenden
> Ergebnis stehen blieb: <http://fraschi.net/temp/reboot.jpg>

Genau. Das ist eine Folge des obigen Problems. Der Kernel hat nichts mehr.

> Neben den vielen [ O.k. ]-Zeilen auf dem Bildschirm gab es aber
> vorher auch eine rote Zeile mit "Failed to start Load Kernel
> Modules". Und in dem umfangreichen Log gab's dann auch noch die
> folgenden vbox-Fehler: <http://fraschi.net/temp/failed.jpg>
>
> Ich bin gerade doch ziemlich ratlos ...

Hast Du noch einen Snapshot von vor dem Update? Am Besten zurück auf
diesen. Dann kannst Du alles ausser virtualbox und kernel installieren
lassen. Diese Module erst später. Ich bin gerade in Eile, doch ich
sollte das korrekte Vorgehen am Nachmittag posten können.

Gruss, Markus

[Franklin Schiftan]

Markus Grob schrieb am 14.05.2016 um 09:25 Uhr:

> Franklin Schiftan schrieb:
>>
>> Gert Link schrieb am 13.05.2016 um 09:34 Uhr:
>>
>>> Am 10.05.2016 um 19:06 schrieb Franklin Schiftan:
>
>>> Im neuen Kernel fehlen dann die VBosGuestAdditions und die
>>> vorhandenen generischen Treiber scheinen mit der
>>> VirtualBox-Version nicht mehr zu funktionieren.
>>>
>>> Abhilfe bei mir ist immer, die VBoxGuestAdditions neu zu
>>> installieren. sudo mount /dev/sr0 /mnt cd /mnt sudo
>>> ./VBoxLinuxAdditions.run
>>
>> Danke für die konkreten Kommandos ... Zunächst mal musste ich
>> ewig suchen und ausprobieren, bis ich auf der Tastatur die
>> völlig woanders liegenden Zeichen gefunden hatte, dann habe ich
>> die Kommandos so eingegeben und anschließend das folgende
>> Ergebnis in der Konsole erhalten:
>> <http://fraschi.net/temp/vbox_run.jpg>
>
> Du hast leider die zweitletzte Zeile nicht beachtet. Dort steht,
> dass der Vorgang fehlgeschlagen ist. Das Problem hatte ich auch
> schon. Die VirtualBox Module können nicht hineinkopiert werden.

Hmm, und warum weiß vermutlich keiner, oder?

> Was auch noch wichtig ist. Er hat schon "non-DKMS" Module gehabt.
> Wichtig ist hier, dass man mit DKMS dafür sorgen kann, dass die
> notwendigen Module automatisch bei einem Update wieder gelinkt
> werden, damit das System anschliessend wieder bootet.
>
>
>>> Dann die VM neu starten: sudo shutdown -r now
>>
>> Auch das tat ich, wobei die VM anschließend mit dem folgenden
>> Ergebnis stehen blieb: <http://fraschi.net/temp/reboot.jpg>
>
> Genau. Das ist eine Folge des obigen Problems. Der Kernel hat
> nichts mehr.
>
>
>> Neben den vielen [ O.k. ]-Zeilen auf dem Bildschirm gab es
>> aber vorher auch eine rote Zeile mit "Failed to start Load
>> Kernel Modules". Und in dem umfangreichen Log gab's dann auch
>> noch die folgenden vbox-Fehler:
>> <http://fraschi.net/temp/failed.jpg>
>>
>> Ich bin gerade doch ziemlich ratlos ...
>
> Hast Du noch einen Snapshot von vor dem Update?

Klar ...

> Am Besten zurück auf diesen.

Done.

> Dann kannst Du alles ausser virtualbox und kernel installieren
> lassen.

Wie gesagt, Kernel wird ja schon der aktuelle 4.5.3.1 genutzt - bis
vor der Update-Orgie auch ohne Probleme ...

> Diese Module erst später.

Sehe ich das richtig, dass ich von den 357 aktuell anstehenden
Update-Paekten (siehe auch
<http://fraschi.net/temp/manjaro_updates.txt>) nicht nur

- virtualbox-guest-utils 5.0.16-0.1 -> 5.0.20-0.1

abwählen sollte, sondern sicherheitshalber auch die Pakete

- linux41-virtualbox-guest-modules 5.0.16-8 -> 5.0.20-1
- linux44-virtualbox-guest-modules 5.0.16-8 -> 5.0.20-2
- linux45-virtualbox-guest-modules 5.0.18-1 -> 5.0.20-2

selbst, wenn ich nicht vorhabe, die Kernel 4.1 und 4.4 noch mal zu
nutzen (irgendwann werde ich sie sicher auch deinstallieren, so dass
dafür auch keine Updates mehr angeboten werden)?

Was mich auch noch gerade etwas verwirrt: Warum will das Paket
- virtualbox-guest-utils 5.0.16-0.1 -> 5.0.20-0.1
von V 5.0.16 aus aktualisiert werden, wenn gleichzeitig das Paket
- linux45-virtualbox-guest-modules 5.0.18-1 -> 5.0.20-2
von V 5.0.18 aus aktualisiert werden soll?

Was ist der Unterschied zwischen diesen beiden Paketen?

Und macht es dann nichts, wenn ich im Host VB 5.0.20 installiert
habe, die vb-guest-utils aber auf 5.0.16 (oder 5.0.18?) bleiben? Nun
ja, momentan läuft's ja in der Konstellation auch ... hmm ... schon
alles komisch irgendwie ...

> Ich bin gerade in Eile, doch ich sollte das korrekte Vorgehen am
> Nachmittag posten können.

Vielen herzlichen Dank für Deine Hilfe, Markus!

> Gruss, Markus

[Gunter Gutzeit]

Franklin Schiftan schrieb am Do 12.05.2016 22:14:52 +0200:

> Und leider lässt sich der letztens von Gunter gepostete Link auf die
> Manjaro-Wiki-Seite zum Downgrade wegen dort abgelaufenem
> SSL-Zertifikat auch nicht öffnen.

Es lag aber nicht in meiner Absicht, Dich zu entmutigen.

Im Gegenteil, mit Deiner Entscheidung Manjaro-Linux, aus zu probieren,
hast Du eine gute Wahl getroffen. Von den derzeit existierenden
Rolling-Release-Linuxen sicher eins der besten und durch die zur
Verfügung stehenden Installer auch für Einsteiger sehr gut geeignet.

Nun, Du bist ja ganz pfiffig und wird Dich da schon durchbeißen :-)

--
Gruß
Gunter
gepostet aus Manjaro-Linux@32BitPc512MbRAM

[Gunter Gutzeit]

Marc Haber schrieb am Fr 13.05.2016 07:58:45 +0200:

> Warum nimmt man als Linux-Nichtkenner eine Distribution, mit der sich
> kein Schwein auskennt?

Ich glaube, dass Du Deinen "schweinischen" und unsachlichen Kommentaren
hier mal wieder niemandem weiterhilfst :-)

[Markus Grob]

Franklin Schiftan schrieb:

>
> Markus Grob schrieb am 14.05.2016 um 09:25 Uhr:
>
>> Franklin Schiftan schrieb:

>>> <http://fraschi.net/temp/vbox_run.jpg>
>>
>> Du hast leider die zweitletzte Zeile nicht beachtet. Dort steht,
>> dass der Vorgang fehlgeschlagen ist. Das Problem hatte ich auch
>> schon. Die VirtualBox Module können nicht hineinkopiert werden.
>
> Hmm, und warum weiß vermutlich keiner, oder?

Ich bin mir gerade nicht sicher, doch soviel ich weiss, stimmen die
Module nicht für den Kernel überein und werden daher nicht genommen. Es
kann auch sein, dass die Kernelheader nicht installiert sind. Genaues
steht in der Logdatei, die im Screenshot auf der nächsten Zeile folgt.
Linux ist in dieser Hinsicht halt anders als Windows. Es wird zwar
gemacht, was man befiehlt, doch man muss danach selber schauen, was man
falsch gemacht hat ;-)
Nein, ich vermute, dass in der Logdatei drin steht, warum das mappen
nicht funktioniert hat und entsprechend muss man dann handeln. Das ist
besser als raten, was die Ursache sein könnte.

>> Hast Du noch einen Snapshot von vor dem Update?
>
> Klar ...
>
>> Am Besten zurück auf diesen.
>
> Done.

Gut. Mir ist es nämlich schon ähnlich passiert, dass nur wenige Pakete
installiert werden sollten und da habe ich halt auf einen Snapshot
verzichtet und befand mich anschliessend in der gleichen Lage halt nur
ohne Resetknopf ;-)

> Sehe ich das richtig, dass ich von den 357 aktuell anstehenden
> Update-Paekten (siehe auch
> <http://fraschi.net/temp/manjaro_updates.txt>) nicht nur
>
> - virtualbox-guest-utils 5.0.16-0.1 -> 5.0.20-0.1
>
> abwählen sollte, sondern sicherheitshalber auch die Pakete
>
> - linux41-virtualbox-guest-modules 5.0.16-8 -> 5.0.20-1
> - linux44-virtualbox-guest-modules 5.0.16-8 -> 5.0.20-2
> - linux45-virtualbox-guest-modules 5.0.18-1 -> 5.0.20-2

Ja, die würde ich alle nicht installieren. Du hast ja mehrere Kernel
installiert, welche Du beim booten angeben kannst, doch wenn Du das
Paket für alle installierst, werden anschliessend alle Kernel das
gleiche Problem haben, weil das Problem nicht der Kernel ist, sondern
die VirtualBox Module, welche beim Neustart nicht mehr eingebunden
werden (können).

> Was mich auch noch gerade etwas verwirrt: Warum will das Paket
> - virtualbox-guest-utils 5.0.16-0.1 -> 5.0.20-0.1
> von V 5.0.16 aus aktualisiert werden, wenn gleichzeitig das Paket
> - linux45-virtualbox-guest-modules 5.0.18-1 -> 5.0.20-2
> von V 5.0.18 aus aktualisiert werden soll?

Ganz einfach. Du hast für jeden Kernel VB-Module und beim 41er und 44er
hast Du die 16er und beim 45er die 18er Version.

> Was ist der Unterschied zwischen diesen beiden Paketen?

Ganz einfach. VB wird ja entwickelt und daher gibt es
Fehlerbereinigungen und Erweiterungen.

> Und macht es dann nichts, wenn ich im Host VB 5.0.20 installiert
> habe, die vb-guest-utils aber auf 5.0.16 (oder 5.0.18?) bleiben? Nun
> ja, momentan läuft's ja in der Konstellation auch ... hmm ... schon
> alles komisch irgendwie ...

Es ist nicht einfach, doch auch nicht kompliziert ;-) Der Host ist
unabhängig von den Gastmodulen. Das heisst, Linux läuft auch ohne
Gastmodule. Diese Module optimieren aber das Verhalten im Gast. Das
heisst, ohne Module kannst Du etwa nicht einfach mittels Klick
hineinwechseln und danach mit der Maus wieder in den Host wechseln. Dazu
geht auch der Datentransfer über ein Netzlaufwerk erst mit den
Gastmodulen und ebenfalls die schönen Grafiktreiber stehen erst damit
zur Verfügung.

Allerdings müssen diese Module auf den Kernel abgestimmt sein, damit es
funktioniert. Daher musst Du diese nachträglich installieren. Bei der
Installation wird geschaut, dass diese Module kompatibel sind. Beim
Update kann es dann aber vorkommen, dass etwas schief läuft und dann
findet der Kernel die Module nicht mehr oder sind sind vorhanden, doch
nicht in der Version, die der Kernel bräuchte.

Damit man das Ganze nicht jedes Mal manuell durchführen muss, gibt es
DKMS. Das sorgt dafür, dass immer die passenden Module für den Kernel
geladen werden:
http://de.wikipedia.org/wiki/Dynamic_Kernel_Module_Support

Daher musst Du prüfen, ob Du DKMS installiert hast. Wenn ja, sollte es
keine Probleme mit dem Update geben.

Wie steht es mit Deinem englisch? Auf der folgenden Seite gibt es eine
Einführung mit vielen Tipps:
https://wiki.archlinux.org/index.php/VirtualBox

Evtl. kann es sein, dass die Module nach dem Neustart einfach nicht
direkt geladen werden:

"https://wiki.archlinux.org/index.php/VirtualBox#Load_the_Virtualbox_kernel_modules_2"

Funktioniert das manuelle Einbinden mit:
modprobe -a vboxguest vboxsf vboxvideo
ohne Fehlermeldung, dann kannst Du dafür sorgen, dass die Module beim
Start automatisch geladen werden. Ich muss dies etwa bei mir bei vboxsf
machen, da der Eintrag in die fstab nach dem Update Probleme macht, da
er dann das Modul noch nicht zur Verfügung hat und in den Emergency Mode
startet.

Die Module können im Unterverzeichnis /etc/modules-load.d hinzugefügt
werden. Am Besten erstellt man in diesem Verzeichnis die Datei
modules.conf (falls noch nicht vorhanden), und schreibt die zu ladenden
Kernelmodule dort hinein auf eine eigene Zeile. Möchte man noch einen
Kommentar haben, so muss diese Zeile mit einem # beginnen:
# vboxsf Modul
vboxsf
# vboxguest Modul
vboxguest

Ich hoffe, ich habe Dich mit den Informationen nicht erschlagen. Ich
musste sie auch in meiner 300 Seiten Doku zusammensuchen :-)

Gruss, Markus

[Gunter Gutzeit]

Markus Grob schrieb am Sa 14.05.2016 14:09:37 +0200:

> Ich hoffe, ich habe Dich mit den Informationen nicht erschlagen. Ich
> musste sie auch in meiner 300 Seiten Doku zusammensuchen :-)

Dank und Glückwunsch für die guten und umfangreichen Erklärungen.

[Marc Haber]

Gunter Gutzeit <gunter....@arcor.de> wrote:
>Marc Haber schrieb am Fr 13.05.2016 07:58:45 +0200:
>> Warum nimmt man als Linux-Nichtkenner eine Distribution, mit der sich
>> kein Schwein auskennt?
>
>Ich glaube, dass Du Deinen "schweinischen" und unsachlichen Kommentaren
>hier mal wieder niemandem weiterhilfst :-)

Getroffene Hunde bellen?

[Gunter Gutzeit]

Marc Haber schrieb am Sa 14.05.2016 15:54:58 +0200:

> Gunter Gutzeit <gunter....@arcor.de> wrote:
>> Marc Haber schrieb am Fr 13.05.2016 07:58:45 +0200:
>>> Warum nimmt man als Linux-Nichtkenner eine Distribution, mit der sich
>>> kein Schwein auskennt?
>>
>> Ich glaube, dass Du Deinen "schweinischen" und unsachlichen Kommentaren
>> hier mal wieder niemandem weiterhilfst :-)
>
> Getroffene Hunde bellen?

Freu' Dich :-)

--
Gruß
Gunter
gepostet aus Puppy-Linux@32BitPc4GbRAM

[Franklin Schiftan]

Markus Grob schrieb am 14.05.2016 um 14:09 Uhr:

Zunächst erstmal einen ganz großen Dank für Deinen umfangreichen
Beitrag!
Es wird jetzt allerdings wieder ein Weilchen dauern, bis ich alles
durchgelesen - auch die Links - und womöglich einen Teil davon
verstanden habe, so dass ich mich auch traue, das eine oder andere
umzusetzen. Außerdem will ich jeden nächsten Schritt erst
durchführen, wenn ich vom jeweils aktuell noch funktionierenden
Stand (die VM ist ja immerhin rd. 32 GB groß) wieder ein Backup
habe, auf das ich zurückgreifen kann. Und aus mir nicht mehr ganz
präsenten Gründen hatte ich mich irgendwann mal dazu entschieden,
dies nicht mit der Vbox-eigenen Möglichkeit von Sicherungspunkten zu
machen, sondern im Rahmen meines normalen Gesamt-PC-Backups.

Also bitte nicht wundern, falls es mit weiteren Miss- oder
Erfolgsmeldungen von meiner Seite aus ein wenig dauert - ich werde
auf jeden Fall wieder berichten, was ich gemacht habe und was dabei
herausgekommen ist.

Zu ein paar kleineren Punkten sage ich aber jetzt schon mal weiter
unten was.

> Franklin Schiftan schrieb:
>>
>> Markus Grob schrieb am 14.05.2016 um 09:25 Uhr:
>>
>>> Franklin Schiftan schrieb:
>
>>>> <http://fraschi.net/temp/vbox_run.jpg>
>>>
>>> Du hast leider die zweitletzte Zeile nicht beachtet. Dort
>>> steht, dass der Vorgang fehlgeschlagen ist. Das Problem hatte
>>> ich auch schon. Die VirtualBox Module können nicht
>>> hineinkopiert werden.
>>
>> Hmm, und warum weiß vermutlich keiner, oder?
>
> Ich bin mir gerade nicht sicher, doch soviel ich weiss, stimmen
> die Module nicht für den Kernel überein und werden daher nicht
> genommen. Es kann auch sein, dass die Kernelheader nicht
> installiert sind.

Bei der Suche in Octopi habe ich dazu lediglich
'kernel-headers-musl' (nicht installiert) gefunden.

> Genaues steht in der Logdatei, die im Screenshot auf der nächsten
> Zeile folgt. Linux ist in dieser Hinsicht halt anders als
> Windows. Es wird zwar gemacht, was man befiehlt, doch man muss
> danach selber schauen, was man falsch gemacht hat ;-) Nein, ich
> vermute, dass in der Logdatei drin steht, warum das mappen nicht
> funktioniert hat und entsprechend muss man dann handeln. Das ist
> besser als raten, was die Ursache sein könnte.

Ich traue mich ja kaum, es zu schreiben, aber dazu fehlen mir halt
tatsächlich die Linux-Grundkenntnisse, um zu wissen, wie ich im CLI
an den Inhalt dieser Logdatei komme. :-( Und dann noch mit diesen
ganzen vertauschten Tasten ... <grrrr>

>>> Hast Du noch einen Snapshot von vor dem Update?
>>
>> Klar ...
>>
>>> Am Besten zurück auf diesen.
>>
>> Done.
>
> Gut. Mir ist es nämlich schon ähnlich passiert, dass nur wenige
> Pakete installiert werden sollten und da habe ich halt auf einen
> Snapshot verzichtet und befand mich anschliessend in der
> gleichen Lage halt nur ohne Resetknopf ;-)

Ja, das kenne ich auch von anderen (Windows-)Rechnern, wo ich
dachte, bei den paar Updates kann ja eigentlich nichts schief gehen.

>> Sehe ich das richtig, dass ich von den 357 aktuell anstehenden
>> Update-Paekten (siehe auch
>> <http://fraschi.net/temp/manjaro_updates.txt>) nicht nur
>>
>> - virtualbox-guest-utils 5.0.16-0.1 -> 5.0.20-0.1
>>
>> abwählen sollte, sondern sicherheitshalber auch die Pakete
>>
>> - linux41-virtualbox-guest-modules 5.0.16-8 -> 5.0.20-1 -
>> linux44-virtualbox-guest-modules 5.0.16-8 -> 5.0.20-2 -
>> linux45-virtualbox-guest-modules 5.0.18-1 -> 5.0.20-2
>
> Ja, die würde ich alle nicht installieren. Du hast ja mehrere
> Kernel installiert, welche Du beim booten angeben kannst, doch
> wenn Du das Paket für alle installierst, werden anschliessend
> alle Kernel das gleiche Problem haben, weil das Problem nicht der
> Kernel ist, sondern die VirtualBox Module, welche beim Neustart
> nicht mehr eingebunden werden (können).

O.k., dann werde ich dies, 357 minus die vier Update-Pakete, mal als
nächstes probieren, sobald ich vom aktuellen Stand ein Backup habe.

>> Was mich auch noch gerade etwas verwirrt: Warum will das Paket
>> - virtualbox-guest-utils 5.0.16-0.1 -> 5.0.20-0.1 von V
>> 5.0.16 aus aktualisiert werden, wenn gleichzeitig das Paket -
>> linux45-virtualbox-guest-modules 5.0.18-1 -> 5.0.20-2 von V
>> 5.0.18 aus aktualisiert werden soll?
>
> Ganz einfach. Du hast für jeden Kernel VB-Module und beim 41er
> und 44er hast Du die 16er und beim 45er die 18er Version.
>
>> Was ist der Unterschied zwischen diesen beiden Paketen?
>
> Ganz einfach. VB wird ja entwickelt und daher gibt es
> Fehlerbereinigungen und Erweiterungen.

Ich glaub, da haben wir uns jetzt missverstanden, ich wollte nicht
den Unterschied zwischen V 5.0.18 zu V 5.0.20 wissen, sondern
welcher Unterschied zwischen 'virtualbox-guest-utils' und
'linux45-virtualbox-guest-modules' besteht ... hört sich halt beides
recht ähnlich an ...

>> Und macht es dann nichts, wenn ich im Host VB 5.0.20
>> installiert habe, die vb-guest-utils aber auf 5.0.16 (oder
>> 5.0.18?) bleiben? Nun ja, momentan läuft's ja in der
>> Konstellation auch ... hmm ... schon alles komisch irgendwie
>> ...
>
> Es ist nicht einfach, doch auch nicht kompliziert ;-) Der Host
> ist unabhängig von den Gastmodulen. Das heisst, Linux läuft auch
> ohne Gastmodule. Diese Module optimieren aber das Verhalten im
> Gast. Das heisst, ohne Module kannst Du etwa nicht einfach
> mittels Klick hineinwechseln und danach mit der Maus wieder in
> den Host wechseln. Dazu geht auch der Datentransfer über ein
> Netzlaufwerk erst mit den Gastmodulen und ebenfalls die schönen
> Grafiktreiber stehen erst damit zur Verfügung.

Das ist schon soweit klar, nur hatte ich gedacht, dass die
Gast-Module - wenn sie denn schon installiert werden - auch immer
die selbe Version haben müssen wie das Hauptprogramm. Auf dem
Windows-Host wird IIRC eine entsprechende Abweichung sogar auch
"angemeckert", so dass zumindest dort das Extension-Pack immer in
der gleichen Version wie das Hauptprogramm installiert ist.

> Allerdings müssen diese Module auf den Kernel abgestimmt sein,
> damit es funktioniert. Daher musst Du diese nachträglich
> installieren. Bei der Installation wird geschaut, dass diese
> Module kompatibel sind. Beim Update kann es dann aber vorkommen,
> dass etwas schief läuft und dann findet der Kernel die Module
> nicht mehr oder sind sind vorhanden, doch nicht in der Version,
> die der Kernel bräuchte.
>
> Damit man das Ganze nicht jedes Mal manuell durchführen muss,
> gibt es DKMS. Das sorgt dafür, dass immer die passenden Module
> für den Kernel geladen werden:
> http://de.wikipedia.org/wiki/Dynamic_Kernel_Module_Support
>
> Daher musst Du prüfen, ob Du DKMS installiert hast. Wenn ja,
> sollte es keine Probleme mit dem Update geben.

Soweit ich das in Octopi gesehen habe, ist DKMS wohl nicht
installiert. Welche der 8 mit dkms im Namen gefundenen Pakete, siehe
auch <http://fraschi.net/temp/dkms.jpg> müsste ich denn dann am
besten noch installieren?

> Wie steht es mit Deinem englisch?

Na ja, so la la ...

> Auf der folgenden Seite gibt es eine Einführung mit vielen
> Tipps: https://wiki.archlinux.org/index.php/VirtualBox
>
> Evtl. kann es sein, dass die Module nach dem Neustart einfach
> nicht direkt geladen werden:
>
> "https://wiki.archlinux.org/index.php/VirtualBox#Load_the_Virtualbox_kernel_modules_2"
>
>
>
> Funktioniert das manuelle Einbinden mit: modprobe -a vboxguest
> vboxsf vboxvideo ohne Fehlermeldung,

Das probiere ich dann ggf. erst später ...

> Ich hoffe, ich habe Dich mit den Informationen nicht erschlagen.
> Ich musste sie auch in meiner 300 Seiten Doku zusammensuchen
> :-)

Nein, nochmals einen ganz großen Dank von mir für diese
Anfänger-Nachhilfe - ich werde schauen, dass ich alles Stück für
Stück ausprobiere.

> Gruss, Markus

Bis dann herzliche Grüße ...

[Helmut Hullen]

Hallo, Franklin,

Du meintest am 14.05.16:

> Ich traue mich ja kaum, es zu schreiben, aber dazu fehlen mir halt
> tatsächlich die Linux-Grundkenntnisse, um zu wissen, wie ich im CLI
> an den Inhalt dieser Logdatei komme. :-( Und dann noch mit diesen
> ganzen vertauschten Tasten ... <grrrr>

Installiere den "Midnight Commander" mc, damit wird vieles einfacher.

Etwaige Ähnlichkeiten mit dem "Norton Commander" sind rein zufällig ...

[Markus Grob]

Franklin Schiftan schrieb:

>
> Markus Grob schrieb am 14.05.2016 um 14:09 Uhr:


> Es wird jetzt allerdings wieder ein Weilchen dauern, bis ich alles
> durchgelesen - auch die Links

Gut. Lesen und Lernen ist wichtig. Mache ich auch so und dies unter
Linux seit 1997 und ich habe das Gefühl, dass ich erst an der Oberfläche
kratze ;-) Kommt wohl davon, dass ich Linux einfach zum "arbeiten"
verwende und daher wenig an der Konfiguration schraube, wenn alles läuft
und das tut es meistens.

> verstanden habe, so dass ich mich auch traue, das eine oder andere
> umzusetzen.

Nur zu. Solange Du keine Konfigurationen speicherst oder Pakete ersetzt,
ist alles nur im Speicher und nach einem Reboot wieder weg.

> durchführen, wenn ich vom jeweils aktuell noch funktionierenden
> Stand (die VM ist ja immerhin rd. 32 GB groß) wieder ein Backup
> habe, auf das ich zurückgreifen kann. Und aus mir nicht mehr ganz
> präsenten Gründen hatte ich mich irgendwann mal dazu entschieden,
> dies nicht mit der Vbox-eigenen Möglichkeit von Sicherungspunkten zu
> machen, sondern im Rahmen meines normalen Gesamt-PC-Backups.

Das mit dem Backup ist zu empfehlen, doch ich würde es kombinieren. Bei
Updates vorher ein Backup und sonst ein Snapshot. Meine VM ist 50GB
gross. Auf dem Backup genügen ja 2 Versionen und bei den heutigen
Preisen reicht 1 Terra ja locker dafür ;-)

> Also bitte nicht wundern, falls es mit weiteren Miss- oder
> Erfolgsmeldungen von meiner Seite aus ein wenig dauert - ich werde
> auf jeden Fall wieder berichten, was ich gemacht habe und was dabei
> herausgekommen ist.

Sehr gut. Infos sind wichtig und die Screenshots helfen, damit man
weniger im Nebel stochern muss ;-)

>> Ich bin mir gerade nicht sicher, doch soviel ich weiss, stimmen
>> die Module nicht für den Kernel überein und werden daher nicht
>> genommen. Es kann auch sein, dass die Kernelheader nicht
>> installiert sind.
>
> Bei der Suche in Octopi habe ich dazu lediglich
> 'kernel-headers-musl' (nicht installiert) gefunden.

Ich kenne Octopi nicht. Ist das der Paketmanager wie Pacman bei Archlinux?

http://askubuntu.com/questions/75709/how-do-i-install-kernel-header-files

> Ich traue mich ja kaum, es zu schreiben, aber dazu fehlen mir halt
> tatsächlich die Linux-Grundkenntnisse, um zu wissen, wie ich im CLI
> an den Inhalt dieser Logdatei komme. :-(

Ganz einfach. Google fragen. Mache ich auch immer wieder. Name der
Datei, ein paar Stichworte und schon weiss man, wo suchen.

> Und dann noch mit diesen
> ganzen vertauschten Tasten ... <grrrr>

Ich zitiere aus "meiner" Doku:

Möchte man die Tastatur auf der Konsole umstellen, so bedient man sich
des Kommandos loadkeys und übergibt danach das gewünschte Layout. Es
handelt sich dabei um das Kürzel der Sprache. Ein paar Beispiele:
de = deutsch
sg = swissgerman
us = us-englisch

Versuche also: loadkeys de

> O.k., dann werde ich dies, 357 minus die vier Update-Pakete, mal als
> nächstes probieren, sobald ich vom aktuellen Stand ein Backup habe.

Sehr gut. Dann schauen wir weiter ;-)

>> Ganz einfach. VB wird ja entwickelt und daher gibt es
>> Fehlerbereinigungen und Erweiterungen.
>
> Ich glaub, da haben wir uns jetzt missverstanden, ich wollte nicht
> den Unterschied zwischen V 5.0.18 zu V 5.0.20 wissen, sondern
> welcher Unterschied zwischen 'virtualbox-guest-utils' und
> 'linux45-virtualbox-guest-modules' besteht ... hört sich halt beides
> recht ähnlich an ...

Ganz einfach. Das Paket guest-utils stellt die Kernelmodule zur Verfügung.

> Das ist schon soweit klar, nur hatte ich gedacht, dass die
> Gast-Module - wenn sie denn schon installiert werden - auch immer
> die selbe Version haben müssen wie das Hauptprogramm.

Muss nicht sein. Wird nur empfohlen nach dem Motto: neuer ist besser.

>> Daher musst Du prüfen, ob Du DKMS installiert hast. Wenn ja,
>> sollte es keine Probleme mit dem Update geben.
>
> Soweit ich das in Octopi gesehen habe, ist DKMS wohl nicht
> installiert. Welche der 8 mit dkms im Namen gefundenen Pakete, siehe
> auch <http://fraschi.net/temp/dkms.jpg> müsste ich denn dann am
> besten noch installieren?

Hm, das bin ich nicht ganz sicher. Das Paket dkms scheint allgemein zu
sein. Evtl. genügt das schon. bei dkms-manjaro könnte es sich um das
Gleiche handeln. Versuche an Hand der Beschreibung herauszufinden, was
die Pakete machen wollen. Evtl. ist auch das guest-dkms sinnvoll. Die
anderen brauchst Du nicht. Falls sich die Pakete nicht beissen, kannst
Du diese drei installieren.

>> Wie steht es mit Deinem englisch?
>
> Na ja, so la la ...

Wenn Du dem Text auf den Linkseiten folgen kannst, dann ist gut, sonst
nachfragen oder schauen, ob es eine übersetzte Version gibt.

>> Funktioniert das manuelle Einbinden mit: modprobe -a vboxguest
>> vboxsf vboxvideo ohne Fehlermeldung,
>
> Das probiere ich dann ggf. erst später ...

Das kannst Du ohne Probleme machen. Gibt höchstens eine Fehlermeldung,
wenn er die Pakete nicht findet.

> Nein, nochmals einen ganz großen Dank von mir für diese
> Anfänger-Nachhilfe - ich werde schauen, dass ich alles Stück für
> Stück ausprobiere.

Bitte. Man hilft gerne, wenn es angewendet wird ;-)

Gruss, Markus

[Franklin Schiftan]

Markus Grob schrieb am 14.05.2016 um 18:43 Uhr:

>> Bei der Suche in Octopi habe ich dazu lediglich
>> 'kernel-headers-musl' (nicht installiert) gefunden.
>
> Ich kenne Octopi nicht. Ist das der Paketmanager wie Pacman bei Archlinux?

Ähm, ja, ich glaube zusätzlich zu Pacman mit der einen oder anderen
weiteren Möglichkeit ... aber man kann wohl beides je nach Vorliebe
nutzen.

>> O.k., dann werde ich dies, 357 minus die vier Update-Pakete, mal als
>> nächstes probieren, sobald ich vom aktuellen Stand ein Backup habe.
>
> Sehr gut. Dann schauen wir weiter ;-)

Sch... -> negativ ... die gleichen Fehler wie vorher:
<http://fraschi.net/temp/vbox_fehler_01.jpg>
<http://fraschi.net/temp/vbox_fehler_02.jpg>
<http://fraschi.net/temp/vbox_fehler_03.jpg>

>> Das ist schon soweit klar, nur hatte ich gedacht, dass die
>> Gast-Module - wenn sie denn schon installiert werden - auch immer
>> die selbe Version haben müssen wie das Hauptprogramm.
>
> Muss nicht sein. Wird nur empfohlen nach dem Motto: neuer ist besser.

Hmm, bei den jetzigen Meldungen nach 'journalctl -xb' gab es einige
Zeilen (siehe ersten Screenshot) mit 'vboxguest: disagrees about
version of ...', welches mir so ausschaut, als ob diesbezüglich wohl
doch nicht alles so passt.

>>> Funktioniert das manuelle Einbinden mit: modprobe -a vboxguest
>>> vboxsf vboxvideo ohne Fehlermeldung,
>>
>> Das probiere ich dann ggf. erst später ...
>
> Das kannst Du ohne Probleme machen. Gibt höchstens eine Fehlermeldung,
> wenn er die Pakete nicht findet.

Hat auch nicht funktioniert 'could not insert .... Exec format
error' für alle drei Module. :-(

Ich fürchte, der Fall ist zu kompliziert ... Dumm ist halt, dass zum
einen auch jedes Mal das Backup (mit packen, spart immerhin 10 GB)
rd. 'ne halbe Stunde braucht und dass auch der Download der 1 GB
Update-Pakete nach Wiederherstellung des alten Zustandes hier an der
lahmen 2000er-Leitung ebenfalls mindestens solange braucht.

> Bitte. Man hilft gerne, wenn es angewendet wird ;-)

:-)

> Gruss, Markus

[Gunter Gutzeit]

Franklin Schiftan schrieb am Sa 14.05.2016 22:22:14 +0200:

>
> Markus Grob schrieb am 14.05.2016 um 18:43 Uhr:
>
>>> Bei der Suche in Octopi habe ich dazu lediglich
>>> 'kernel-headers-musl' (nicht installiert) gefunden.
>>
>> Ich kenne Octopi nicht. Ist das der Paketmanager wie Pacman bei Archlinux?
>
> Ähm, ja, ich glaube zusätzlich zu Pacman mit der einen oder anderen
> weiteren Möglichkeit ... aber man kann wohl beides je nach Vorliebe
> nutzen.

Octopi bietet auch für Manjaro eine gute graphische Oberfläche für
Pacman und Yaourt. Kann auch mit einem Notifier installiert werden.

Meines Erachtens sehr empfehlenswert auch was die Suche, Installation
oder Deinstallation geeigneter Packages angeht.

https://wiki.manjaro.org/index.php?title=Octopi

[Franklin Schiftan]

Markus Grob schrieb am 14.05.2016 um 18:43 Uhr:

>> O.k., dann werde ich dies, 357 minus die vier Update-Pakete, mal als
>> nächstes probieren, sobald ich vom aktuellen Stand ein Backup habe.
>
> Sehr gut. Dann schauen wir weiter ;-)

Ich hatte ja vorgestern Abend schon von diesem Misserfolg berichtet,
Message-ID: <dppfnt...@mid.individual.net>.
Inzwischen hatte ich von den mittlerweile 382 Update-Paketen
<http://fraschi.net/temp/manjaro_updates_20160516.html> bzw.
<http://fraschi.net/temp/manjaro_updates_20160516.rtf>
zum einen ca. die Hälfte der Updates, in der alphabetischen Liste
von 'A' bis 'K', und danach auch noch mal eine noch kleinere Menge,
nämlich die Pakete 'A' bis 'J' - ich weiß, diese Auswahl war völlig
willkürlich, da ich aber keine Ahnung habe, wäre alles andere auch
nur ein Rumstochern im Nebel gewesen - installiert.

Ergebnis dieser beiden Teil-Update-Versuche (die halt jedesmal mit
Download und Wiederherstellen des Ausgangszustandes rd. zwei Stunden
dauerten) war, dass die Manjaro-VM zwar ohne Fehlermeldung wie
gewohnt gestartet ist, auch das Fenster die übliche Größe annahm
[hatte mich schon gefreut], danach aber der Bildschirm bei
rotierender "Sanduhr" schwarz blieb und nicht wie erwartet der
Manjaro-Willkommens-Bildschirm mit der Passwort-Eingabemöglichkeit
erschien ... schade ...

Ich könnte jetzt natürlich auch noch beliebige andere Kombinationen
von Updates durchprobieren (wobei die Auswahl wie gesagt immer nur
völlig willkürlich erfolgen könnte), aber ich glaube, dass das nicht
wirklich zielführend ist, zumal ja alle paar Tage auch wieder neue
Update-Pakete hinzu kommen.

> Gruss, Markus

[Gunter Gutzeit]

Franklin Schiftan schrieb am Mo 16.05.2016 08:57:36 +0200:

> Ergebnis dieser beiden Teil-Update-Versuche (die halt jedesmal mit
> Download und Wiederherstellen des Ausgangszustandes rd. zwei Stunden

> dauerten) [...]

Mein Hochachtung für diese Fleißarbeit ...

> Ich könnte jetzt natürlich auch noch beliebige andere Kombinationen
> von Updates durchprobieren (wobei die Auswahl wie gesagt immer nur
> völlig willkürlich erfolgen könnte), aber ich glaube, dass das nicht
> wirklich zielführend ist, zumal ja alle paar Tage auch wieder neue
> Update-Pakete hinzu kommen.

Du beginnst zu begreifen, dass die Virtualbox für das Austesten von
Rolling-Release-Linuxen nur bedingt tauglich ist (für einen
Langzeittest m.E. wohl eher nicht) ...

--
Gruß
Gunter
gepostet aus Manjaro-Linux@32BitPc4GbRAM

[Franklin Schiftan]

Hmm, und was wäre jetzt Deiner Meinung nach sinnvoller? Statt VBox
einen anderen Virtualisierer verwenden (falls ja, welchen?)? Oder
unter VBox eine andere Distribution nehmen (wobei es mir als
windows-gewohnter Linux-Neuling damals unter allen ausprobierten
Linuxen Manjaro schon am einfachsten gemacht hat)? Auf jeden Fall
meine bisherigen Update-Versuche mit der Manjaro-VBox-VM aufgeben,
einfach alle angebotenen Updates künftig ignorieren und auf dem
aktuellen und funktionierenden Stand belassen?

[Markus Grob]

Franklin Schiftan schrieb:

>
> Markus Grob schrieb am 14.05.2016 um 18:43 Uhr:

>> Ich kenne Octopi nicht. Ist das der Paketmanager wie Pacman bei Archlinux?
>
> Ähm, ja, ich glaube zusätzlich zu Pacman mit der einen oder anderen
> weiteren Möglichkeit ... aber man kann wohl beides je nach Vorliebe
> nutzen.

Auf den Rest gehe ich ein, wenn ich mehr Zeit habe. Muss jetzt Fische
braten ;-)

Evtl. könnte es sein, dass Octopi Meldungen unterschlägt, die man mit
Pacman zu sehen bekäme, falls ein Paket diese meldet. Das hatte ich
unter Suse auch schon mit yast und zypper.
Lies Dich doch mal kurz in die Bedienung von Pacman ein und dann update
paketweise.
Der Ansatz mit A-x war nicht schlecht. Welche grafische
Benutzeroberfläche verwendest Du? Es kann natürlich dort auch zu
weiteren Problemen kommen.
Kannst Du nach dem Start mit der Sanduhr auf eine Konsole wechseln
(Ctrl-Alt-F1) oder steht der Rechner?

Gruss, Markus

[Peter Köhlmann]

Franklin Schiftan wrote:

>
>
> Gunter Gutzeit schrieb am 16.05.2016 um 11:38 Uhr:
>
>> Franklin Schiftan schrieb am Mo 16.05.2016 08:57:36 +0200:
>>
>>> Ergebnis dieser beiden Teil-Update-Versuche (die halt jedesmal mit
>>> Download und Wiederherstellen des Ausgangszustandes rd. zwei Stunden
>>> dauerten) [...]
>>
>> Mein Hochachtung für diese Fleißarbeit ...
>>
>>> Ich könnte jetzt natürlich auch noch beliebige andere Kombinationen
>>> von Updates durchprobieren (wobei die Auswahl wie gesagt immer nur
>>> völlig willkürlich erfolgen könnte), aber ich glaube, dass das nicht
>>> wirklich zielführend ist, zumal ja alle paar Tage auch wieder neue
>>> Update-Pakete hinzu kommen.
>>
>> Du beginnst zu begreifen, dass die Virtualbox für das Austesten von
>> Rolling-Release-Linuxen nur bedingt tauglich ist (für einen
>> Langzeittest m.E. wohl eher nicht) ...
>
> Hmm, und was wäre jetzt Deiner Meinung nach sinnvoller? Statt VBox
> einen anderen Virtualisierer verwenden (falls ja, welchen?)? Oder
> unter VBox eine andere Distribution nehmen (wobei es mir als
> windows-gewohnter Linux-Neuling damals unter allen ausprobierten
> Linuxen Manjaro schon am einfachsten gemacht hat)?

Kann ich mir nicht so recht vorstellen.
Ubuntu ist garantiert Einsteiger-freundlicher. Oder OpenSuse.
Letztere habe ich auch in virtuellen Machinen laufen und diverse Male ohne
Probleme upgedated

[Wolfgang Bauer]

Franklin Schiftan schrieb:

> Gunter Gutzeit schrieb am 16.05.2016 um 11:38 Uhr:

>> Du beginnst zu begreifen, dass die Virtualbox für das Austesten von
>> Rolling-Release-Linuxen nur bedingt tauglich ist (für einen
>> Langzeittest m.E. wohl eher nicht) ...
>
> Hmm, und was wäre jetzt Deiner Meinung nach sinnvoller? Statt VBox
> einen anderen Virtualisierer verwenden (falls ja, welchen?)?

Meine unmaßgebliche Meinung:
Für jedes System *eine* SSD/HD im Wechselrahmen.

ICY BOX
IB-2227StS
Wechselrahmen für 2x 2,5" (6,35 cm) HDD und SSD
ca. € 34

ICY BOX
IB-148SSK-B
Wechselrahmen für 3,5" (8,89 cm) und 2,5" (6,35 cm) SATA/SAS Festplatten
ca. € 46

Der Einschub von 2 Platten ermöglicht auch den Datenaustausch.

Wolfgang

--
Arthur Schopenhauer

Natürlicher Verstand kann fast jeden Grad von Bildung ersetzen,
aber keine Bildung den natürlichen Verstand.
Arthur Schopenhauer

[Franklin Schiftan]

Peter Köhlmann schrieb am 16.05.2016 um 13:30 Uhr:

>> unter VBox eine andere Distribution nehmen (wobei es mir als
>> windows-gewohnter Linux-Neuling damals unter allen ausprobierten
>> Linuxen Manjaro schon am einfachsten gemacht hat)?
>
> Kann ich mir nicht so recht vorstellen.
> Ubuntu ist garantiert Einsteiger-freundlicher.

Hmm, unter dem damals ausprobierten Lubuntu konnte ich jedenfalls -
um mal nur ein Beispiel zu nennen - nicht so einfach per Mausklick
mein gewünschtes Datum-/Zeit-Format im Systray einstellen.

> Oder OpenSuse.
> Letztere habe ich auch in virtuellen Machinen laufen und diverse Male ohne
> Probleme upgedated

Die Manjaro-Updates liefen hier in den vergangenen zwei Jahren - und
das waren üblicherweise pro Woche 50 bis 100 Pakete - (bis auf eine
vorübergehende Inkonsistenz mit OpenXP, die inzwischen dort behoben
wurde) auch immer problemlos über die Bühne.

[Franklin Schiftan]

Wolfgang Bauer schrieb am 16.05.2016 um 14:00 Uhr:

> Franklin Schiftan schrieb:
>> Gunter Gutzeit schrieb am 16.05.2016 um 11:38 Uhr:
>
>>> Du beginnst zu begreifen, dass die Virtualbox für das Austesten von
>>> Rolling-Release-Linuxen nur bedingt tauglich ist (für einen
>>> Langzeittest m.E. wohl eher nicht) ...
>>
>> Hmm, und was wäre jetzt Deiner Meinung nach sinnvoller? Statt VBox
>> einen anderen Virtualisierer verwenden (falls ja, welchen?)?
>
> Meine unmaßgebliche Meinung:
> Für jedes System *eine* SSD/HD im Wechselrahmen.

Mein Arbeitsrechner ist ein Laptop ... da wird das etwas schwierig.
Aber klar, das aktuelle Problem mit den VirtualBox-Guest-Modulen
hätte ich dann natürlich nicht gehabt.

[Markus Grob]

Franklin Schiftan schrieb:

> Sch... -> negativ ... die gleichen Fehler wie vorher:
> <http://fraschi.net/temp/vbox_fehler_01.jpg>
> <http://fraschi.net/temp/vbox_fehler_02.jpg>
> <http://fraschi.net/temp/vbox_fehler_03.jpg>

Die Module stimmen nicht mit dem Kernel überein. Versuch es bitte mit
einem Snapshot. Der Vorteil ist, dass Du da schnell zwischen
verschiedenen Zuständen umschalten kannst. Vor allem auch mit try and
error oder schrittweisem Vorgehen. Paket installieren, testen, weiter
oder zurück.

>>> Das ist schon soweit klar, nur hatte ich gedacht, dass die
>>> Gast-Module - wenn sie denn schon installiert werden - auch immer
>>> die selbe Version haben müssen wie das Hauptprogramm.
>>
>> Muss nicht sein. Wird nur empfohlen nach dem Motto: neuer ist besser.
>
> Hmm, bei den jetzigen Meldungen nach 'journalctl -xb' gab es einige
> Zeilen (siehe ersten Screenshot) mit 'vboxguest: disagrees about
> version of ...', welches mir so ausschaut, als ob diesbezüglich wohl
> doch nicht alles so passt.

Dort fehlt mir leider die ganze Meldung, doch ich vermute, dass es nicht
an der Version der Gastmodule liegt, sondern an der Version des Kernels
und den kompilierten Modulen, so dass der Kernel diese nicht laden kann.
Dies ist unabhängig von der Version der Gastmodule mit der Version des
Hosts.

>>>> Funktioniert das manuelle Einbinden mit: modprobe -a vboxguest
>>>> vboxsf vboxvideo ohne Fehlermeldung,
>>>
>>> Das probiere ich dann ggf. erst später ...
>>
>> Das kannst Du ohne Probleme machen. Gibt höchstens eine Fehlermeldung,
>> wenn er die Pakete nicht findet.
>
> Hat auch nicht funktioniert 'could not insert .... Exec format
> error' für alle drei Module. :-(

Dann stimmen die Module nicht zum Kernel. Das heisst, hier liegt das
Problem. Versuch daher, die vboxguestadditions nochmals auszuführen und
beim Fehler das Logbuch anzuschauen.
Hast DU unterdessen die Kernelheader installiert?

> Ich fürchte, der Fall ist zu kompliziert ...

Nö. Kompliziert ja, da leider sehr individuell und nicht von jedem
angewendet, doch zu kompliziert kann es nicht geben ;-)

> einen auch jedes Mal das Backup (mit packen, spart immerhin 10 GB)
> rd. 'ne halbe Stunde braucht und dass auch der Download der 1 GB
> Update-Pakete nach Wiederherstellung des alten Zustandes hier an der
> lahmen 2000er-Leitung ebenfalls mindestens solange braucht.

Daher empfehle ich das Snapshot. Die Punkte kannst Du nach den Versuchen
löschen oder halt wieder zurückgehen. Ist schnell und einfach und bis
jetzt hatte ich damit kaum Probleme.

Gruss, Markus

[Wolfgang Bauer]

Franklin Schiftan schrieb:

Es gibt auch externe Wechselrahmen mit USB Anschluß.

Wolfgang

--
Ohne Vergangenheit und ohne Gegenwart gäbe es auch keine Zukunft.
Deshalb gilt es, die Vergangenheit zu bewahren, die Gegenwart zu leben
und die Zukunft zu gestalten.
Wolfgang Kownatka

[Gunter Gutzeit]

Franklin Schiftan schrieb am Mo 16.05.2016 13:17:44 +0200:

> Hmm, und was wäre jetzt Deiner Meinung nach sinnvoller? Statt VBox
> einen anderen Virtualisierer verwenden (falls ja, welchen?)? Oder
> unter VBox eine andere Distribution nehmen (wobei es mir als
> windows-gewohnter Linux-Neuling damals unter allen ausprobierten
> Linuxen Manjaro schon am einfachsten gemacht hat)? Auf jeden Fall
> meine bisherigen Update-Versuche mit der Manjaro-VBox-VM aufgeben,
> einfach alle angebotenen Updates künftig ignorieren und auf dem
> aktuellen und funktionierenden Stand belassen?

Also was der Markus da zu den Themen Virtualbox und Manjaro schreibt ist
wirklich erste Sahne :-)

Vielleicht kommst Du damit ja ans Ziel :-) immerhin verfügst Du über
einen leistungsstarken Rechner.

1.
Ich habe die Virtualbox mal mit Mint betrieben - war echt easy. Das ist
mit Arch/Manjaro leider nicht ganz so einsteigerfreundlich.

2.
Ich arbeite hier mit ziemlich leistungsschwacher Hardware und die
Virtualbox kann auch ziemlich ressourcen-hungrig und langsam werden.

3.
Die Kernel-Module der Virtualbox haben bei meinem Manjaro nach gewissen
Regel-Updates auch schon mal Probleme verursacht (sowohl innerhalb
als auch außerhalb der Box).

4.
Ein Rolling-Release-Linux ist kein statisches Linux mehr - Du hast
praktisch nach jedem Regel-Update (bei Manjaro i.d.R. wöchentlich - bei
Arch i.d.R. täglich) ein neues Linux. Snapshots helfen hier nur
wirklich, wenn im Nachhinein nicht zu viele Updates "aufgelaufen"
sind.

5.
Keep It Simple - Ich persönlich bemühe mich, mein Manjaro so einfach
wie möglich zu halten, dass heisst: nur einfache Komponenten und
möglichst kleine Programme zu installieren, die ich wirklich brauche.
Die Reduktion der Komplexität ist nicht nur wichtig für einen geringen
Ressourcenverbrauch, sondern auch dann, wenn Du eine weniger
umfangreiche Update-Listen abarbeiten musst. Das geht dann einfach
schneller und vermindert die Fehleranfälligkeit des Gesamtsystems.
Ein Rolling-Release-Linux ist technisch eine ziemlich komplexe
Angelegenheit.

6.
Nun, wenn Du künftig die Updates einfach ignorierst, wäre das
sicherlich die schlechteste Lösung. Schließlich willst Du ja
fortwährend ein möglichst aktuelles und sicheres Linux haben. Trotzdem
halte ich es über kurz oder lang für wichtig, sich mit dem
(vorübergehenden) "Downgrade" einzelner Pakete und dem (vorübergehenden)
"Einfrieren" einzelner Pakete vertraut zu machen. Es kann vorkommen,
dass es keine andere Lösung gibt.

7.
In vielen (leichten) Problem-Fällen kann es aber in der Tat schon mal
das beste sein - das weiß ich auch von Nutzern anderer
Rolling-Release-Systeme - erst einmal gar nichts zu tun. Oftmals wird
ein eingeschlichener "echter" Bug bei den nächsten Regel-Updates
ausgebügelt.

8.
Wenn ich selbst mal sicherheitskritische Dinge mit meinem Manjaro
ausprobieren will, bei dem ich nicht weiß, ob mein Manjaro danach noch
funktioniert, mache ich dies am liebsten, in dem ich das im Augenblick
aktuelle Manjaro clone. Der Clone ist sofort aktuell und schneller
verfügbar als ein umständlich in einer Virtualbox installiertes
Manjaro-System, welches sich dann ja auch noch einmal updaten muss.
Außerdem stehen mir so immer 100% RAM meines Systems zur Verfügung. Die
Langzeitauswirkungen der durchgeführten Manipulationen lassen sich so
in einem Parallel-Betrieb (einschließlich folgender Regel-Updates) über
eine längeren Zeitraum gefahrlos in einem wirklichen Echt-Betrieb m.E.
am Besten beobachten.

9.
Alles das schließt aber nicht aus, dass ich in der Zukunft - wenn ich
die Zeit dazu finde - auch einmal qemu ausprobieren werde.

[Franklin Schiftan]

Markus Grob schrieb am 16.05.2016 um 15:15 Uhr:

> Franklin Schiftan schrieb:
>> Sch... -> negativ ... die gleichen Fehler wie vorher:
>> <http://fraschi.net/temp/vbox_fehler_01.jpg>
>> <http://fraschi.net/temp/vbox_fehler_02.jpg>
>> <http://fraschi.net/temp/vbox_fehler_03.jpg>
>
> Die Module stimmen nicht mit dem Kernel überein. Versuch es bitte mit
> einem Snapshot. Der Vorteil ist, dass Du da schnell zwischen
> verschiedenen Zuständen umschalten kannst. Vor allem auch mit try and
> error oder schrittweisem Vorgehen. Paket installieren, testen, weiter
> oder zurück.

O.k., das habe ich jetzt mal so angefangen ... aber auch da kann ich
ja - mangels besserem Wissen - leider nur die alphabetische Liste
der Reihe nach installieren.

>>>>> Funktioniert das manuelle Einbinden mit: modprobe -a vboxguest
>>>>> vboxsf vboxvideo ohne Fehlermeldung,
>>>>
>>>> Das probiere ich dann ggf. erst später ...
>>>
>>> Das kannst Du ohne Probleme machen. Gibt höchstens eine Fehlermeldung,
>>> wenn er die Pakete nicht findet.
>>
>> Hat auch nicht funktioniert 'could not insert .... Exec format
>> error' für alle drei Module. :-(
>
> Dann stimmen die Module nicht zum Kernel. Das heisst, hier liegt das
> Problem. Versuch daher, die vboxguestadditions nochmals auszuführen und
> beim Fehler das Logbuch anzuschauen.
> Hast DU unterdessen die Kernelheader installiert?

Mit dem Begriff 'kernel-headers' im Namen gab es wie gesagt nur
dieses eine Paket 'kernel-headers-musl' (nicht installiert). Mit
'headers' im Namen gibt es noch diverse (nicht installierte) Pakete
namens 'linux..-headers', wobei die zwei Punkte für die
verschiedenen Kernel-Versionen stehen.
Installiert ist hier das Paket 'linux-api-headers', Kernel headers
sanitized for use in userspace. Keine Ahnung, ob das ausreicht.

>> Ich fürchte, der Fall ist zu kompliziert ...
>
> Nö. Kompliziert ja, da leider sehr individuell und nicht von jedem
> angewendet, doch zu kompliziert kann es nicht geben ;-)

[Franklin Schiftan]

Markus Grob schrieb am 16.05.2016 um 15:15 Uhr:

> Dann stimmen die Module nicht zum Kernel. Das heisst, hier liegt
> das Problem. Versuch daher, die vboxguestadditions nochmals
> auszuführen und beim Fehler das Logbuch anzuschauen.

Das tat ich nun ... d.h. nein, vorher hatte ich noch die vier
dkms-Pakete installiert ... aber nach der Ausführung von sudo
./VBoxLinuxAdditions.run erhielt ich wieder die gleichen Meldungen
wie letztens mit dem 'failed' in der vorletzten Zeile.

Aus zwei Log-Dateien:

VBoxGuestAdditions.log:
./vboxadd: Zeile 553: /sbin/rcvboxadd-x11: Datei oder Verzeichnis
nicht gefunden

vboxadd-install.log:
Uninstalling modules from DKMS
Attempting to install using DKMS

Creating symlink /var/lib/dkms/vboxguest/5.0.20/source ->
/usr/src/vboxguest-5.0.20

DKMS: add completed.
Error! echo
Your kernel headers for kernel 4.5.2-1-MANJARO cannot be found at
/usr/lib/modules/4.5.2-1-MANJARO/build or
/usr/lib/modules/4.5.2-1-MANJARO/source.
Failed to install using DKMS, attempting to install without
/tmp/vbox.0/Makefile.include.header:115: *** Error: unable to find
the include directory for your current Linux kernel. Specify
KERN_INCL=<directory> and run Make again. Schluss.
Creating user for the Guest Additions.
Creating udev rule for the Guest Additions kernel module.

> Hast DU unterdessen die Kernelheader installiert?

Offensichtlich scheint dieses installierte Paket 'linux-api-headers'
nicht auszureichen ... vielleicht probiere ich einfach mal, das
Paket 'linux45-headers' auch noch zu installieren ...>

[Franklin Schiftan]

Franklin Schiftan schrieb am 16.05.2016 um 20:00 Uhr:

> Markus Grob schrieb am 16.05.2016 um 15:15 Uhr:
>
>> Dann stimmen die Module nicht zum Kernel. Das heisst, hier liegt
>> das Problem. Versuch daher, die vboxguestadditions nochmals
>> auszuführen und beim Fehler das Logbuch anzuschauen.
>
> Das tat ich nun ... d.h. nein, vorher hatte ich noch die vier
> dkms-Pakete installiert ... aber nach der Ausführung von sudo

> ../VBoxLinuxAdditions.run erhielt ich wieder die gleichen Meldungen

> wie letztens mit dem 'failed' in der vorletzten Zeile.

Und beim anschließenden Boot-Versuch landete ich wieder nur auf dem CLI.

>> Hast DU unterdessen die Kernelheader installiert?
>
> Offensichtlich scheint dieses installierte Paket 'linux-api-headers'
> nicht auszureichen ... vielleicht probiere ich einfach mal, das
> Paket 'linux45-headers' auch noch zu installieren ...>

Wenn ich nur die dkms-Pakete und linux45-headers installiere, sehe
ich zwar kurz beim Bootvorgang wieder diese Meldung 'Failed starting
load kernel modules', aber ich komme trotzdem noch ganz normal auf
die Maschine und kann mich einloggen etc.

Sobald ich aber die VBoxLinuxAddition.run ausführe, erhalte ich
wieder den bekannten Fehler
<http://fraschi.net/temp/vbox_run_02.jpg> und lande anschließend
wieder nur im CLI. :-(

[Franklin Schiftan]

Gunter Gutzeit schrieb am 16.05.2016 um 15:23 Uhr:

> Franklin Schiftan schrieb am Mo 16.05.2016 13:17:44 +0200:
>
>> Hmm, und was wäre jetzt Deiner Meinung nach sinnvoller? Statt
>> VBox einen anderen Virtualisierer verwenden (falls ja,
>> welchen?)? Oder unter VBox eine andere Distribution nehmen
>> (wobei es mir als windows-gewohnter Linux-Neuling damals unter
>> allen ausprobierten Linuxen Manjaro schon am einfachsten
>> gemacht hat)? Auf jeden Fall meine bisherigen Update-Versuche
>> mit der Manjaro-VBox-VM aufgeben, einfach alle angebotenen
>> Updates künftig ignorieren und auf dem aktuellen und
>> funktionierenden Stand belassen?
>
> Also was der Markus da zu den Themen Virtualbox und Manjaro
> schreibt ist wirklich erste Sahne :-)

Ja, und ich bin Euch beiden auch ganz dankbar, dass ihr Euch so um
die Beseitigung des Problemes hier kümmert!

> Vielleicht kommst Du damit ja ans Ziel :-) immerhin verfügst Du
> über einen leistungsstarken Rechner.
>

> 3. Die Kernel-Module der Virtualbox haben bei meinem Manjaro nach
> gewissen Regel-Updates auch schon mal Probleme verursacht (sowohl
> innerhalb als auch außerhalb der Box).

Hmm, und wie hattest Du das dann jeweils lösen können?

> 4. Ein Rolling-Release-Linux ist kein statisches Linux mehr - Du
> hast praktisch nach jedem Regel-Update (bei Manjaro i.d.R.
> wöchentlich - bei Arch i.d.R. täglich) ein neues Linux. Snapshots
> helfen hier nur wirklich, wenn im Nachhinein nicht zu viele
> Updates "aufgelaufen" sind.
>
> 5. Keep It Simple - Ich persönlich bemühe mich, mein Manjaro so
> einfach wie möglich zu halten, dass heisst: nur einfache
> Komponenten und möglichst kleine Programme zu installieren, die
> ich wirklich brauche. Die Reduktion der Komplexität ist nicht nur
> wichtig für einen geringen Ressourcenverbrauch, sondern auch
> dann, wenn Du eine weniger umfangreiche Update-Listen abarbeiten
> musst. Das geht dann einfach schneller und vermindert die
> Fehleranfälligkeit des Gesamtsystems.

Schon klar ... ich hatte eigentlich seit dem damals fertigen ISO von
der COM! zum Ausprobieren nur ganz wenige Programme installiert,
weil ich insbesondere wieder ein funktionierendes Crosspoint-Derivat
haben wollte, um mit der bis dahin genutzten 16-bit-Version nicht
mehr auf mein 32-bittiges WinXP angewiesen zu sein. Ansonsten liefen
eigentlich immer nur die wöchentlichen Updates durch - und das rd.
zwei Jahre lang im wesentlichen auch problemlos.

> Ein Rolling-Release-Linux ist technisch eine ziemlich komplexe
> Angelegenheit.
>
> 6. Nun, wenn Du künftig die Updates einfach ignorierst, wäre das
> sicherlich die schlechteste Lösung. Schließlich willst Du ja
> fortwährend ein möglichst aktuelles und sicheres Linux haben.
> Trotzdem halte ich es über kurz oder lang für wichtig, sich mit
> dem (vorübergehenden) "Downgrade" einzelner Pakete und dem
> (vorübergehenden) "Einfrieren" einzelner Pakete vertraut zu
> machen. Es kann vorkommen, dass es keine andere Lösung gibt.

Ja, das eine oder andere Paket steht hier auch schon auf der
Pacman-Ignore-List ... ;-)

> 8. Wenn ich selbst mal sicherheitskritische Dinge mit meinem
> Manjaro ausprobieren will, bei dem ich nicht weiß, ob mein
> Manjaro danach noch funktioniert, mache ich dies am liebsten, in
> dem ich das im Augenblick aktuelle Manjaro clone.

Das heißt doch aber, dass Du Dein Manjaro nicht in einer virtuellen
Maschine betreibst? Oder lese ich das gerade falsch?

> Der Clone ist sofort aktuell und schneller verfügbar als ein
> umständlich in einer Virtualbox installiertes Manjaro-System,
> welches sich dann ja auch noch einmal updaten muss. Außerdem
> stehen mir so immer 100% RAM meines Systems zur Verfügung. Die
> Langzeitauswirkungen der durchgeführten Manipulationen lassen
> sich so in einem Parallel-Betrieb (einschließlich folgender
> Regel-Updates) über eine längeren Zeitraum gefahrlos in einem
> wirklichen Echt-Betrieb m.E. am Besten beobachten.
>
> 9. Alles das schließt aber nicht aus, dass ich in der Zukunft -
> wenn ich die Zeit dazu finde - auch einmal qemu ausprobieren
> werde.

Danke auch Dir für Deine interessanten Ausführungen.

[Gunter Gutzeit]

Franklin Schiftan schrieb am Mo 16.05.2016 20:37:25 +0200:

> Gunter Gutzeit schrieb am 16.05.2016 um 15:23 Uhr:

>> Die Kernel-Module der Virtualbox haben bei meinem Manjaro nach
>> gewissen Regel-Updates auch schon mal Probleme verursacht (sowohl
>> innerhalb als auch außerhalb der Box).
>
> Hmm, und wie hattest Du das dann jeweils lösen können?

1.
Einmal musste ich das Zusatz-Modul aus dem AUR downgraden, weil die
Arch-Linux-Leute mit ihrem Upate schneller fertig waren, als die
Manjaro-Linux-Leute mit ihren Haupt-Paketen. In der Zwischenzeit konnte
ich die Virtualbox dann normal in der alten Version weiter nutzen. Als
sich dann die Manjaro-Updates installiert hatten, habe ich das neue
Zusatz-Paket aus dem Cache händisch wieder geupdatet, so dass alle
Virtualbox-Packete die neue gleiche Version hatten. Und alles lief
danach ohne Probleme.

2.
Aber bei meinem letzten Kernel-Typ-Austausch von 4.1... nach 4.4...
verhielten sich die Virtualbox-Kernel-Module etwas komisch.
Schließlich lief bei mir nichts mehr und mein System ließ sich nicht
mehr booten (Kernel-Panik). Aber irgendwie habe ich es dann doch
geschafft, mit dem alten nicht mehr installierten Kernel das System ohne
graphische Oberfläche in einem absicherten Modus wieder zu starten.
Zuerst habe ich dann einmal die Virturalbox komplett deinstalliert und
den alten Kernel-Typ wieder installiert.

Inzwischen habe ich den Kernel-Austausch von 4.1... nach 4.5...
vollzogen. Das System läuft wieder wie geölt und die Virtualbox habe
ich bisher nicht mehr wieder installiert.

>> [...] Die Reduktion der Komplexität ist nicht nur

>> wichtig für einen geringen Ressourcenverbrauch, sondern auch
>> dann, wenn Du eine weniger umfangreiche Update-Listen abarbeiten
>> musst. Das geht dann einfach schneller und vermindert die
>> Fehleranfälligkeit des Gesamtsystems.
>
> Schon klar ... ich hatte eigentlich seit dem damals fertigen ISO von
> der COM! zum Ausprobieren nur ganz wenige Programme installiert,
> weil ich insbesondere wieder ein funktionierendes Crosspoint-Derivat
> haben wollte, um mit der bis dahin genutzten 16-bit-Version nicht
> mehr auf mein 32-bittiges WinXP angewiesen zu sein. Ansonsten liefen
> eigentlich immer nur die wöchentlichen Updates durch - und das rd.
> zwei Jahre lang im wesentlichen auch problemlos.

Ja, meine älteste Manjaro-Installation ist inzwischen auch schon 2
Jahre alt und ich wundere mich darüber, dass das Ding immer noch läuft,
wenn man bedenkt, was ich dem schon alles zugemutet habe.

Wenn es um die Zuverlässigkeit von Büroanwendungen geht, verlasse ich
mich aber lieber auf mein altbewährtes Puppy-Linux. Bei einem
Rolling-Release-Linux weiß man am Ende eines Updates nie, welche
Programme oder selbst erstellten Skripte nach einem Update noch
funktionieren wie gewohnt oder wo es wieder was zu schrauben gibt :-)

Da, wo es auf die Aktualität der Programme an kommt (Internet,
Multimedia, Sicherheit) ist Manjaro aber wirklich sehr gut!

>> [...] Schließlich willst Du ja

>> fortwährend ein möglichst aktuelles und sicheres Linux haben.
>> Trotzdem halte ich es über kurz oder lang für wichtig, sich mit
>> dem (vorübergehenden) "Downgrade" einzelner Pakete und dem
>> (vorübergehenden) "Einfrieren" einzelner Pakete vertraut zu
>> machen. Es kann vorkommen, dass es keine andere Lösung gibt.
>
> Ja, das eine oder andere Paket steht hier auch schon auf der
> Pacman-Ignore-List ... ;-)

Wenn man ein Betriebssystem schon 2 Jahre benutzt, kennt man sich doch
schon etwas damit aus ;-) und man weiß, was man an so einem "Exoten"
hat, da mögen andere Linux-Experten sich noch sehr darüber lustig
machen :-)

>> Wenn ich selbst mal sicherheitskritische Dinge mit meinem
>> Manjaro ausprobieren will, bei dem ich nicht weiß, ob mein
>> Manjaro danach noch funktioniert, mache ich dies am liebsten, in
>> dem ich das im Augenblick aktuelle Manjaro clone.
>
> Das heißt doch aber, dass Du Dein Manjaro nicht in einer virtuellen
> Maschine betreibst?

Das ist völlig richtig. Obwohl ich die Virtualbox in Manjaro anfangs
auch dafür gebraucht habe, darin Manjaro zu installieren, um zu sehen,
wie sich Manjaro seinerseits in der Virtualbox verhält und um zu
schauen, welche Guest- und Host-Module, wo und an welcher Stelle
installiert werden.

[Franklin Schiftan]

Martin Schnitkemper schrieb am 16.05.2016 um 20:56 Uhr:

> Am Montag, 16.05.2016 20:00 schrieb Franklin Schiftan:
>
>> Das tat ich nun ... d.h. nein, vorher hatte ich noch die vier
>> dkms-Pakete installiert ... aber nach der Ausführung von sudo
>> ./VBoxLinuxAdditions.run erhielt ich wieder die gleichen
>> Meldungen
>

> Wieso hantierst du überhaupt mit den VBoxLinuxAdditions.run
> herum?

Weil mir das hier in der NG so empfohlen wurde.

> Wenn Manjaro auch nur ansatzweise noch etwas mit Arch gemeinsam
> hat dann gibt es dort auch das Paket virtualbox-guest-dkms,

Das habe ich jetzt - wie in den anderen letzten Postings beschrieben
- auch installiert, es war vorher nicht automatisch installiert.

> das über einen Pacman-Hook bei jedem Kernel- oder
> VirtualBox-Update die benötigten Module automatisch kompiliert.
> Somit passen dann auch immer alle Module zum Kernel.

Und wie bekomme ich dieses automatische Passend-machen jetzt auch
noch nachträglich irgendwie hin? Denn offensichtlich scheint es ja
im Moment noch nicht so richtig zu passen.

> Als Abhängigkeit wird das Paket "dkms"

Dieses hatte ich jetzt auch parallel zu den anderen Paketen installiert.

> noch nachgezogen so dass man sich darum auch nicht kümmern muss,
> nur die optionale Abhängigkeit der Kernel-Header (hier das Paket
> linux-headers) muss man noch selber installieren.

Wie gesagt, das Paket 'linux-api-headers' war schon installiert, und
'linux45-headers' habe ich jetzt auch installiert (ein Paket
'linux-headers' ohne Version gibt es hier nicht, höchstens noch ein
Paket namens 'linux-netbook-manjaro-headers' ... vielleicht sollte
ich das auch noch installieren ....????).

Trotzdem ist nach wie vor beim Booten kurz die Meldung zu sehen
'Failed to start loading kernel modules'. Scheint also noch nicht
alles ganz passend zu sein ...

Ansonsten habe ich mittlerweile auch die ersten 25 Pakete aus der
alphabetischen Update-Liste installiert, so dass "nur noch" 357
Pakete ausstehen.

> Martin.

[Franklin Schiftan]

Martin Schnitkemper schrieb am 17.05.2016 um 01:28 Uhr:

> Am Montag, 16.05.2016 23:49 schrieb Franklin Schiftan:

>> Wie gesagt, das Paket 'linux-api-headers' war schon installiert, und
>> 'linux45-headers' habe ich jetzt auch installiert (ein Paket
>> 'linux-headers' ohne Version gibt es hier nicht, höchstens noch ein
>> Paket namens 'linux-netbook-manjaro-headers' ... vielleicht sollte
>> ich das auch noch installieren ....????).
>

> In den optionalen Abhängigkeiten des Pakets "dkms" ist doch bestimmt
> hinterlegt, welche Header-Pakete je nach verwendetem Kernel zu installieren
> sind.

Na ja, da steht nur

Optionelle Abhängigkeiten
linux-headers: build modules against Arch kernel [installed]
linux-lts-headers: build modules against LTS Arch kernel

Aber wie gesagt, ein Paket 'linux-headers' ohne Version im Namen
gibt es nicht - und das Paket 'linux45-headers' hatte ich dann ja
wie geschrieben auch schon parallel installiert.

> Damit erübrigen sich alle weiteren Spekulationen, welches Paket das
> richtige sein könnte.

[Markus Grob]

Franklin Schiftan schrieb:

>
> Gunter Gutzeit schrieb am 16.05.2016 um 11:38 Uhr:

>> Du beginnst zu begreifen, dass die Virtualbox für das Austesten von
>> Rolling-Release-Linuxen nur bedingt tauglich ist (für einen
>> Langzeittest m.E. wohl eher nicht) ...

Das kann ich nur bedingt beatätigen. VBox hat manchmal seine Probleme,
doch die gibt es auch bei nativen Installationen. Vor allem, wenn jemand
NVidia oder so verwendet. Ich denke nicht, dass dies unter VBox
signifikant schlechter ist.

> Hmm, und was wäre jetzt Deiner Meinung nach sinnvoller? Statt VBox
> einen anderen Virtualisierer verwenden (falls ja, welchen?)?

Ich selber habe vorher VMWare verwendet, doch das unterscheidet sich
nicht gross und hat auch seine Mängel. KVM kenne ich nicht.

> unter VBox eine andere Distribution nehmen (wobei es mir als
> windows-gewohnter Linux-Neuling damals unter allen ausprobierten
> Linuxen Manjaro schon am einfachsten gemacht hat)?

Ich betreibe aktiv Opensuse Leap, wobei es auch da schon (vor allem
unter Tumbleweed) zu den exakt gleichen Problemen gekommen ist.

> meine bisherigen Update-Versuche mit der Manjaro-VBox-VM aufgeben,
> einfach alle angebotenen Updates künftig ignorieren und auf dem
> aktuellen und funktionierenden Stand belassen?

Hatte ich auch schon. Mich hatte es damals bewogen, von Tumbleweed (RR)
auf Leap zu wechseln.
Bei mir ging eine VM (ich habe diverse installiert, doch nutze ich diese
kaum) lange Zeit nicht, weil es Probleme mit KDE5 gab. Die VM läuft
unterdessen wieder, doch ich musste diese neu aufsetzen.
Da ich meine "echten" Daten nicht in der VM aufbewahre sondern auf dem
NAS oder über einen Laufwerkshare einbinde, macht ein neu aufsetzen
wenig Probleme.

Meine Schlussfolgerung: Keine System läuft immer fehlerfrei. Manchmal
hilft es, wie vorgeschlagen, einfach abzuwarten und bei anderen Fällen
muss man manche Programme manuell kompilieren, weil die binären Pakete
nicht laufen wie sie sollen.

Gruss, Markus

[Markus Grob]

Franklin Schiftan schrieb:

>
> Markus Grob schrieb am 16.05.2016 um 15:15 Uhr:

>> Die Module stimmen nicht mit dem Kernel überein. Versuch es bitte mit
>> einem Snapshot. Der Vorteil ist, dass Du da schnell zwischen
>> verschiedenen Zuständen umschalten kannst. Vor allem auch mit try and
>> error oder schrittweisem Vorgehen. Paket installieren, testen, weiter
>> oder zurück.
>
> O.k., das habe ich jetzt mal so angefangen ... aber auch da kann ich
> ja - mangels besserem Wissen - leider nur die alphabetische Liste
> der Reihe nach installieren.

Bis jetzt fehlt mir noch die Angabe zur grafischen Oberfläche, denn ich
vermute, dass es da noch ein zweites Problem gibt.

> Mit dem Begriff 'kernel-headers' im Namen gab es wie gesagt nur
> dieses eine Paket 'kernel-headers-musl' (nicht installiert). Mit
> 'headers' im Namen gibt es noch diverse (nicht installierte) Pakete
> namens 'linux..-headers', wobei die zwei Punkte für die
> verschiedenen Kernel-Versionen stehen.
> Installiert ist hier das Paket 'linux-api-headers', Kernel headers
> sanitized for use in userspace. Keine Ahnung, ob das ausreicht.

Installier doch einfach zum testen alle header Pakete. Da diese nur
zusätzliche Dateien zur Verfügung stellen, gibt es damit keine
zusätzlichen Probleme.

Gruss, Markus

[Markus Grob]

Franklin Schiftan schrieb:

>
> Franklin Schiftan schrieb am 16.05.2016 um 20:00 Uhr:
>
>> Markus Grob schrieb am 16.05.2016 um 15:15 Uhr:
>>
>>> Dann stimmen die Module nicht zum Kernel. Das heisst, hier liegt
>>> das Problem. Versuch daher, die vboxguestadditions nochmals
>>> auszuführen und beim Fehler das Logbuch anzuschauen.
>>
>> Das tat ich nun ... d.h. nein, vorher hatte ich noch die vier
>> dkms-Pakete installiert ... aber nach der Ausführung von sudo
>> ../VBoxLinuxAdditions.run erhielt ich wieder die gleichen Meldungen
>> wie letztens mit dem 'failed' in der vorletzten Zeile.
>
> Und beim anschließenden Boot-Versuch landete ich wieder nur auf dem CLI.

Das ist doppelt gemoppelt ;-) Wenn Du dkms machst, musst Du nicht mehr
die Guest-Module installieren. Dies hat Martin in seinem Artikel ja auch
erwähnt. In diesem Fall erledigt dann das System das nachladen und
einbinden der Module.

Wenn Du hingegen die Guest-Module manuell einbinden möchtest, dann
müssen zwingend die Kernel-Header Dateien für den installierten Kernel
zur Verfügung stehen. Sonst gibt es obigen Fehler und dann läuft es nach
dem Reboot nicht mehr.

> Wenn ich nur die dkms-Pakete und linux45-headers installiere, sehe
> ich zwar kurz beim Bootvorgang wieder diese Meldung 'Failed starting
> load kernel modules', aber ich komme trotzdem noch ganz normal auf
> die Maschine und kann mich einloggen etc.

Moment mal. Du installierst nur dkms und die Header und alle Updates
lässt Du wo sie sind und es kommt trotzdem die Fehlermeldung? Dann kann
dkms sich nicht sauber einbinden, weil ihm Dateien fehlen. Daher mein
Ratschlag mit der Kommandozeile. Es kann sein, dass die grafische
Oberfläche nicht alles notwendige anzeigt.

> Sobald ich aber die VBoxLinuxAddition.run ausführe, erhalte ich
> wieder den bekannten Fehler
> <http://fraschi.net/temp/vbox_run_02.jpg> und lande anschließend
> wieder nur im CLI. :-(

Wie erwähnt, entweder oder.

Gruss, Markus

[Markus Grob]

Franklin Schiftan schrieb:

> Wie gesagt, das Paket 'linux-api-headers' war schon installiert, und
> 'linux45-headers' habe ich jetzt auch installiert (ein Paket
> 'linux-headers' ohne Version gibt es hier nicht, höchstens noch ein
> Paket namens 'linux-netbook-manjaro-headers' ... vielleicht sollte
> ich das auch noch installieren ....????).

Wie erwähnt, die Header müssen zum Kernel passen und daher sind diese
nummeriert. Es kann natürlich sein, dass noch Programme fehlen, wie etwa
make, damit die Header auch einen Sinn ergeben

> Ansonsten habe ich mittlerweile auch die ersten 25 Pakete aus der
> alphabetischen Update-Liste installiert, so dass "nur noch" 357
> Pakete ausstehen.

Dann fleissig weiter ;-)

Gruss, Markus

[Markus Grob]

Martin Schnitkemper schrieb:

> Wenn man möchte, kann man das auf der Konsole mit "dkms" auch manuell
> durchführen, die nötigen Parameter sind in den manpages zu dkms zu finden.

https://wiki.ubuntuusers.de/DKMS/

Ist eine gute Einführung.

Gruss, Markus

[Franklin Schiftan]

Markus Grob schrieb am 17.05.2016 um 13:26 Uhr:

> Franklin Schiftan schrieb:
>
>> Wie gesagt, das Paket 'linux-api-headers' war schon installiert, und
>> 'linux45-headers' habe ich jetzt auch installiert (ein Paket
>> 'linux-headers' ohne Version gibt es hier nicht, höchstens noch ein
>> Paket namens 'linux-netbook-manjaro-headers' ... vielleicht sollte
>> ich das auch noch installieren ....????).
>
> Wie erwähnt, die Header müssen zum Kernel passen und daher sind diese
> nummeriert. Es kann natürlich sein, dass noch Programme fehlen, wie etwa
> make, damit die Header auch einen Sinn ergeben

Make war schon installiert, war jetzt nur in den Update-Paketen mit
einem Update dabei.

>> Ansonsten habe ich mittlerweile auch die ersten 25 Pakete aus der
>> alphabetischen Update-Liste installiert, so dass "nur noch" 357
>> Pakete ausstehen.
>
> Dann fleissig weiter ;-)

Aktuelle sind's noch 328 - bei ansonsten nach wie vor dieser
Fehlermeldung über nicht startende Kernel Module beim Boot, ABER
dennoch bislang anschließend "normaler" Funktion, kann mich anmelden
und die paar Dinge arbeiten, die ich brauche.

> Gruss, Markus

[Franklin Schiftan]

Markus Grob schrieb am 17.05.2016 um 13:21 Uhr:

> Franklin Schiftan schrieb:
>>
>> Franklin Schiftan schrieb am 16.05.2016 um 20:00 Uhr:
>>
>>> Markus Grob schrieb am 16.05.2016 um 15:15 Uhr:
>>>
>>>> Dann stimmen die Module nicht zum Kernel. Das heisst, hier
>>>> liegt das Problem. Versuch daher, die vboxguestadditions
>>>> nochmals auszuführen und beim Fehler das Logbuch
>>>> anzuschauen.
>>>
>>> Das tat ich nun ... d.h. nein, vorher hatte ich noch die vier
>>> dkms-Pakete installiert ... aber nach der Ausführung von sudo
>>> ../VBoxLinuxAdditions.run erhielt ich wieder die gleichen
>>> Meldungen wie letztens mit dem 'failed' in der vorletzten
>>> Zeile.
>>
>> Und beim anschließenden Boot-Versuch landete ich wieder nur
>> auf dem CLI.
>
> Das ist doppelt gemoppelt ;-) Wenn Du dkms machst, musst Du
> nicht mehr die Guest-Module installieren. Dies hat Martin in
> seinem Artikel ja auch erwähnt. In diesem Fall erledigt dann das
> System das nachladen und einbinden der Module.

Das war mir bis dahin nicht so klar.

> Wenn Du hingegen die Guest-Module manuell einbinden möchtest,
> dann müssen zwingend die Kernel-Header Dateien für den
> installierten Kernel zur Verfügung stehen. Sonst gibt es obigen
> Fehler und dann läuft es nach dem Reboot nicht mehr.

Die linux45-headers sind ja nun inzwischen installiert.

>> Wenn ich nur die dkms-Pakete und linux45-headers installiere,
>> sehe ich zwar kurz beim Bootvorgang wieder diese Meldung
>> 'Failed starting load kernel modules', aber ich komme trotzdem
>> noch ganz normal auf die Maschine und kann mich einloggen etc.
>
> Moment mal. Du installierst nur dkms und die Header und alle
> Updates lässt Du wo sie sind und es kommt trotzdem die
> Fehlermeldung?

Nun, ich hatte, bevor ich dkms und die linux45-headers installiert
hab, ja schon einige Updates aus der alphabetischen Liste
installiert. Und ehrlich gesagt weiß ich nicht mehr, ab welchem
Zeitpunkt genau diese Fehlermeldung über die nicht startenden Kernel
Module beim Booten auftrat, zumal diese Meldung hier ja auch recht
schnell über den Bildschirm rauscht und dann weg ist.

> Dann kann dkms sich nicht sauber einbinden, weil ihm Dateien
> fehlen. Daher mein Ratschlag mit der Kommandozeile.

Ähm, was meinst Du damit jetzt noch mal genau, bitte?

> Es kann sein, dass die grafische Oberfläche nicht alles
> notwendige anzeigt.

[Franklin Schiftan]

Markus Grob schrieb am 17.05.2016 um 13:14 Uhr:

> Franklin Schiftan schrieb:
>>
>> Markus Grob schrieb am 16.05.2016 um 15:15 Uhr:

> Bis jetzt fehlt mir noch die Angabe zur grafischen Oberfläche, denn ich
> vermute, dass es da noch ein zweites Problem gibt.

Hmm, meinst Du damit XFCE oder KDE oder wodran könnte ich die
richtige Antwort ersehen?

>> Mit dem Begriff 'kernel-headers' im Namen gab es wie gesagt nur
>> dieses eine Paket 'kernel-headers-musl' (nicht installiert). Mit
>> 'headers' im Namen gibt es noch diverse (nicht installierte) Pakete
>> namens 'linux..-headers', wobei die zwei Punkte für die
>> verschiedenen Kernel-Versionen stehen.
>> Installiert ist hier das Paket 'linux-api-headers', Kernel headers
>> sanitized for use in userspace. Keine Ahnung, ob das ausreicht.
>
> Installier doch einfach zum testen alle header Pakete. Da diese nur
> zusätzliche Dateien zur Verfügung stellen, gibt es damit keine
> zusätzlichen Probleme.

Das hatte ich ja letztens schon gemacht, zumindest für die hier noch
vorhandenen Kernel 4.1 und 4.5. Die linux44-headers wollte er nicht
installieren, weil er meinte, dann irgend ein anderes Modul
entfernen zu müssen - also sind diese nicht installiert. Ich denke
aber, dass dies auch kein Problem ist, sofern ich nicht auf den
4.4er Kernel zurückgehe, oder?

> Gruss, Markus

Danke für Deine unermüdliche Hilfe ...

[Franklin Schiftan]

Markus Grob schrieb am 16.05.2016 um 13:21 Uhr:

> Franklin Schiftan schrieb:
>>
>> Markus Grob schrieb am 14.05.2016 um 18:43 Uhr:

> Evtl. könnte es sein, dass Octopi Meldungen unterschlägt, die man mit
> Pacman zu sehen bekäme, falls ein Paket diese meldet. Das hatte ich
> unter Suse auch schon mit yast und zypper.

Das glaube ich insofern nicht, alldiweil ich aus aus Octopi heraus
auch immer auf 'im Terminalfenster ausführen' klicke, so dass ich
dort eigentlich auch immer alle Meldungen sehe - wenngleich ich sie
auch nicht immer verstehe ... ;-)

> Kannst Du nach dem Start mit der Sanduhr auf eine Konsole wechseln
> (Ctrl-Alt-F1) oder steht der Rechner?

Also *diese* Tastenkombination hatte ich nicht ausprobiert, aber
alles mögliche andere - ohne dass die Sanduhr verschwand.

> Gruss, Markus

[Franklin Schiftan]

Markus Grob schrieb am 14.05.2016 um 14:09 Uhr:

> Franklin Schiftan schrieb:
>>

>> Markus Grob schrieb am 14.05.2016 um 09:25 Uhr:

> Funktioniert das manuelle Einbinden mit: modprobe -a vboxguest
> vboxsf vboxvideo ohne Fehlermeldung,

Das funktioniert jetzt übrigens im aktuellen Snapshot-Stand ohne
Fehlermeldung.

> dann kannst Du dafür sorgen, dass die Module beim Start
> automatisch geladen werden. Ich muss dies etwa bei mir bei vboxsf
> machen, da der Eintrag in die fstab nach dem Update Probleme
> macht, da er dann das Modul noch nicht zur Verfügung hat und in
> den Emergency Mode startet.
>
> Die Module können im Unterverzeichnis /etc/modules-load.d
> hinzugefügt werden. Am Besten erstellt man in diesem Verzeichnis
> die Datei modules.conf (falls noch nicht vorhanden), und schreibt
> die zu ladenden Kernelmodule dort hinein auf eine eigene Zeile.
> Möchte man noch einen Kommentar haben, so muss diese Zeile mit
> einem # beginnen: # vboxsf Modul vboxsf # vboxguest Modul
> vboxguest

Muss/Soll ich das Vorstehende jetzt eigentlich auch mal machen,
ausprobieren?

[Christoph 'Mehdorn' Weber]

Hallo!

* Franklin Schiftan <fraschi...@arcor.de>:

> dass auch der Download der 1 GB Update-Pakete nach
> Wiederherstellung des alten Zustandes hier an der lahmen
> 2000er-Leitung ebenfalls mindestens solange braucht.

Bei Debian wuerde ich auf einem separaten Rechner so etwas wie
apt-cacher-ng oder approx einrichten, bzw. habe ich gemacht.
Insbesondere, wenn man mehrere Rechner hinter der Leitung hat,
merkt man das deutlich. Mehrfach derselbe Stand eines Rechners
ist in der Hinsicht fast dasselbe.

Christoph

--
telnet ist vollkommen ueberladen. Das kann Mail, News, HTTP
und so weiter. Unix-Philosophie ist, dass man ein Tool fuer
genau eine Aufgabe benutzt. telnet ist was fuer Windows-Leute.
(Christian Garbs)

[Markus Grob]

Franklin Schiftan schrieb:

>
> Markus Grob schrieb am 14.05.2016 um 14:09 Uhr:

>> Funktioniert das manuelle Einbinden mit: modprobe -a vboxguest
>> vboxsf vboxvideo ohne Fehlermeldung,
>
> Das funktioniert jetzt übrigens im aktuellen Snapshot-Stand ohne
> Fehlermeldung.

Das sollte es auch. Das bedeutet, dass der Kernel die entsprechenden
Module kennt. Sonst würde er hier auch meckern. Was gibt die aktuelle
Konfiguration eigentlich als Kernelversion aus? 4.5?

>> Die Module können im Unterverzeichnis /etc/modules-load.d
>> hinzugefügt werden.

> Muss/Soll ich das Vorstehende jetzt eigentlich auch mal machen,
> ausprobieren?

Nein, das musst DU nur, wenn er nach der Installation zwar startet, doch
meckert, dass er die Module nicht findet, der obige Befehl die Module
dann aber einbindet. In diesem Fall hat das mit dem automatischen
einbinden nämlich nicht funktioniert.

Gruss, Markus

[Markus Grob]

Franklin Schiftan schrieb:
>
> Markus Grob schrieb am 16.05.2016 um 13:21 Uhr:
>
>> Franklin Schiftan schrieb:
>>>
>>> Markus Grob schrieb am 14.05.2016 um 18:43 Uhr:
>
>> Evtl. könnte es sein, dass Octopi Meldungen unterschlägt, die man mit
>> Pacman zu sehen bekäme, falls ein Paket diese meldet. Das hatte ich
>> unter Suse auch schon mit yast und zypper.
>
> Das glaube ich insofern nicht, alldiweil ich aus aus Octopi heraus
> auch immer auf 'im Terminalfenster ausführen' klicke, so dass ich
> dort eigentlich auch immer alle Meldungen sehe - wenngleich ich sie
> auch nicht immer verstehe ... ;-)

Das tönt gut. Kannst diese Meldungen ja googeln. Da wird sicher manches
klarer ;-)

>> Kannst Du nach dem Start mit der Sanduhr auf eine Konsole wechseln
>> (Ctrl-Alt-F1) oder steht der Rechner?
>
> Also *diese* Tastenkombination hatte ich nicht ausprobiert, aber
> alles mögliche andere - ohne dass die Sanduhr verschwand.

Es geht darum, dass auch nach dem Absturz der grafischen Oberfläche der
Textmodus meist noch funktioniert. Wenn man dann dahin wechselt, kann
man über die Logbücher herausfinden, wo er hängt.
Dann kann man auch manuell X beenden und über die Konsole neu starten
(startx). Anschliessend hat man meist direkt in der Konsole brauchbare
Fehlermeldungen, wenn es nicht zu viele sind. Diese sind dann aber auch
im Logbuch wieder auffindbar, wenn man weiss, in welches Logbuch
geschrieben wird.

Dies war früher einfach, da man einfach /var/log beobachten musste.
Heute mit systemd wird manches noch exportiert und anderes behält er für
sich und muss ausgeraben werden :-(

Gruss, Markus

[Markus Grob]

Franklin Schiftan schrieb:
>
> Markus Grob schrieb am 17.05.2016 um 13:14 Uhr:
>
>> Franklin Schiftan schrieb:
>>>
>>> Markus Grob schrieb am 16.05.2016 um 15:15 Uhr:
>
>> Bis jetzt fehlt mir noch die Angabe zur grafischen Oberfläche, denn ich
>> vermute, dass es da noch ein zweites Problem gibt.
>
> Hmm, meinst Du damit XFCE oder KDE oder wodran könnte ich die
> richtige Antwort ersehen?

Verwendest Du XFCE oder KDE oder Gnome oder... dann am Besten noch die
verwendete Version. Ach ja, beim Anmelde Bildschirm. Hast DUu dort
verschiedene Displaymanager zur Auswahl? Wenn ja, dann schalte einmal
auf einen schlanken wie iceWM oder Openbox um.

>> Installier doch einfach zum testen alle header Pakete. Da diese nur
>> zusätzliche Dateien zur Verfügung stellen, gibt es damit keine
>> zusätzlichen Probleme.
>
> Das hatte ich ja letztens schon gemacht, zumindest für die hier noch
> vorhandenen Kernel 4.1 und 4.5. Die linux44-headers wollte er nicht
> installieren, weil er meinte, dann irgend ein anderes Modul
> entfernen zu müssen - also sind diese nicht installiert. Ich denke
> aber, dass dies auch kein Problem ist, sofern ich nicht auf den
> 4.4er Kernel zurückgehe, oder?

Richtig. Er bruacht eigentlich nur 4.5, wenn Du diesen auch einsetzt ;-)

> Danke für Deine unermüdliche Hilfe ...

Bitte. So kann ich testen, was ich weiss und wo ich noch Lücken habe ;-)

Gruss, Markus

[Markus Grob]

Franklin Schiftan schrieb:

>
> Markus Grob schrieb am 17.05.2016 um 13:21 Uhr:

>> Moment mal. Du installierst nur dkms und die Header und alle
>> Updates lässt Du wo sie sind und es kommt trotzdem die
>> Fehlermeldung?
>
> Nun, ich hatte, bevor ich dkms und die linux45-headers installiert
> hab, ja schon einige Updates aus der alphabetischen Liste
> installiert. Und ehrlich gesagt weiß ich nicht mehr, ab welchem
> Zeitpunkt genau diese Fehlermeldung über die nicht startenden Kernel
> Module beim Booten auftrat, zumal diese Meldung hier ja auch recht
> schnell über den Bildschirm rauscht und dann weg ist.

Das ist schon so. Allerdings ist das ein wichtiger Punkt. Ich vermute,
dass ein Paket ein neuer Kernel ist oder irgendwelche Pakete für
Virtualbox. Sonst dürfte kein Paket einen solchen Fehler produzieren.

>> Dann kann dkms sich nicht sauber einbinden, weil ihm Dateien
>> fehlen. Daher mein Ratschlag mit der Kommandozeile.
>
> Ähm, was meinst Du damit jetzt noch mal genau, bitte?

1. Dass Du es mit Pacman versuchen sollst, falls es dort mehr Meldungen
gibt. Unterdessen hast Du zwar gesagt, dass Du Dein Tool in einer Box
startest, so dass Du die Meldungen siehst, doch evtl. zeigt Pacman was
anderes.

2. Dass Du bei einem Misserfolg von dkms das Ganze manuell mit der
./vboxguetadditions.run testen sollst und herausfinden, wieso das
kompilieren der Module fehlschlägt

Ach ja, setze doch beim updaten die problematischen Pakete auf "nicht
anfassen". Dann ist der grosse Teil durch und Du hast nur noch ein
"Restproblem".

Gruss, Markus

[Franklin Schiftan]

Markus Grob schrieb am 17.05.2016 um 18:44 Uhr:

> Franklin Schiftan schrieb:
>>
>> Markus Grob schrieb am 14.05.2016 um 14:09 Uhr:
>
>>> Funktioniert das manuelle Einbinden mit: modprobe -a
>>> vboxguest vboxsf vboxvideo ohne Fehlermeldung,
>>
>> Das funktioniert jetzt übrigens im aktuellen Snapshot-Stand
>> ohne Fehlermeldung.
>
> Das sollte es auch. Das bedeutet, dass der Kernel die
> entsprechenden Module kennt. Sonst würde er hier auch meckern.
> Was gibt die aktuelle Konfiguration eigentlich als Kernelversion
> aus? 4.5?

Yep, auf dem 4.5er Kernel bin ich ja schon von Anfang an, als ich
das erste Mal die rd. 300 Updates installieren wollte und danach
eben nichts mehr ging.

>>> Die Module können im Unterverzeichnis /etc/modules-load.d
>>> hinzugefügt werden.
>
>> Muss/Soll ich das Vorstehende jetzt eigentlich auch mal
>> machen, ausprobieren?
>
> Nein, das musst DU nur, wenn er nach der Installation zwar
> startet, doch meckert, dass er die Module nicht findet,

Es kommt zwar nach wie vor beim Booten kurz die Meldung 'Failed to
start Load Kernel Modules', aber ich kann danach wie gesagt arbeiten
wie gewohnt. Möglicherweise sind es andere als die Vbox-Module, die
er nicht laden kann? Kann man in irgendeiner Log-Datei vielleicht
sehen, welche das sind?

Ich hab ja schon mal probiert, mir die Log-Dateien unter /var/log
anzuschauen (alle will er mir nicht anzeigen - trotz Krusader-Start
mit Systemverwalterrechten), aber z.B. in der Datei boot.log steht
ja nicht mal was von dieser Fehlermeldung drin ... alles nur
O.k.-Zeilen.

> der obige Befehl die Module dann aber einbindet. In diesem Fall
> hat das mit dem automatischen einbinden nämlich nicht
> funktioniert.
>
> Gruss, Markus

[Franklin Schiftan]

Markus Grob schrieb am 17.05.2016 um 18:48 Uhr:

> Franklin Schiftan schrieb:
>>
>> Markus Grob schrieb am 16.05.2016 um 13:21 Uhr:
>>
>>> Franklin Schiftan schrieb:
>>>>
>>>> Markus Grob schrieb am 14.05.2016 um 18:43 Uhr:

>>> Kannst Du nach dem Start mit der Sanduhr auf eine Konsole
>>> wechseln (Ctrl-Alt-F1) oder steht der Rechner?

Nein, inzwischen hatte ich gerade jetzt nach Update der Pakete von G
bis H diesen Zustand auch wieder, da brachte auch obige
Tasten-Kombination die drehende "Sanduhr" nicht zum Verschwinden.

Bin jetzt schon bei nur noch 270 restlich upzudatenden Paketen und
muss halt näher eingrenzen, welches der G-H-Pakete jetzt dafür
verantwortlich ist. Drei foomatic-Pakete und gutenprint musste ich
auch schon auslassen, weil danach irgendwas nicht mehr richtig lief.

>> Also *diese* Tastenkombination hatte ich nicht ausprobiert,
>> aber alles mögliche andere - ohne dass die Sanduhr verschwand.
>
> Es geht darum, dass auch nach dem Absturz der grafischen
> Oberfläche der Textmodus meist noch funktioniert.

Wie gesagt, in dem Fall komme ich aus dem Sanduhr-Zustand nicht
wirklich raus.

> Dies war früher einfach, da man einfach /var/log beobachten
> musste. Heute mit systemd wird manches noch exportiert und
> anderes behält er für sich und muss ausgeraben werden :-(

Oha ...

[Franklin Schiftan]

Markus Grob schrieb am 17.05.2016 um 18:57 Uhr:

> Franklin Schiftan schrieb:
>>
>> Markus Grob schrieb am 17.05.2016 um 13:14 Uhr:
>>
>>> Franklin Schiftan schrieb:
>>>>
>>>> Markus Grob schrieb am 16.05.2016 um 15:15 Uhr:
>>
>>> Bis jetzt fehlt mir noch die Angabe zur grafischen
>>> Oberfläche, denn ich vermute, dass es da noch ein zweites
>>> Problem gibt.
>>
>> Hmm, meinst Du damit XFCE oder KDE oder wodran könnte ich die
>> richtige Antwort ersehen?
>
> Verwendest Du XFCE oder KDE oder Gnome oder...

Oh je ... also, wenn ich mir so die installierten Pakete anschaue,
dann ist von allen drei vorgenannten irgendwas aus einer großen
Menge von Paketen mit dem jeweiligen Teil im Namen installiert.
Daher ja meine Frage, wodran ich am besten erkennen kann, was hier
verwendet wird ... sorry für meine Dummheit ...

> dann am Besten noch die verwendete Version. Ach ja, beim Anmelde
> Bildschirm. Hast DUu dort verschiedene Displaymanager zur
> Auswahl?

Nö, nicht, dass ich wüsste ... da erscheint der
Manjaro-Willkommens-Bildschirm, wo ich mein Passwort eingeben kann,
und dann bin ich auch schon drin ... ;-)

> Wenn ja, dann schalte einmal auf einen schlanken wie
> iceWM oder Openbox um.

>> Danke für Deine unermüdliche Hilfe ...
>
> Bitte. So kann ich testen, was ich weiss und wo ich noch Lücken
> habe ;-)

:-)

> Gruss, Markus

[Gunter Gutzeit]

Martin Schnitkemper schrieb am Di 17.05.2016 21:13:10 +0200:

> Das läuft beim Original "Arch" alles deutlich problemloser. Aber
> irgendwie muss sich ein Derivat ja vom Original unterscheiden. Und wenn
> es nur dadurch ist, eigentlich einfache Prozesse wieder unnötig zu
> verkomplizieren. Hauptsache anders.

Also mich mich würde mal ganz grundsätzlich interessieren, was für Leute
überhaupt eigentlich hinter dem Arch- und Manjaro-Projekt (ggf. mit
welche unterschiedlichen wirtschaftlichen oder technischen Interessen
und Zielrichtungen) stecken?

Warum haben sich die Manjaro-Leute überhaupt in dieser Weise aus dem
Arch-Projekt verabschiedet und manchen da jetzt ihr eigenes Ding?

Magst Du dazu hier was schreiben?

[Markus Grob]

Franklin Schiftan schrieb:
>
> Markus Grob schrieb am 17.05.2016 um 18:48 Uhr:

>>>> Kannst Du nach dem Start mit der Sanduhr auf eine Konsole
>>>> wechseln (Ctrl-Alt-F1) oder steht der Rechner?
>
> Nein, inzwischen hatte ich gerade jetzt nach Update der Pakete von G
> bis H diesen Zustand auch wieder, da brachte auch obige
> Tasten-Kombination die drehende "Sanduhr" nicht zum Verschwinden.

Welcher Fenstermanager ist im Einsatz? Gnome? Ctrl-Alt-Backspace (2 Mal)
bringt auch nichts?
Das mit der Sanduhr tönt aber nicht nach Virtualbox sondern nach anderen
Problemen.

> Bin jetzt schon bei nur noch 270 restlich upzudatenden Paketen und
> muss halt näher eingrenzen, welches der G-H-Pakete jetzt dafür
> verantwortlich ist. Drei foomatic-Pakete und gutenprint musste ich
> auch schon auslassen, weil danach irgendwas nicht mehr richtig lief.

Das tönt aber weniger nach VBox, sondern danach, dass sonst etwas
schiefläuft. Unter Suse gibt es Repositories mit Entwicklerversionen.
Hast Du evtl. ein solches bei Manjaro aktiviert und bekommst nun Pakete
die nicht stabil, sondern einfach nur neu sind?

Gruss, Markus

[Markus Grob]

Franklin Schiftan schrieb:

>
> Markus Grob schrieb am 17.05.2016 um 18:57 Uhr:

>> Verwendest Du XFCE oder KDE oder Gnome oder...
>
> Oh je ... also, wenn ich mir so die installierten Pakete anschaue,
> dann ist von allen drei vorgenannten irgendwas aus einer großen
> Menge von Paketen mit dem jeweiligen Teil im Namen installiert.
> Daher ja meine Frage, wodran ich am besten erkennen kann, was hier
> verwendet wird ... sorry für meine Dummheit ...

Nicht schlimm. Einfach mal einen Screenshot der Anmeldemaske und beim
gestarteten System machen. Sonst sollte ein F1 Infos zum Fenstermanager
bringen.

Es ist so, dass Du nämlich mehrere Manager installieren kannst.

http://grobmark.myhostpoint.ch/anmeldung.jpg

Kannst Du schauen, wie dies bei Manjaro läuft? Falls es nämlich nur
einen Fenstermanager betrifft, läuft der andere noch und wenn es das
xwindow selber betrifft, dann läuft der auch nicht mehr.

Gruss, Markus

[Markus Grob]

Franklin Schiftan schrieb:

> Es kommt zwar nach wie vor beim Booten kurz die Meldung 'Failed to
> start Load Kernel Modules', aber ich kann danach wie gesagt arbeiten
> wie gewohnt. Möglicherweise sind es andere als die Vbox-Module, die
> er nicht laden kann? Kann man in irgendeiner Log-Datei vielleicht
> sehen, welche das sind?

boot.log eigentlich. Bei systemd musst Du schnell googeln, wo er die
Meldungen hinschreibt.

> Ich hab ja schon mal probiert, mir die Log-Dateien unter /var/log
> anzuschauen (alle will er mir nicht anzeigen - trotz Krusader-Start
> mit Systemverwalterrechten), aber z.B. in der Datei boot.log steht
> ja nicht mal was von dieser Fehlermeldung drin ... alles nur
> O.k.-Zeilen.

Am Besten die Konsole öffnen, su werden und mit vim anschauen.


Gruss, Markus

[Franklin Schiftan]

Markus Grob schrieb am 18.05.2016 um 12:52 Uhr:

> Franklin Schiftan schrieb:
>>
>> Markus Grob schrieb am 17.05.2016 um 18:57 Uhr:
>
>>> Verwendest Du XFCE oder KDE oder Gnome oder...
>>
>> Oh je ... also, wenn ich mir so die installierten Pakete anschaue,
>> dann ist von allen drei vorgenannten irgendwas aus einer großen
>> Menge von Paketen mit dem jeweiligen Teil im Namen installiert.
>> Daher ja meine Frage, wodran ich am besten erkennen kann, was hier
>> verwendet wird ... sorry für meine Dummheit ...
>
> Nicht schlimm. Einfach mal einen Screenshot der Anmeldemaske und beim
> gestarteten System machen. Sonst sollte ein F1 Infos zum Fenstermanager
> bringen.

F1 bringt in der Desktop-Ansicht keine Reaktion. Ansonsten hab ich
mal ein paar Screenshots hochgeladen:

<http://fraschi.net/temp/anmeldung_manjaro.jpg>
<http://fraschi.net/temp/systray_manjaro.jpg>
<http://fraschi.net/temp/start_manjaro.jpg>
<http://fraschi.net/temp/rechtsklick_manjaro.jpg>

> Es ist so, dass Du nämlich mehrere Manager installieren kannst.
>
> http://grobmark.myhostpoint.ch/anmeldung.jpg

Sieht hier natürlich gaaaanz anders aus ... ;-)

> Kannst Du schauen, wie dies bei Manjaro läuft? Falls es nämlich nur
> einen Fenstermanager betrifft, läuft der andere noch und wenn es das
> xwindow selber betrifft, dann läuft der auch nicht mehr.
>
> Gruss, Markus

[Franklin Schiftan]

Markus Grob schrieb am 18.05.2016 um 13:01 Uhr:

> Franklin Schiftan schrieb:
>
>> Es kommt zwar nach wie vor beim Booten kurz die Meldung 'Failed
>> to start Load Kernel Modules', aber ich kann danach wie gesagt
>> arbeiten wie gewohnt. Möglicherweise sind es andere als die
>> Vbox-Module, die er nicht laden kann? Kann man in irgendeiner
>> Log-Datei vielleicht sehen, welche das sind?
>
> boot.log eigentlich.

Wie gesagt, da stehen (letzter richtiger Boot) nur lauter
O.k.-Meldungen:

*x- - - - - - - - - - - - - > Schnipp < - - - - - - - - - - - -x*

boot.log
[#[0;32m OK #[0m] Started Apply Kernel Variables.
[#[0;32m OK #[0m] Started Tell Plymouth To Write Out Runtime Data.
[#[0;32m OK #[0m] Started udev Kernel Device Manager.
#%G[#[0;32m OK #[0m] Started Flush Journal to Persistent Storage.
Starting Create Volatile Files and Directories...
[#[0;32m OK #[0m] Started Create Volatile Files and Directories.
Starting Update UTMP about System Boot/Shutdown...
[#[0;32m OK #[0m] Started Update UTMP about System Boot/Shutdown.
[#[0;32m OK #[0m] Started Setup keyboard layout.
[#[0;32m OK #[0m] Started Show Plymouth Boot Screen.
[#[0;32m OK #[0m] Started Forward Password Requests to Plymouth
Directory Watch.
[#[0;32m OK #[0m] Started Dispatch Password Requests to Console
Directory Watch.
[#[0;32m OK #[0m] Reached target Paths.
#%G#%G[#[0;32m OK #[0m] Found device VBOX_HARDDISK 1.
Activating swap
/dev/disk/by-uuid/7a0a9b86-7c77-44c6-9d99-86dcb137d412...
[#[0;32m OK #[0m] Activated swap
/dev/disk/by-uuid/7a0a9b86-7c77-44c6-9d99-86dcb137d412.
[#[0;32m OK #[0m] Reached target Swap.
[#[0;32m OK #[0m] Reached target System Initialization.
[#[0;32m OK #[0m] Started Daily Cleanup of Temporary Directories.
[#[0;32m OK #[0m] Started Daily locate database update.
[#[0;32m OK #[0m] Started Daily man-db cache update.
[#[0;32m OK #[0m] Listening on D-Bus System Message Bus Socket.
[#[0;32m OK #[0m] Reached target Sockets.
[#[0;32m OK #[0m] Reached target Basic System.
[#[0;32m OK #[0m] Started D-Bus System Message Bus.
[#[0;32m OK #[0m] Started CUPS Scheduler.
Starting System Logger Daemon...
[#[0;32m OK #[0m] Started Periodic Command Scheduler.
Starting Permit User Sessions...
Starting Network Manager...
Starting Login Service...
[#[0;32m OK #[0m] Started Daily verification of password and group
files.
[#[0;32m OK #[0m] Started Daily rotation of log files.
[#[0;32m OK #[0m] Reached target Timers.
[#[0;32m OK #[0m] Started Permit User Sessions.
[#[0;32m OK #[0m] Started Login Service.
Starting Terminate Plymouth Boot Screen...
Starting Wait for Plymouth Boot Screen to Quit...

*x- - - - - - - - - - - - - > Schnapp < - - - - - - - - - - - -x*

Der Befehl 'journalctl -b' (aktueller Zeitpunkt) bietet hingegen -
als root ausgeführt - jede Menge Informationen. Zwei Screenshots,
auf denen rote Zeilen auftauchten, hab ich mal hochgeladen:

<http://fraschi.net/temp/modules_failed.jpg>
<http://fraschi.net/temp/fehler_manjaro.jpg>

> Bei systemd musst Du schnell googeln, wo er die Meldungen
> hinschreibt.

Mach ich später ... muss erstmal weg ...

[Gunter Gutzeit]

Martin Schnitkemper schrieb am Mi 18.05.2016 20:54:16 +0200:

[...]

> Sie machen ihr eigenes Ding aus den gleichen Gründen wie auch Mint sein
> eigenes Ding aus Ubuntu und diese wieder aus Debian gemacht haben: sie
> deklassieren die ursprüngliche Distribution als "nicht benutzerfreundlich"
> und meinen, alles besser als das Original machen zu müssen.

[...]

Hab' dank für Deine Einschätzung ...

Nun, nach meiner subjektiven Erfahrung, ist und war die Einarbeitung in
die Linux-Welt für einen interessierten Laien, wie mich, nicht unbedingt
einfach.

Insoweit bitte ich um Verständnis, wenn ich einen Installer benutze, um
mir da erst einmal einen Zugang in diese Linux-Welt verschaffen zu
können. Wenn sich in dieser Welt damit weitere Probleme auftun, beklage
ich mich deshalb nicht :-)

[Markus Grob]

Franklin Schiftan schrieb:

> F1 bringt in der Desktop-Ansicht keine Reaktion. Ansonsten hab ich
> mal ein paar Screenshots hochgeladen:
>
> <http://fraschi.net/temp/anmeldung_manjaro.jpg>

OK. Das schaut nicht nach einer Umschaltungsmöglichkeit auf einen
anderen Fenstermanager aus.


> <http://fraschi.net/temp/start_manjaro.jpg>

Was zeigt die Hilfe oder das System an? Auf Grund des Theme kann ich
nicht feststellen, ob es nicht einfach ein Gnome oder KDE ist.

>> Kannst Du schauen, wie dies bei Manjaro läuft? Falls es nämlich nur
>> einen Fenstermanager betrifft, läuft der andere noch und wenn es das
>> xwindow selber betrifft, dann läuft der auch nicht mehr.

Konntest Du dies nachforschen ob es noch andere gibt und wie man die
starten würde?

Gruss, Markus

[Markus Grob]

Franklin Schiftan schrieb:

> Der Befehl 'journalctl -b' (aktueller Zeitpunkt) bietet hingegen -
> als root ausgeführt - jede Menge Informationen.

Das soll er auch ;-)


> <http://fraschi.net/temp/modules_failed.jpg>

OK. Hier will er vbox Module laden, die er aber nicht einbinden kann.
Die wichtigsten findet er. Andere wie vboxdrv hingegen kann er nicht
finden. Das kann daran liegen, dass es das Modul nicht gibt, dass es
nicht am richtigen Ort ist oder dass das Modul nicht als gültig
empfunden und daher nicht geladen wird.

Öffne doch einmal die systemd-modules-load.service Datei. Ist bei mir im
Verzeichnis/usr/lib/systemd/system und poste deren Inhalt. Evtl. sind
dort nur Links auf andere Dateien drin und evtl. auch direkt die
gesuchten Module. Suche sonst in den verlinkten Dateien nach den
Modulen. So können wir herausfinden, ob die Module fehlen oder was ist.


> <http://fraschi.net/temp/fehler_manjaro.jpg>

Die obigen Daten sind nicht tragische Meldungen. Irgendwie hat er
Probleme, die Netzwerkkarten mit IPv6 zu konfigurieren.

Die Meldung zur Glib musst Du mal googeln, die sagt mir nichts.

Gruss, Markus

[Franklin Schiftan]

Markus Grob schrieb am 19.05.2016 um 11:48 Uhr:

> Franklin Schiftan schrieb:
>
>> Der Befehl 'journalctl -b' (aktueller Zeitpunkt) bietet
>> hingegen - als root ausgeführt - jede Menge Informationen.
>
> Das soll er auch ;-)
>
>
>> <http://fraschi.net/temp/modules_failed.jpg>
>
> OK. Hier will er vbox Module laden, die er aber nicht einbinden
> kann. Die wichtigsten findet er.

Daher meine Frage, ob ich die anderen überhaupt brauche ... denn
solange der Fenstermanager startet und ich ansonsten normal arbeiten
kann, stört mich diese kurze Kernel-Modul-Lade-Fehlermeldung beim
Booten nicht wirklich. ;-)

> Öffne doch einmal die systemd-modules-load.service Datei. Ist bei
> mir im Verzeichnis/usr/lib/systemd/system und poste deren
> Inhalt.

*x- - - - - - - - - - - - - > Schnipp < - - - - - - - - - - - -x*

# This file is part of systemd.
#
# systemd is free software; you can redistribute it and/or modify it
# under the terms of the GNU Lesser General Public License as
published by
# the Free Software Foundation; either version 2.1 of the License, or
# (at your option) any later version.

[Unit]
Description=Load Kernel Modules
Documentation=man:systemd-modules-load.service(8) man:modules-load.d(5)
DefaultDependencies=no
Conflicts=shutdown.target
Before=sysinit.target shutdown.target
ConditionCapability=CAP_SYS_MODULE
ConditionDirectoryNotEmpty=|/lib/modules-load.d
ConditionDirectoryNotEmpty=|/usr/lib/modules-load.d
ConditionDirectoryNotEmpty=|/usr/local/lib/modules-load.d
ConditionDirectoryNotEmpty=|/etc/modules-load.d
ConditionDirectoryNotEmpty=|/run/modules-load.d
ConditionKernelCommandLine=|modules-load
ConditionKernelCommandLine=|rd.modules-load

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/lib/systemd/systemd-modules-load
TimeoutSec=90s

*x- - - - - - - - - - - - - > Schnapp < - - - - - - - - - - - -x*

> Evtl. sind dort nur Links auf andere Dateien drin und evtl. auch
> direkt die gesuchten Module. Suche sonst in den verlinkten
> Dateien nach den Modulen. So können wir herausfinden, ob die
> Module fehlen oder was ist.

Wenn ich z.B. in dem erstgenannten Verzeichnis /lib/modules-load.d
nachsehe, gibt es dort drei Dateien:

- nfs-utils.conf
- virtualbox-guest-dkms.conf
- virtualbox-host-dkms.conf

In der Datei virtualbox-guest-dkms.conf stehen die drei Zeilen:

vboxguest
vboxsf
vboxvideo

Das sind die drei Module, die nunmehr auch problemlos gefunden und
eingebunden werden.

In der Datei virtualbox-host-dkms.conf stehen die folgenden vier Zeilen:

vboxdrv
vboxpci
vboxnetadp
vboxnetflt

Das sind die vier Module, die nicht geladen werden.
Aber ob ich die überhaupt brauche ....?

BTW: Ich habe bei meinen sukzessiven Update-Versuchen bis zum
Buchstabe 'j' inzwischen sechs Pakete gefunden, die ich auf die
Pacman-Ignore-List gesetzt habe, weil ich mit denen sonst beim
nächsten Boot-Versuch nicht über die drehende "Sanduhr" hinauskam.

Daneben hatte ich zwischendurch auch einfach mal ausserhalb der
alphabetischen Reihenfolge probiert, das Paket

virtualbox-guest-utils von 5.0.16-0.1 auf 5.0.20-0.1

upzudaten, aber danach war dann wieder das Problem mit dem nicht
mehr startenden X-Server. So bin ich wieder zurück auf den letzten
Snapshot davor und mache nachher oder morgen mit den verbliebenen
250 Update-Paketen ab Buchstabe 'k' weiter.

Vielleicht kann ich dann jetzt hier auch gleich noch was zu Deiner
Frage im anderen Posting zum Fenster-Manager sagen: Also, es gibt
sowohl 'KDE-Systemeinstellungen' als auch 'Grafische
Einstellungsverwaltung für Xfce4'. Wenn ich mir bei beiden mal so
die einzelnen Einstellungen, z.B. für den Anmeldebildschirm, näher
anschaue, dann komme ich zu der Überzeugung, dass hier wohl
standardmäßig die Einstellungen von Xfce4 verwendet werden.

[Franklin Schiftan]

Martin Schnitkemper schrieb am 19.05.2016 um 22:01 Uhr:

> Am Donnerstag, 19.05.2016 13:41 schrieb Franklin Schiftan:
>
>> Wenn ich z.B. in dem erstgenannten Verzeichnis /lib/modules-load.d
>> nachsehe, gibt es dort drei Dateien:
>>
>> - nfs-utils.conf
>> - virtualbox-guest-dkms.conf
>> - virtualbox-host-dkms.conf
>

> ....und das ist auch schon wieder Murks: ein Client kann entweder nur Host
> oder Guest, aber nicht beides sein.

>
>> In der Datei virtualbox-host-dkms.conf stehen die folgenden vier Zeilen:
>>
>> vboxdrv
>> vboxpci
>> vboxnetadp
>> vboxnetflt
>>
>> Das sind die vier Module, die nicht geladen werden.
>

> Ist doch auch klar: warum sollten Host-Module auf einem Guest-Client
> geladen werden? Das Paket virtualbox-host-dkms gehört hier überhaupt nicht
> installiert.

O.k., danke ... dann könnte ich dieses Paket also einfach wieder
deinstallieren - und dann wäre vermutlich auch diese Fehlermeldung
beim Booten, dass er Kernel-Module nicht laden kann, verschwunden?

> Martin.

[Franklin Schiftan]

Franklin Schiftan schrieb am 20.05.2016 um 06:30 Uhr:

>> Ist doch auch klar: warum sollten Host-Module auf einem Guest-Client
>> geladen werden? Das Paket virtualbox-host-dkms gehört hier überhaupt nicht
>> installiert.
>
> O.k., danke ... dann könnte ich dieses Paket also einfach wieder
> deinstallieren - und dann wäre vermutlich auch diese Fehlermeldung
> beim Booten, dass er Kernel-Module nicht laden kann, verschwunden?

Der Versuch schlug mit der folgenden, für mich (zunächst) absolut
unverständlichen Fehlermeldung (siehe nachstehend) fehl. (Wieso soll
es ein Problem sein, wenn beim Entfernen von virtualbox-host-dkms
auch ein von virtualbox-host-dkms benötigtes Paket mit entfernt wird?)

[leser@leser ~]$ sudo pacman -R virtualbox-host-dkms
[sudo] Passwort für leser:
Prüfe Abhängigkeiten...
Fehler: Konnte den Vorgang nicht vorbereiten (Kann Abhängigkeiten
nicht erfüllen)
:: virtualbox-dkms-manjaro: das Entfernen von virtualbox-host-dkms
löscht ein benötigtes Packet von 'virtualbox-host-dkms'
[leser@leser ~]$

Etwas später kam ich dann dahinter, dass mit dieser, nach meinem
Verständnis reichlich ungeschickt formulierten, Fehlermeldung wohl
eigentlich gemeint war, dass das Paket virtualbox-host-dkms nicht
entfernt werden kann, weil es noch von virtualbox-dkms-manjaro
benötigt wird, (Warum schreiben die das nicht gleich so?), denn dort
stand:

virtualbox-dkms-manjaro
VirtualBox kernel modules dkms helpers

Hängt ab von
virtualbox-host-dkms virtualbox-guest-dkms


Nun kann ich doch aber das Paket virtualbox-dkms-manjaro nicht auch
noch entfernen - schließlich ist es das einzige hier aufgeführte
Paket, welches 'virtualbox' und 'dkms' im Namen hat, oder?

[Markus Grob]

Franklin Schiftan schrieb:

> virtualbox-dkms-manjaro
> VirtualBox kernel modules dkms helpers
>
> Hängt ab von
> virtualbox-host-dkms virtualbox-guest-dkms
>
>
> Nun kann ich doch aber das Paket virtualbox-dkms-manjaro nicht auch
> noch entfernen - schließlich ist es das einzige hier aufgeführte
> Paket, welches 'virtualbox' und 'dkms' im Namen hat, oder?

Snapshot, testen, schauen ;-)

Gruss, Markus

[Markus Grob]

Franklin Schiftan schrieb:

> Wenn ich z.B. in dem erstgenannten Verzeichnis /lib/modules-load.d
> nachsehe, gibt es dort drei Dateien:
>
> - nfs-utils.conf
> - virtualbox-guest-dkms.conf
> - virtualbox-host-dkms.conf

Markiere den Eintrag vom Host sonst als Kommentar, dann kannst Du das
ominöse Paket auch installiert lassen. Ich würde aber einfach den Tipp
mit entfernen der Pakete durchführen, da das dkms für den Host nicht
gebraucht wird.

> BTW: Ich habe bei meinen sukzessiven Update-Versuchen bis zum
> Buchstabe 'j' inzwischen sechs Pakete gefunden, die ich auf die
> Pacman-Ignore-List gesetzt habe, weil ich mit denen sonst beim
> nächsten Boot-Versuch nicht über die drehende "Sanduhr" hinauskam.

Welche?

> Vielleicht kann ich dann jetzt hier auch gleich noch was zu Deiner
> Frage im anderen Posting zum Fenster-Manager sagen: Also, es gibt
> sowohl 'KDE-Systemeinstellungen' als auch 'Grafische
> Einstellungsverwaltung für Xfce4'.

Hm, das könnte auf Xfce4 als Displaymanager hindeuten, welche auch den
Anmeldeschirm liefert und anschliessend wird KDE gestartet.

Gruss, Markus

[Franklin Schiftan]

Ha, gute Idee ... ich glaub, ich muss einfach ein bisschen mutiger
sein ... ;-)

Ich habe jetzt also die beiden Pakete 'virtualbox-dkms-manjaro' und
'virtualbox-host-dkms' entfernt - und siehe da, die Fehlermeldung
über nicht ladbare Kernel-Module ist (natürlich) weg. :-)

Und bezüglich der sonstigen Arbeit habe ich beim ersten Test auch
keinerlei Beeinträchtigung feststellen können. Dann kann ich ja
langsam mit den restlichen 250 Update-Paketen weiter probieren. ;-)

> Gruss, Markus

Danke für Deiner Hilfe und Ermutigung - auch an Martin fürs
Aufdecken und Nennen der Ungereimtheiten.

[Franklin Schiftan]

Markus Grob schrieb am 20.05.2016 um 11:36 Uhr:

> Franklin Schiftan schrieb:
>
>> Wenn ich z.B. in dem erstgenannten Verzeichnis /lib/modules-load.d
>> nachsehe, gibt es dort drei Dateien:
>>
>> - nfs-utils.conf
>> - virtualbox-guest-dkms.conf
>> - virtualbox-host-dkms.conf
>
> Markiere den Eintrag vom Host sonst als Kommentar, dann kannst Du das
> ominöse Paket auch installiert lassen. Ich würde aber einfach den Tipp
> mit entfernen der Pakete durchführen, da das dkms für den Host nicht
> gebraucht wird.

Done, erfolgreich, siehe anderes Posting. :-)

>> BTW: Ich habe bei meinen sukzessiven Update-Versuchen bis zum
>> Buchstabe 'j' inzwischen sechs Pakete gefunden, die ich auf die
>> Pacman-Ignore-List gesetzt habe, weil ich mit denen sonst beim
>> nächsten Boot-Versuch nicht über die drehende "Sanduhr" hinauskam.
>
> Welche?

Name Veraltete Version Verfügbare Version
foomatic-db 3:20160214-1 3:20160416-1
foomatic-db-engine 3:20160214-1 4:4.0.12-2
foomatic-db-nonfree 3:20160214-1 3:20160416-1
gutenprint 5.2.11-1 5.2.11-3
harfbuzz 1.2.4-1 1.2.7-1
harfbuzz-icu 1.2.4-1 1.2.7-1
hplip 3.16.3-1 3.16.5-1
icu 56.1-2 57.1-1

Von diesen Paketen kann es sein, dass hplip den Fehler nicht
wirklich verursacht; da ich hier aber eh keinen HP-Drucker habe,
brauche ich dieses recht umfangreiche Paket wohl eher nicht, so dass
ich es auch gleich mit auf die Ignore-Liste gesetzt habe.

>> Vielleicht kann ich dann jetzt hier auch gleich noch was zu Deiner
>> Frage im anderen Posting zum Fenster-Manager sagen: Also, es gibt
>> sowohl 'KDE-Systemeinstellungen' als auch 'Grafische
>> Einstellungsverwaltung für Xfce4'.
>
> Hm, das könnte auf Xfce4 als Displaymanager hindeuten, welche auch den
> Anmeldeschirm liefert und anschliessend wird KDE gestartet.

Hmm, ich trau mich ja schon wieder gar nicht zu fragen, was denn
überhaupt der Unterschied zwischen einem Displaymanager, einem
Fenster-Manager und X-window ist?

Ich mach dann mal langsam mit den vielen mit 'k' beginnenden
Update-Paketen weiter ...

[Markus Grob]

Franklin Schiftan schrieb:

> Name Veraltete Version Verfügbare Version
> foomatic-db 3:20160214-1 3:20160416-1
> foomatic-db-engine 3:20160214-1 4:4.0.12-2
> foomatic-db-nonfree 3:20160214-1 3:20160416-1
> gutenprint 5.2.11-1 5.2.11-3
> harfbuzz 1.2.4-1 1.2.7-1
> harfbuzz-icu 1.2.4-1 1.2.7-1
> hplip 3.16.3-1 3.16.5-1
> icu 56.1-2 57.1-1

Schau doch, wo Abhängigkeiten bestehen und sonst würde ich möglichst
viel rauswerfen. Je mehr unnützer Krempel installiert ist, umso mehr
Probleme entstehen.

> Hmm, ich trau mich ja schon wieder gar nicht zu fragen, was denn
> überhaupt der Unterschied zwischen einem Displaymanager, einem
> Fenster-Manager und X-window ist?

Ganz einfach... etwas googeln und Du findest es heraus ;-)

Ganz kurz:
x-window ist das Grundgerüst, welches die Kommunikation mit dem
Grafikkartentreiber übernimmt:
https://de.wikipedia.org/wiki/X_Window_System

Displaymanager = Bildschirmmanager / Loginmanager:
https://wiki.ubuntuusers.de/Displaymanager/

Windowmanager = Fenstermanager: Link schon gepostet ;-)

> Ich mach dann mal langsam mit den vielen mit 'k' beginnenden
> Update-Paketen weiter ...

Das tönt nach KDE.

Gruss, Markus

[Franklin Schiftan]

Markus Grob schrieb am 20.05.2016 um 16:45 Uhr:

> Franklin Schiftan schrieb:
>> Name Veraltete Version Verfügbare Version
>> foomatic-db 3:20160214-1 3:20160416-1
>> foomatic-db-engine 3:20160214-1 4:4.0.12-2
>> foomatic-db-nonfree 3:20160214-1 3:20160416-1
>> gutenprint 5.2.11-1 5.2.11-3
>> harfbuzz 1.2.4-1 1.2.7-1
>> harfbuzz-icu 1.2.4-1 1.2.7-1
>> hplip 3.16.3-1 3.16.5-1
>> icu 56.1-2 57.1-1
>
> Schau doch, wo Abhängigkeiten bestehen und sonst würde ich möglichst
> viel rauswerfen. Je mehr unnützer Krempel installiert ist, umso mehr
> Probleme entstehen.

Nun ja, unnütz dürften die Pakete vermutlich kaum sein, denn bei den
meisten von ihnen wollten beim Entfernen gleich auch noch etliche
andere (vermutlich durchaus auch essentielle wie cups etc.) mit
entfernt werden, beim Paket 'icu' wären sogar 265 andere Pakete
auch mit entfernt worden ... ich hab' sie also einfach erstmal in
den veralteten Versionen weiter auf der VM gelassen und sie
lediglich auf die Pacman-Ignore-List gesetzt.

Ansonsten war ich damals ganz froh, dass ich diese von der COM!
schon fix und fertig eingerichtete und ausgestattete und
konfigurierte VM bekommen hab, um damit dann später eine Alternative
für mein damals nur noch unter Win-XP laufendes 16-bit-Programm
ausprobieren zu können. Und wie gesagt lief es ja auch zwei Jahre
lang mit den wöchentlichen Updates nahezu problemlos.

>> Ich mach dann mal langsam mit den vielen mit 'k' beginnenden
>> Update-Paketen weiter ...
>
> Das tönt nach KDE.

Ja, dazu waren etliche dabei ... mittlerweile ist 'k' auch durch und
es warten nur noch 198 Pakete - hurra, fast die Hälfte geschafft ...
na ja, am Wochenende werden dafür ja wieder ein paar neue dazu
kommen ... ;-)

ABER ganz so einfach war es dann doch nicht ... ;-) ... wäre ja auch
zu schön gewesen ...
Irgendwann fing es beim Start der VM nämlich an, dass die
Num-Lock-Taste ständig laufend an und aus ging. Das hatte natürlich
auch Auswirkungen auf alle Eingaben, so dass ich nur per Zufall
richtig ins Passwort-Feld tippen und mich anmelden konnte.

Bis ich dann nach Durchtesten älterer Snapshots irgendwann
feststellen durfte, dass dieser Effekt offensichtlich *nicht* durch
eines der letzten Update-Pakete entstanden war, weil es nämlich auch
mit früheren Snapshots, bei denen der Effekt damals sicher nicht
gewesen war, so lief, dauerte ein Weilchen.

Offensichtlich hatte mich jetzt hier - wie ich dann bei weiterer
Netz-Recherche - erfuhr, ein grundsätzliches Vbox-Problem erwischt.

Die gefundene Lösung, der nachstehende vboxmanage-Befehl,

> VBoxManage setextradata "<machine-name>" GUI/HidLedsSync "0"

brachte dann tatsächlich die Lösung für dieses absolut störende
Num-Lock-Wechsel-Problem. Jetzt wechselt die Num-Lock-Taste nicht
mehr eigenständig beim VM-Start und ich kann wieder ganz normal
Eingaben tippen. :-)

[Manuel Rodriguez]

Am Mittwoch, 18. Mai 2016 09:45:07 UTC+2 schrieb Gunter Gutzeit:
> Also mich mich würde mal ganz grundsätzlich interessieren, was für Leute
> überhaupt eigentlich hinter dem Arch- und Manjaro-Projekt (ggf. mit
> welche unterschiedlichen wirtschaftlichen oder technischen Interessen
> und Zielrichtungen) stecken?

Um das herauszufinden kann man nach Leuten googlen, die sich enttäuscht von dem Projekt verabschiedet haben ("Archlinux resign") und findet hier
https://pierre-schmitz.com/arch-before-it-was-cool/

eine persönliche Beschreibung von einem Ex-ArchLinux Developer. Die Hauptmotivation scheint darin zu bestehen, dass man als Maintainer das System von sehr vielen Leuten kaputt machen kann, und sich dann darüber freut, dass in einem Forum wie diesen hier Neueinsteiger mit nicht mehr bootenden Systemen konfrontiert sind.

[Gunter Gutzeit]

Manuel Rodriguez schrieb am So 22.05.2016 14:18:39 -0700:

> Um das herauszufinden kann man nach Leuten googlen, die sich enttäuscht
> von dem Projekt verabschiedet haben ("Archlinux resign") und findet
> hier https://pierre-schmitz.com/arch-before-it-was-cool/
>
> eine persönliche Beschreibung von einem Ex-ArchLinux Developer. Die
> Hauptmotivation scheint darin zu bestehen, dass man als Maintainer das
> System von sehr vielen Leuten kaputt machen kann, und sich dann darüber
> freut, dass in einem Forum wie diesen hier Neueinsteiger mit nicht mehr
> bootenden Systemen konfrontiert sind.

Danke für den Link mit diesen aufschlussreichen
Hintergrund-Informationen aus der Insider-Szene!

[Ralph Angenendt]

Well, Manuel Rodriguez <a...@gmx.net> wrote:
> Am Mittwoch, 18. Mai 2016 09:45:07 UTC+2 schrieb Gunter Gutzeit:
>> Also mich mich würde mal ganz grundsätzlich interessieren, was für Leute
>> überhaupt eigentlich hinter dem Arch- und Manjaro-Projekt (ggf. mit
>> welche unterschiedlichen wirtschaftlichen oder technischen Interessen
>> und Zielrichtungen) stecken?
>
> Um das herauszufinden kann man nach Leuten googlen, die sich enttäuscht von dem Projekt verabschiedet haben ("Archlinux resign") und findet hier
> https://pierre-schmitz.com/arch-before-it-was-cool/
>
> eine persönliche Beschreibung von einem Ex-ArchLinux Developer.

Aha. Seit wann ist Pierre denn nicht mehr bei Arch?

> Die Hauptmotivation scheint darin zu bestehen, dass man als Maintainer
> das System von sehr vielen Leuten kaputt machen kann, und sich dann
> darüber freut, dass in einem Forum wie diesen hier Neueinsteiger mit
> nicht mehr bootenden Systemen konfrontiert sind.

Unfug.

Ralph
--
His goal in life was to be an echo

[Markus Grob]

Franklin Schiftan schrieb:

> Die gefundene Lösung, der nachstehende vboxmanage-Befehl,
>
>> VBoxManage setextradata "<machine-name>" GUI/HidLedsSync "0"
>
> brachte dann tatsächlich die Lösung für dieses absolut störende
> Num-Lock-Wechsel-Problem. Jetzt wechselt die Num-Lock-Taste nicht
> mehr eigenständig beim VM-Start und ich kann wieder ganz normal
> Eingaben tippen. :-)

Danke für diesen Post. Das wusste ich nicht und bei meinen Recherchen
fand ich nur die Lösung, die Num-Lock Taste beim Starten fix einzuschalten.

Das werde ich nachher gleich testen ;-)

Gruss, Markus

[Franklin Schiftan]

Gefunden hatte ich diese Lösung übrigens auf der Seite
<https://martinvanbeurden.nl/blog/virtualbox-numlock-weirdness/>

Was die Ursprungsfrage angeht, bin ich übrigens inzwischen mit allen
Update-Paketen soweit durch, mit Ausnahme der folgenden, die wie
gesagt momentan auf der pacman-Ignorelist stehen (die ersten drei
schon von früheren Nebenwirkungen), weil danach entweder der
x-server gar nicht mehr startete oder ich keinen Anmelde-Bildschirm
bekam oder die Manjaro-Settings nicht mehr erschienen ... (ich kann
mit dem Zustand, diese Pakete nicht zu aktualisieren, momentan ganz
gut leben ... bis vielleicht dadurch irgendwann auch mal wieder was
anderes nicht mehr geht ...):

*x- - - - - - - - - - - - - > Schnipp < - - - - - - - - - - - -x*

IgnorePkg = baloo4 baloo4-akonadi pyparted-git foomatic-db
foomatic-db-engine foomatic-db-nonfree gutenprint harfbuzz
harfbuzz-icu hplip icu pygobject-devel python-gobject
python2-gobject openssl qt5-base qt5-webkit webkit2gtk webkitgtk
webkitgtk2 manjaro-settings-manager virtualbox-guest-utils

*x- - - - - - - - - - - - - > Schnapp < - - - - - - - - - - - -x*

In dem Zustand funktioniert der Rechner jetzt auch soweit wie
früher. Allerdings bin ich noch am Überlegen, ob ich trotzdem
*jetzt*, nachdem alle anderen Pakete upgedatet sind, diese bislang
ausgelassenen Pakete nicht doch noch mal einzeln durchprobieren
sollte - jetzt, wo ich ja weiß, wie schnell das ganze mit den
Snapshots funktioniert. ;-)

Ich hatte nämlich während der Update-Arie auch den Fall, dass sich
das Paket linux-firmware nicht updaten ließ, also hab ich es
zunächst beiseite gelassen ... aber irgendwann später dann doch noch
mal probiert (inzwischen hatte ich neben x anderen Paketen auch das
Paket manjaro-firmware aktualisiert ... möglicherweise war das ja
hilfreich dafür) und siehe da, die beim ersten Versuch aufgetretene
Fehlermeldung kam nicht mehr, so dass auch das Paket linux-firmware
aktualisiert werden konnte.

[Markus Grob]

Franklin Schiftan schrieb:

> *x- - - - - - - - - - - - - > Schnipp < - - - - - - - - - - - -x*
> IgnorePkg = baloo4 baloo4-akonadi pyparted-git foomatic-db
> foomatic-db-engine foomatic-db-nonfree gutenprint harfbuzz
> harfbuzz-icu hplip icu pygobject-devel python-gobject
> python2-gobject openssl qt5-base qt5-webkit webkit2gtk webkitgtk
> webkitgtk2 manjaro-settings-manager virtualbox-guest-utils
> *x- - - - - - - - - - - - - > Schnapp < - - - - - - - - - - - -x*

Verschiedenes Zeugs von der Desktopsuche zum Unterbau alles dabei ;-)

> In dem Zustand funktioniert der Rechner jetzt auch soweit wie
> früher. Allerdings bin ich noch am Überlegen, ob ich trotzdem
> *jetzt*, nachdem alle anderen Pakete upgedatet sind, diese bislang
> ausgelassenen Pakete nicht doch noch mal einzeln durchprobieren
> sollte - jetzt, wo ich ja weiß, wie schnell das ganze mit den
> Snapshots funktioniert. ;-)

Darfst Du versuchen. Evtl. wartest Du aber auch, bis neue Updates
draussen sind, die vielleicht die Fehler beheben, die mit den jetzigen
Releases auftreten.

> Ich hatte nämlich während der Update-Arie auch den Fall, dass sich
> das Paket linux-firmware nicht updaten ließ,

Das hatte ich auch schon mehrmals bei Opensuse. Da war dann meistens ein
Problem mit dem Paket und es hiess, es sei beschädigt. Keine Ahnung,
wieso es immer dieses Paket trifft, doch nach ein paar Tagen lief es
dann auch durch.

Gruss, Markus

[Ch. Hanisch]

Hallo,

Am 10.05.2016 um 19:06 schrieb Franklin Schiftan:
>
> kürzlich wollte meine Manjaro(Arch-Linux)-VM - wie nahezu jede Woche
> - mal wieder etliche Updates einspielen, diesmal 236 Stück.
>
> Wie üblich ließ ich dies zu, konnte dann diesmal aber anschließend
> nicht mehr wirklich mit der VM arbeiten, weil der X-Server nicht
> mehr starten konnte. Im angebotenen Log stand dann zum Schluss, dass
> er keinen Screen gefunden hätte.
>
Ich hatte kürzlich einen ähnliche Fall mit Netrunner

Die Lösung für mein Problem mit Netrunner ist gefunden.
https://forum.manjaro.org/t/xorg-still-broken-in-virtualbox-after-update-2016-05-22-stable/1999/13
Yes, that is the solution in
https://github.com/manjaro/manjaro-tools/issues/208#issuecomment-217862127
with
press the hostkey of your virtualbox plus F2
login on the console
sudo nano /etc/X11/xorg.conf.d/90-mhwd.conf
comment out these lines:

#Section "Device"
# Identifier "Device0"
# Driver "vboxvideo"
#EndSection

save the changes with 'Ctrl'+o and 'Enter' and close with 'Ctrl'+x

Gruß
Ch. Hanisch