MX Nvidia installer breaks systemd

[linexer2016]

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.

[dolphin_oracle]

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.

[linexer2016]

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.

[dolphin_oracle]

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).

[SwampRabbit]

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.

[JuhaT]

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.

[JayM]

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.

[MH3]

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.

[SwampRabbit]

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.

[JuhaT]

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.