I have been running artix for a few years. Never had any trouble with it. Yesterday, I did a system upgrade, "pacman -Syu". Now artix won't boot. It can't mount the root file system. It performs a jsck.jfs and the response is "Filesystem is clean." But, it can't mount the filesystem.
I tried booting my system with SystemRescue and did an fsck from there. It also said the the filesystem was clean. While still in SystemRescue I was able to mount the /dev/md126p5 partition (my root partition) and access files on it.
It appears that either the new kernel or the new initramfs that was created by the upgrade process is bad. I am using the OpenRC init system, but I don't think that matters at this point because the boot process doesn't get that far.
I haven't changed anything with my system hardware for a long time.
How do I get myself out of this jam?
I am attaching a log file with the boot messages I am seeing.
Something with mkinitcpio must've changed, check if you have /etc/mkinitcpio.conf.pacnew or post /etc/mkinitcpio.conf. You should also post /etc/fstab.
I completed an upgrade yesterday - not seeing that sort of issue.
[chris@mars .config]$ uname -a
Linux mars 6.11.3-artix1-1 #1 SMP PREEMPT_DYNAMIC Fri, 11 Oct 2024 03:02:25 +0000 x86_64 GNU/Linux
[chris@mars .config]$ uptime
06:10:18 up 9:19, 1 user, load average: 1.90, 1.92, 1.74
And then running my update this morning...
[chris@mars ~]$ update
:: Synchronizing package databases...
system is up to date
world is up to date
galaxy is up to date
extra is up to date
python-inflect 7.3.1-1 -> 7.4.0-1
python-pyqt6 6.7.1-2 -> 6.8.0dev2410141303-2
xf86-input-libinput 1.4.0-2 -> 1.5.0-1
From your rescue medium chroot into the Artix system and run
mkinitcpio -P. Make sure your /boot is also mounted into the chroot and also /dev, /sys and /proc are bind-mounted. If you use an Artix live medium,
artix-chroot does the bind-mounts itself.
I did a chroot to artix from my rescue system and executed mkinitcpio -P. artix still won't boot. I am attaching my /etc/mkinitcpio.conf, /etc/mkinitcpio.d/linux-lts.preset, /etc/fstab and mkinitcpio log file. (I added the .txt suffix to all of them so that this forum tool would allow me to upload them; it allows only certain file types.) Hopefully, someone can take a look at them and get a clue as to what I am doing wrong (which used to work until the latest update).
Maybe I should explain why I am loading the mdadm_udev hook. My main hard disk is actually 2 disks configured via the Intel UEFI BIOS as RAID0. I have Windows 7, artix linux, rocky linux, devuan linux and crux linux all running in different partitions. I select which one I want to run via the UEFI boot menu at boot time.
Thanks
Did you try with different kernel or downgrade your kernel?
The kernel I had before the upgrade was linux-lts 6.6.51-1.
The last system upgrade gave me linux-lts 6.6.54-1.
6.6.51-1 was still in the pacman cache so I chroot'd from my rescue system and downgraded to that one.
Artix is booting fine again.
So the problem is definitely with kernel linux-lts 6.6.54-1.
After getting artix to boot again, I tried doing another system upgrade. That gave me linux-lts 6.6.57-1. Once again, artix failed to boot. I chroot'd from my rescue system and downgraded the kernel to linux-lts 6.6.51-1 once again. Now artix is booting again.
It appears that kernel versions past 6.6.51 are incompatible with my system. Is there a way I can freeze the kernel at that version and still let pacman upgrade other packages?
https://wiki.archlinux.org/title/Pacman#Skip_package_from_being_upgraded