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>
This allows booting pmOS from u-boot on existing and new installs.
Setting the boot partition to vfat isn't strictly necessary (ext2 seems
to work OK), but IIUC either FAT is in the EFI spec or it's what
everyone else uses. We made a similar patch to the OP6/OP6T previously.
Signed-off-by: Clayton Craft <craftyguy@postmarketos.org>
Part-of: <https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/7961>
The hw CI isn't stable yet, if a platform is entirely offline (e.g.
because we only have 1 device in CI and it's down for maint.) then the
test job is "pending" for a verrrry long time (16hrs+). mrtest (for
example) is then unable to be used on the MR because the pipeline is
not "success."
Signed-off-by: Clayton Craft <craftyguy@postmarketos.org>
Part-of: <https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/7943>
Unit files were added to the upstream aports pkg.
pw and pw-pulse are no longer socket activated with this change, because
that requires linking against libsystemd(which isn't enabled upstream),
but I think that's worth avoiding all of the packaging complexity of
having a pipewire pkg fork in pmaports.
Fixes#4279
Signed-off-by: Clayton Craft <craftyguy@postmarketos.org>
Part-of: <https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/7894>
This disables swap-based killing and sets a lower pressure threshold
for user apps in the app slice so they will get killed sooner than other
things (e..g the whole session slice).
Killing based on swap usage was resulting in some sudden kills from
oomd, and upon further investigation is seems like other distros
(ubuntu, fedora) either never enabled this or walked it back due to it
being confusing for users.
The override for app.slice and sets the pressure limit to a value less
than the other slices, in an attempt to fix situations where an app
(e.g. firefox) was creating a ton of pressure and systemd-oomd was
killing the entire UI/session.
Signed-off-by: Clayton Craft <craftyguy@postmarketos.org>
Part-of: <https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/7751>
This "size"/factor/percentage represents the total amount of
**uncompressed** data that is allowed to be written to the zram-backed
swap device. It is **not** the amount of RAM to use for zram swap (as I
had previously and erroneously thought.) What this means is that if we
set the percent to 50% on a device with 3GB of RAM then up to 1.5GB of
*uncompressed* data can be written to it, BUT since compression algos
usually do better than a ratio of 1:1... less than 1.5GB of RAM will
actually be occupied by this data when it is compressed.
A 1.5:1 compression ratio seems relatively safe to assume, even if we
use lz4 (which is less "good" at compressing than zstd), so I propose we
set the size to 150%. Some distros (PureOS) set this higher (200%), but
I think we should be somewhat conservative since we want to avoid any
thrashing in case the compression ratio at runtime ends up being less
than 2:1 for some reason.
This does set a limit of 50% for devices with >32GB of RAM, to
reduce overhead with using a larger amount of zram swap. The kernel
documentation for zram suggests there's a 0.1% overhead, so if we let
this amount get large then it could be tens or hundreds of MB of RAM
"wasted." The amount I chose is kinda arbitrary, I think this can be
improved later. At the very least, users can change this amount in the
deviceinfo variable.
Fixes#4250
Signed-off-by: Clayton Craft <craftyguy@postmarketos.org>
Part-of: <https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/7754>
This is meant to replace zram-init. It's much simpler, since it only
sets up zram swap and doesn't try to do all the things that zram-init
does. This also lets us add additional logic, such as selecting
different default algorithms based on the runtime CPU arch and
conditionally applying sysctl settings that might be inappropriate when
*not* using zram swap.
To create zramstart, I took the zram-configurator, which reads config
from deviceinfo vars, and extended it to create the zram swap device.
zramstart and zramstop were inspired by what Fedora does. The sysctl
config is from the work done here:
https://source.puri.sm/Librem5/librem5-base/-/merge_requests/381
Signed-off-by: Clayton Craft <craftyguy@postmarketos.org>
Part-of: <https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/7754>
This unit will activate `time-sync.target` after system time is synced,
e.g. by NTP. We can use this target to delay starting some units until
we know that system time is correct. IIUC this shouldn't have any impact
on system startup otherwise, including existing units we enable, so
nothing should be slowed down by adding this.
Signed-off-by: Clayton Craft <craftyguy@postmarketos.org>
Part-of: <https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/7711>
Setting it to =y requires also setting CONFIGFS=y, but since we have
CONFIGFS=m this needs to be adjusted or else config generated from this
toml will fail validation / kconfigcheck.
```
[09:25:01] Copy kernel config back to pmaports dir
[09:25:02] (native) generate checksums for linux-postmarketos-asahi
[09:25:03] INFO: config-postmarketos-asahi.aarch64: CONFIG_USB_F_FS is preferably y, but currently m (category:usb_gadgets)
[09:25:03] Fragment pmos.config: CONFIG_USB_F_FS expected to be 'y' but has different value in final config
[09:25:03] ERROR: Fragment validation failed: Some options from fragments did not make it to the final kernel config. This usually means missing dependencies.
```
Signed-off-by: Clayton Craft <craftyguy@postmarketos.org>
Part-of: <https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/7713>
The previous rule is too vague and would also tag /dev/fastrpc-cdsp
devices too. Sometimes iio-sensor-proxy would bind to this which
seemed to always produce inverted orientation values. If only
/dev/fastrpc-adsp* is tagged, then orientation always seems to be
correct.
fixes#3741
Signed-off-by: Clayton Craft <craftyguy@postmarketos.org>
Part-of: <https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/7681>
MTP transfers write files to the home folder of the user.
If no GID and UID are specified, uMTP-responder will use the GID/UID
under which it is running at the time of the file transfer.
This causes users to not be able to access the files on the device after transfering.
This patch adds a systemd generator that:
1) reads /etc/default_user, and appends config to
/etc/umtprd/umtprd.conf to set the MTP default user/group. If this
file doesn't exist, 10000:10000 is the fallback uid:gid.
2) installs this config to /run/umtprd/umptrd.conf
3) adds a unit override to /run for umtprd.service that runs the daemon
with this modified config
The generator is used instead of hardcoding a uid and gid in umtprd.conf
so that this can support immutable installs or situations where the
default UID/GID is not 10000.
Co-authored-by: Dylan Van Assche <dylan@postmarketos.org>
Signed-off-by: Clayton Craft <craftyguy@postmarketos.org>
Part-of: <https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/7658>
modem-gnss / qmicli depends on qrtr being up, or it fails on boot and
GPS doesn't work on this device:
sargo systemd[1]: Starting Google Sargo (Pixel 3a) GNSS Modem Setup...
sargo qmicli[1080]: error: node with id 0 not found in QRTR bus
Ideally there would be a path in /dev or sysfs so we could add a
ConditionPathExists= in the unit, but I tried hard to find something and
was unable to. Making modem-gnss depend on ModemManager seems to work
around this issue, since qrtr seems to always (in my testing) be up by
then. IIUC in the future we may not have to run qmicli to enable GPS, so
this patch is a workaround to fix a workaround.
Signed-off-by: Clayton Craft <craftyguy@postmarketos.org>
Part-of: <https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/7636>
MM does other important things (like enable GPS) even if no SIM is
installed, but when this returns non-zero after timing out waiting for a
SIM then we lose the ability to have MM enable GPS (for example). Other
failures related to selecting SIMs should still trigger a non-zero exit
and block MM (I guess), but if we waited a while and no SIM shows up
then let MM start anyways.
Signed-off-by: Clayton Craft <craftyguy@postmarketos.org>
Part-of: <https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/7634>
Else systemd/meson may try to generate it at build time, which doesn't
work when the host kernel is a different arch than the target.
Signed-off-by: Clayton Craft <craftyguy@postmarketos.org>
This builds from upstream now.
- tests are re-enabled
- disable BTF support / drop vmlinux.h dependency, enabling bpf is
enough for mkosi/testing stuff, and getting a sane vmlinux.h that
systemd can compile with seems to be "complicated."
- armhf is re-enabled since we don't enable BTF anymore
- workaround stage0 linking failing on riscv64 by enabling tests
- increase test timeout for main pkg, because running in qemu is slow
- a lot more dependencies are explicitly listed now, because they are
dlopened and abuild doesn't know how to detect these
- meson build options re-arranged / cleaned up (some of these are
implicitly disabled by using -Dlibc=musl)
- tests are skipped for archs that we build in CI/bpo that don't have
native hw, since ~13 of them fail for unknown (or timeout) reasons. 2
of them time out after >1200 seconds and 11 fail for mysterious
reasons.
Signed-off-by: Clayton Craft <craftyguy@postmarketos.org>
Part-of: <https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/7584>
Apparently the user slice and root slice weren't being configured
correctly and oomd was not stepping in during high swap pressure events
before the kernel oom killer showed up to the party. This (hopefully)
properly configures systemd-oomd now... The configuration was inspired
by Fedora.
https://fedoraproject.org/wiki/Changes/EnableSystemdOomd
I used the test in that wiki page to confirm it's now properly configured:
$ systemd-run --user tail /dev/zero
$ journalctl -f
...
systemd[1081]: Started [systemd-run] /usr/bin/tail /dev/zero.
systemd-oomd[517]: Considered 79 cgroups for killing, top candidates were:
systemd-oomd[517]: Path: /user.slice/user-10000.slice/user@10000.service/app.slice/run-p5146-i5147.service
systemd-oomd[517]: Swap Usage: 4.6G
systemd-oomd[517]: Killed /user.slice/user-10000.slice/user@10000.service/app.slice/run-p5146-i5147.service due to memory used (2458>
systemd[1081]: run-p5146-i5147.service: systemd-oomd killed 1 process(es) in this unit.
systemd[1081]: run-p5146-i5147.service: Main process exited, code=killed, status=9/KILL
systemd[1081]: run-p5146-i5147.service: Failed with result 'oom-kill'.
Signed-off-by: Clayton Craft <craftyguy@postmarketos.org>
Part-of: <https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/7556>
Clayton Craft