postmarketOS pmaports Mount Issue

Table of Contents

What is the issue?

There are a number of known issues (#258, #661, #664) related to the mounting of the root and boot partitions by fstab when they should be mounted from the initramfs. There is a merge request (https://gitlab.com/postmarketOS/pmaports/-/merge_requests/1398) to address these issues.

How to tell if your system is impacted

At the moment the fix is not merged, so we are all impacted. However, to verify you can open up /etc/fstab and see if it lists the root and boot mount points:

# <file system> <mount point>   <type>  <options>               <dump>  <pass>
LABEL="pmOS_root"       /       ext4    relatime,data=ordered   0       1
LABEL="pmOS_boot"       /boot   auto    defaults                0       2

When the fix has been merged /etc/fstab will have a comment stating that it is not being used to mount boot or root. Having said that, even if the fix has been merged, if the impacted packages have not been upgraded you might still have old artifacts in the boot partition.

What is the impact?

Sometimes when you boot your device the boot partition will not be mounted. Other times it will be mounted. To test if boot was mounted properly you can simply use the mountpoint(1) command.

second-chance:~$ mountpoint /boot
/boot is not a mountpoint

You can see that the contents of what should be in boot were actually written to the root file system in a directory named boot.

second-chance:~$ ls /boot
initramfs-postmarketos-allwinner        sun50i-a64-pinephone-1.1.dtb            uInitrd-postmarketos-allwinner
initramfs-postmarketos-allwinner-extra  uImage-postmarketos-allwinner           vmlinuz-postmarketos-allwinner

There were probably written there during an upgrade, that means that the real /boot partition might not have the latest version of those files.

What to do about it?

You may wish to backup the contents of the /boot directory before proceeding. I decided to not assume that the contents of the /boot directory are the latest version of those files. I have upgraded several times with this issue and perhaps only some of those times the boot partition was not mounted. I decided to remove the contents of the directory (not the partition) /boot and then mount the boot partition manually. After that we will reinstall the packages responsible for these files.

second-chance:~$ sudo rm /boot/*
second-chance:~$ sudo mount /dev/mmcblk0p1 /boot
second-chance:~$ ls -lah /boot
total 41M
drwxr-xr-x    3 root     root        1.0K Jul  6 07:44 .
drwxr-xr-x   21 root     root        4.0K May 31 12:40 ..
-rw-r--r--    1 root     root         949 Jun 17 03:19 boot.scr
-rw-r--r--    1 root     root        1.4M Jul  6 07:44 initramfs-postmarketos-allwinner
-rw-r--r--    1 root     root        6.6M Jul  6 07:44 initramfs-postmarketos-allwinner-extra
drwx------    2 root     root       12.0K May 31 12:40 lost+found
-rwxr-xr-x    1 root     root       34.9K Jul  6 07:44 sun50i-a64-pinephone-1.1.dtb
-rw-r--r--    1 root     root       15.7M Jul  6 07:44 uImage-postmarketos-allwinner
-rw-r--r--    1 root     root        1.4M Jul  6 07:44 uInitrd-postmarketos-allwinner
-rw-r--r--    1 root     root       15.7M Jul  5 11:56 vmlinuz-postmarketos-allwinner

The apk info --who-owns command can be used to identify some of the packages which are responsible for deploying payloads to the boot partition.

second-chance:~$ find /boot -type f -exec apk info --who-owns '{}' \;
find: /boot/lost+found: Permission denied
ERROR: /boot/sun50i-a64-pinephone-1.1.dtb: Could not find owner package
/boot/boot.scr is owned by device-pine64-pinephone-0.3-r2
/boot/vmlinuz-postmarketos-allwinner is owned by linux-postmarketos-allwinner-5.7.0_git20200704-r0
ERROR: /boot/uInitrd-postmarketos-allwinner: Could not find owner package
ERROR: /boot/initramfs-postmarketos-allwinner-extra: Could not find owner package
ERROR: /boot/uImage-postmarketos-allwinner: Could not find owner package
ERROR: /boot/initramfs-postmarketos-allwinner: Could not find owner package

From the output we can see that we will need to run a fix on at least device-pine64-pinephone and linux-postmarketos-allwinner. The GitLab issue mentions postmarketos-mkinitfs and after asking on IRC what packages were responsible for payloads to the boot partition, it was suggested that postmarketos-mkinitfs is also important.

Now, let’s run the apk fix command for all three of the identified packages and their dependencies. When typing the command, be careful not to make a typo in any of the package names because nvalid package names will be silently ignored. For that reason, I will run a simulation first so that I may visually verify that all three packages will be reinstalled.

second-chance:~$ apk fix -sr  device-pine64-pinephone linux-postmarketos-allwinner postmarketos-mkinitfs
(1/3) Reinstalling postmarketos-mkinitfs (0.12.2-r0)
(2/3) Reinstalling linux-postmarketos-allwinner (5.7.0_git20200704-r0)
(3/3) Reinstalling device-pine64-pinephone (0.3-r2)
OK: 1413 MiB in 616 packages

After that, drop the simulation flag -s, add the dependency flag -d and run the command again:

second-chance:~$ sudo apk fix -rd  device-pine64-pinephone linux-postmarketos-allwinner postmarketos-mkinitfs

I omitted the output because the list is quite long.

Now, when I list the contents of /boot you can see that many of the payloads were updated:

second-chance:~$ ls -lh /boot
total 41M
-rw-r--r--    1 root     root         949 Jun 17 03:19 boot.scr
-rw-r--r--    1 root     root        1.4M Jul  7 08:29 initramfs-postmarketos-allwinner
-rw-r--r--    1 root     root        6.6M Jul  7 08:29 initramfs-postmarketos-allwinner-extra
drwx------    2 root     root       12.0K May 31 12:40 lost+found
-rwxr-xr-x    1 root     root       34.9K Jul  7 08:29 sun50i-a64-pinephone-1.1.dtb
-rw-r--r--    1 root     root       15.7M Jul  7 08:29 uImage-postmarketos-allwinner
-rw-r--r--    1 root     root        1.4M Jul  7 08:29 uInitrd-postmarketos-allwinner
-rw-r--r--    1 root     root       15.7M Jul  5 11:56 vmlinuz-postmarketos-allwinner

Verify mountpoints

To validate both / and /boot mountpoints we can use the mountpoint(1)]] command once again.

second-chance:~$ mountpoint / && mountpoint /boot
/ is a mountpoint
/boot is a mountpoint

Another way to verify that mountpoints exist for boot and root is to use the lsblk(8) command to list the block devices with a MOUNTPOINT column.

second-chance:~$ lsblk
NAME         MAJ:MIN RM  SIZE RO TYPE  MOUNTPOINT
mmcblk0      179:0    0 59.5G  0 disk
├─mmcblk0p1  179:1    0   79M  0 part  /boot
└─mmcblk0p2  179:2    0 59.4G  0 part
  └─root     254:0    0 59.4G  0 crypt /
mmcblk2      179:32   0 14.7G  0 disk
├─mmcblk2p1  179:33   0   65M  0 part
├─mmcblk2p2  179:34   0    1G  0 part
├─mmcblk2p1  254:1    0   65M  0 part
└─mmcblk2p2  254:2    0    1G  0 part
mmcblk2boot0 179:64   0    4M  1 disk
mmcblk2boot1 179:96   0    4M  1 disk

Note, in my case postmarketOS is deployed to an SD card and my root file system is encrypted. Your output might very depending on your configuration.

There are other ways to validate mountpoints of course, but either of the above methods should provide you with sufficient confidence that boot and root are mounted correctly.

After thoughts

Until this issue is fixed, you will want to double check that /boot is mounted before running apk upgrade -a. otherwise, the updated initramfs will be deployed to a directory named /boot once again, rather than to the boot partition where it belongs.

Comments

Your comment has been submitted and is now pending moderation

Be the first to comment on this article.