The first "officially" tested images of 2025 are available. Please, report any problems here.
Hello,
I am trying to install artix Linux on my Desktop and fail miserably...
What I've done:
downloaded the iso image from herer:
https://artixlinux.org/download.php
I've checked the sha256 checksum of the downloaded ISO:
sha256sum artix-base-openrc-20250310-x86_64.iso
cc6fac7eb62a816cbb40e59712c2d2760b554411ea1056cbd020b45aa426f446 artix-base-openrc-20250310-x86_64.iso
...
seems fine to me. I also downloaded the corresponding .sig file and tried the gpg check, which kind of fails:
gpg --auto-key-retrieve --verify artix-base-openrc-20250310-x86_64.iso.sig artix-base-openrc-20250310-x86_64.iso
gpg: Signature made Wed Mar 12 14:49:50 2025 CET
gpg: using RSA key A574A1915CEDE31A3BFF5A68606520ACB886B428
gpg: Good signature from "Christos Nouskas <
[email protected]>" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: A574 A191 5CED E31A 3BFF 5A68 6065 20AC B886 B428
tried to flash a USB with the iso using the dd command:
dd if=./artix-base-openrc-20250310-x86_64.iso of=/dev/sda status=progress
whereas /dev/sda is my newly bought USB flash drive.
dd runs through and if I reboot my laptop with the USB attached it boots into the live OS (BIOS settings set to boot from USB first of course).
When I use the same stick on my Desktop, BIOS recognizes it to be bootable as it shows up on the BIOS Boot Selection screen. But as soon as it starts booting from USB, I have a dark screen and system seems to be frozen (waited for 10 min now...)
Any suggestions on the issue and how to resolve it are highly appreciated ;)
I have a nvidia in my desktop machine. Is the issue maybe related with that?
edit: just downloaded an older image... this one:
https://iso.artixlinux.org/archived-iso/artix-base-openrc-20240823-x86_64.iso
and tried the same steps and it worked. I am in the live OS and can proceed installing... Maybe the issue can get fixed, although I have a "running" solution now. /if you need any further information(specs or something else), feel free to reach out to me.
Hm, weird, I personally boot-tested and installed all base ISOs before promoting to stable. It's probably a KMS (i.e. a kernel issue); can you try booting with disabled KMS (https://wiki.archlinux.org/title/Kernel_mode_setting#Disabling_modesetting)?
I already installed with the old iso now. But I think I can have a look later this week. I've never fuzzed around with kernel parameters (knowingly). So I guess I'll learn something new. Just need to find time for that ;)
I'll keep you updated here, as I've got new information on this.
It probably has nothing to do with the problem, but I also recommend using the options "bs=64M oflag=direct".
will do. If nothing else it shouldn't hurt
I experienced this issue too when I tried creating a bootable USB using Rufus. I attempted to burn artix-xfce-openrc-20250310-x86_64.iso to my USB using the dd mode in Rufus, but it didn't work. After failing to create a bootable USB with Rufus, I tried using Ventoy, and surprisingly, it now boots fine on my system.
Is it possible to create a custom graphical Artix Linux ISO that uses the LTS Linux kernel instead of the non-LTS one?
The attached photo is basically my current experience with any graphical Artix Linux ISO out of the box. I previously reported this problem in 2024 on https://forum.artixlinux.org/index.php/topic,7222.0.html and was told that an update would eventually resolve the issue, but the problem still affects me! I wish the graphical live environments worked fine on my machine from the start without little hacks! It would have been handy for me to have access to a web browser while doing a base install.
You can chroot into the base install partition from any linux live iso or another linux partition on the system (should one exist).
Then you have your web browser for help while you set things up.
Standard blocksize is 512 Byte, so 64M is faster and oflag=direct prevent wasting memory for writecache.
Usually 4M are recommended, but with 64M I had the best experiences. No matter if USB Stick, HD, or SSD.
Yeah, I know that I can chroot into the base install partition from any live Linux environment. I also know that I can use the nomodeset kernel parameter, but still it would have been nice if the live Artix USB worked out of the box on all machines, like Linux Mint.
+@nous:
The artix-xfce-runit-20250310-x86_64.iso don't boot with Ventoy: No matter if CSM or UEFI: Screen becomes black immediately and the LED of the Stick shows no activity anymore.
Up to the artix-xfce-runit-20240823-x86_64.iso there was no Problem and I like Ventoy very much. I use it for bootable Backup-Drives too:

I don't try the weeklys, because the ISOs became so huge and my Traffic is limited.
When I started with Artix in 2020 the ISO was less than 1 GiB and even not CUPS was preinstalled: That was much better.
Which Graphic?
After booting into Ventoy, use the grub2 mode instead of the Normal mode.
Check! :)
Works with CSM, UEFI and KVM:
#!/bin/bash
if [ $# == 0 ];then echo "vms /dev/sd? …";exit;fi
cl="qemu-system-x86_64 -nodefaults -enable-kvm -cpu host -smp cores=4 -m 4G -vga none -device virtio-vga-gl -display sdl,gl=on -audio sdl,model=hda -boot menu=on"
while [ $# -gt 0 ]
do cl=$cl" -drive file=/dev/sd$1,if=virtio,aio=io_uring,snapshot=on,format=raw"
shift;done
$cl
(I belong to "disk" and know what that means)