Errors with SLiM and Block Device Naming

Austin Haedicke bio photo By Austin Haedicke Comment

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"
comments powered by Disqus