MX Linux Forum

Posted: **Tue Aug 25, 2020 10:27 pm**

I require systemd to enable my VPN client software, which is otherwise unusable. After successfully booting with systemd on a fresh install of MX Linux KDE my VPN software was functional. I then installed the Nvidia driver using MX Tools and rebooted the system. When using systemd to boot the system I ended up at an unresponsive terminal prompt.

I apologize for not being able to use the MX system info tool, but VPN access is required, as is the Nvidia driver. Since those options are currently incompatible, I restored my system to it's original state - Debian Buster.

Posted: **Tue Aug 25, 2020 11:06 pm**

MH3 wrote: Tue Aug 25, 2020 10:27 pm I require systemd to enable my VPN client software, which is otherwise unusable. After successfully booting with systemd on a fresh install of MX Linux KDE my VPN software was functional. I then installed the Nvidia driver using MX Tools and rebooted the system. When using systemd to boot the system I ended up at an unresponsive terminal prompt.

I apologize for not being able to use the MX system info tool, but VPN access is required, as is the Nvidia driver. Since those options are currently incompatible, I restored my system to it's original state - Debian Buster.

MX Xfce, systemd, and Nvidia drivers work fine together, I think we would know if there was an issue with the KDE version, but no one has reported this issue yet.

If you can't provide the Nvidia driver installer logs, Quick System Info, or anything else.... why even report you had an issue?
How are we supposed to know why it didn't work on your system?

Posted: **Tue Aug 25, 2020 11:55 pm**

Also missing is whether the sysvinit boot would succeed with the Nvidia driver installed--then we could say that only the systemd boot was affected. Without that datum, it might have been one of the standard "Nvidia driver boots to black screen" type problems that we see every so often, since I can't remember any systemd-specific video driver issues--ever.

Posted: **Thu Aug 27, 2020 12:34 am**

Stevo wrote: Tue Aug 25, 2020 11:55 pm Also missing is whether the sysvinit boot would succeed with the Nvidia driver installed--then we could say that only the systemd boot was affected. Without that datum, it might have been one of the standard "Nvidia driver boots to black screen" type problems that we see every so often, since I can't remember any systemd-specific video driver issues--ever.

Like I said, I apologize for some of the lack of info in my original post. The system I was using is also used by another person and I had to return it to working condition as soon as possible.

I have since performed another clean install. Once logged in I used MX Tools to modify GRUB so that it would boot into systemd by default. I then used MX Tools to install the Nvidia driver. I rebooted the machine and was left at a terminal prompt. I was able to login, first as root, later as a regular user, albeit the text in the terminal is garbled and can be confusing if you mistype a character. After one failed attempt, I was able to issue the "startx" command, both as root and as a regular user. In both cases, Plasma was launched successfully. I've copied the Quick System Info below:

Code: Select all

System:    Host: <filter> Kernel: 5.6.0-2-amd64 x86_64 bits: 64 compiler: gcc v: 8.3.0 
           parameters: BOOT_IMAGE=/boot/vmlinuz-5.6.0-2-amd64 root=UUID=a935bb47-01a0-4062-935f-896f97d6795e ro 
           quiet splash init=/lib/systemd/systemd 
           Desktop: KDE Plasma 5.14.5 wm: kwin_x11 dm: SDDM Distro: MX-19.2_KDE_x64 patito feo August 16  2020 
           base: Debian GNU/Linux 10 (buster) 
Machine:   Type: Desktop Mobo: ASUSTeK model: PRIME B350-PLUS v: Rev X.0x serial: <filter> 
           UEFI [Legacy]: American Megatrends v: 5407 date: 12/31/2019 
CPU:       Topology: 6-Core model: AMD Ryzen 5 2600 bits: 64 type: MT MCP arch: Zen+ family: 17 (23) model-id: 8 
           stepping: 2 microcode: 800820D L2 cache: 3072 KiB 
           flags: avx avx2 lm nx pae sse sse2 sse3 sse4_1 sse4_2 sse4a ssse3 svm bogomips: 86395 
           Speed: 1447 MHz min/max: 1550/3600 MHz boost: disabled Core speeds (MHz): 1: 1439 2: 1436 3: 3592 
           4: 1432 5: 3600 6: 1448 7: 3600 8: 1445 9: 1434 10: 1440 11: 3581 12: 1433 
           Vulnerabilities: Type: itlb_multihit status: Not affected 
           Type: l1tf status: Not affected 
           Type: mds status: Not affected 
           Type: meltdown status: Not affected 
           Type: spec_store_bypass mitigation: Speculative Store Bypass disabled via prctl and seccomp 
           Type: spectre_v1 mitigation: usercopy/swapgs barriers and __user pointer sanitization 
           Type: spectre_v2 mitigation: Full AMD retpoline, IBPB: conditional, STIBP: disabled, RSB filling 
           Type: srbds status: Not affected 
           Type: tsx_async_abort status: Not affected 
Graphics:  Device-1: NVIDIA GP108 vendor: eVga.com. driver: nvidia v: 440.100 bus ID: 07:00.0 chip ID: 10de:1d01 
           Display: server: X.Org 1.20.4 driver: nvidia unloaded: fbdev,modesetting,nouveau,vesa alternate: nv 
           compositor: kwin_x11 resolution: 1920x1080~60Hz 
           OpenGL: renderer: GeForce GT 1030/PCIe/SSE2 v: 4.6.0 NVIDIA 440.100 direct render: Yes 
Audio:     Device-1: NVIDIA GP108 High Definition Audio vendor: eVga.com. driver: snd_hda_intel v: kernel 
           bus ID: 07:00.1 chip ID: 10de:0fb8 
           Device-2: Advanced Micro Devices [AMD] Family 17h HD Audio vendor: ASUSTeK driver: snd_hda_intel 
           v: kernel bus ID: 09:00.3 chip ID: 1022:1457 
           Sound Server: ALSA v: k5.6.0-2-amd64 
Network:   Device-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet vendor: ASUSTeK driver: r8169 v: kernel 
           port: f000 bus ID: 03:00.0 chip ID: 10ec:8168 
           IF: eth0 state: up speed: 1000 Mbps duplex: full mac: <filter> 
Drives:    Local Storage: total: 465.76 GiB used: 96.86 GiB (20.8%) 
           ID-1: /dev/sda vendor: Crucial model: CT500MX500SSD1 size: 465.76 GiB block size: physical: 4096 B 
           logical: 512 B speed: 6.0 Gb/s serial: <filter> rev: 022 scheme: MBR 
Partition: ID-1: / raw size: 22.35 GiB size: 21.88 GiB (97.87%) used: 7.50 GiB (34.3%) fs: ext4 dev: /dev/sda1 
           ID-2: /home raw size: 443.41 GiB size: 436.32 GiB (98.40%) used: 89.36 GiB (20.5%) fs: ext4 
           dev: /dev/sda2 
Sensors:   System Temperatures: cpu: 46.5 C mobo: N/A gpu: nvidia temp: 43 C 
           Fan Speeds (RPM): N/A gpu: nvidia fan: 43% 
Repos:     No active apt repos in: /etc/apt/sources.list 
           Active apt repos in: /etc/apt/sources.list.d/debian-stable-updates.list 
           1: deb http://deb.debian.org/debian buster-updates main contrib non-free
           Active apt repos in: /etc/apt/sources.list.d/debian.list 
           1: deb http://deb.debian.org/debian buster main contrib non-free
           2: deb http://deb.debian.org/debian-security buster/updates main contrib non-free
           Active apt repos in: /etc/apt/sources.list.d/mx.list 
           1: deb https://mirror.kku.ac.th/mx-packages/mx/repo/ buster main non-free
           2: deb https://mirror.kku.ac.th/mx-packages/mx/repo/ buster ahs
           No active apt repos in: /etc/apt/sources.list.d/various.list 
Info:      Processes: 293 Uptime: 10m Memory: 15.64 GiB used: 1.41 GiB (9.0%) Init: systemd v: 241 runlevel: 5 
           default: 5 Compilers: gcc: 8.3.0 alt: 8 Shell: quick-system-in running in: quick-system-in inxi: 3.0.36

Posted: **Thu Aug 27, 2020 1:44 am**

I assume when you said you used MX Tools to modify grub for a systemd boot you meant MX Boot Options. See these wiki articles for suggestions on what to try for the Nvidia issue: https://mxlinux.org/wiki/hardware/nvidi ... -recovery/ and https://mxlinux.org/wiki/help-files/hel ... nstallers/.

You could also try booting without systemd just to test whether or not it makes any difference re: Nvidia. If you still get the "black screen of death" then the init system has nothing to do with it and it's just an Nvidia driver issue.

Which Nvidia driver did you select in the driver installer? If you chose 440 that may be the issue. Some research indicates that this card needs (or at least works with) driver version 381, which we don't have in our repos. The closest one we have is the 390 legacy driver which may be the one that your card requires. OTOH if you selected the 390 driver you should purge it as per the instructions in the first Wiki article then reboot and rerun the installer, this time selecting the 440 driver. That is, if renaming your /etc/X11/xorg.conf and rebooting doesn't fix it.

Posted: **Thu Aug 27, 2020 3:14 am**

SwampRabbit wrote: Tue Aug 25, 2020 11:06 pm
MH3 wrote: Tue Aug 25, 2020 10:27 pm I require systemd to enable my VPN client software, which is otherwise unusable. After successfully booting with systemd on a fresh install of MX Linux KDE my VPN software was functional. I then installed the Nvidia driver using MX Tools and rebooted the system. When using systemd to boot the system I ended up at an unresponsive terminal prompt.

I apologize for not being able to use the MX system info tool, but VPN access is required, as is the Nvidia driver. Since those options are currently incompatible, I restored my system to it's original state - Debian Buster.
MX Xfce, systemd, and Nvidia drivers work fine together, I think we would know if there was an issue with the KDE version, but no one has reported this issue yet.

If you can't provide the Nvidia driver installer logs, Quick System Info, or anything else.... why even report you had an issue?
How are we supposed to know why it didn't work on your system?

I actually did report exactly this problem in MX KDE in the feedback thread. I too need systemd for my VPN software (OVPN) None of the suggestion I got helped. I did not have this problem in MX XFCE, so I think it is a MX KDE specific problem.

viewtopic.php?p=589631#p589631

*edit 121720* I dont know if it is some update or if my VPN provider (OVPN) has done something with their app but now the VPN app works just fine in sysvinit too.

Posted: **Thu Aug 27, 2020 5:24 am**

Interesting. Apparently the forum moderators don't like bug reports, in spite of this being a form for bug reports. I've made two subsequent posts on this topic providing the information requested and neither of them have shown up.

Posted: **Thu Aug 27, 2020 5:39 am**

People have a thing called "a life". We're also a very small team, so be a bit more patient.

Posted: **Thu Aug 27, 2020 5:42 am**

I see you both have very recent hardware, maybe it isn't fully supported yet by the 5.6 LInux kernel.
You can choose to install a newer kernel, either the one from Debian Backports or the Liquorix kernel from MX Test, both are in the Popular Apps tab in MX Package Installer

Posted: **Thu Aug 27, 2020 6:12 am**

Not that recent. The CPU, mobo and video card date from 2017 or 2018. They should be fully supported by the standard AHS 5.6 kernel.

Still waiting for the OP to try booting without systemd and test whether the nvidia driver works, and for him to tell us which driver he installed, etc. as per my post #5.

Posted: **Thu Aug 27, 2020 6:39 am**

JayM wrote: Thu Aug 27, 2020 6:12 am Not that recent. The CPU, mobo and video card date from 2017 or 2018. They should be fully supported by the standard AHS 5.6 kernel.

Still waiting for the OP to try booting without systemd and test whether the nvidia driver works, and for him to tell us which driver he installed, etc. as per my post #5.

I have done that when testing earlier, the 440 driver works fine for me when booting into sysvinit. I now run the noveau driver but I'll post my specs for info.

Code: Select all

System:    Host: <filter> Kernel: 5.6.0-2-amd64 x86_64 bits: 64 compiler: gcc v: 8.3.0 
           parameters: BOOT_IMAGE=/boot/vmlinuz-5.6.0-2-amd64 root=UUID=<filter> ro quiet splash 
           init=/lib/systemd/systemd 
           Desktop: KDE Plasma 5.14.5 wm: kwin_x11 dm: SDDM Distro: MX-19.2_KDE_x64 patito feo August 16  2020 
           base: Debian GNU/Linux 10 (buster) 
Machine:   Type: Desktop System: Gigabyte product: Z390 GAMING X v: N/A serial: <filter> 
           Mobo: Gigabyte model: Z390 GAMING X-CF v: x.x serial: <filter> UEFI [Legacy]: American Megatrends v: F9 
           date: 10/15/2019 
CPU:       Topology: 8-Core model: Intel Core i7-9700K bits: 64 type: MCP arch: Kaby Lake family: 6 model-id: 9E (158) 
           stepping: D (13) microcode: D6 L2 cache: 12.0 MiB 
           flags: avx avx2 lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx bogomips: 57600 
           Speed: 800 MHz min/max: 800/4900 MHz Core speeds (MHz): 1: 800 2: 800 3: 800 4: 800 5: 800 6: 800 7: 800 8: 800 
           Vulnerabilities: Type: itlb_multihit status: KVM: Split huge pages 
           Type: l1tf status: Not affected 
           Type: mds status: Not affected 
           Type: meltdown status: Not affected 
           Type: spec_store_bypass mitigation: Speculative Store Bypass disabled via prctl and seccomp 
           Type: spectre_v1 mitigation: usercopy/swapgs barriers and __user pointer sanitization 
           Type: spectre_v2 mitigation: Enhanced IBRS, IBPB: conditional, RSB filling 
           Type: srbds mitigation: TSX disabled 
           Type: tsx_async_abort mitigation: TSX disabled 
Graphics:  Device-1: NVIDIA GP104 [GeForce GTX 1070] vendor: Gigabyte driver: nouveau v: kernel bus ID: 01:00.0 
           chip ID: 10de:1b81 
           Display: x11 server: X.Org 1.20.4 driver: modesetting unloaded: fbdev,vesa compositor: kwin_x11 tty: N/A 
           OpenGL: renderer: NV134 v: 4.3 Mesa 20.0.7 direct render: Yes 
Audio:     Device-1: Intel Cannon Lake PCH cAVS vendor: Gigabyte driver: snd_hda_intel v: kernel bus ID: 00:1f.3 
           chip ID: 8086:a348 
           Device-2: NVIDIA GP104 High Definition Audio vendor: Gigabyte driver: snd_hda_intel v: kernel bus ID: 01:00.1 
           chip ID: 10de:10f0 
           Sound Server: ALSA v: k5.6.0-2-amd64 
Network:   Device-1: Intel Ethernet I219-V vendor: Gigabyte driver: e1000e v: 3.2.6-k port: efa0 bus ID: 00:1f.6 
           chip ID: 8086:15bc 
           IF: eth0 state: up speed: 100 Mbps duplex: half mac: <filter> 
           IF-ID-1: vpn76-se-sto state: unknown speed: N/A duplex: N/A mac: N/A 
Drives:    Local Storage: total: 5.11 TiB used: 28.04 GiB (0.5%) 
           ID-1: /dev/sda vendor: Samsung model: SSD 860 EVO 1TB size: 931.51 GiB block size: physical: 512 B logical: 512 B 
           speed: 6.0 Gb/s serial: <filter> rev: 1B6Q scheme: MBR 
           ID-2: /dev/sdb vendor: Samsung model: SSD 850 EVO 250GB size: 232.89 GiB block size: physical: 512 B logical: 512 B 
           speed: 6.0 Gb/s serial: <filter> rev: 2B6Q scheme: GPT 
           ID-3: /dev/sdc vendor: Seagate model: ST2000DX001-1CM164 size: 1.82 TiB block size: physical: 4096 B logical: 512 B 
           speed: 6.0 Gb/s rotation: 7200 rpm serial: <filter> rev: CC43 scheme: MBR 
           ID-4: /dev/sdd vendor: Samsung model: SSD 870 QVO 2TB size: 1.82 TiB block size: physical: 512 B logical: 512 B 
           speed: 6.0 Gb/s serial: <filter> rev: 1B6Q scheme: GPT 
           ID-5: /dev/sde vendor: Samsung model: SSD 860 EVO M.2 250GB size: 232.89 GiB block size: physical: 512 B 
           logical: 512 B speed: 6.0 Gb/s serial: <filter> rev: 3B6Q scheme: MBR 
           ID-6: /dev/sdf type: USB vendor: Western Digital model: WDS1 20G2G0A-00JH30 size: 111.80 GiB block size: 
           physical: 512 B logical: 512 B serial: <filter> rev: 0107 
Partition: ID-1: / raw size: 29.34 GiB size: 28.76 GiB (98.00%) used: 9.95 GiB (34.6%) fs: ext4 dev: /dev/sdb1 
           ID-2: /home raw size: 203.54 GiB size: 199.35 GiB (97.94%) used: 18.09 GiB (9.1%) fs: ext4 dev: /dev/sdb2 
Sensors:   System Temperatures: cpu: 34.0 C mobo: 27.8 C gpu: nouveau temp: 31 C 
           Fan Speeds (RPM): N/A gpu: nouveau fan: 1218 
Repos:     No active apt repos in: /etc/apt/sources.list 
           Active apt repos in: /etc/apt/sources.list.d/brave-browser-release.list 
           1: deb [arch=amd64] https://brave-browser-apt-release.s3.brave.com/ buster main
           Active apt repos in: /etc/apt/sources.list.d/debian-stable-updates.list 
           1: deb http://deb.debian.org/debian buster-updates main contrib non-free
           Active apt repos in: /etc/apt/sources.list.d/debian.list 
           1: deb http://deb.debian.org/debian buster main contrib non-free
           2: deb http://deb.debian.org/debian-security buster/updates main contrib non-free
           Active apt repos in: /etc/apt/sources.list.d/megasync.list 
           1: deb https://mega.nz/linux/MEGAsync/Debian_10.0/ ./
           Active apt repos in: /etc/apt/sources.list.d/mx.list 
           1: deb http://ftp.acc.umu.se/mirror/mxlinux.org/packages/mx/repo/ buster main non-free
           2: deb http://ftp.acc.umu.se/mirror/mxlinux.org/packages/mx/repo/ buster ahs
           Active apt repos in: /etc/apt/sources.list.d/unstable.list 
           1: deb http://deb.debian.org/debian/ unstable main
           No active apt repos in: /etc/apt/sources.list.d/various.list 
Info:      Processes: 259 Uptime: 18h 21m Memory: 23.49 GiB used: 4.50 GiB (19.1%) Init: systemd v: 241 runlevel: 5 default: 5 
           Compilers: gcc: 8.3.0 alt: 8 Shell: quick-system-in running in: quick-system-in inxi: 3.0.36

Posted: **Thu Aug 27, 2020 8:12 am**

JuhaT wrote: Thu Aug 27, 2020 6:39 am I have done that when testing earlier, the 440 driver works fine for me when booting into sysvinit. I now run the noveau driver but I'll post my specs for info.

I think it could be very helpful to have a kernel log of a systemd session where you used the nvidia driver. That log would be in /var/log/kern.log
You can also remove the 'quiet splash' boot parameters to see if you get some clear error on your screen when you boot with nvidia+systemd but maybe it will fly past too quickly.
When you get in such a scrambled command-line prompt, you can try to boot with startx like MH3 mentioned in post #4.

edit: /var/log/Xorg.0.log may be relevant too

Posted: **Thu Aug 27, 2020 9:12 am**

Just a suggestion ... does this thread have some similarities to viewtopic.php?f=108&t=60048

Posted: **Thu Aug 27, 2020 9:21 am**

Just installed latest nvidia driver in a fresh MX KDE installation.
What I have done:
purged all dmks, I don't need virtualbox (on this pc), broadcom, ( and I looked for ndiswrapper to purge, but was not installed.)
Now I run

Code: Select all

mx-pkexec ddm-mx -i nvidia

And installed nvidia 440.100 driver from the main repo.
That's it. Rebooted and run in either systemd or sysvinit just fine:
optirun glxspheres64
and
optirun quick-system-info-mx

Code: Select all

System:    Host: <filter> Kernel: 5.6.0-2-amd64 x86_64 bits: 64 compiler: gcc v: 8.3.0 
           parameters: BOOT_IMAGE=/boot/vmlinuz-5.6.0-2-amd64 root=UUID=<filter> ro quiet splash 
           init=/lib/systemd/systemd 
           Desktop: KDE Plasma 5.14.5 wm: kwin_x11 dm: SDDM Distro: MX-19.2_KDE_x64 patito feo August 16  2020 
           base: Debian GNU/Linux 10 (buster) 
Machine:   Type: Laptop System: Acer product: Aspire A515-51G v: V1.12 serial: <filter> 
           Mobo: KBL model: Charmander_KL v: V1.12 serial: <filter> UEFI [Legacy]: Insyde v: 1.12 date: 11/08/2017 
Battery:   ID-1: BAT1 charge: 44.1 Wh condition: 44.1/48.9 Wh (90%) volts: 16.6/15.2 model: COMPAL PABAS0241231 type: Li-ion 
           serial: <filter> status: Full 
CPU:       Topology: Quad Core model: Intel Core i7-8550U bits: 64 type: MT MCP arch: Kaby Lake family: 6 model-id: 8E (142) 
           stepping: A (10) microcode: D6 L2 cache: 8192 KiB 
           flags: avx avx2 lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx bogomips: 31999 
           Speed: 2840 MHz min/max: 400/4000 MHz Core speeds (MHz): 1: 2840 2: 2842 3: 2828 4: 2805 5: 2623 6: 2837 7: 2813 
           8: 1990 
           Vulnerabilities: Type: itlb_multihit status: KVM: Split huge pages 
           Type: l1tf mitigation: PTE Inversion; VMX: conditional cache flushes, SMT vulnerable 
           Type: mds mitigation: Clear CPU buffers; SMT vulnerable 
           Type: meltdown mitigation: PTI 
           Type: spec_store_bypass mitigation: Speculative Store Bypass disabled via prctl and seccomp 
           Type: spectre_v1 mitigation: usercopy/swapgs barriers and __user pointer sanitization 
           Type: spectre_v2 mitigation: Full generic retpoline, IBPB: conditional, IBRS_FW, STIBP: conditional, RSB filling 
           Type: srbds mitigation: Microcode 
           Type: tsx_async_abort status: Not affected 
Graphics:  Device-1: Intel UHD Graphics 620 vendor: Acer Incorporated ALI driver: i915 v: kernel bus ID: 00:02.0 
           chip ID: 8086:5917 
           Device-2: NVIDIA GP108M [GeForce MX150] vendor: Acer Incorporated ALI driver: nvidia v: 440.100 bus ID: 01:00.0 
           chip ID: 10de:1d10 
           Display: x11 server: X.Org 1.20.4 driver: modesetting unloaded: fbdev,vesa compositor: kwin_x11 
           resolution: 1920x1080~60Hz 
           OpenGL: renderer: GeForce MX150/PCIe/SSE2 v: 4.6.0 NVIDIA 440.100 direct render: Yes 
Audio:     Device-1: Intel Sunrise Point-LP HD Audio vendor: Acer Incorporated ALI driver: snd_hda_intel v: kernel 
           bus ID: 00:1f.3 chip ID: 8086:9d71 
           Sound Server: ALSA v: k5.6.0-2-amd64 
Network:   Device-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet vendor: Acer Incorporated ALI driver: r8169 
           v: kernel port: 3000 bus ID: 02:00.1 chip ID: 10ec:8168 
           IF: eth0 state: up speed: 100 Mbps duplex: full mac: <filter> 
           Device-2: Qualcomm Atheros QCA9377 802.11ac Wireless Network Adapter vendor: Lite-On driver: ath10k_pci v: kernel 
           port: 3000 bus ID: 03:00.0 chip ID: 168c:0042 
           IF: wlan0 state: down mac: <filter> 
Drives:    Local Storage: total: 1.86 TiB used: 12.85 GiB (0.7%) 
           ID-1: /dev/sda vendor: Western Digital model: WD10SPZX-21Z10T0 size: 931.51 GiB block size: physical: 4096 B 
           logical: 512 B speed: 6.0 Gb/s rotation: 5400 rpm serial: <filter> rev: 1A02 scheme: GPT 
           ID-2: /dev/sdb vendor: Crucial model: CT1050MX300SSD4 size: 978.09 GiB block size: physical: 512 B logical: 512 B 
           speed: 6.0 Gb/s serial: <filter> rev: R040 scheme: GPT 
Partition: ID-1: / raw size: 30.00 GiB size: 29.40 GiB (98.01%) used: 12.85 GiB (43.7%) fs: ext4 dev: /dev/sdb17 
           ID-2: swap-1 size: 4.00 GiB used: 0 KiB (0.0%) fs: swap swappiness: 15 (default 60) cache pressure: 100 (default) 
           dev: /dev/sdb15 
Sensors:   System Temperatures: cpu: 50.0 C mobo: N/A 
           Fan Speeds (RPM): N/A 
Repos:     No active apt repos in: /etc/apt/sources.list 
           Active apt repos in: /etc/apt/sources.list.d/debian-stable-updates.list 
           1: deb http://deb.debian.org/debian buster-updates main contrib non-free
           Active apt repos in: /etc/apt/sources.list.d/debian.list 
           1: deb http://deb.debian.org/debian buster main contrib non-free
           2: deb http://deb.debian.org/debian-security buster/updates main contrib non-free
           Active apt repos in: /etc/apt/sources.list.d/mx.list 
           1: deb https://mxlinux.mirror.iphh.net/packages/mx/repo/ buster main non-free
           2: deb https://mxlinux.mirror.iphh.net/packages/mx/repo/ buster ahs
           No active apt repos in: /etc/apt/sources.list.d/various.list 
Info:      Processes: 257 Uptime: 3m Memory: 19.50 GiB used: 842.5 MiB (4.2%) Init: systemd v: 241 runlevel: 5 default: 5 
           Compilers: gcc: 8.3.0 alt: 8 Shell: quick-system-in running in: quick-system-in inxi: 3.0.36

So all works fine in systemd and sysvinit, without any issue.

Posted: **Thu Aug 27, 2020 9:24 am**

linexer2016 wrote: Thu Aug 27, 2020 9:12 am Just a suggestion ... does this thread have some similarities to viewtopic.php?f=108&t=60048

Thank you! That solved the problem for me!

I used the Nvidia installer in MX-tools. Chose default on every question. Added the code "xorg=nvidia" into "kernel parameters" in MX Boot Options and now nvidia driver works in systemd!

Posted: **Thu Aug 27, 2020 9:46 am**

JuhaT wrote: Thu Aug 27, 2020 9:24 am
linexer2016 wrote: Thu Aug 27, 2020 9:12 am Just a suggestion ... does this thread have some similarities to viewtopic.php?f=108&t=60048
Thank you! That solved the problem for me!

I used the Nvidia installer in MX-tools. Chose default on every question. Added the code "xorg=nvidia" into "kernel parameters" in MX Boot Options and now nvidia driver works in systemd!

that actually shouldn't have worked. the xorg=nvidia doesn't do anything on installed systems (the commands its triggers don't even exist) , and systemd doesn't work correctly on live systems.

so I remain stumped.

Posted: **Thu Aug 27, 2020 9:54 am**

this part of the OP's post makes me think the display manager isn't starting.

I have since performed another clean install. Once logged in I used MX Tools to modify GRUB so that it would boot into systemd by default. I then used MX Tools to install the Nvidia driver. I rebooted the machine and was left at a terminal prompt. I was able to login, first as root, later as a regular user, albeit the text in the terminal is garbled and can be confusing if you mistype a character. After one failed attempt, I was able to issue the "startx" command, both as root and as a regular user. In both cases, Plasma was launched successfully. I've copied the Quick System Info below:

checking

Code: Select all

systemd-analyze blame

may be beneficial. or looking for stopped and/or pending jobs.

the arch wiki has some info in their nvidia troubleshooting guide that says that its possible on fast systems that systemd will try to start the display manager before nvidia is finished getting set up. there are some tweaks for that.

https://wiki.archlinux.org/index.php/NV ... tarts_fine

Posted: **Thu Aug 27, 2020 9:56 am**

dolphin_oracle wrote: Thu Aug 27, 2020 9:46 am that actually shouldn't have worked. the xorg=nvidia doesn't do anything on installed systems (the commands its triggers don't even exist) , and systemd doesn't work correctly on live systems.

so I remain stumped.

I'm just guessing but maybe there was a problem in the beta (when JuhaT had this problem) and now it's been solved (miraculously or not).

Posted: **Thu Aug 27, 2020 9:59 am**

MH3 wrote: Thu Aug 27, 2020 5:24 am Interesting. Apparently the forum moderators don't like bug reports, in spite of this being a form for bug reports. I've made two subsequent posts on this topic providing the information requested and neither of them have shown up.

Oh please, you don't need to make blanked and false statements like this to get help. A simple forum search would prove that quickly.

It's a well know fact that not only the MX team, but also users, will go far out of their way to help users identify if something is a bug or not.
Everything reported as an issue isn't always a bug, sometimes there is a logical explanation to a issue that isn't a bug or something goofed up on MX.

There was already a known fix for certain Nvidia issues suggested on post #17 here.

I was actually about to drop everything I have to do for my real job to burn a fresh ISO onto a USB to do what fehlix just did, but they beat me to it.

JuhaT wrote: Thu Aug 27, 2020 6:39 am

Code: Select all

           Active apt repos in: /etc/apt/sources.list.d/unstable.list 
           1: deb http://deb.debian.org/debian/ unstable main
           No active apt repos in: /etc/apt/sources.list.d/various.list

I'm gonna go out on a limb and say that is a really bad idea. If you are keeping this repo enabled and or are installing large amounts of things from Debian Unstable, you should post in the MX Modified section of the forum.

Posted: **Thu Aug 27, 2020 10:02 am**

Rather than using MX Boot Options to modify boot parameters, has someone with Nvidia issues tried to simply select booting with systemd at the actual GRUB menu?

Posted: **Thu Aug 27, 2020 10:04 am**

dolphin_oracle wrote: Thu Aug 27, 2020 9:46 am
JuhaT wrote: Thu Aug 27, 2020 9:24 am
linexer2016 wrote: Thu Aug 27, 2020 9:12 am Just a suggestion ... does this thread have some similarities to viewtopic.php?f=108&t=60048
Thank you! That solved the problem for me!

I used the Nvidia installer in MX-tools. Chose default on every question. Added the code "xorg=nvidia" into "kernel parameters" in MX Boot Options and now nvidia driver works in systemd!
that actually shouldn't have worked. the xorg=nvidia doesn't do anything on installed systems (the commands its triggers don't even exist) , and systemd doesn't work correctly on live systems.

so I remain stumped.

DO, I suppose at the end of the day if whatever the OP did following the suggestion worked then provided all else remains intact it must be a case of "if it ain't broke, don't fix it". When I saw the post it struck me that the OP was describing things similar to the OP in that linked post so I thought it might be worth a try and so it seems, it was. Of course, your experienced eye might be a little concerned that something else was also in play and that something else might rear its head again later but I imagine that can be a discussion for another day if it happens.

Posted: **Thu Aug 27, 2020 10:07 am**

SwampRabbit wrote: Thu Aug 27, 2020 10:02 am Rather than using MX Boot Options to modify boot parameters, has someone with Nvidia issues tried to simply select booting with systemd at the actual GRUB menu?

in this case, adding the init= line in the boot options is the exact same thing as in the usual grub menu.

the OP doesn't have unstable enabled, while that might be an issue for JuhaT, its' not for the OP.

the fact that the OP can get into X using startx makes me think the display manager thing posted above is at least worth checking out.

A timing issue would explain why it doesn't break for everybody too.

Posted: **Thu Aug 27, 2020 10:11 am**

SwampRabbit wrote: Thu Aug 27, 2020 10:02 am Rather than using MX Boot Options to modify boot parameters, has someone with Nvidia issues tried to simply select booting with systemd at the actual GRUB menu?

Indeed SR, I run systemd and whenever I do a reinstall or a major upgrade or some such, I have to review GRUB to ensure systemd is the selected boot option. Not because the standard boot option doesn't boot (for me) it's just a program I run seems to prefer/need systemd. So yes, your suggestion would seem to be worth a try for anyone using systemd rather than systemvinit.

Posted: **Thu Aug 27, 2020 10:11 am**

linexer2016 wrote: Thu Aug 27, 2020 10:04 am
dolphin_oracle wrote: Thu Aug 27, 2020 9:46 am
JuhaT wrote: Thu Aug 27, 2020 9:24 am

Thank you! That solved the problem for me!

I used the Nvidia installer in MX-tools. Chose default on every question. Added the code "xorg=nvidia" into "kernel parameters" in MX Boot Options and now nvidia driver works in systemd!
that actually shouldn't have worked. the xorg=nvidia doesn't do anything on installed systems (the commands its triggers don't even exist) , and systemd doesn't work correctly on live systems.

so I remain stumped.
DO, I suppose at the end of the day if whatever the OP did following the suggestion worked then provided all else remains intact it must be a case of "if it ain't broke, don't fix it". When I saw the post it struck me that the OP was describing things similar to the OP in that linked post so I thought it might be worth a try and so it seems, it was. Of course, your experienced eye might be a little concerned that something else was also in play and that something else might rear its head again later but I imagine that can be a discussion for another day if it happens.

well, just because I don't think anything should happen doesn't mean it doesn't LOL. maybe the extra half second the kernel spends trying to figure a bogus boot code is enough, or maybe the code also means something to systemd (I would think that would be unlikely, but who knows).

Posted: **Thu Aug 27, 2020 10:16 am**

dolphin_oracle wrote: Thu Aug 27, 2020 10:07 am in this case, adding the init= line in the boot options is the exact same thing as in the usual grub menu.

the OP doesn't have unstable enabled, while that might be an issue for JuhaT, its' not for the OP.

the fact that the OP can get into X using startx makes me think the display manager thing posted above is at least worth checking out.

A timing issue would explain why it doesn't break for everybody too.

Yep, I was just maybe taking a stab at if there was something going on between MX Boot Options and the newer GRUB, maybe.

* Speaking of the timing issue, these users may want to check if "Fast Boot" or similar options are enabled in the BIOS. I have a MSI B350 mobo with the same CPU that flakes out sometimes with sysvinit or systemd, until I disable that and not use UEFI.

The JuhaT statement was more or less for education and future reference. Save them and us from running in circles later trying to fix something Debian Unstable packages broke.

Posted: **Thu Aug 27, 2020 10:18 am**

dolphin_oracle wrote: Thu Aug 27, 2020 9:46 am
JuhaT wrote: Thu Aug 27, 2020 9:24 am
linexer2016 wrote: Thu Aug 27, 2020 9:12 am Just a suggestion ... does this thread have some similarities to viewtopic.php?f=108&t=60048
Thank you! That solved the problem for me!

I used the Nvidia installer in MX-tools. Chose default on every question. Added the code "xorg=nvidia" into "kernel parameters" in MX Boot Options and now nvidia driver works in systemd!
that actually shouldn't have worked. the xorg=nvidia doesn't do anything on installed systems (the commands its triggers don't even exist) , and systemd doesn't work correctly on live systems.

so I remain stumped.

Then we have a mystery here I guess :)
To test it I changed the parameter back to "quiet splash" rebooted and systemd wouldnt boot.. got the three dots and then landed on the scrambled prompt again.
I then rebooted into sysvinit and changed it to "xorg=nvidia" again and rebooted and it worked fine to boot into systemd again.

Posted: **Thu Aug 27, 2020 8:08 pm**

JuhaT wrote: Thu Aug 27, 2020 3:14 am I did not have this problem in MX XFCE, so I think it is a MX KDE specific problem.

Was that the AHS version of MX with Xfce? If it wasn't, you may be comparing apples to oranges: AHS uses a newer kernel, newer firmware packages, newer mesa and graphics stack than standard MX. You'd have to test MX AHS Xfce to get a good comparison as MX-KDE is based on AHS. Otherwise there are too many other differences to be able to say it's purely a desktop environment issue. This would actually be good data for the developers to have as they'll know whether the problem is common to AHS or specific to KDE.

Posted: **Fri Aug 28, 2020 2:07 am**

I doubt this post will see the light of day, but I'll try anyway. Several responsdents have complained about the lack of feedback by the OP. Well, I am the OP and I have posted quite detailed feedback. The problem is that the forum appears to be moderated and the moderator(s) has deleted several of my posts. I mentioned this in my last post and was criticized for it, so I doubt this will be posted. It's OK. Given the many (documented) issues I've had with MX Linux KDE, I don't intend to use it.

Posted: **Fri Aug 28, 2020 3:02 am**

MH3 wrote: Fri Aug 28, 2020 2:07 am I doubt this post will see the light of day, but I'll try anyway. Several responsdents have complained about the lack of feedback by the OP. Well, I am the OP and I have posted quite detailed feedback. The problem is that the forum appears to be moderated and the moderator(s) has deleted several of my posts. I mentioned this in my last post and was criticized for it, so I doubt this will be posted. It's OK. Given the many (documented) issues I've had with MX Linux KDE, I don't intend to use it.

Note: if you post right after someone else posts the forum holds your posts and tells you that someone posted while you were writing your post.
This is pretty obvious but it can get missed if someone doesn't pay attention, I have issues with it sometimes when I post from my phone.

I am pretty sure moderators make sure it is know before posts are deleted, they don't randomly delete posts.
If you were violating the terms of use of the forum you'd know that as well. We have a great forum, great community, great team, great users, and a great distro.

And you were far from "criticized" ... but best of luck with whatever you intend to use.... lots of good distros out there.

Posted: **Fri Aug 28, 2020 3:10 am**

JayM wrote: Thu Aug 27, 2020 8:08 pm
JuhaT wrote: Thu Aug 27, 2020 3:14 am I did not have this problem in MX XFCE, so I think it is a MX KDE specific problem.
Was that the AHS version of MX with Xfce? If it wasn't, you may be comparing apples to oranges: AHS uses a newer kernel, newer firmware packages, newer mesa and graphics stack than standard MX. You'd have to test MX AHS Xfce to get a good comparison as MX-KDE is based on AHS. Otherwise there are too many other differences to be able to say it's purely a desktop environment issue. This would actually be good data for the developers to have as they'll know whether the problem is common to AHS or specific to KDE.

I have a pretty modern desktop so I use AHS.

Posted: **Fri Aug 28, 2020 3:13 am**

JuhaT wrote: Fri Aug 28, 2020 3:10 am
JayM wrote: Thu Aug 27, 2020 8:08 pm
JuhaT wrote: Thu Aug 27, 2020 3:14 am I did not have this problem in MX XFCE, so I think it is a MX KDE specific problem.
Was that the AHS version of MX with Xfce? If it wasn't, you may be comparing apples to oranges: AHS uses a newer kernel, newer firmware packages, newer mesa and graphics stack than standard MX. You'd have to test MX AHS Xfce to get a good comparison as MX-KDE is based on AHS. Otherwise there are too many other differences to be able to say it's purely a desktop environment issue. This would actually be good data for the developers to have as they'll know whether the problem is common to AHS or specific to KDE.
I have a pretty modern desktop so I used AHS on Xfce.

MX Linux Forum

MX Nvidia installer breaks systemd

MX Nvidia installer breaks systemd

Re: MX Nvidia installer breaks systemd

Re: MX Nvidia installer breaks systemd

Re: MX Nvidia installer breaks systemd

Re: MX Nvidia installer breaks systemd

Re: MX Nvidia installer breaks systemd

Re: MX Nvidia installer breaks systemd

Re: MX Nvidia installer breaks systemd

Re: MX Nvidia installer breaks systemd

Re: MX Nvidia installer breaks systemd

Re: MX Nvidia installer breaks systemd

Re: MX Nvidia installer breaks systemd

Re: MX Nvidia installer breaks systemd

Re: MX Nvidia installer breaks systemd

Re: MX Nvidia installer breaks systemd

Re: MX Nvidia installer breaks systemd

Re: MX Nvidia installer breaks systemd

Re: MX Nvidia installer breaks systemd

Re: MX Nvidia installer breaks systemd

Re: MX Nvidia installer breaks systemd

Re: MX Nvidia installer breaks systemd

Re: MX Nvidia installer breaks systemd

Re: MX Nvidia installer breaks systemd

Re: MX Nvidia installer breaks systemd

Re: MX Nvidia installer breaks systemd

Re: MX Nvidia installer breaks systemd

Re: MX Nvidia installer breaks systemd

Re: MX Nvidia installer breaks systemd

Re: MX Nvidia installer breaks systemd

Re: MX Nvidia installer breaks systemd

Re: MX Nvidia installer breaks systemd