pending unit after encrypted boot

[Dimitri John Ledkov]

This seems to work okay from my testing, which was done with manually built images on amd64 with encryption on and off, in install, run and recover modes. I also tested this with manually built images for arm64 on the rpi4, by downloading kernel rev 154, and injecting these changes into the initrd there.

I also checked the output of `systemctl list-units --all` as well as `systemctl --failed` and all of the failed/inactive units there with this patch seem to match what I see w/o this patch so this patch is at least not making it any worse.

However one small thing I noticed in recover mode is that we see that the systemd unit for /dev/mapper/ubuntu-data-<uuid> is always "activating (tentative)":

$ systemctl status dev-mapper-ubuntu\\x2ddata\\x2df17d7f11\\x2df364\\x2d4b6a\\x2d8a4b\\x2ded601350a308.device
● dev-mapper-ubuntu\x2ddata\x2df17d7f11\x2df364\x2d4b6a\x2d8a4b\x2ded601350a308.device - /dev/mapper/ubuntu-data-f17d7f11-f364-4b6a-8a4b-ed601350a308
     Loaded: loaded
     Active: activating (tentative) since Tue 2020-05-12 01:48:25 UTC; 2min 7s ago
     Device: /sys/devices/virtual/block/dm-0

As per https://github.com/systemd/systemd/issues/5781, it seems this is caused by a discrepency between either fstab or /proc/self/mountinfo about where /dev/mapper/ubuntu-data-<uuid> actually comes from or is used by. This is probably fine for beta, but it would be nice to fix this eventually I think.

[Ian Johnson (anonymouse67)]

@xnox is this fixed? I don't see where you fixed this in ubuntu-core-initramfs git?

[Dimitri John Ledkov (xnox)]

hm, not sure what this was about.

will have to look into it again just in case.