We plan to make a lot of changes to the initramfs which will require
incresaing the size. There are some devices that have literally no free
space for this, so make a -minimal initramfs fork that can continue to
support those while we update the regular initramfs.
Signed-off-by: Caleb Connolly <caleb@postmarketos.org>
All these config update are there since 2020. Having them there
serves no purpose, apart from increasing packaging complexity and
have some unnecessary files under /etc
This was enabled in the "default" runlevel during upgrades, which is an
error, since it depends on bootmisc, which is in "boot" runlevel
Fixes#2473
[ci:skip-build]: Already built successfully in CI.
And enable it by default, since it's a sensible thing to do.
This makes the bootmisc config file unnecessary, since it was only
used before to make sure that /tmp was wiped on every boot.
Mounting /tmp as a tmpfs will be skipped if:
* The user or maintainer configured deviceinfo_tmp_as_tmpfs_size=0
* If they didn't but the device has less than 2GB of RAM
* And in any case, if it is already mounted, to respect users that
might have it in /etc/fstab
The options for mounting /tmp has been copied from my local debian
tmp.mount service. The only real difference is that we are mounting it
after /etc/fstab, and they do so before.
Fixes#2233
Logging is important, we want our users to have logging, so make sure we
enable the new logbookd service on existing installation.
We check that we're upgrading from a postmarketos-base version that
predates logbookd and only enable the service in this case. This way we
won't enable it again for folks who disabled it manually.
Signed-off-by: Caleb Connolly <caleb@connolly.tech>
[ci:skip-vercheck]
Use logbookd to replace the busybox in-memory logger. The default
configuration of logbookd still logs in-memory but writes out the log on
shutdown or manual trigger.
The logread command is also replaced by a drop-in replacement for the
busybox tool.
The post-upgrade script in pmos-base isn't symlinked to the post-install
script, so zram-init wasn't being enabled on systems that upgraded to
the pmos-base version that intro'd this feature. I think this should
have been enabled by default on upgraded systems. There's a deviceinfo
toggle for it, so users who won't want to use this can set that var to
disable it, in that case having the service enabled is basically a
no-op.
Update by Oliver: add a comment to mention the deviceinfo variable
[ci:skip-build]: already built successfully in CI
So that old installations that run setup-timezone without "-i" do not
need to execute manual steps to get sensible timezone configurations.
See https://gitlab.com/postmarketOS/pmaports/-/issues/2168 for more context
Fixes#2168
[ci:skip-build]: already built successfully in CI
sudo-ldap is providing cmd:sudo/sudo-virt.
Replace files from sudo-ldap to solve conflict about /etc/sudoers
Fixes#2032
[ci:skip-build]: already built successfully in CI
Changes the dependency from pmos-mkinitfs to pmos-initramfs, so now the
dependency chain for boot config packages is:
base -> postmarketos-initramfs -> postmarketos-mkinitfs -> boot-deploy
Sorting dependencies this way makes sense because "base" just needs an
initramfs, it doesn't care about the implementation (that currently uses
"postmarketos-mkinitfs.")
[ci:ignore-count]
[ci:skip-build] already successfully built in CI
This installs zram-init and sets it to start on boot for all
devices/UIs. The included conf.d/zram-init also allows diabling using
zram swap or overriding the size by using a deviceinfo var.
I did an analysis of the pmos base install size with the 'none' UI
selected, after depending on zram-init, and the following new package is
installed:
zram-init-11.1-r1 installed size: 40 KiB
These packages are dependencies of zram-init, however they are already
installed in the base image (with 'none' UI) so they are not counted
above:
util-linux-misc-2.38.1-r0 installed size: 6816 KiB
e2fsprogs-extra-1.46.5-r4 installed size: 1324 KiB
So this seems like a very small price to pay for the benefit of not
making the logic/implementation more complicated than this.
* Starting busybox syslog ... [ ok ]
ssh-keygen: generating new host keys: RSA ECDSA ED25519
* Starting sshd ... [ ok ]
zram swap: activating with size: 243 MB
* Loading zram module...
[ ok ]
* Swap->zram0
[ ok ]
* Starting local ... [ ok ]
This change introduces one new deviceinfo variable:
deviceinfo_zram_swap_pct: percentage of RAM to use for zram swap
Default percentages if the second var is unset are explained in the
zram-init file this commit adds. A value of 0 disables zram swap.
fixes#1133
Add rules for regulator-haptic, which is used on:
- samsung-e5/e7
- samsung-cprime/gprime
- samsung-j3/j5(x)
Note that regulator-haptic is not supported on some devices yet,
and samsung-e5 is not ported at the moment.
[ci:skip-build]: already built successfully in CI
At the moment almost all device packages force installation of the Mesa
drivers, even when they are not used by any application (for example on
a minimal headless installation with "none" or "console" UI).
Omitting mesa-dri-gallium from such installations saves about ~150 MiB
of disk space (469 MiB -> 317 MiB rootfs for minimal installation on
arrow-db410c).
The "classic" drivers have been removed from Mesa so only one mesa-dri-
package exists now: mesa-dri-gallium contains all Mesa drivers,
llvmpipe, freedreno, lima, panfrost, Intel (iris/crocus), ...
This means we can easily create an install_if package in
postmarketos-base that installs that driver package only if needed
(= only if another package requires the "mesa" package).
Strictly speaking the install_if could be restricted further since
mesa-dri-gallium is only needed by "mesa-egl", "mesa-gbm" and "mesa-gl"
but not e.g. the Vulkan drivers. Having three postmarketos-base
subpackages (one install_if for each of them) seems a bit
overengineered, though. "mesa" is a common dependency of all three
of them, so using install_if="... mesa" should be good enough.
This would mitigate issues where apk unexpectedly replaces packages
somewhat as this way the user will be able to see precisely what changes
will happen to their system before they are committed. Furthermore, most
users are likely accustomed to package managers like apt, dnf, pacman,
among others that all are interactive by default and as such this would
provide a more familiar experience for them.
This will not affected pre-existing installs, and advanced users who
do not like this behaviour can restore the old one by deleting
/etc/apk/interactive.
[ci:skip-build]: already built successfully in CI
Alpine does not use setup-udev anymore and provides the same
functionality through setup-devd. The setup-udev script was deleted [1]
but postmarketos-base still used it and caused pmbootstrap to fail when
building a device image. Use the rc-service setup directly from
setup-devd.
[1] b56c4c2b9d
Fixes error: postmarketos-base-18-r0: trying to overwrite etc/fstab owned by alpine-baselayout-data-3.2.0-r20.
caused by 9ecba8a514
[ci:skip-build] already built successfully in CI
MMS support (via mmsd-tng) involves sending/receiving network
requests/responses over the wwan interface. If it's ipv4-only and the
device is connected to some other ipv4 network on another iface (like
wifi), this can cause the rp_filter to reject responses on wwan iface
because it incorrectly thinks they are martian packets.
This does theoretically disable some "security" feature in the kernel,
but it's worth noting that:
1) rp_filter isn't implemented at all in the kernel for ipv6
2) other distros (mobian, pureos at least) are also disabling rp_filter
3) this seems to be a relatively common problem with folks using mms on
pmOS, since many carriers' data networks are ipv4-only
also see:
https://gitlab.com/kop316/mmsd/-/merge_requests/55/diffs?commit_id=b22c253fb939ff1eb949ea4e628706e6a28c851a
[ci:skip-build] already built successfully in CI
This configures bootmisc to clear /tmp on bootup. I think most folks
expect distros to do this, many even mount /tmp as tmpfs. I don't think
that's a great idea in pmOS since RAM is usually limited on many
devices. So this, clearing it on boot, seems like a reasonable compromise.
Fixes#1342
Installing postmarketos-base currently changes the file permissions
of /etc/sudoers:
# apk add sudo
# stat /etc/sudoers
Access: (0440/-r--r-----) Uid: ( 0/ root) Gid: ( 0/ root)
# apk add postmarketos-base
# stat /etc/sudoers
Access: (0044/----r--r--) Uid: ( 0/ root) Gid: ( 0/ root)
The file mode 0044 decodes to:
- User *cannot* read
- Group can read
- Other can read
which does not make any sense. The "sudoers" man page makes it very
clear that this file should have a file mode of 0440 [1]
("readable by owner and group, writable by none").
This looks like a bad typo. However, given that only read permissions
were given out this shouldn't have major security implications
(except allowing all users to see who can use sudo).
Install the file with 0440 instead of 0044 to fix this:
# apk add postmarketos-base
# stat /etc/sudoers
Access: (0440/-r--r-----) Uid: ( 0/ root) Gid: ( 0/ root)
[1]: https://www.sudo.ws/man/1.9.8/sudoers.man.html#Error_log_entries
Allow users in group "input" to control the tm2-touchkey leds.
Additionally correcting the udev rule for disabling the tm2-touchkey leds by default.
[ci:skip-build] already built successfully in CI
The udev file "20-tm2-touchkey-leds.rules" disables the leds of
tm2-touchkey by default because they are in an unconfigured state.
The udev file "95-rt5033-battery-refresh.rules" triggers a refresh
of the rt5033-battery information within UPower 5 secs after
initialization. This avoids a wrong battery icon after boot.
The udev file "50-firmware.rules" was moved from /etc/udev/rules.d
to /lib/udev/rules.d.
Related: https://wiki.postmarketos.org/wiki/Packaging#Device_specific_quirks
This enables the firewall by default, and could be split off into a
future ui-base package so that the firewall (among other things) are
enabled only when UIs are installed.
Don't suspend the device while alsa is playing. I ran this for two days
in combination with suspend time set to 1 min on the pinephone and it
works great. Finally no suspend while VLC is playing podcasts.
CRDA in the kernel requires a regulatory database to be available
to configure the WiFi card correctly following the regulations in
each possible environment.
