Fails on (and should be removed from) raspi desktop

[Dave Jones]

The protection-domain-mapper package (and qrtr-tools) are both installed by default on the Ubuntu Desktop for Raspberry Pi images, thanks to their inclusion in the desktop-minimal seed for arm64. However, there's no hardware that they target on these platforms, and the result is a permanently failed service (pd-mapper.service).

It appears these were added to support the X13s laptop [1]. I've attempted to work around the issue by excluding these packages in the desktop-raspi seed (experimentally in my no-pd-mapper branch [2]) but this does not work (the packages still appear in the built images). Ideally, these packages should be moved into a hardware-specific seed for the X13s (and/or whatever other laptops need these things). Alternatively, at a bare minimum, the package should have some conditional that causes the service not to attempt to start when it's not on Qualcomm hardware.

[1]: https://git.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/+git/ubuntu/commit/desktop-minimal?id=afe820cd49514896e96d02303298ed873d8d7f8a

[2]: https://git.launchpad.net/~waveform/ubuntu-seeds/+git/ubuntu/commit/?id=875bddac19675f7e971f56d9c5d39a9912dc6e38

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Ubuntu QA Website (ubuntuqa)]

This bug has been reported on the Ubuntu ISO testing tracker.

A list of all reports related to this bug can be found here:
http://iso.qa.ubuntu.com/qatracker/reports/bugs/2062667

[Mark Esler (eslerm)]

This impacts all arm64 installs, not just raspberry pi.

The MIR for qrtr and protection-domain-mapper [0] was requested late in the Mantic cycle and was only approved by Security since it was promised to only be used for x13s hardware enablement. Hopefully Qualcomm IPC is only enabled for x13s kernels.

As noted in the qrtr MIR:
> We should be cautious of IPC routers running root permissions. Similar code has
> enabled vendor backdoors [1].

Furthermore, qrtr has nearly no documentation and has no inline code comments [2].

Please remove this from the mantic and noble's ubuntu-meta package.

[0] https://bugs.launchpad.net/ubuntu/+source/qrtr/+bug/2038942
[1] https://redmine.replicant.us/projects/replicant/wiki/samsunggalaxybackdoor
[2] https://github.com/linux-msm/qrtr

[Tobias Heider (tobhe)]

Can confirm that this is was a major annoyance on my m2 air after upgrading to noble. it seems like this worked better in previous releases. Looking at my logs it seems like it was already installed on mantic but didn't cause startup problems. I think it gets pulled in by being in Recommends for ubuntu-desktop.

I'm all for making it device specific instead. IMO there is no point in having it installed on non Qualcomm devices.

[Tobias Heider (tobhe)]

Looking at the diff between mantic and noble I think the regression was cause by a change to pd-mapper.service.in for https://bugs.launchpad.net/ubuntu/+source/qrtr/+bug/2054296

[Juerg Haefliger (juergh)]

We should drop it from the seed since we're not building ARM ISOs anymore.

[Tobias Heider (tobhe)]

I don't think that's enough since it also gets pulled in by ubuntu-desktop and ubuntu-desktop-minimal as recommends. It would also be nice if we found a solution that fixes the issue on existing installations since upgrades from mantic to noble will trigger the bug.

[Seth Arnold (seth-arnold)]

I'm having trouble seeing what the consequences are:

> the result is a permanently failed service

vs

> this is was a major annoyance on my m2 air after upgrading to noble

Was it it more than a red line in systemctl status output? Does it have annoying logging behaviour or break some other service if it isn't running?

[Tobias Heider (tobhe)]

> Was it it more than a red line in systemctl status output? Does it have annoying logging behaviour or break some other service if it isn't running?

Red lines and an avoidable boot delay while trying to restart and failing a bunch of times.

[Nicolas Dechesne (ndec)]

pd mapper and qrtr-ns both rely on opening the AF_QIPCRTR socket interface. Wouldn't the right thing to do to do some sort of socket based activation in the systemd services ? We could work with upstream on that. That looks like even something that can be done through our qcom partnership.

[Dave Jones (waveform)]

> Was it it more than a red line in systemctl status output? Does it have annoying logging behaviour or break some other service if it isn't running?

A red line in systemctl status output is sufficient, to my understanding? I was under the impression that, absent any hardware issues, a freshly installed copy of Ubuntu ought to boot to the "running" state, and that booting to the "degraded" state was a bug (e.g. LP: #1660598). Not necessarily a high-priority one if it doesn't break any other functionality (and I acknowledge this does not, as far as I can tell), but a bug nonetheless as it interferes with the ability to notice when something else is failing.