# Errors with SLiM and Block Device Naming

SLiM has well documented errors with systemd’s shutdown process (See ArchWiki). While this was the root of the problem, the related errors I found while working backwards are worth pointing out.

### Failure to mount /boot:

I noticed periodically that my boot process was failing and I was getting dropped to recovery mode. Of course, the first thing I did was check /etc/fstab for errors, but found none. Running \$ lsblk showed that my block devices had been mislabeled.

I don’t think this is particularly an Arch or Linux issue, but maybe to do with the MicroSD slots of the Asus X205TA. /dev/mmcblk0 is the onboard card, while /dev/mmcblk1 is the external that I use for a swap partition and backups.

A proper mount would look like this:

NAME               MAJ:MIN RM  SIZE RO TYPE  MOUNTPOINT
mmcblk0rpmb        179:24   0    4M  0 disk
mmcblk0boot0       179:8    0    4M  1 disk
mmcblk0boot1       179:16   0    4M  1 disk
mmcblk0            179:0    0 29.1G  0 disk
├─mmcblk0p1        179:1    0  100M  0 part  /boot
├─mmcblk0p2        179:2    0   10G  0 part  /
└─mmcblk0p3        179:3    0   19G  0 part
└─_dev_mmcblk0p3 254:0    0   19G  0 crypt /home/austin
mmcblk1            179:32   0 29.7G  0 disk
└─mmcblk1p1        179:33   0    2G  0 part  [SWAP]


However, after the initial boot, the devices were getting mixed up (e.g. the system thought /devmmcblk1p1 was the /boot partition).

• One solution would be to remove the /boot entry from /etc/fstab since it technically isn’t needed after the boot process. However, this can cause some inconvenience when it comes to things like updating your kernel or initramfs.
• So, I found that using UUIDs in /etc/fstab took care of this problem just as well.

### Failure to Execute Login Command:

Once I got to past the boot (re)mount problems I was getting “random” failure to execute login command errors from SLiM when trying to login. Typically this happens when you’ve got a typo or other errors in ~/.xinitrc. But I had no erorrs there.

I have been using Home Folder Encryption so, next I checked my dm-crypt setup and everything looked fine.

Remembering the above erros, I was able to recreate it by observing that SLiM interferes with the shutdown process. When a proper shutdown occurred, there was not a labeling error. However, when I had to hard reboot (via power button) – due to SLiM inhibiting the shutdown process – the mislabeling happend on the subsequent startup.

The solution here for me was, rather than creating a system call as the Arch Wiki suggests, just a simple shell alias to force SLiM to stop before the system tries to poweroff. Something like:

alias shutdown="sleep 1 && sudo shutdown now | sudo systemctl stop slim"