Back in the days, hexagonrpcd was not suitable for generic device
packages and we had to hack around it with this service / script. Now
that hexagonrpcd can guess the HexagonFS directory location at runtime,
we can and should get rid of this service to align with our (future)
firmware packaging guidelines.
Part-of: <https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/8163>
This changes the override to:
1) use /sys/kernel/config for the configfs location
2) depend on the sys-kernel-config.mount unit, which will automatically
mount configfs
3) depend on modprobing libcomposite
4) create the g1/configs/c.1 path automatically in case it's not created
yet
The configfs.ini file is also updated with the path
Signed-off-by: Clayton Craft <craftyguy@postmarketos.org>
Part-of: <https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/8175>
The version of OpenBSD's doas packaged by Alpine had its last commit
21-02-2022. This in itself is not bad, but the issue is that in that time,
there have been many MRs and issues filed to the repo that see no action.
One major MR, that being a hardening patch against rowhammer attacks,
has layed stale since 03-03-2024. After Natanael Copa asked if the repo
was still maintained, the response was that it is low-priority.
As such switching to sudo-rs, despite its larger size and attack surface, makes
sense due to more users and thus more eyes on it performing analysis and fixing
security issues quicker. OpenBSD doas does not have this itself, and a low-usage
fork of it definitely does not. While there are snazzier, more modern
alternatives like run0, capsudo, or s6-sudo, none of these are in a state where
they can fully replace all the features that sudo provides.
sudo-rs was chosen over the original sudo due to a few factors. The first is
memory safety, as Rust generally solves that issue in the codebase, so a whole
class of possible vulns are eliminated. Second is that sudo-rs is already in
use by larger distributions like Canonical's Ubuntu, meaning that the user base
is already quite large, leading to similar amounts of eyes on the source code.
Third, sudo-rs has had support from the original authors of sudo, allowing the
project to avoid the pitfalls of the legacy C codebase. Finally, sudo-rs has
already had two fairly recent independent security audits, meaning that their
security posture is diligent enough to be trusted.
See https://github.com/trifectatechfoundation/sudo-rs/tree/main/docs/audit
In the future, any further switch in the privilege-escalation tool should keep
the sudo command, be it through a symlink, shim, or a binary itself. This is
maintained currently due to having installed doas-sudo-shim by default, but
more care should be taken in the future to not break user workflows.
Partially reverts 0f327af853
See https://gitlab.postmarketos.org/postmarketOS/pmaports/-/issues/4144
Signed-off-by: Aster Boese <asterboese@mailbox.org>
Part-of: <https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/7967>
Without a sufficient vm.min_free_kbytes value, the kernel may not start
reclaiming memory early enough to make use of zram swap before the
kernel OOM killer fires. Set a minimum of 100000 KB on devices with >=
1GB of RAM where the kernel's calculated value is lower.
This ignores devices with <1GB of RAM, because I think with so little
RAM isn't unlikely to really matter and if we set this too high then we
risk insta-OOMs.
Signed-off-by: Clayton Craft <craftyguy@postmarketos.org>
Part-of: <https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/8157>
Put phosh-tour in pmb_recommends instead of having postmarketos-welcome
indirectly installed by default through
postmarketos-base-ui-gnome-mobile. In order to do that, move
postmarketos-welcome from the pmb_recommends of
postmarketos-base-ui-gnome-mobile to postmarketos-ui-gnome-mobile.
The reasons for that is that the postmarketos-welcome app by now has
in part incomplete and outdated explanations about how phosh shall be
used. For example, a common question that we don't answer but phosh-tour
does is how the keyboard can be launched from any app.
The postmarketos-welcome app warns more about that this is an
experimental system, but that is prominently displayed on our homepage
when trying to download images. Otherwise it also doesn't contain much
information that makes it worth keeping instead of phosh-tour.
Finally phosh upstrem has also said that they would be willing to have
distro-specific tour pages, so if we notice that something would be
really good to have there in the long run, we could look into getting it
in phosh-tour.
[ci:skip-vercheck]: changing pmb_recommends doesn't need rebuilds
Signed-off-by: Oliver Smith <ollieparanoid@postmarketos.org>
Part-of: <https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/8145>
* Fix wrong path for lomiri-indicator-location, this has probably
changed upstream a while ago and was missed.
* Fix font rendering on some Adreno GPUs
* Clean up dependencies
* Don't force-depend on pipewire* and wireplumber.
* Remove font-droid-nonlatin since that's already in _pmb_recommends
of postmarketos-base-ui.
* Remove networkmanager since that's already a dependency of
postmarketos-base-ui-networkmanager.
* Add more Lomiri apps as recommended
* Set home button background color, otherwise the white logo is
invisible on a (default) white background.
Part-of: <https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/8076>
We pre-install Firefox but that isn't available anymore on x86 since
67ceb722092486a00de16b6ae72933e179f07fc9 in aports. Since
_pmb_recommends doesn't support things like 'case "$CARCH" in', there is
no way to conditonally disable Firefox on the architecture so we have to
disable the entire UI for it for now.
[ci:skip-vercheck]
Part-of: <https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/8080>
All GNOME-like UIs should install the backgrounds to get a few default
ones to choose from in g-c-c. ui-gnome previously pulled them in per
`gnome`-pkg, ui-gnome-mobile previously depended on the wallpapers
directly. So only phosh has a actual effect.
Part-of: <https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/8068>
On devices using a combined initramfs, init_2nd.sh is exec'd directly
from the first stage without ever calling load_modules(). This means the
loop kernel module (CONFIG_BLK_DEV_LOOP=m) is not guaranteed to be
loaded before mount_subpartitions() runs, causing losetup to fail:
losetup: /dev/sda13: failed to set up loop device: No such file or directory
ERROR: failed to mount subpartitions!
On the split initramfs path (init.sh), load_modules is called explicitly
before jumping to init_2nd.sh, so this regression did not affect those
devices.
Fix by explicitly loading the loop module in mount_subpartitions(),
right before the loop that searches for partitions. This location was
suggested by Clayton Craft.
Regression introduced by: 86bdb82116 (use loop device for subpartitions)
Tested on: oneplus-cheeseburger (combined initramfs, msm8998, loop=m)
Part-of: <https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/8034>
This reworks the subpartition init to use loop devices instead of
kpartx/dm mappings. This allows us to use the same logic for resizing
as we do for other partitioning schemes (and refactors that code a bit).
This also helps duranium, because systemd tooling (repart, sysupdate,
gpt-auto-generator) can't properly handle GPT subpartitions exposed via
kpartx dm mappings, but works correctly with loop devices created with
partition scanning enabled.
After this change, subpartitions show up as loop devices, e.g.:
$ ls /dev/loop*
/dev/loop0p1
/dev/loop0p2
There *should* be no impact to existing installs.
This also drops the dependency on multipath-tools, which seems to have
been added years ago as a workaround for installing kpartx (like maybe
multipath-tools used to provide kpartx?), see 7573f5fce4. Anyways, we
don't use anything in this pkg in the initramfs AFAIK.
Signed-off-by: Clayton Craft <craftyguy@postmarketos.org>
Part-of: <https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/7932>
Bart Ribbers