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.
Some new element, I noticed that I had a blinking POST code at boot:
White (10 seconds), Green X 12, Orange, Blue, Blue, Green, Blue, Green, Green, Green
which seems to mean 0x17 or “BDS_CONNECT_CONSOLE_OUT”, i.e. “video device initialization”.
But I have no idea how to use that information.
BTW I am in contact with Support and I provided them all these informations.
They have replied to me and are working on the case.
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.
Ooh yeah, that’s a lot more information!
But I fear that what came before this screen is lost.
Thank you a lot for this tip!
Although I’m unable to take advantage of these new data… do you see anyting that stands out?
Here is another attempt while taking care to add the i915.enable_psr=0, just in case it would change anything:
Yeah this is useful in telling us that the last thing happening is i915 aka Intel graphics driver doing something. This seems relaxed:
Although the outcome isn’t all that positive… You might try Ubuntu “Safe Graphics”, maybe it works and see if you can replicate what was seen in that thread.
Ouch. Exactly the same thing.
Likely a hardware issue too, then…
Many many thanks…
I’m in contact with Support, I’ll see soon.
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.
Could you maybe try to disable “VTd” in the BIOS?
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.
It would be really interesting to know if Windows now uses Software Rendering as well. However I don’t know how you would check that.
So, the results:
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.Please paste your dmesg log here so we can figure out what’s going on.
Also the Xorg.0.log would be useful to see why it cannot even use mesa drivers. (or did you not install any?)
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-4 (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.
Update:
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.
As for the extension ports, it looks like nothing works except the charging port for power: USB-A, ethernet, both fail.
I managed to use a USB-A mouse once during these tests, but did not manage to reproduce. Weird fluke.
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.
This prompted me to do more thorough testing, and I also sent these results to Support.
I have done more thorough tests on whether the sdcard or the USB-A are usable at boot time with a Live Ubuntu.
What I have said before is inexact (I tried generalizing with too little data etc etc).
These results below are reproducible and constant.
L=left R=right U=upper (closer the screen hinge) D=lower (further from the screen hinge)
Y=yes N=no
Can see the Linux EFI from the F3 menu at boot:
With micro-sdcard reader in slot
LU:Y LD:Y RU:Y RD:N
With USB-A (and a micro-sdcard to USB-A adapter) in slot
LU:Y LD:Y RU:Y RD:Y
Yes it’s hard to believe, but while the sdcard consistently fails in the RD slot, the USB-A consistently succeeds everywhere.
NOTE: in those tests, only one extension board was plugged in the laptop. Not even a power cord was present.
As for the USB-A mouse:
Starting from a booted Windows (at the lock screen), with all extension slots empty,
for any of the extensions slot, the scenario is the same:
So it’s like if the first extension slot used is making disappear all the others.
NOTE: again, only 1 extension card maximum was ever plugged-in at any point of these tests. No power plug neither.