MX Linux Forum

Quick Question. Got a Dell XPS 14, 2024 model, NVIDIA graphics. Do I want to install the "standard" version of MX or the AHS version?

Thank you.

AHS version.

I would try the standard version.

I just built a system with a very new CPU, and motherboard that has been out a year or so.
I have both the regular xfce version and the AHS version installed.

I am going back to the standard for daily driver. I had some unexplained instability with the liquirix kernel, and problems getting the nvidia driver to load after an apparently successful MX tools install.
In contrast, in early testing, the standard version with the 6.1 kernel seems stable, as I expect from MX Linux, and the nvidia driver seemed to install correctly and loads with no problems. Only problem, the CPU temperature sensor does not report. Under AHS it gave a reading, always 37C, at idle or heavy load, so not believable. I ran sensors-detect on both installs.

Why are you using MBR on a very modern UEFI system? That could account for the instability that you experienced as the CSM module is meant for users that want to install Win 7, not do a legacy Linux install.

grasshopper wrote: Mon Jul 21, 2025 5:38 pm Quick Question. Got a Dell XPS 14, 2024 model, NVIDIA graphics. Do I want to install the "standard" version of MX or the AHS version?

Thank you.

I would suggest the standard version and then after your install, make a timeshift, update your machine. Then timeshift again, and turn on the MX ahs repo ( MX Repo Manager ) and update.

Personally, I would try loading up a liquorix kernel (that is all I will run ) , and I would head for a 6.12 FIRST.. then if all good, add on a 6.14 and test it well. (I stayed with the 6.12.x as it is PERFECT on my rigs. ( HP late 2023 and gigabyte Z790 AERO G - also late 2023 )

I believe you will find the liquorix kernel better for all of your hardware and how it runs, most people do... but some have trouble with it as well.

The cool things
a) You can swap out and remove the liquorix kernel VERY easily, and

b) If you timeshift before you AHS upgrades ( and any upgrades actually !!) ... then you have a method of easily recovering should you want too.. or if something goes wrong on the update !!!!

Speaking out-of-turn, MBR because it's sane and able to be understood by mere mortals.

figueroa wrote: Mon Jul 21, 2025 10:35 pm Speaking out-of-turn, MBR because it's sane and able to be understood by mere mortals.

+1

CharlesV wrote: Mon Jul 21, 2025 10:39 pm

figueroa wrote: Mon Jul 21, 2025 10:35 pm Speaking out-of-turn, MBR because it's sane and able to be understood by mere mortals.

+1

After staunchly resisting UEFI for years, I finally had to bite the bullet when I bought a 4 TB disk for my daily driver a few years ago. Speaking honestly as a ZFS user, the biggest insult to me was the obligatory FAT32 partition but, other than that, UEFI isn't so insulting and not nearly as injurious as I had feared. It's a pretty simple set of changes to make to the old "just dd some bytes to sector 0" approach we're all used to and maintenance is virtually nil.

Granted, I don't have a sophisticated UEFI setup where I want to boot between Windows, Windows Server, four different Linux distros, DOS, FreeBSD, and Haiku. That might make for a more difficult setup than I typically run, but as someone with a little bit of experience in MBR-era dual-booting I'm a lot less intimidated by the idea of a 9-way UEFI setup than a 2- or 3- or 4-way MBR config.

DukeComposed wrote: Mon Jul 21, 2025 11:00 pm

CharlesV wrote: Mon Jul 21, 2025 10:39 pm

figueroa wrote: Mon Jul 21, 2025 10:35 pm Speaking out-of-turn, MBR because it's sane and able to be understood by mere mortals.

+1

After staunchly resisting UEFI for years, I finally had to bite the bullet when I bought a 4 TB disk for my daily driver a few years ago. Speaking honestly as a ZFS user, the biggest insult to me was the obligatory FAT32 partition but, other than that, UEFI isn't so insulting and not nearly as injurious as I had feared. It's a pretty simple set of changes to make to the old "just dd some bytes to sector 0" approach we're all used to and maintenance is virtually nil.

Granted, I don't have a sophisticated UEFI setup where I want to boot between Windows, Windows Server, four different Linux distros, DOS, FreeBSD, and Haiku. That might make for a more difficult setup than I typically run, but as someone with a little bit of experience in MBR-era dual-booting I'm a lot less intimidated by the idea of a 9-way UEFI setup than a 2- or 3- or 4-way MBR config.

Agree 100%! I have resisted as well, and with my last four machines I have just gone through to uefi and they are just fine. ( But..mbr is so much more intuitive to me - an age thing I guess.)

@j2mcgreg

Why are you using MBR on a very modern UEFI system? That could account for the instability that you experienced...

I don't think so.

Whether MBR or UEFI has no impact on stability; it depends on the intended use. I've used both on several PCs without encountering any problems. My oldest PC is from 2018, so Windows 7 wasn't around anymore.
My current boot disk has a GPT partition table, but QSI correctly says "BIOS (legacy, CSM, MBR)." So it's a real mix, and the MX installer handled it well :-)

My only disk with four primary partitions is the one with the three test installations (the fourth is a data partition, which doesn't even need to be a primary, bootable partition).
But fortunately, I don't have a Windows system as ballast, so UEFI is unavoidable ;-}

j2mcgreg wrote: Mon Jul 21, 2025 7:21 pm CSM module is meant for users that want to install Win 7, not do a legacy Linux install.

Can you link to an official source that confirms this, thanks?

In the recent past, you've said things about CSM like:

j2mcgreg wrote: It should not be used with Linux and users can expect erratic behaviour when they do just that. The reason is that the bios will be looking for the Windows 7 hooks and will try any other connection when they are absent. Sometimes it gets them right but more often it gets them wrong.

I haven't bothered to reply to this particular claim even if it's one of those things that always catches my eye; latching onto something like this is always a bit of a drag xD. This is just one of those "weird claim gets repeated over and over, and at some point someone should ask for clarification / correct it" types of things. So for example, Intel's official CSM specification was something like 200 pages long at one point, and didn't mention Windows 7 even once. I'm not saying there can't be CSM related problems (of course there can be those, for various reasons), but the whole idea that CSM is literally specifically made for Windows 7 and only works reliably with some "Windows 7 hooks" and stuff like that... That is something that would be nice to confirm by linking to some official spec or source.

I'm very happy with MBR on my 2015 multiboot PC. No Windows on this at all.

Boot mode per QSI is
MBR is on a SSD with legacy msdos partition table.
My other devices are HDD with GPT. All distros on either the SSD or HDD all boot and run just fine.

Not saying I won't ever use UEFI, since my laptop is UEFI boot (also multiboot, though only 3 distros). But I have had no issues with the PC at all.

Nokkaelaein wrote: Tue Jul 22, 2025 8:47 am

j2mcgreg wrote: Mon Jul 21, 2025 7:21 pm CSM module is meant for users that want to install Win 7, not do a legacy Linux install.

Can you link to an official source that confirms this, thanks?

In the recent past, you've said things about CSM like:

j2mcgreg wrote: It should not be used with Linux and users can expect erratic behaviour when they do just that. The reason is that the bios will be looking for the Windows 7 hooks and will try any other connection when they are absent. Sometimes it gets them right but more often it gets them wrong.

I haven't bothered to reply to this particular claim even if it's one of those things that always catches my eye; latching onto something like this is always a bit of a drag xD. This is just one of those "weird claim gets repeated over and over, and at some point someone should ask for clarification / correct it" types of things. So for example, Intel's official CSM specification was something like 200 pages long at one point, and didn't mention Windows 7 even once. I'm not saying there can't be CSM related problems (of course there can be those, for various reasons), but the whole idea that CSM is literally specifically made for Windows 7 and only works reliably with some "Windows 7 hooks" and stuff like that... That is something that would be nice to confirm by linking to some official spec or source.

It's anecdotal and I'm willing to concede that it may depend on how the individual manufacturers deploy UEFI. I've had it confirmed by an HP engineer (now deceased -- Covid) and I have personally also experienced it with late model Acers and Lenovos. It goes like this: you do an MBR install and initially everything seems fine, but over time the machine gets more and more erratic. All the problems disappear after a UEFI reinstall.

j2mcgreg wrote: Tue Jul 22, 2025 10:06 am It's anecdotal and I'm willing to concede that it may depend on how the individual manufacturers deploy UEFI. I've had it confirmed by an HP engineer (now deceased -- Covid) and I have personally also experienced it with late model Acers and Lenovos. It goes like this: you do an MBR install and initially everything seems fine, but over time the machine gets more and more erratic. All the problems disappear after a UEFI reinstall.

I can roll with that, and I also don't have a problem with anecdotes per se, myself. I'd suggest something like mentioning you have noticed things not working well on some systems that have had CSM enabled, and leaving it at that; i.e. dropping the claims of Windows 7 specificity, and making it seem like things are thus bound to fail with CSM, and other such details that cannot be verified and seem to be off. No biggie. Also some Occam's razor kind of stuff, as in, generally if there is an accumulating vague "something is going wrong with this system" vibe, i.e. "over time the machine has gotten more and more erratic", there are of course countless of situations where a reinstall would cure that in any case. No matter whether UEFI or not.

I think the real issue with using CMS or not, is that it is a legacy boot mode that emulates a traditional BIOS environment. CMS provides backward compatibility with old operating systems and hardware devices that did not support the newer UEFI standard. AND how manufacturers held with the standard, as well as updates to bios, were usually the issues.

If you have a bios / machine that is capable of UEFI .. then it is usually better to rely on that, then on CMS.

As for specific wording... Intel's verbiage in their spec on CMs and the wording of ... "support of traditional OS's" reads as "Windows 2000, XP and Windows 7", which I believe was context at that time.

I think it is better to always install first the Classic version for MX ... (after it is always possible to activate the AHS version, the AHS repositories.)
It is my practice until now.

My totally uneducated opinion on this is: start with the standard versions.

If the system works great with that, cool! It works, that is what you want.

If there are things that DON'T work, then you can always try the AHS and such, to see if that helps sort things.

It depends on the hardware, which we really don't know much about. If it's this: https://www.notebookcheck.net/Dell-XPS- ... 652.0.html

Definitely AHS.

Don't forget you can also install a backported Debian 6.12 LTS kernel from AHS or bookworm-backports with a few clicks in MXPI and a reboot.

Eadwine Rose,
Agreed with you on this.

The OP was going onto a Dell computer, a year or so old. If the kernel guys have been doing their work, support is often in the standard kernel. And one can select many kernels, AntiX has many available, liquorix from AHS etc. If it works, it works.

But try the standard version first, it is where the most experience is had. Here is my build details with CSM and the integrated video saga.
viewtopic.php?t=85199
I still don't have the system sensors working correctly yet.

I find if I configure my system with all data on a separate data partition, is is fast and easy to try versions and kernels, especially if you test things before extensive tweaking.
Also with my partition scheme, I have the daily driver, three partitions ala Warren Woodford, 1, swap, /home.

This leaves a fourth primary partition, which I use for testing betas, and versions by installing grub to root. [soon I home a beta of MX 25 !]
This allows direct comparison of speed and stability on the same hardware by choosing one install or the other.

I muddied the waters on this thread, early, sorry to hijack the thread, but someone posted on my choice of CSM installation instead of the more modern UEFI.
But here the set up is useful.
I had maybe 1 day of booting into the AHS. Two glitches.
I now have 4 days booted into the standard. Absolutely stable, as I expect MX Linux to be.
And of course, the important detail, both versions are being booted from the same drive and BIOS with CSM. So, I don't think the CSM booting is causing instability.

I did no real trouble shooting, and it might have been some failure to load the nvidia driver (nvidia installation tool on standard version works great).
I am not saying AHS is bad or unstable, I make NO claims from this new hardware yet until stability is proven over time. Other MX installs I have regularly have 40-100 day up-times.

Stevo has the right approach, best to search the specific model, and look for Linux success or horror stories.
Noting carefully the dates !

Some stuff gets fixed with newer kernels, when it does, terrible problems, are easy as if by magic !