I wonder if the problem can be the SSD: it’s a SN850.
But then why XUbuntu on a microSD would also get stuck during the boot sequence? (maybe because the SSD is still inside the machine?)
Also, why the issue would start to happen suddenly, while for months all was perfect?
EDIT: no it’s not the SSD, as I have the same problem with another SSD model.
If you want to, you could try removing the “quiet” kernel parameter. There should be a lot more text on the screen, possibly indicating that it gets stuck at some other point.
Press e in the grub menu, go to the linux line and remove the word “quiet”, press ctrl + x to boot.
Might be. You could try some live USB with a recent kernel like fedora 37 just to rule out old kernel problems but Artix should already be on 6.1.x so… not all that much hope left. However if the device or your Artix install is somewhat usable with “nomodeset” you can at least, well, use it for now.
I’ll try nomodeset and I’ll try to disable VT-d, those are both excellent ideas!! (I’ll try in a little while, I can’t do it right now)
Although, of course I’d hope to come back to full functionality eventually, but for a temporary fix it would be nice.
I think that Windows automatically does something equivalent to nomodeset which is why my SO is able to use it, but not me with Linux.
adding nomodeset to my Artix kernel arguments did allow to start completely, except Xorg that is still unable to run. So I can use Linux in text mode, at least. It may be because I would need to install an additional xf86-video-* package, but as I was unable to connect to Internet (ethernet extension card not detected, and a minor problem with bluetooth/wifi), I give up for now.
Well that fits to the issue in the other thread.
After replicating the “nomodeset” kernel parameter on my other (Arch Linux) System, which also uses an intel iGPU, I installed xf86-video-vesa and xf86-video-fbdev and got graphical video output. Before that Xorg did indeed not start (because it had no driver).
But without the internet connection working it might be a bit of a pain to install those.
For Arch Linux (and probably Artix as well) you could use another computer to download it from the official package website (say Arch Linux - xf86-video-fbdev 0.5.0-3 (x86_64) but for Artix) and put it on a USB stick and try installing using sudo pacman -U /path/to/package
You probably want to download both -vesa and -fbdev drivers first.
You probably need to mount your USB-Stick manually though. Assuming the USB drive is /dev/sda1: (check lsblk for unmounted /dev/sd* partitions) sudo mkdir /mnt/usbstick
sudo mount /dev/sda1 /mnt/usbstick
First, an update on the sdcard Live Ubuntu Linux (with nomodeset): it works!
The other Ubuntu I had tried yesterday was in fact, not a “live” but a bootable full installation on the sdcard.
Both for the full-sdcard-Ubuntu and Artix, I think the problem was that I used a xorg.conf file which asked explicitly for the modesetting video driver. EDIT: on the full-sdcard-Ubuntu there was no custom xorg.conf, so that’s something else…
I’ll try commenting the contents of the xorg.conf.
Then if it still doesn’t work I’ll install a xf86-video-fbdev package or something.
Then I’ll report.
I’m also in progress on the diagnostics with Support.
On the Artix SSD, if I both install xf86-video-fbdev and remove my custom xorg.conf, it works (i.e. Xorg starts). I tried to do only either but both are really required.
No update for the full-install Ubuntu sdcard for now, I’ll try to get the log from Xorg.
However there seem to be deeper problems with systemd on this Ubuntu (the other one, the real Live one, works [i.e. Xorg starts]). Thus that may make it trickier to get the log.
Good to know it is at least partially working. Do the expansion ports work neither on Artix nor on the Ubuntu Live boot? Since the SD card reader is working if you can boot from it, does it matter which port it is plugged into?
Does the ethernet card show up in lsusb?
Apart from trying different ports I don’t have any useful tips at the moment.