moin,
Ist schon ein wenig offtopic.
Habe mir gerade mal die Installationsroutine von LM angeschaut, natürlich ähnlich wie Ubuntu. Fällt mir schwer zu glauben, daß dein Rechner überhaupt nicht mit dem 4.15 funktioniert, ist zwar nicht der neueste, aber noch aktuell. Hatte auch immer mal Startschwierigkeiten bei Installationen, ist häufig behebbar mit Änderung der Bootoptionen. Für Lm siehe hier
Ansonsten LM Forum
Tschau nepo
Warte halt den Monat ab dann kannst genug testen.
Das hat eh für mich NULL priorität... MX Linux läuft ja hervorragen. Insofern...
Dennoch hätte mich interessiert, wie man in einem Install-Image.iso, nen Kernel wechseln kann.
Natürlich hätte ich den Erbauer, dann nach seiner Vorgehensweise befragt...
Verstehst Du?
Das könnte ggf. auch an der internen Firewall liegen. Versuch mal:
sudo systemctl status ufw.service
Ich glaube ich weiss es...
Bei beiden kommt:
System has not been booted with systemd as init system (PID 1). Can't operate.
Failed to connect to bus: Der Rechner ist nicht aktiv
Irgendwo las ich das MX Linux, das booten MIT systemd unterbunden hat...
irgendwie gibt/gab es mit systemd wohl komplikationen...
Ich werde das im laufe des Tages mit systemd aber nochmal testen, bzw. damit booten um zu gucken, ob es damit klappt...
Einfach nur um zu sehen, ob der Fehler dadrauf beruht...
Da das mounten ja grundsätzlich funktioniert und nur Thunar sich da weigert, ist es mir nicht so wichtig.
Anzeigen im Double Commander klappt ja mittels sftp://
Insofern alles gut...
Ich werde berichten...
Fällt mir schwer zu glauben, daß dein Rechner überhaupt nicht mit dem 4.15 funktioniert, ist zwar nicht der neueste, aber noch aktuell. Hatte auch immer mal Startschwierigkeiten bei Installationen, ist häufig behebbar mit Änderung der Bootoptionen. Für Lm siehe hier
Jo, wundert mich eigentlich auch... Dennoch glaube es bitte. An bootoptionen komme ich ja schon nicht mehr ran, denn schon da bleibt der Bildschirm Schwarz.
Ich denke bei der kurzen Zeit, bis 19.3 kommt, lasse ich das ganze nun... Muss ich mal sehen...
sudo systemctl status ufw.service
OK, jetzt mit systemd kommt:
$ sudo systemctl status ufw.service
● ufw.service - Uncomplicated firewall
Loaded: loaded (/lib/systemd/system/ufw.service; enabled; vendor preset: enabled)
Active: active (exited) since Wed 2019-11-13 13:25:14 CET; 12min ago
Docs: man:ufw(8)
Process: 368 ExecStart=/lib/ufw/ufw-init start quiet (code=exited, status=0/SUCCESS)
Main PID: 368 (code=exited, status=0/SUCCESS)
Warning: Journal has been rotated since unit was started. Log output is incomplete or unavailable.
-----------------------------------
Beim Stoppen der Firewall kommt:
$ sudo systemctl stop firewalld.service
Failed to stop firewalld.service: Unit firewalld.service not loaded.
------------------------------------
Beim Start der Firewall kommt:
$ sudo systemctl start firewalld.service
Failed to start firewalld.service: Unit firewalld.service not found.
------------------------------------
Thunar sagt:
Da ich ja nun eigentlich grundsätzlich das NFS-Protokoll erlebte und es im Prinzip für mich OK ist, frage ich nochmal...
Wenn meine Shares über Samba laufen, und auch Kodi und Emby hervorragend damit laufen...
Hat NFS irgendwelche Vorteile in der Geschwindigkeit beispielsweise...???
Warum ich das wissen will ist ganz einfach:
Ich weiss einfach dass ich NIE WIEDER Windows benutzen werde... Und wenn da NFS bzw. sogar NFSv4 da besser sind, würde ich diese Arbeit irgendwann in Angriff nehmen.
INFO:
Warum MX Linux das Systemd zwar mitliefert, jedoch standadmässig nicht aktiviert:
Hier die Antwort: https://mxlinux.org/wiki/system/systemd/
Noch interessanter ist das hier. Speziell der Kommi von Steve(Klasse):
https://mxlinux.org/blog/about-mx-19-and-systemd/
Richtig lesen 
Es läuft entweder ufw oder firewalld. Wenn ufw läuft, dann kannst du nicht versuchen firewalld zu stoppen
versuch mal sudo systemctl stop ufw.service
Irgendwo las ich das MX Linux, das booten MIT systemd unterbunden hat...
Wenn das der Fall ist, dann bin ich raus. Wenn ein System noch init verwendet, müsste ich gerade selbst noch viel googlen und meine Wahl würde dann auf ein anderes OS fallen. init ist schon recht veraltet und sogar urgesteine wie CentOS verwenden schon systemd
Jo, wundert mich eigentlich auch... Dennoch glaube es bitte. An bootoptionen komme ich ja schon nicht mehr ran, denn schon da bleibt der Bildschirm Schwarz.
Ich denke bei der kurzen Zeit, bis 19.3 kommt, lasse ich das ganze nun... Muss ich mal sehen...
Du kannst dich ja in der Zeit etwas umsehen, welche Distro dir am besten gefällt. Am Anfang springt man meist durch einige Distros, bis man dann bei einer landet, die einem genau passt. (einer der Gründe, warum es so viele gibt)
Als Kontrast zu Mx Linux wäre z.B. die KDE Plasma Fassung von Manjaro (https://manjaro.org/download/official/kde/)
(iso auf nen USB Stick und dann vom Stick booten, wenn man es einfach nur mal Anschauen möchte)
Manjaro richtet sich als Arch Derivat aber eher an den schon fortgeschrittenen Linux User. Während MX als "debian stable" Derivat eher auf Stabilität, ältere Software, wenig Speicherverbrauch, kein systemd und Einsteigerfreundlich setzt,
ist Manjaro eher aktuell (Kernel 5.2, mit Update kommt gleich 5.3), sehr aktuelle Software, aber komplexer, viele Quellen (flatpak, snap, aur), KDE größer und mehr Einstellungen usw..
sudo systemctl stop ufw.service
Hat er gemacht... Dennoch das selbe wie vorher... Thunar sagt:
Richtig lesen
Es läuft entweder ufw oder firewalld. Wenn ufw läuft, dann kannst du nicht versuchen firewalld zu stoppen
Ich lese immer richtig.
Wenn ich aber nicht weiss was "ufw" ist, tue ich, was Du mir rätst, weil ich Dich schon etwas kenne und Dir da vertraue...
Wenn das der Fall ist, dann bin ich raus. Wenn ein System noch init verwendet, müsste ich gerade selbst noch viel googlen und meine Wahl würde dann auf ein anderes OS fallen. init ist schon recht veraltet und sogar urgesteine wie CentOS verwenden schon systemd
Ich habe davon keine Ahnung. Ich kann dazu nur sagen, lese Dir den Artikel durch. Denn von init stand dort nichts.
genau genommen steht dort, dass sie sysvinit bzw. systemd-shim benutzen. Vor allem aber sagen sie auch warum und welche Vor- Nachteile das hat...
Das eigentliche Gemeckere "DORT" von einigen Trollen kann ich absolut nicht nachvollziehen.
Die MX Linux Leute, sagen doch KLAR und DEUTLICH dass sie systemd beibehalten, nur eben Standartmässig deaktivieren.
Du selbst entscheidest als MX Linux-User, boote ich mit systemd oder eben nicht.
In GRUB-> einmal runter -> ENTER
Fertig.
Das ist wirklich meckern auf höchsten Niveau, wenn man es trotz der Fehler mit dem tmp und pulsaudio dem User überläßt, was er möchte.
Ich sagte ja; Lese Dir die beiden Links bei wirklichem Interesse ruhig durch... Is interessant...
Mehr möchte ich dazu aber nicht mehr sagen... Ich kenne mich mit diesen systemd, init, sysvinit oder systemd-shim nicht aus.
Kann da null mitreden...
Willst Du systemd in MX Linux IMMER, genügt EINE Zeile in der /etc/default/grub zu ändern nämlich GRUB_DEFAULT=0 in GRUB_DEFAULT=1.
voila... haste Dein systemd 
Für mich ist das ein Zusatzfeature, anstatt...
Du kannst dich ja in der Zeit etwas umsehen, welche Distro dir am besten gefällt. Am Anfang springt man meist durch einige Distros, bis man dann bei einer landet, die einem genau passt. (einer der Gründe, warum es so viele gibt)
Hmmm, ich frage mich immer zwischen so vielen lieben Hilfreichen Menschen...
Liest eigentlich auch iwer was genau ich schreibe?
Sagte ich denn nicht deutlich genug, dass ich mit MX Linux glücklich und zufrieden bin?
Auch bin ich nicht NEU was Linux betrifft... Hier würde mich dringend interessieren, aus welchen Zeilen von mir, das herausgelesen wird.
Weil ich vom "Favoriten" Linux Mint sprach? Hmmm?
Fakt ist Monarc:
Vielen Dank für Deine Mühe, aber ich suche keine neue Distro. Diese habe ich in MX Linux gefunden...
Warten möchte ich auf Linux Mint mit 4.19er bzw. 5er Kernel, um es live und in Farbe in realen bedingungen, testen zu können.
Dann erst entscheide ich mich, ob ich bei MX Linux bleibe oder doch auf meinen ehemaligen Favoriten hüpfe...
Es ist daher FÜR MICH wirklich besser, wenn hier nicht soviel gerüchte gestreut werden, nur weil jemand nicht genau liest was ich möchte, habe, und in was ich mich verliebte
Alles andere hier im Thread sind Feinheiten, die evtl. Userfehler (meiner Einer) beseitigen.
zB. das was ich grad mit @DaVu mache bzw. wir...
Ich lerne aus dem Tips...
Insofern: Alles ist Gut
Dennoch hätte mich interessiert, wie man in einem Install-Image.iso, nen Kernel wechseln kann.
Wenn das auf Ubuntubasis läuft, dann sollte der Weg gehen: https://wiki.ubuntuusers.de/LiveCD_manuell_remastern/
Sieht sehr komplex aus, ist es aber letztendlich nicht, wenn man sich schritt für Schritt an die Anleitung hält
Wenn das auf Ubuntubasis läuft, dann sollte der Weg gehen: http://wiki.ubuntuusers.de/LiveCD_manuell_remastern/
Sieht sehr komplex aus, ist es aber letztendlich nicht, wenn man sich schritt für Schritt an die Anleitung hält
OK, das klingt einfach...
Kannst Du mir hier sagen, an welcher Stelle dort aber der Kernel gewechselt wird?
Ich fand hier nur den Hinweis darauf, dass man zwischen
Bearbeiten des Live-Systems
und
Abschließen der Modifikationen
Das System verändern kann. Nicht aber wie ich dort einen anderen Kernel auswechseln kann...
Aber Danke für den Link, der könnte iwann mal Hilfreich sein..
Sobald du in die chroot gewechselt bist und du Pakete de-/installieren kannst, solltest du den Kernel wechseln können. Jedenfalls vermute ich das
Sobald du in die chroot gewechselt bist und du Pakete de-/installieren kannst, solltest du den Kernel wechseln können. Jedenfalls vermute ich das
Ahh OK:
chroot steht für „change root“ und ist eine Funktion unter Unix-Systemen, um das Rootverzeichnis zu ändern. Sie wirkt sich nur auf den aktuellen Prozess und seine Kindprozesse aus. „chroot“ selbst kann sich sowohl auf den Systemaufruf chroot(2) als auch auf das Dienstprogramm chroot(8) beziehen.
Danke... wees trotzdem nicht, wie ich dann dort den Kernel wechsle...
Ich glaub da bräuchte ich dann schon noch mehr Input um das genau zu verstehen...
Warum verkomplizierst du dir das jetzt, indem du Begrifflichkeiten auseinanderklaubst. Lies die Anleitung und den Punkt
Innerhalb der aktuellen chroot-Umgebung werden alle Änderungen relativ zum Wurzelverzeichnis des zukünftigen Livesystems ausgeführt. Das bedeutet insbesondere, dass nur bereits auf dem Livesystem vorhandene Programme und Einstellungen sichtbar sind.
hab ich halt etwas verkürzt dargestellt. Und so wie du den Kernel bei deinem System geändert hast, sollte dies auch nun in der aktuellen chroot- Umgebung funktionieren, schließlich kannst du den Kernel ja auch wie ein anderes Paket installieren. Ansonsten könnte das was sein: http://linuxiumcomau.blogspot.com/2017/06/custom…umentation.html
Wenn das systemd Kommando funktioniert, dann hast du systemd auch am laufen und ich würde dir empfehlen auch dabei zu bleiben. init stirbt mehr und mehr aus.
Was mich jedoch wunder ist, dass du das Verzeichnis (ich denke, dass das der mountpoint ist) in Thunas nicht öffnen kannst.
Kannst du mir mal deine /etc/exports zeigen.
Keine Sorge, da steht nichts drin, was geheim sein müsste.
Wie, also mit welchem Befehl hast du das genau gemountet?
Ich gehe davon aus, dass MX Linux Ubuntu/Debian basiert ist und du solltest solche shares in /media/ mounten.
Also solltest du sowas wie: sudo -t nfs -o vers=<version> <ip>:/pfad/share /media/<mountpoint>
Wenn du via Kommandozeile in deinen "aktuellen" mountpoint wechselst, erhälst du mit pwd die genau Pfadangabe.
Also hierzu möchte ich schonmal sagen, dass mich das "world writable" schon etwas erschreckte und ich mich demnächst mit der Firewall beschäftigen werde.
Auf jedenfall ist wirklich "ufw" hier installiert, inaktiv aber nicht eingerichtet...
Is das bei vpn-verbindungen eigentl. überhaupt noch relevant?
Wie dem auch sei... würdest Du mir/uns Deine ufw-config mal überlassen?
Zu Thunar, NFS usw. komme ich später nochmal zurück...
Warum verkomplizierst du dir das jetzt, indem du Begrifflichkeiten auseinanderklaubst. Lies die Anleitung und den Punkt
"auseinanderklaubst" ist hier einfach der falsche Ausdruck glaube ich... Einfach weil ich "Chroot" erst jetzt in gänze(naja) verstehe...
Verstehst Du mich da ein wenig...
hab ich halt etwas verkürzt dargestellt. Und so wie du den Kernel bei deinem System geändert hast, sollte dies auch nun in der aktuellen chroot- Umgebung funktionieren, schließlich kannst du den Kernel ja auch wie ein anderes Paket installieren. Ansonsten könnte das was sein: http://linuxiumcomau.blogspot.com/201…u-isos-documentation.html
Warscheinlich lag es daran, dass Du's verkürztes, ja...
Nichts desto trotz begreife ich jetzt offensichtlich was für Auswirkungen es hat, wenn man / zB. in eine (entpackte) ISO-Live-CD-Strucktur umlegt.
Ich würde es fast wie ein Boot-Platten-Wechsel beschreiben... "Interpretiere" ich das richtig?
Yeah, ich glaube ich habe verstanden und werde es bei Zeiten ausprobieren... Danke Dir.
Wenn das systemd Kommando funktioniert, dann hast du systemd auch am laufen
@DaVu, ganz ehrlich... ich möchte mich nicht mit Dir Streiten, aber Du schriebst ich solle GENAU LESEN.
Dann bitte tue Du das auch... Ich habe genau geschrieben, wie man unter MX Linux das gesammte System mit systemd bootet.
GRUB Eintrag 0 = ohne Systemd sondern mit sysvinit bzw. systemd-shim
GRUB Eintrag 1 = MIT Systemd
Nochmal:
Du musst hier schon verstehen, dass MX Linux EBEN NICHT von Systemd weg ist, sondern hier eine ZUSÄTZLICHE Boot-Alternative (die auch DEFAULT=0 werden kann), anbietet.
Also absolut GAR KEIN Grund von MX Linux weg zu gehen...
Frage:
Hast Du es mitbekommen, dass ich NIE etwas von "init" schrieb sondern von sysvinit und systemd-shim
Oder ist sysvinit das gleich wie init? Was ist dann systemd-shim?
und ich würde dir empfehlen auch dabei zu bleiben. init stirbt mehr und mehr aus.
Und hier verstehe ich meine beiden Links eben völlig anders. Nämlich so, als würde init etwas völlig andere sein als sysvinit bzw. systemd-shim.
Bitte hier dringens um Aufklärung.
Da @DaVu wohl hier nur querliest.. Sorry, aber wenn Du darauf nicht eingehst...
Was mich jedoch wunder ist, dass du das Verzeichnis (ich denke, dass das der mountpoint ist) in Thunas nicht öffnen kannst.
Nöö, war die Netzwerksuche und das Ergebnis zeigte ich Dir als Screenshot an... Hätte man Anhand der Icons aber erkennen müssen...
Kannst du mir mal deine /etc/exports zeigen.
Klar. Selbstverständlich:
/etc/exports
# This configuration file is auto-generated.
# WARNING: Do not edit this file, your changes will be lost.#
# /etc/exports: the access control list for filesystems which may be exported
# to NFS clients. See exports(5).
/export/TSMD 192.168.178.0/24(fsid=1,rw,subtree_check,insecure)
# NFSv4 - pseudo filesystem root
/export 192.168.178.0/24(ro,fsid=0,root_squash,no_subtree_check,hide)
Wie, also mit welchem Befehl hast du das genau gemountet?
sudo mount -t nfs -o vers=3 homeserver:/export/TSMD /export/TSMD
KLAPPT
sudo mount -t nfs -o vers=4 homeserver:/export/TSMD /export/TSMD
KLAPPT ebenfalls
Auch KLAPPT
sudo mount -t nfs homeserver:/export/TSMD /export/TSMD
Alles obige klappt auch mit der IP.
Ich will nur dass Du weisst, dass ich das alles durchprobiert habe.
Die /etc/exports liegt natürlich und selbstverständlich auf dem Server, auf dem OMV (OpenMediaVault (Debian(Stretch))) läuft.
Ich gehe davon aus, dass MX Linux Ubuntu/Debian basiert ist und du solltest solche shares in /media/ mounten.
Also solltest du sowas wie: sudo -t nfs -o vers=<version> <ip>:/pfad/share /media/<mountpoint>
Jeppt Debian 10 (Buster)
OMV legt sie AUTOMATISCH am Server in den Ordner /export
Sambafreigaben allerdings in /sharedfolders
Welche ich per fstab allerdings zusätzlich in /media mounte...
Was ich auch mit den /exports machen würde...
Daran möchte ich nicht rütteln, weil ich was das angeht, gern mit der Weboberfläche arbeite... Die macht das nunmal so...
Ausser natürlich das mit der fstab, das mache ich so, weils hervorragend klappt und ich es mir dadurch einfacher machte für die Zukunft...
Das ganze führt aber zu weit...
Wenn du via Kommandozeile in deinen "aktuellen" mountpoint wechselst, erhälst du mit pwd die genau Pfadangabe.
$ pwd
/export
Hmm, aber das weiß ich doch schon... Bin doch mit cd /ex<TAB> reingesprungen...
Was ich halt verstehen möchte ist, warum wir zB. OHNE Firewall (DAS SAGTE ICH DIR) an diesen Dingen fummeln wollen...
Thunar sagt immer noch:
hab ich halt etwas verkürzt dargestellt. Und so wie du den Kernel bei deinem System geändert hast, sollte dies auch nun in der aktuellen chroot- Umgebung funktionieren, schließlich kannst du den Kernel ja auch wie ein anderes Paket installieren. Ansonsten könnte das was sein: http://linuxiumcomau.blogspot.com/201…u-isos-documentation.html
Ich habs gemach und es verlief auch alles absolut unkompliziert.
Nun, als ich die Kernel-Header und das Image installieren wollte kommt folgendes:
sudo dpkg -i *deb
Selecting previously unselected package linux-headers-4.19.0-041900-generic.
(Reading database ... 253788 files and directories currently installed.)
Preparing to unpack linux-headers-4.19.0-041900-generic_4.19.0-041900.201810221809_amd64.deb ...
Unpacking linux-headers-4.19.0-041900-generic (4.19.0-041900.201810221809) ...
Selecting previously unselected package linux-headers-4.19.0-041900.
Preparing to unpack linux-headers-4.19.0-041900_4.19.0-041900.201810221809_all.deb ...
Unpacking linux-headers-4.19.0-041900 (4.19.0-041900.201810221809) ...
Selecting previously unselected package linux-image-unsigned-4.19.0-041900-generic.
Preparing to unpack linux-image-unsigned-4.19.0-041900-generic_4.19.0-041900.201810221809_amd64.deb ...
Unpacking linux-image-unsigned-4.19.0-041900-generic (4.19.0-041900.201810221809) ...
Setting up linux-headers-4.19.0-041900 (4.19.0-041900.201810221809) ...
dpkg: dependency problems prevent configuration of linux-image-unsigned-4.19.0-041900-generic:
linux-image-unsigned-4.19.0-041900-generic depends on linux-modules-4.19.0-041900-generic; however:
Package linux-modules-4.19.0-041900-generic is not installed.
dpkg: error processing package linux-image-unsigned-4.19.0-041900-generic (--install):
dependency problems - leaving unconfigured
Setting up linux-headers-4.19.0-041900-generic (4.19.0-041900.201810221809) ...
/etc/kernel/header_postinst.d/dkms:
* dkms: running auto installation service for kernel 4.19.0-041900-generic
...done.
Errors were encountered while processing:
linux-image-unsigned-4.19.0-041900-generic
root@test-VirtualBox:/#
---------------------------------------
Kannst Du dazu etwas sagen, bevor ich das Live-System nun abschliesse und es testen kann?
Also ich würde versuchen das über ein entsprechendes Kernelrepository zu installieren. Dann können auch Abhängigkeiten automatisch aufgelöst werden
Was ich gerade nicht verstehe, warum läuft das in einer VirtualBox? Das ist doch gar nicht notwendig..
Also ich würde versuchen das über ein entsprechendes Kernelrepository zu installieren. Dann können auch Abhängigkeiten automatisch aufgelöst werden
Ahh OK, das ist ne gute Idee...
Leider habe ich mir grad ein wenig das Mint-vdi zerschossen, sodass ich es nochmal neu installieren muss.
Ist aber kein Problem, da sowas schnell installiert ist...
Was ich gerade nicht verstehe, warum läuft das in einer VirtualBox? Das ist doch gar nicht notwendig..
Warum denn nicht?
Weil es mich in den Fingern juckte, dass ganze jetzt einfach mal zu tun...
Und wenn man sich nicht zu 100% sicher ist, mache ich das lieber in einer VM...
Verstehst Du das echt nicht?
Was mich viel mehr wundert ist, warum die VirtualBox-VMs unter Linux so schnell sind.
Man merkt oft gar nicht, dass man NUR in einer VM arbeitet... Geht Dir das auch so?
Also das Problem mit einem Lifesystem ist, dass wenn es keine Persistenz hat, die Änderungen nach einem Neustart weg sind. Und wenn du mit einer Persistenz arbeitest, dann musst du diese auch auf dein installationsmedium rüberziehen, was du also machst ist in etwa das gleiche, wenn du an deinem laufenden system den Kernel wechselst, davon hast du auch keine installationsiso mit gewechseltem Kernel.
Und ich benutze unter Linux keine VMs, da habe ich einfach keine Notwendigkeit für
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!
