I have more evidence that the issue is indeed the same.
The original bug was fixed by making casper depend on finalrd, see the explanatory casper 1.420 d/changelog entry reported in comment 33. However it appears that the fix is racey: sometimes finalrd is not triggered in time at shutdown/reboot, and the system gets stuck with the errors that pivoting to /run/initramfs would prevent.
I verified this by jumping in a shell during a subiquity install and running
# systemctl stop finalrd
and logging out. After doing this the reboot doesn't fail anymore. (Note that finalrd.service has
ExecStart=/bin/true
ExecStop=/usr/bin/finalrd
so it actually does its /run/initramfs overlay mount at *stop* (= at shutdown), and not at start.) Apparently this doesn't happen early or fast enough to save the day when rebooting the live session.
I guess we need to enforce some ordering in the shutdown targets execution.
I have more evidence that the issue is indeed the same.
The original bug was fixed by making casper depend on finalrd, see the explanatory casper 1.420 d/changelog entry reported in comment 33. However it appears that the fix is racey: sometimes finalrd is not triggered in time at shutdown/reboot, and the system gets stuck with the errors that pivoting to /run/initramfs would prevent.
I verified this by jumping in a shell during a subiquity install and running
# systemctl stop finalrd
and logging out. After doing this the reboot doesn't fail anymore. (Note that finalrd.service has
ExecStart=/bin/true /usr/bin/ finalrd
ExecStop=
so it actually does its /run/initramfs overlay mount at *stop* (= at shutdown), and not at start.) Apparently this doesn't happen early or fast enough to save the day when rebooting the live session.
I guess we need to enforce some ordering in the shutdown targets execution.