Have an odd issue that I've not run into yet on any other distro even after hard shutdowns. Approximately every 5-10 reboots Artix can't seem to find my luks FDE partition. After entering in the passphrase it just says that the partition can't be found. Not a big deal because it can be fixed by booting off the Artix live USB, cryptsetup and mount the partition then cleanly cryptsetup close and reboot and it will start working properly again but just a hassle at this point if I'm in a rush. Anyone have any thoughts on a permanent fix? Because the decryption happens so early on I don't think there will be any logs to indicate what's going on.
Can you post your /etc/fstab and your boot cmdline (It will be in some conf file in /boot, and will include vmlinuz, initrd, etc.)
Sorry. I didn't receive an email letting me know there was a reply. I will post the requested information tonight.
You must mean /boot/grub/grub.cfg and the menuentry you use to boot the specific partition up. More specifically the linux line would be of interest but the whole menuentry is best.
Sorry again, been busy putting Artix on 20 other machines and documenting the live CD issues and workarounds for my friends that are also replacing their current setups with Artix.
Here is the line:
linux /boot/vmlinuz-linux-lts root=UUID=XXXXXXXXXXXXXXXXXXXXXXXXXX rw quiet cryptdevice=UUID=XXXXXXXXXXXXXXXXXXXXXXX:luks-XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX root=/dev/mapper/luks-XXXXXXXXXXXXXXXXXXXXXXXXXXX resume=/dev/mapper/luks-XXXXXXXXXXXXXXXXXXXXXXXX
(UUID info intentionally sanatized)
As I stated, this happens after the machine has been cleanly powered off. Booting the machine back up from the Artix LiveCD and cryptsetup luksOpen then luksClose then reboot lets the machine boot up properly without making any other changes. Also, this only happens on my Sony Vaio. I have a Lenovo Yoga 2 Pro & a Dell Precision 7510 that doesn't have this issue. Grepping for the drive in all the logs doesn't return lines indicating that there was any error of any type or that it was dismounted improperly.
And this is the contents of fstab although this happens at the grub prompt:
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a device; this may
# be used with UUID= as a more robust way to name devices that works even if
# disks are added and removed. See fstab(5).
#
# <file system> <mount point> <type> <options> <dump> <pass>
UUID=XXXX-XXXX /boot/efi vfat defaults,noatime 0 2
/dev/mapper/luks-XXXXXXXXXXXXXXXXXXXXXXXXXXXX / ext4 defaults,noatime,discard 0 1
/dev/mapper/luks-XXXXXXXXXXXXXXXXXXXXXXXXXXXX swap swap defaults,noatime,discard 0 2
tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0
Any ideas on this one? I just did an update on my Lenovo 2 Pro and now it has the same issue as the Vaio. Booted up fine before the update now it's having the same symptoms. Boots up to Luks prompt and after entering in the key correctly eventually times out and states "error: disk `cryptouuid/98173482573856091234asdfawuih2232` not found"
This needs further investigation. Could you paste here the packages that got updated?
My experience is this happens either when hardware acks up or when there is a process access the drive that can't be killed for some reason. It won't unmount if there are processes still pointing to files on the FS.
Lately I've found it hard to manually unmount a partition and I get "device is busy" even though it is not busy as far as I can tell. So I wonder whether a delayed or impossible shutting down is caused by difficulty to unmount a volume.
I've had the exact same thing happen on my desktop and my laptop. The desktop is dual boot, so I boot the OS on the other hard drive and fix the Artix HD with fsck. On the laptop, I gave up and installed a different distro.
why would you instlaa a different system based on this minor problem?
Thanks, that needs alot of studying on its own.
I did not download the gui for it as it needs all that jre (7,8,9) to run, I am tempted to temporarily as it seems very complex for meaningful use.
Early on I couldn't locate how lsof would point me to files open from a specific mount point, other than grep the mount point. I tried that while on chroot to a mounted installation and it produced nothing.
how can you do this it in chroot? In fact, chroot can be hanging you. Usually, when this happens, it is a case of a moved log file which still have open handle, or an opened socket that was removed from the file system but still ghosted. Could be a database semiphore as well, or a mounted network drive that disapeared which confused the file system. I'm not sure why you care, though. Who cares if the filesystem hangs when the system goes down, as long as it goes down. These files systems are fairly bullet proof these days.
[
Because I need a laptop that will boot when I turn it on. At home, if my desktop computer won't boot, I have another computer available to use. When I'm away from home, however, I need my laptop to be reliable. As much as I want it to be, Artix just isn't there yet.
I'm not sure if we are miscommunicating here or if something else is happening.
A file system that doesn't unmount cleanly, on a modern file system, will amost certainly __not__ prevent the system from rebooting. This would be true of a UEFI system, which has a seperate boot partition, or a traditional setup. The system will just clear unclosed bits on boot up. I think they will even do an fsck on a rougue file system, although I can't imagine what abuse you would need to do to the system to cause this kind of error to the point where the system won't mount or boot.
Also, this is not likely an OS problem. It is likely a run away user space process problem.
So you might find Artix as not ready for your purposes, but not for this reason.
I don't have any processes locked keeping the drive open and it shuts down clean it just don't come back up clean after a shutdown. I haven't gotten any further finding the root cause because there is nothing in the logs. What I have been doing is keeping a Artix install USB handy and when it happens, I boot live, launch partitionmanager, unlock the drive, re-lock it, reboot and everything just works again. I don't have the same issue on my Precision 7510 however and both machines are UEFI but I don't even have to mount the /boot partition to get it working again just /
Tell me do you duel boot with windows?
A pox on you mentioning that thing here :). J/K no dual boot here. Artix all the way.
Possibly dracut would log something if you set it? See the manpage for dracut.
Artix doesn't have dracut, we have mkinitcpio.
I should have checked that suggestion properly, ;D on non Artix compatible HW at that moment so I searched the forum for dracut instead. Yes, it was there... So is THAT why F2FS installation fails looking for dracut? You found the answer! I'll keep quiet - for a bit... ;)
https://forum.artixlinux.org/index.php/topic,394.msg3132.html#msg3132
If dracut is the reason why it fails, then yes that would be the cause. dracut can be found in the AUR though if F2FS is really desired.
I'm hugely sorry I wasn't able to provide more supporting troubleshooting information on this but the problem for me seems to have been resolved (at least over the course of patching over the last few weeks). Not sure if it was a patch that fixed the issue or if switching to only using pacman + yaourt for updates was the true fix but I no longer have the issue on any of my systems at all. If no one else is experiencing this issue I will change the subject & mark it as solved unless you guys want me to leave it as is?
Hopefully you might be able to tell us what you did to fix it to help other people who have the same issue. But if not, don't worry. I will go ahead and mark this as closed since your issue is resolved.
Unfortunately, as stated, the only thing I did was keep up with the updates and stop using pamac. I'm really trying to be a contributor and not just a "consumer" for Artix because I'm a strong believer and supporter of it's direction and mission but unfortunately, that's all I did to fix the problem. After a while it seems to have just worked it's own way out.