Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > de.comp.os.unix.linux.misc > #112578 > unrolled thread
| Started by | Matthias Gerds <m.gerds@posteo.de> |
|---|---|
| First post | 2020-10-16 09:49 +0000 |
| Last post | 2020-10-23 10:53 +0200 |
| Articles | 13 on this page of 33 — 7 participants |
Back to article view | Back to de.comp.os.unix.linux.misc
Nvidia-Treiber Matthias Gerds <m.gerds@posteo.de> - 2020-10-16 09:49 +0000
Re: Nvidia-Treiber Matthias Gerds <m.gerds@posteo.de> - 2020-10-16 12:05 +0200
Re: Nvidia-Treiber Matthias Gerds <m.gerds@posteo.de> - 2020-10-16 15:20 +0200
Re: Nvidia-Treiber Matthias Gerds <m.gerds@posteo.de> - 2020-10-17 02:40 +0200
Re: Nvidia-Treiber Matthias Gerds <m.gerds@posteo.de> - 2020-10-17 17:05 +0200
Re: Nvidia-Treiber Torsten Berger <toberger@t-online.de> - 2020-10-17 20:43 +0200
Re: Nvidia-Treiber Torsten Berger <toberger@t-online.de> - 2020-10-17 22:58 +0200
Re: Nvidia-Treiber Matthias Gerds <m.gerds@posteo.de> - 2020-10-18 17:33 +0200
Re: Nvidia-Treiber Torsten Berger <toberger@t-online.de> - 2020-10-18 20:32 +0200
Re: Nvidia-Treiber Matthias Gerds <m.gerds@posteo.de> - 2020-10-19 02:23 +0200
Re: Nvidia-Treiber Christian Garbs <mitch@cgarbs.de> - 2020-10-19 09:30 +0200
Re: Nvidia-Treiber Matthias Gerds <m.gerds@posteo.de> - 2020-10-22 07:35 +0200
Re: Nvidia-Treiber Jens Schüßler <jgs@trash.net> - 2020-10-22 19:05 +0200
Re: Nvidia-Treiber Matthias Gerds <m.gerds@posteo.de> - 2020-10-22 21:45 +0200
Re: Nvidia-Treiber Christian Garbs <mitch@cgarbs.de> - 2020-10-23 10:03 +0200
Re: Nvidia-Treiber Matthias Gerds <m.gerds@posteo.de> - 2020-10-23 10:44 +0200
Re: Nvidia-Treiber Christian Garbs <mitch@cgarbs.de> - 2020-10-29 16:50 +0100
Re: Nvidia-Treiber Holger Schauer <Holger.Schauer@gmx.de> - 2020-10-30 16:14 +0100
Re: Nvidia-Treiber Jens Schüßler <jgs@trash.net> - 2020-10-24 19:48 +0200
Re: Nvidia-Treiber Matthias Gerds <m.gerds@posteo.de> - 2020-10-26 02:34 +0100
Re: Nvidia-Treiber Matthias Gerds <m.gerds@posteo.de> - 2020-10-26 02:35 +0100
Re: Nvidia-Treiber Marc Haber <mh+usenetspam1118@zugschl.us> - 2020-10-26 16:35 +0100
Re: Nvidia-Treiber Matthias Gerds <m.gerds@posteo.de> - 2020-10-26 23:34 +0100
Re: Nvidia-Treiber Jens Schüßler <jgs@trash.net> - 2020-10-27 01:17 +0100
Re: Nvidia-Treiber Marc Haber <mh+usenetspam1118@zugschl.us> - 2020-10-27 16:16 +0100
Re: Nvidia-Treiber Matthias Gerds <m.gerds@posteo.de> - 2020-10-27 17:11 +0100
Re: Nvidia-Treiber Jens Schüßler <jgs@trash.net> - 2020-10-27 01:13 +0100
Re: Nvidia-Treiber Bernd Mayer <beam.bam.boom@knuut.de> - 2020-10-27 09:49 +0100
Re: Nvidia-Treiber Torsten Berger <toberger@t-online.de> - 2020-10-27 16:31 +0100
Re: Nvidia-Treiber Christian Garbs <mitch@cgarbs.de> - 2020-10-22 19:29 +0200
Re: Nvidia-Treiber Matthias Gerds <m.gerds@posteo.de> - 2020-10-22 21:53 +0200
Re: Nvidia-Treiber Christian Garbs <mitch@cgarbs.de> - 2020-10-23 09:56 +0200
Re: Nvidia-Treiber Matthias Gerds <m.gerds@posteo.de> - 2020-10-23 10:53 +0200
Page 2 of 2 — ← Prev page 1 [2]
| From | Matthias Gerds <m.gerds@posteo.de> |
|---|---|
| Date | 2020-10-26 02:35 +0100 |
| Message-ID | <hvmnenF2hboU2@mid.individual.net> |
| In reply to | #112748 |
On 24.10.20 19:48, Jens Schüßler wrote:
> * Matthias Gerds <m.gerds@posteo.de> [22-10-20 19:45]:
>> On 22.10.20 19:05, Jens Schüßler wrote:
>>>
>>> Darf man fragen warum du denn überhaupt den Nvidia-Treiber aus den Backports
>>> installierst wenn du ansonsten buster fährst? Geht der in stable
>>> nicht oder erhoffst du dir neue Features wenn du einen aus backports
>>> nutzt?
>>
>> Weil das explizit auf dem Wiki beschrieben ist, dass der neueste Version
>> 450.66 nur über die Backports installierbar ist. Wahrscheinlich weil
>> Debian/LMDE traditionell eher einen älteren Kenel fährt.
>
> Das ist mir schon klar.
> Was meine Frage aber nicht beantwortet, warum du glaubst diese neueste
> Version zu benötigen. Falls es mit der abgehangenen aus stable bis dato
> keine Probleme gab, aber mit der aus Backports schon, würde ich doch
> bei dieser bleiben.
Weil die Softwareaktualisierung mir das angeboten bzw. mich ständig mit
dieser Benachrichtigung genervt hat.
>> Wusste ehrlich gesagt ich auch nicht, wie man den älteren Treiber
>> installiert. nvidia-driver installiert ja automatisch den 450.66.
>
> Nur wenn man das mal implizit angeben hat buster-backports für das Paket
> zu benutzen.
> Willst du downgraden solltest du mal dies versuchen
> ,----
> | apt-get install nvidia-driver/buster
> `----
Ja, da will er tatsächlich den 418.152.xx installieren. Warum das jetzt
durch '/buster' geht weiß wohl nur der Eingeweihte. Es werden aber
diverse nicht näher spezifizierte Fehler angezeigt:
====================================================
sudo apt-get install nvidia-driver/buster
[sudo] Passwort für mg:
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.
Statusinformationen werden eingelesen.... Fertig
Version »418.152.00-1« (Debian:10.6/stable [amd64]) für »nvidia-driver«
gewählt.
Version »418.152.00-1« (Debian:10.6/stable [amd64]) für
»nvidia-driver-libs« gewählt aufgrund von »nvidia-driver«.
Version »418.152.00-1« (Debian:10.6/stable [amd64]) für
»libgl1-nvidia-glvnd-glx« gewählt aufgrund von »nvidia-driver-libs«.
Version »418.152.00-1« (Debian:10.6/stable [amd64]) für »libglx-nvidia0«
gewählt aufgrund von »libgl1-nvidia-glvnd-glx«.
Version »418.152.00-1« (Debian:10.6/stable [amd64]) für
»nvidia-alternative« gewählt aufgrund von »libglx-nvidia0«.
Version »418.152.00-1« (Debian:10.6/stable [amd64]) für
»libnvidia-glcore« gewählt aufgrund von »libglx-nvidia0«.
Version »418.152.00-1« (Debian:10.6/stable [amd64]) für »nvidia-egl-icd«
gewählt aufgrund von »nvidia-driver-libs«.
Version »418.152.00-1« (Debian:10.6/stable [amd64]) für »libegl-nvidia0«
gewählt aufgrund von »nvidia-egl-icd«.
Version »418.152.00-1« (Debian:10.6/stable [amd64]) für
»libnvidia-eglcore« gewählt aufgrund von »libegl-nvidia0«.
Version »418.152.00-1« (Debian:10.6/stable [amd64]) für
»libgles-nvidia1« gewählt aufgrund von »nvidia-driver-libs«.
Version »418.152.00-1« (Debian:10.6/stable [amd64]) für
»libgles-nvidia2« gewählt aufgrund von »nvidia-driver-libs«.
Version »418.152.00-1« (Debian:10.6/stable [amd64]) für »libnvidia-cfg1«
gewählt aufgrund von »nvidia-driver-libs«.
Version »418.152.00-1« (Debian:10.6/stable [amd64]) für
»nvidia-vulkan-icd« gewählt aufgrund von »nvidia-driver-libs«.
Version »418.152.00-1« (Debian:10.6/stable [amd64]) für
»libnvidia-glvkspirv« gewählt aufgrund von »nvidia-vulkan-icd«.
Version »418.152.00-1« (Debian:10.6/stable [amd64]) für »libnvidia-cbl«
gewählt aufgrund von »nvidia-vulkan-icd«.
Version »418.152.00-1« (Debian:10.6/stable [amd64]) für
»libnvidia-fatbinaryloader« gewählt aufgrund von »libnvidia-cbl«.
Version »418.152.00-1« (Debian:10.6/stable [amd64]) für
»libnvidia-ptxjitcompiler1« gewählt aufgrund von
»libnvidia-fatbinaryloader«.
Version »418.152.00-1« (Debian:10.6/stable [amd64]) für
»libnvidia-rtcore« gewählt aufgrund von »nvidia-vulkan-icd«.
Version »418.152.00-1« (Debian:10.6/stable [amd64]) für
»nvidia-driver-bin« gewählt aufgrund von »nvidia-driver«.
Version »418.152.00-1« (Debian:10.6/stable [amd64]) für
»xserver-xorg-video-nvidia« gewählt aufgrund von »nvidia-driver«.
Version »418.152.00-1« (Debian:10.6/stable [amd64]) für
»nvidia-kernel-dkms« gewählt aufgrund von »xserver-xorg-video-nvidia«.
Version »418.152.00-1« (Debian:10.6/stable [amd64]) für
»nvidia-vdpau-driver« gewählt aufgrund von »nvidia-driver«.
Einige Pakete konnten nicht installiert werden. Das kann bedeuten, dass
Sie eine unmögliche Situation angefordert haben oder, wenn Sie die
Unstable-Distribution verwenden, dass einige erforderliche Pakete noch
nicht erstellt wurden oder Incoming noch nicht verlassen haben.
Die folgenden Informationen helfen Ihnen vielleicht, die Situation zu lösen:
Die folgenden Pakete haben unerfüllte Abhängigkeiten:
nvidia-driver : Hängt ab von: nvidia-driver-libs (= 418.152.00-1) soll
aber nicht installiert werden oder
nvidia-driver-libs-nonglvnd (=
418.152.00-1) soll aber nicht installiert werden
Hängt ab von: nvidia-driver-bin (= 418.152.00-1) soll
aber nicht installiert werden
Hängt ab von: xserver-xorg-video-nvidia (=
418.152.00-1) soll aber nicht installiert werden
Hängt ab von: nvidia-kernel-dkms (= 418.152.00-1) soll
aber nicht installiert werden oder
nvidia-kernel-418.152.00
E: Probleme können nicht korrigiert werden, Sie haben zurückgehaltene
defekte Pakete.
====================================================
Die Fehler werden unter Synaptic aber nicht angezeigt, warum auch immer.
Mittlerweile habe ich auch herausgefunden, wie man auf einem
Systemd-System in den Textmodus kommt:
systemctl set-default multi-user.target
systemctl reboot
Denn das ist auf jeden Fall sicherer, wenn ein neuer Grafiktreiber zu
installieren ist (für's nächste Mal).
M:
[toc] | [prev] | [next] | [standalone]
| From | Marc Haber <mh+usenetspam1118@zugschl.us> |
|---|---|
| Date | 2020-10-26 16:35 +0100 |
| Message-ID | <rn6qct$1ul$1@news1.tnib.de> |
| In reply to | #112754 |
Matthias Gerds <m.gerds@posteo.de> wrote: >Mittlerweile habe ich auch herausgefunden, wie man auf einem >Systemd-System in den Textmodus kommt: > >systemctl set-default multi-user.target >systemctl reboot > >Denn das ist auf jeden Fall sicherer, wenn ein neuer Grafiktreiber zu >installieren ist (für's nächste Mal). Ja, bei nVidia braucht man das. Bei allen anderen Open Source Treibern macht man einfach das Update und alles ist fein. In einem Mehrrechnerhaushalt wäre übrigens ssh von einem anderen System eine Möglichkeit sich den reboot zu ersparen. Grüße Marc -- -------------------------------------- !! No courtesy copies, please !! ----- Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
[toc] | [prev] | [next] | [standalone]
| From | Matthias Gerds <m.gerds@posteo.de> |
|---|---|
| Date | 2020-10-26 23:34 +0100 |
| Message-ID | <hvp17cFhd8oU1@mid.individual.net> |
| In reply to | #112755 |
On 26.10.20 16:35, Marc Haber wrote: > Matthias Gerds <m.gerds@posteo.de> wrote: >> Mittlerweile habe ich auch herausgefunden, wie man auf einem >> Systemd-System in den Textmodus kommt: >> >> systemctl set-default multi-user.target >> systemctl reboot >> >> Denn das ist auf jeden Fall sicherer, wenn ein neuer Grafiktreiber zu >> installieren ist (für's nächste Mal). > > Ja, bei nVidia braucht man das. Bei allen anderen Open Source Treibern > macht man einfach das Update und alles ist fein. Mit dem Open-Souce-Treiber für Nvidia-Karten kann man eben nicht spielen und auch sonst kann der Nouveau-Treiber kaum befriedigen. Das sieht wohl bei AMD inzwischen anders aus. Überlege mir echt, beim nächsten Rechner auf eine AMD-Karte umzusteigen. Passt dann auch mit dem Ryzen zusammen. > In einem Mehrrechnerhaushalt wäre übrigens ssh von einem anderen > System eine Möglichkeit sich den reboot zu ersparen. Verstehe ich nicht. Inwiefern könnte ssh den Reboot auf der Maschine mit dem neuen Treiber ersparen, damit er geladen wird? Könnte man doch auch an der Maschine selbst, wenn man die Mühen der Systemd-Befehle nicht scheut. Reboot ist halt schneller und einfacher. M:
[toc] | [prev] | [next] | [standalone]
| From | Jens Schüßler <jgs@trash.net> |
|---|---|
| Date | 2020-10-27 01:17 +0100 |
| Message-ID | <rh5k6h-4p1.ln1@luEaABwb52.dumb1.com> |
| In reply to | #112756 |
* Matthias Gerds <m.gerds@posteo.de> [26-10-20 22:34]: > On 26.10.20 16:35, Marc Haber wrote: >> Matthias Gerds <m.gerds@posteo.de> wrote: >>> Mittlerweile habe ich auch herausgefunden, wie man auf einem >>> Systemd-System in den Textmodus kommt: >>> >>> systemctl set-default multi-user.target >>> systemctl reboot >>> >>> Denn das ist auf jeden Fall sicherer, wenn ein neuer Grafiktreiber zu >>> installieren ist (für's nächste Mal). >> >> Ja, bei nVidia braucht man das. Bei allen anderen Open Source Treibern >> macht man einfach das Update und alles ist fein. > > Mit dem Open-Souce-Treiber für Nvidia-Karten kann man eben nicht spielen > und auch sonst kann der Nouveau-Treiber kaum befriedigen. Da muß ich irgendwas falsch machen. Seit drei Jahren auf nouveau umgestiegen, kann immer noch spielen spielen und alles machen was ich vorher gemacht habe. Einziger Effekt war der Wegfall extremer permanenter Schmerzen mit dem proprietären Nvidia-Geraffel, solche wie du sie gerade hast.
[toc] | [prev] | [next] | [standalone]
| From | Marc Haber <mh+usenetspam1118@zugschl.us> |
|---|---|
| Date | 2020-10-27 16:16 +0100 |
| Message-ID | <rn9dkn$g9e$1@news1.tnib.de> |
| In reply to | #112756 |
Matthias Gerds <m.gerds@posteo.de> wrote: >Verstehe ich nicht. Inwiefern könnte ssh den Reboot auf der Maschine mit >dem neuen Treiber ersparen, damit er geladen wird? Kann man nicht, aber man muss nicht vorher in einen "Textmodus" umbooten weil man die Konsole nicht verliert wenn die Grafikkarte in einen komischen Zustand fällt. Grüße Marc -- -------------------------------------- !! No courtesy copies, please !! ----- Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
[toc] | [prev] | [next] | [standalone]
| From | Matthias Gerds <m.gerds@posteo.de> |
|---|---|
| Date | 2020-10-27 17:11 +0100 |
| Message-ID | <hvqv5kFtlkqU1@mid.individual.net> |
| In reply to | #112769 |
Am 27.10.20 um 16:16 schrieb Marc Haber: > Matthias Gerds <m.gerds@posteo.de> wrote: >> Verstehe ich nicht. Inwiefern könnte ssh den Reboot auf der Maschine mit >> dem neuen Treiber ersparen, damit er geladen wird? > > Kann man nicht, aber man muss nicht vorher in einen "Textmodus" > umbooten weil man die Konsole nicht verliert wenn die Grafikkarte in > einen komischen Zustand fällt. Als Ersatz für die kaputten virtuellen Konsolen, ok. M:
[toc] | [prev] | [next] | [standalone]
| From | Jens Schüßler <jgs@trash.net> |
|---|---|
| Date | 2020-10-27 01:13 +0100 |
| Message-ID | <2a5k6h-4p1.ln1@luEaABwb52.dumb1.com> |
| In reply to | #112754 |
* Matthias Gerds <m.gerds@posteo.de> [26-10-20 01:35]: >> `---- > > Ja, da will er tatsächlich den 418.152.xx installieren. Warum das jetzt > durch '/buster' geht weiß wohl nur der Eingeweihte. Es werden aber > diverse nicht näher spezifizierte Fehler angezeigt: > > ==================================================== > sudo apt-get install nvidia-driver/buster > [sudo] Passwort für mg: > Paketlisten werden gelesen... Fertig > Abhängigkeitsbaum wird aufgebaut. > Statusinformationen werden eingelesen.... Fertig > Version »418.152.00-1« (Debian:10.6/stable [amd64]) für »nvidia-driver« > gewählt. > Version »418.152.00-1« (Debian:10.6/stable [amd64]) für >»nvidia-driver-libs« gewählt aufgrund von »nvidia-driver«. > Version »418.152.00-1« (Debian:10.6/stable [amd64]) für >»libgl1-nvidia-glvnd-glx« gewählt aufgrund von »nvidia-driver-libs«. > Version »418.152.00-1« (Debian:10.6/stable [amd64]) für »libglx-nvidia0« > gewählt aufgrund von »libgl1-nvidia-glvnd-glx«. > Version »418.152.00-1« (Debian:10.6/stable [amd64]) für >»nvidia-alternative« gewählt aufgrund von »libglx-nvidia0«. > Version »418.152.00-1« (Debian:10.6/stable [amd64]) für >»libnvidia-glcore« gewählt aufgrund von »libglx-nvidia0«. > Version »418.152.00-1« (Debian:10.6/stable [amd64]) für »nvidia-egl-icd« > gewählt aufgrund von »nvidia-driver-libs«. > Version »418.152.00-1« (Debian:10.6/stable [amd64]) für »libegl-nvidia0« > gewählt aufgrund von »nvidia-egl-icd«. > Version »418.152.00-1« (Debian:10.6/stable [amd64]) für >»libnvidia-eglcore« gewählt aufgrund von »libegl-nvidia0«. > Version »418.152.00-1« (Debian:10.6/stable [amd64]) für >»libgles-nvidia1« gewählt aufgrund von »nvidia-driver-libs«. > Version »418.152.00-1« (Debian:10.6/stable [amd64]) für >»libgles-nvidia2« gewählt aufgrund von »nvidia-driver-libs«. > Version »418.152.00-1« (Debian:10.6/stable [amd64]) für »libnvidia-cfg1« > gewählt aufgrund von »nvidia-driver-libs«. > Version »418.152.00-1« (Debian:10.6/stable [amd64]) für >»nvidia-vulkan-icd« gewählt aufgrund von »nvidia-driver-libs«. > Version »418.152.00-1« (Debian:10.6/stable [amd64]) für >»libnvidia-glvkspirv« gewählt aufgrund von »nvidia-vulkan-icd«. > Version »418.152.00-1« (Debian:10.6/stable [amd64]) für »libnvidia-cbl« > gewählt aufgrund von »nvidia-vulkan-icd«. > Version »418.152.00-1« (Debian:10.6/stable [amd64]) für >»libnvidia-fatbinaryloader« gewählt aufgrund von »libnvidia-cbl«. > Version »418.152.00-1« (Debian:10.6/stable [amd64]) für >»libnvidia-ptxjitcompiler1« gewählt aufgrund von >»libnvidia-fatbinaryloader«. > Version »418.152.00-1« (Debian:10.6/stable [amd64]) für >»libnvidia-rtcore« gewählt aufgrund von »nvidia-vulkan-icd«. > Version »418.152.00-1« (Debian:10.6/stable [amd64]) für >»nvidia-driver-bin« gewählt aufgrund von »nvidia-driver«. > Version »418.152.00-1« (Debian:10.6/stable [amd64]) für >»xserver-xorg-video-nvidia« gewählt aufgrund von »nvidia-driver«. > Version »418.152.00-1« (Debian:10.6/stable [amd64]) für >»nvidia-kernel-dkms« gewählt aufgrund von »xserver-xorg-video-nvidia«. > Version »418.152.00-1« (Debian:10.6/stable [amd64]) für >»nvidia-vdpau-driver« gewählt aufgrund von »nvidia-driver«. > Einige Pakete konnten nicht installiert werden. Das kann bedeuten, dass > Sie eine unmögliche Situation angefordert haben oder, wenn Sie die > Unstable-Distribution verwenden, dass einige erforderliche Pakete noch > nicht erstellt wurden oder Incoming noch nicht verlassen haben. > Die folgenden Informationen helfen Ihnen vielleicht, die Situation zu lösen: > > Die folgenden Pakete haben unerfüllte Abhängigkeiten: > nvidia-driver : Hängt ab von: nvidia-driver-libs (= 418.152.00-1) soll > aber nicht installiert werden oder > nvidia-driver-libs-nonglvnd (= > 418.152.00-1) soll aber nicht installiert werden > Hängt ab von: nvidia-driver-bin (= 418.152.00-1) soll > aber nicht installiert werden > Hängt ab von: xserver-xorg-video-nvidia (= > 418.152.00-1) soll aber nicht installiert werden > Hängt ab von: nvidia-kernel-dkms (= 418.152.00-1) soll > aber nicht installiert werden oder > nvidia-kernel-418.152.00 > E: Probleme können nicht korrigiert werden, Sie haben zurückgehaltene > defekte Pakete. Das ist der Grund warum ich aptitude verwende, dessen resolver zeigt einm genau was das Problem ist und schlägt verschiedene Lösungen vor. Dein Problem ist auch irgendwie keines, es müssen brauch einfach nur nur ein downgrade auf buster für diese Pakete. Und deutsche Locale in der Shell stinken immer noch.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Mayer <beam.bam.boom@knuut.de> |
|---|---|
| Date | 2020-10-27 09:49 +0100 |
| Message-ID | <rn8mub$bbm$1@news.dns-netz.com> |
| In reply to | #112754 |
Am 26.10.20 um 02:35 schrieb Matthias Gerds: > > Mittlerweile habe ich auch herausgefunden, wie man auf einem > Systemd-System in den Textmodus kommt: > > systemctl set-default multi-user.target > systemctl reboot > Hallo, geht das nicht auch einfacher über runlevel ohne reboot mit init 2? Bernd Mayer
[toc] | [prev] | [next] | [standalone]
| From | Torsten Berger <toberger@t-online.de> |
|---|---|
| Date | 2020-10-27 16:31 +0100 |
| Message-ID | <r3rl6h-7ia.ln1@tb.all> |
| In reply to | #112759 |
Sorry, die Info wollte ich noch der Vollständigkeit halber nachliefern ... Das soll _KEINE EMPFEHLUNG_ zum Nachmachen sein! Jeder muss selbst entscheiden, ob er so vorgeht oder nicht. -------- $ grep -i "dlloader X Driver" /var/log/Xorg.0.log [ 4.664] (II) NVIDIA dlloader X Driver 450.80.02 Wed Sep 23 00:53:01 UTC 2020 $ cat /proc/cmdline BOOT_IMAGE=/vmlinuz-4.19.0-12-amd64 initrd=/initrd.img-4.19.0-12-amd64 root=LABEL=rootfs ro resume=LABEL=swap vga=845 nomodeset quiet $ cat /proc/version Linux version 4.19.0-12-amd64 (debian-kernel@lists.debian.org) (gcc version 8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 4.19.152-1 (2020-10-18) -------- Ja, auch die Konsolen funktionieren - auch wenn ich mit "systemctl stop lightdm" die X-Session beende. Bye Torsten. -- PGP public key: http://pool.sks-keyservers.net/pks/lookup?op=get&search=0x983B7EA7E3FC9051
[toc] | [prev] | [next] | [standalone]
| From | Christian Garbs <mitch@cgarbs.de> |
|---|---|
| Date | 2020-10-22 19:29 +0200 |
| Message-ID | <rmsfin$odj4$1@yggdrasil.dn.cgarbs.de> |
| In reply to | #112708 |
Mahlzeit! Matthias Gerds <m.gerds@posteo.de> wrote: > On 19.10.20 09:30, Christian Garbs wrote: > Scheint auch eine Eigenheit von Linux Mint zu sein, denn bestimmte > Kernel-Parameter in grub.cfg zu ignorieren, oder ich kenne nicht die > 'richtigen': > vga=ask, text bzw. textonly, init 3 bzw. 3 Ich gehe davon aus, dass Linux Mint systemd einsetzt, dann gibt es das klassische Konzept verschiedener Runlevel nicht mehr in der Form. Ein init 3 dürfte ignoriert werden. telinit(8) sagt hier auf dem Debian Buster, dass Runlevel 1 auf "system rescue modus" mappt, vielleicht kannst Du den mal probieren. Zeigt grub selbst denn die Kernel-Parameter an? Du kannst da ja sogar interaktiv die Boot-Parameter editieren, wenn grub nicht auf "automatisch irgendwas starten" steht. Gruß Christian -- ....Christian.Garbs....................................https://www.cgarbs.de Das beste vom Sonntag ist der Samstagabend.
[toc] | [prev] | [next] | [standalone]
| From | Matthias Gerds <m.gerds@posteo.de> |
|---|---|
| Date | 2020-10-22 21:53 +0200 |
| Message-ID | <hve6a4F956jU1@mid.individual.net> |
| In reply to | #112726 |
On 22.10.20 19:29, Christian Garbs wrote: > Mahlzeit! > > Matthias Gerds <m.gerds@posteo.de> wrote: >> On 19.10.20 09:30, Christian Garbs wrote: > >> Scheint auch eine Eigenheit von Linux Mint zu sein, denn bestimmte >> Kernel-Parameter in grub.cfg zu ignorieren, oder ich kenne nicht die >> 'richtigen': >> vga=ask, text bzw. textonly, init 3 bzw. 3 > > Ich gehe davon aus, dass Linux Mint systemd einsetzt, dann gibt es das > klassische Konzept verschiedener Runlevel nicht mehr in der Form. Ein > init 3 dürfte ignoriert werden. Verstehe. Aber in openSUSE Tumbleweed hat das trotzdem funktioniert. Vielleicht haben sie da die althergebrachten Parameter ge-backport-et oder gemapped oder wie das heißt? > telinit(8) sagt hier auf dem Debian Buster, dass Runlevel 1 auf > "system rescue modus" mappt, vielleicht kannst Du den mal probieren. Text only würde mich interessieren. Ist ja schön, dass Systemd die ganze Sache vereinheitlicht bzw. beschleunigt, aber muss man deswegen alle tradierten Befehle deaktivieren? > Zeigt grub selbst denn die Kernel-Parameter an? Du kannst da ja sogar > interaktiv die Boot-Parameter editieren, wenn grub nicht auf > "automatisch irgendwas starten" steht. Also ich will definitiv nach wie vor bei Bedarf das System auch ohne DM und X starten können. M:
[toc] | [prev] | [next] | [standalone]
| From | Christian Garbs <mitch@cgarbs.de> |
|---|---|
| Date | 2020-10-23 09:56 +0200 |
| Message-ID | <rmu2al$jpss$1@yggdrasil.dn.cgarbs.de> |
| In reply to | #112730 |
Mahlzeit!
Matthias Gerds <m.gerds@posteo.de> wrote:
> On 22.10.20 19:29, Christian Garbs wrote:
>> Ich gehe davon aus, dass Linux Mint systemd einsetzt, dann gibt es
>> das klassische Konzept verschiedener Runlevel nicht mehr in der
>> Form. Ein init 3 dürfte ignoriert werden.
Nach mehr Recherche behaupte ich nun das Gegenteil :)
> Verstehe. Aber in openSUSE Tumbleweed hat das trotzdem funktioniert.
> Vielleicht haben sie da die althergebrachten Parameter ge-backport-et
> oder gemapped oder wie das heißt?
In der Tat, hier sind die Runlevel gemappt. Ich habe das noch nie
benutzt, aber das sieht auf den ersten Blick so aus, als ob der
init=-Parameter tatsächlich etwas tun sollte:
$ ls -lh /usr/lib/systemd/system/runlevel?.target
lrwxrwxrwx 1 root root 15 Apr 27 19:02 /usr/lib/systemd/system/runlevel0.target -> poweroff.target
lrwxrwxrwx 1 root root 13 Apr 27 19:02 /usr/lib/systemd/system/runlevel1.target -> rescue.target
lrwxrwxrwx 1 root root 17 Apr 27 19:02 /usr/lib/systemd/system/runlevel2.target -> multi-user.target
lrwxrwxrwx 1 root root 17 Apr 27 19:02 /usr/lib/systemd/system/runlevel3.target -> multi-user.target
lrwxrwxrwx 1 root root 17 Apr 27 19:02 /usr/lib/systemd/system/runlevel4.target -> multi-user.target
lrwxrwxrwx 1 root root 16 Apr 27 19:02 /usr/lib/systemd/system/runlevel5.target -> graphical.target
lrwxrwxrwx 1 root root 13 Apr 27 19:02 /usr/lib/systemd/system/runlevel6.target -> reboot.target
> Text only würde mich interessieren. Ist ja schön, dass Systemd die
> ganze Sache vereinheitlicht bzw. beschleunigt, aber muss man
> deswegen alle tradierten Befehle deaktivieren?
Das haben sie hier wohl mal unerwarteterweise nicht gemacht :)
Ansonsten sind die Konzepte anders, so dass sich nicht alles passend
übernehmen lässt.
Du kannst ja mal ein "telinit 3" zum Wechsel des Runlevels absetzen
und gucken, was passiert. Oder gucken, wie die Runlevel-Targets auf
Mint definiert sind.
Wenn der Runlevel-Wechsel klappt, wäre "warum kommen die Bootparameter
nicht im Grub an" vermutlich die nächste Stelle zum Suchen.
Gruß
Christian
--
....Christian.Garbs....................................https://www.cgarbs.de
We use Linux for all our mission-critical applications. Having the source code
means that we are not held hostage by anyone's support department.
(Russell Nelson, President of Crynwr Software)
[toc] | [prev] | [next] | [standalone]
| From | Matthias Gerds <m.gerds@posteo.de> |
|---|---|
| Date | 2020-10-23 10:53 +0200 |
| Message-ID | <hvfk0iFi0rbU1@mid.individual.net> |
| In reply to | #112735 |
On 23.10.20 09:56, Christian Garbs wrote: > Mahlzeit! > > Matthias Gerds <m.gerds@posteo.de> wrote: >> On 22.10.20 19:29, Christian Garbs wrote: > >>> Ich gehe davon aus, dass Linux Mint systemd einsetzt, dann gibt es >>> das klassische Konzept verschiedener Runlevel nicht mehr in der >>> Form. Ein init 3 dürfte ignoriert werden. > > Nach mehr Recherche behaupte ich nun das Gegenteil :) > >> Verstehe. Aber in openSUSE Tumbleweed hat das trotzdem funktioniert. >> Vielleicht haben sie da die althergebrachten Parameter ge-backport-et >> oder gemapped oder wie das heißt? > > In der Tat, hier sind die Runlevel gemappt. Ich habe das noch nie > benutzt, aber das sieht auf den ersten Blick so aus, als ob der > init=-Parameter tatsächlich etwas tun sollte: > > $ ls -lh /usr/lib/systemd/system/runlevel?.target > lrwxrwxrwx 1 root root 15 Apr 27 19:02 /usr/lib/systemd/system/runlevel0.target -> poweroff.target > lrwxrwxrwx 1 root root 13 Apr 27 19:02 /usr/lib/systemd/system/runlevel1.target -> rescue.target > lrwxrwxrwx 1 root root 17 Apr 27 19:02 /usr/lib/systemd/system/runlevel2.target -> multi-user.target > lrwxrwxrwx 1 root root 17 Apr 27 19:02 /usr/lib/systemd/system/runlevel3.target -> multi-user.target > lrwxrwxrwx 1 root root 17 Apr 27 19:02 /usr/lib/systemd/system/runlevel4.target -> multi-user.target > lrwxrwxrwx 1 root root 16 Apr 27 19:02 /usr/lib/systemd/system/runlevel5.target -> graphical.target > lrwxrwxrwx 1 root root 13 Apr 27 19:02 /usr/lib/systemd/system/runlevel6.target -> reboot.target > >> Text only würde mich interessieren. Ist ja schön, dass Systemd die >> ganze Sache vereinheitlicht bzw. beschleunigt, aber muss man >> deswegen alle tradierten Befehle deaktivieren? > > Das haben sie hier wohl mal unerwarteterweise nicht gemacht :) > Ansonsten sind die Konzepte anders, so dass sich nicht alles passend > übernehmen lässt. > > Du kannst ja mal ein "telinit 3" zum Wechsel des Runlevels absetzen > und gucken, was passiert. Oder gucken, wie die Runlevel-Targets auf > Mint definiert sind. > > Wenn der Runlevel-Wechsel klappt, wäre "warum kommen die Bootparameter > nicht im Grub an" vermutlich die nächste Stelle zum Suchen. Interessanterweise funktionieren die virtuellen Konsolen auf dem LMDE4-Live-System (USD-Installations-Stick) einwandfrei, und zwar ganz gleich, ob mit dem Standard-(Nouveau) oder dem Nvidia-Treiber. Das bietet das GRUB des Live-Systems nämlich an. Da werde ich mal reingucken. Also muss es doch machbar sein, dass das auf dem installierten System auch mit dem Nvidia-Treiber funktioniert. M:
[toc] | [prev] | [standalone]
Page 2 of 2 — ← Prev page 1 [2]
Back to top | Article view | de.comp.os.unix.linux.misc
csiph-web