[SOLVED] Need "nomodeset" to boot Linux, and extension ports malfunction

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.

1 Like

Could you maybe try to disable “VTd” in the BIOS?

1 Like

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.

1 Like

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.

1 Like

So, the results:

  • 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.
  • with or without VTd the situation is the same

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

1 Like

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

1 Like

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.

1 Like

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:

  • the first extension slot in which I plug the USB-A extension card + mouse, the mouse works
  • when I move this extension card and the mouse to another extension slot, it doesn’t work, for any of the 3 other extension slots
  • if I come back to the original extension slot, it works again.

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.

1 Like

It didn’t show up.
But I may have to do more tests, as, based on the behavior of the USB-A + mouse, it may depend on if anything I plug is the first thing I plug since starting the machine.

When I do tests on Live Linuces, anything I plug will NOT be the first thing I plug…

So to continue the tests I will have to swap again the SSDs.

This issue seems interesting and weird. Given that this could be a hardware issue it might be wasted effort or as they say beating a dead horse. Would be nice if you could keep us updated with what happens regarding support or any further tests you do. I am currently out of ideas, maybe someone else might have a clue.

1 Like

So, after following a series of diagnostic checks with the Support team, they’ve got me a replacement mainboard through RMA (many thanks!!), and all the problems are solved now!

5 Likes