Which Version of MX to install?

[grasshopper]

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.

[siamhie]

AHS version.

[entropyfoe]

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.

Code: Select all

System:
[b]  Kernel: 6.1.0-37-amd64 [6.1.140-1][/b] arch: x86_64 bits: 64 compiler: gcc v: 12.2.0
    parameters: BOOT_IMAGE=/boot/vmlinuz-6.1.0-37-amd64 root=UUID=<filter> ro quiet splash
  Desktop: Xfce v: 4.20.0 tk: Gtk v: 3.24.38 info: xfce4-panel wm: xfwm v: 4.20.0 vt: 7
    dm: LightDM v: 1.32.0 Distro: MX-23.6_x64 Libretto Jan 12  2025 base: Debian GNU/Linux 12
    (bookworm)
Machine:
  Type: Desktop System: ASUS product: N/A v: N/A serial: <superuser required>
[b]  Mobo: ASUSTeK model: PRIME B650-PLUS WIFI[/b] v: Rev 1.xx serial: <superuser required>
    BIOS: American Megatrends v: 3057 date: 10/29/2024
[b]CPU:
  Info: model: AMD Ryzen 7 9700X bits: [/b]64 type: MT MCP arch: N/A level: v4 note: check
    family: 0x1A (26) model-id: 0x44 (68) stepping: 0 microcode: 0xB404023
  Topology: cpus: 1x cores: 8 tpc: 2 threads: 16 smt: enabled cache: L1: 640 KiB
    desc: d-8x48 KiB; i-8x32 KiB L2: 8 MiB desc: 8x1024 KiB L3: 32 MiB desc: 1x32 MiB
  Speed (MHz): avg: 3006 high: 3050 min/max: 3000/3800 boost: enabled scaling:
    driver: acpi-cpufreq governor: ondemand cores: 1: 3000 2: 3000 3: 3000 4: 3000 5: 3000 6: 3000
    7: 3050 8: 3000 9: 3000 10: 3000 11: 3000 12: 3049 13: 3000 14: 3000 15: 3000 16: 3000
    bogomips: 121599
 ...
Graphics:
  Device-1: [b]NVIDIA GK208B [GeForce GT 710] vendor: Micro-Star MSI driver: nvidia v: 470.256.02[/b]
    non-free: series: 470.xx+ status: legacy-active (EOL~2023/24) arch: Fermi 2 code: GF119/GK208
    process: TSMC 28nm built: 2010-16 pcie: gen: 2 speed: 5 GT/s lanes: 8 bus-ID: 01:00.0
    chip-ID: 10de:128b class-ID: 0300
  Display: x11 server: X.Org v: 1.21.1.7 compositors: 1: xfwm v: 4.20.0 2: Compton v: 1 driver:
    X: loaded: nvidia unloaded: fbdev,modesetting,nouveau,vesa alternate: nv gpu: nvidia
    display-ID: :0.0 screens: 1

....
Swap:
  Kernel: swappiness: 1 (default 60) cache-pressure: 100 (default)
  ID-1: swap-1 type: partition size: 64.45 GiB used: 0 KiB (0.0%) priority: -2
    dev: /dev/nvme0n1p2 maj-min: 259:2
    
[b]Sensors:
  System Temperatures: cpu: 0.0 C mobo: N/A gpu: nvidia temp: 44 C[/b]
  Fan Speeds (RPM): N/A gpu: nvidia fan: 50%

Boot Mode: BIOS (legacy, CSM, MBR)

[j2mcgreg]

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.

[CharlesV]

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 !!!!

[figueroa]

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

[CharlesV]

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

+1

[DukeComposed]

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.

[CharlesV]

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

[wdscharff]

@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 ;-}