Artix is my first foray into the world outside of SystemD. I have done a few Arch installs before, but only now am migrating to this distro. However, whenever I try to boot the system, it hangs on checking filesystems. It gets through saying that my root partition is clean, but then hangs. The partition that is next in my fstab is /dev/sdb2, my home partition that I brought from my previous distro. I would provide logs if I could access them.
UPDATE: From further testing, I have found that the filesystem check is not always the point where it hangs.
Use the live ISO to boot, mount your root partition somewhere and comment out your /home entry in /etc/fstab (or better yet, add the noauto option). If your system reboots fine, then you can troubleshoot further.
It now hangs on remounting root filesystem R/W
Some things I might try (that might not work though) from a live iso / other bootable partition:
fdisk -l, lsblk, blkid to get some info on filetypes, UUID's, etc, carefully check /etc/fstab is correct. If unusual filesystems are used, they may need additional packages to support them. Also if I copy the root partition to clone an OS often I need to chroot in and remake the initrd, so possibly running mkinitcpio or just reinstalling the kernel with pacman (which is easier to remember the command) might help. Also try to mount the partitions in your rescue env and see if that works, run an fsck on them from there to see if they are really OK. There are probably no logs if nothing has been mounted r/w although in future you can get logs from dracut, but it isn't used yet.
Give some more info: fstype, encryption, lsblk output, fdisk -l /dev/sda...
The partition is a standard EXT4 filesystem created on an install of Arch Linux. I have moved it several times, and have not had many issues. However, it does now occur to me that I never did create a user to use said partition. There is no encryption on the drive. I have already fought with making a functional bootimage, and had to backport to the lts kernel. Without the partition, the error still occurs when remounting root. Further, one boot with home got past the home partition, so it probably is not at fault. If it means anything, they are both 1.5TB partitions(in case OpenRc has issues with large partitions). Part of me wants to try to change the runlevel and see if the log is being printed correctly.
The partitions in use are(in mounting order):
/dev/sdb5 mounted at / (EXT4 Root partition)
/dev/sdb2 mounted at /home (EXT4 Home partition)
/dev/sda1 mounted at /boot (FAT32 EFI System partition)
/dev/sda7 not mounted (Linux Swap)
They are all mounted by UUID as given by fstabgen
Kernel version in use: 4.19 LTS
Looking in /etc/init.d/fsck shows a simple way to disable fsck, make the file /fastboot which did that OK when I tried it here (although as remount is just after it probably won't help...) Alt F2/F3 etc might get another working tty login if they had been set up at that point and the OS was not hanging, just the boot.
$ sudo touch /fastboot
(rebooted)
$ sudo cat /dev/vcs1
[ ok ]
* Mounting misc binary format filesystem ...
[ ok ]
* Loading custom binary format handlers ...
[ ok ]
* Skipping fsck due to /fastboot
* Remounting filesystems ...
[ ok ] * Updating /etc/mtab ...
* Creating mtab symbolic link
[ ok ] * Activating swap devices ...
[ ok ] * Mounting local filesystems ...
[ ok ] * Configuring kernel parameters ...
[ ok ] * Creating user login records ...
[ ok ] * Starting dbus ...
[ ok ] * Starting elogind ...
UPDATE: Upon rebooting with /fastboot created, OpenRc hangs at updating the system clock. I will attempt to reinstall openrc
And both commands to reinstall it do fail
If you chroot in it usually works, even if it doesn't in the problem OS. Some users have used Arch kernels of various sorts as a workaround for hardware issues in the past, there are some non standard ones available like linux-ck, and they are available as bin pkgs that could be manually installed with pacman -U. It's unlikely to be OpenRC itself, unless it hadn't installed properly due to some error. nous might come up with some insight with more info as some issues are known on particular hardware. If you got past mounting / there's probably something logged in /var/log that might help if you mounted it and took a look.
The problem is that it sometimes hangs several tasks before mounting. The point where it hangs is inconsistent.
Another thing to note is that I currently have not set up a user account, I only have root.
useradd and userdel have a -R option to run in some other chroot too. You could try creating a test user on the / partition, and delete it later if required? It wouldn't be a case of looking at the logs to see where it hangs if it isn't consistent, but search them for "error" and "warning". You should have collected something on some boots that will now be saved in /var/log.
# /usr/bin/useradd --create-home --groups wheel,rfkill,network,audio,optical,floppy,power testuser
# passwd testuser
New password:
Retype new password:
passwd: password updated successfully
# userdel -r testuser
The boot never got past mounting rw.
Now that my computer has been moved(painting the house, sorry), I have found that OpenRC is not hanging, but crashing. The cursor stops blinking, meaning that there is no response from OpenRC during boot.
This is a arch converted system, yes?
You got to make sure each and every single arch core/extra package is replaced by the artix system/world package.
Sounds a lot like there are some arch packages left that lead to crash.
Honestly, OpenRC may just not work with my computer. I have found similar issues with Debian installs. I have found that the system boots under stock systemd arch, so I may just stick with that.
Now time to deal with wifi drivers (burn, Broadcom-wl). I apologise for the inconvenience this post may have caused.
Kernel versions should not matter too much for chrooting, I often chroot to / from different distros or outdated bootable isos with only minor complications. Artoo has a good suggestion, and there is little difference between Arch and Artix, if one works the other should too. Many of the Artix packages are built just the same as the Arch ones, but they are in the Artix repos to keep the versions compatible. The extra and community repos are used, they are Arch repos, and they are compatible. Devuan / Debian kernels can cause problems, they are server optimized. Installing aftermarket desktop / laptop optimized kernels could help there. There are also at least 3 different install isos for Artix, with different software and versions, surely something would work if you have the patience ;)
I might try using the migration procedure from this systemd arch install and see if it’s just the openrc install system being wierd