GRUB is broken

[MH3]

Set GRUB_DISABLE_LINUX_UUID=true then did update-grub. Modified /etc/fstab to replace UUID entries with traditional device names. When I rebooted I was left in a console with an error message about a missing "machine-id" or some such. Since I'm no longer running MX Linux because of this and other issues I can't re-create the exact error message. Just an FYI for developers.

[tony37]

The only thing I can come up with is that the initramfs was still hardcoded to try to resume from your swap partition using a UUID.

[MH3]

The only thing I can come up with is that the initramfs was still hardcoded to try to resume from your swap partition using a UUID.

Maybe. But why would it try to resume from swap in the first place? This was a desktop installation that never goes to sleep. I have seen initramfs complain about a missing UUID for the swap partition (Debian Buster) but it never failed to boot the system. Also, I've had lots of issues with GRUB and UUIDs, which is why I disable them, and I've never seen the "missing machine-id" error before.

On a related note, I tried reinstalling GRUB (using a GRUB rescue disk) and ended up with the exact same issue. That also has never happened to me before, and I've reinstalled GRUB using GRUB rescue on numerous occasions. It's always left me with a bootable system.

[fehlix]

probably nothing related to grub, but rather with an invalid fstab. Also note: device names like /dev/sda, /dev/sdb
can change they are not static. Depending on linux kernel version and whether you plugged in an e.g. USBstick, you might get next boot other device names. A more stable alternative would be using partition filesystem-labels, if you rather prefer not to use UUID's.

[MH3]

probably nothing related to grub, but rather with an invalid fstab. Also note: device names like /dev/sda, /dev/sdb
can change they are not static. Depending on linux kernel version and whether you plugged in an e.g. USBstick, you might get next boot other device names. A more stable alternative would be using partition filesystem-labels, if you rather prefer not to use UUID's.

I always make the mistake that other people will understand implicit that's implicit. I run Debian Buster. I've mentioned that previously. I run it on multiple machines, desktop, laptop, netbook. MX Linux is supposedly based on Buster. I've posted three problems I've experienced with MX Linux that I have NOT experienced with Debian Buster.

I also explicitly stated that I've had issues with GRUB and UUIDs. I mentioned explicitly that I disable those UUIDs. Implicit in those statements is the fact that I have no problem with traditional device names. My BIOS does not arbitrarily reassign devices. This should have been understood based on what I previously stated.

I do NOT need suggestions about how to configure /etc/fstab as that should also have been clear from my previous post. What is needed is for the MX team to address the issues I've raised rather than trying to educate me on matters I am already familiar with.

LET ME REPEAT MYSELF. I HAVE EXACTLY THE SAME CONFIGURATION SETTINGS IN DEBIAN BUSTER THAT I TRIED TO USE WITH MX LINUX. THERE ARE NO ISSUES WITH DEBIAN BUSTER. THERE ARE SEVERAL ISSUES WITH MX LINUX.

1. The Nvidia installer is broken;
2. GRUB is broken;
3. OSS sound is broken.

I HAVE NONE OF THOSE ISSUES WITH DEBIAN BUSTER.

And before you tell to me f_off and use Debian, that is what I'm doing. I'm merely posting here in an attempt to assist the MX developers in fixing problems. I was extremely impressed with MX Linux when I recently installed it in a VM. So much so that I installed it on my laptop to test it on real hardware. Again, I was impressed. So much so I decided to install it on my production desktop. That turned out to be a mistake, as it revealed several flaws in the distro. While many people may not experience those same problems (excepting the Nvidia issue), those flaws were for me deal breakers.

Mostly what I've received from MX support is denial that any problems exist. It's hard to solve problems when you're in denial.

[fehlix]

It's hard to solve problems when you're in denial.

It's hard to solve problems without given enough information.
You might consider read "How to ask for help".

[tony37]

I did the same thing as you did: change fstab from uuid's to /dev/sdax and set GRUB_DISABLE_LINUX_UUID=true + update-grub. I have no problems here.
So somehow there must be something unusual going on with your hardware, I'm not implying this is your fault, but without more info about that hardware the developers won't be able to do much about this.

I think the Nvidia issue was just a misunderstanding that sometimes when you click on 'submit' on this forum, it doesn't submit automatically when someone else has posted while you were typing. You somehow went a bit paranoid because of that, otherwise the nvidia problem might have been solved long ago, or at least it would have been clearer what caused it.

And about the OSS issue: you told there yourself that you also had similar issues with Kubuntu 20.04 and with Debian testing. The conclucion seems obvious that you had these issues in MX too because for some programs MX is using newer versions (I guess the AHS) than vanilla Debian Buster. If you don't tell us for example which kernel you're using in Debian, then it's difficult to say if your problems are because of the kernel or not.