boot-deploy uses 'local', which technically isn't POSIX-compliant
and if someone has 'sh' from something else that strictly adheres to
POSIX then boot-deploy will fail.
This is a workaround for https://gitlab.postmarketos.org/postmarketOS/boot-deploy/-/issues/38
[ci:skip-build]: already built successfully in CI
There is a special check in init_2nd.sh for older postmarketOS
installations that do not have a valid /etc/fstab file. When /boot does not
appear in fstab, it searches for the boot partition and mounts it manually.
However, /boot might be intentionally omitted in fstab, e.g. because we
just have a single rootfs partition that also contains /boot. In that case
it will wait forever, trying to find the missing boot partition.
The old installations do not have any entries in fstab, so fix this by
checking if the file is empty instead (with all comments and whitespace
removed).
[ci:skip-build]: already built successfully in CI
This reverts commit 1259d74b09.
The main reason why that change was necessary is because we skipped
mounting subpartitions entirely if we found a potential root partition
(which could be simply a crypto_LUKS partition from a different distro).
Now that we look only for the actual root partition (based on the UUID),
this should not happen anymore.
Checking both conditions causes delays if there is no boot partition,
e.g. if pmOS was installed with --single-partition. Usually we don't need
to mount the boot partition anymore, because all needed files are part of
the initramfs. So let's drop the check for the boot partition again and
rely on the UUIDs to ensure we set up the correct partitions.
When using an encrypted installation of postmarketOS, the pmos_root_uuid=
on the cmdline only tells us the UUID of the crypto_LUKS partition. Once
the partition is unlocked, we perform the the old unreliable auto detection
again. This might mount the wrong partition if multiple installations of
pmOS are attached to the system.
After we unlock the root partition, we know exactly where the root
partition is supposed to be (= at /dev/mapper/root). Let's use that
directly instead of going through the whole detection sequence again.
Right now we fallback to the old behavior of searching for the "pmOS_root"
label when the root partition specified by pmos_root_uuid= on the cmdline
is not found. This works fine most of the time, but there are edge cases in
which this does not behave correctly. Problems occur especially if there
are multiple installations of pmOS (e.g. one on internal storage, and one
on USB drive/SD card). Depending on timing or enumeration order, the system
might boot into the wrong rootfs if the intended root partition shows up
too late.
For the boot partition we already enforce the UUID provided on the cmdline.
Let's apply the same for the root partition to ensure we always boot into
the correct root partition.
To support the HTC One (M8), a new specific target is required
since it needs non-default values for mkbootimg.
Signed-off-by: Alexandre Messier <alex@me.ssier.org>
LXQt can control the display brightness. It doesn't save and restore it
over boots, however. In distributions with systemd this is handled by
"systemd-backlight@.service". For OpenRC the package brightnessctl offers
a service saving the state of the brightness at shutdown and reboot.
In addition to the pmos.debug-shell cmdline argument, add
pmos.usb-storage=<block-device> to set up the USB mass storage gadget by
default when going into debug shell. This allows building a special boot
image/option that directly exposes the storage for flashing, without having
to type in extra debug-shell commands.
Right now we have two similar implementations of setting up a USB mass
storage gadget, in init_functions.sh and as separate script for the
debug-shell. Given that init_functions.sh is available in debug-shell
anyway, unify both in a common setup_usb_storage_configfs() function.
Having this included in the initramfs debug-shell by default (without
installing postmarketos-mkinitfs-hook-debug-shell) also simplifies
recovery, since you can set up the USB storage for repairing the flashed
postmarketOS installation in case of boot failures. The size overhead is
minimal, since this has no extra dependencies.
BTRFS only supports online resizing. Right now we implement that by
temporarily mounting the file system, resizing it, and then unmounting it
again. But most of this is redundant since we mount the rootfs at /sysroot
immediately after.
Avoid this by splitting the file system resizing in offline resize (before
mount) and online resize (after mount) and resize BTRFS after mounting
/sysroot. For EXT4 we can either do offline resizing or online resizing.
Keep offline resizing for now for better compatibility with older kernels.
F2FS does not seem to support online resizing, so we need to keep the
functionality for offline resizing anyway.
Drop the splash for now, since it would introduce flickering on each boot.
We can restore it later if needed (ideally by adding a way to update the
splash message without restarting pbsplash).
Right now we use the resize2fs -f (force) option, which "Forces resize2fs
to proceed with the filesystem resize operation, overriding some safety
checks which resize2fs normally enforces." For example, this flag instructs
resize2fs to attempt resizing file systems with errors in some situations.
We primarily care about resizing the file system on initial boot, where we
shouldn't have any errors in the file system. For all other subsequent
boots, we shouldn't risk the filesystem data just to resize it again.
So let's drop the -f flag and only resize clean file systems.
At the moment, the root file system is only resized to span the entire
partition if we previously also resized the partition itself. However, if
a rootfs image without subpartitions is flashed to a pre-existing partition
this means that the installation only has very limited space available
without manual resizing.
Such a setup is used for devices using the "fastboot-bootpart" flasher
(e.g. asus-me176c), where boot and root images are flashed to two separate
partitions and the device boots directly from the boot partition.
Avoid this problem on these devices by always resizing the root file system
on each boot. All the resize tools exit early if the file system is already
expanded to the maximum size. It's faster to call resize2fs unconditionally
instead of manually checking if the file system needs resizing before.
Similar tooling like systemd-growfs also resizes unconditionally.
Fix the bug that prevented "pmbootstrap install" from working with
postmarketos-ui-gnome (not -mobile).
This bug has been here in pmaports for a long time, but until recent
changes in apk's resolver code, this did not fail (apk installed
gnome-extensions-app instead of gnome-mobile-extensions-app in that
scenario).
How it happened:
* postmarketos-ui-gnome has _pmb_recommends="gnome-extensions-app".
* pmbootstrap: pmb.install._install.get_recommends() works like this:
1. Look at the packages i in _pmb_recommends of the packages that
will be installed in "pmbootstrap install".
2. For each package j in _pmb_recommends of i:
2.1 Add all packages in j's _pmb_recommends to the list of
packages to be installed.
(2.2 Recurse by doing 1. with each package in j's _pmb_recommends.)
* In step 2:
* pmaports doesn't have a gnome-extensions-app (it's in Alpine, a
subpackage of gnome-shell).
* Therefore our gnome-shell-mobile fork gets looked at, which has a
gnome-mobile-extensions-app subpackage that provides
gnome-extensions-app.
* pmbootstrap looks at the _pmb_recommends of the gnome-shell-mobile
package, which has "gnome-mobile-extensions-app" (this is wrong,
it should be in postmarektos-ui-gnome-mobile instead and this patch
fixes this!).
* pmbootstrap adds the "gnome-mobile-extensions-app" to the list of
packages to be installed.
* The result is an "apk add" line that has "postmarketos-ui-gnome" and
"gnome-mobile-extensions-app" (and more packages), which results in a
conflict betwen gnome and gnome-mobile packages.
Fixes: issue 3360
[ci:skip-vercheck]: _pmb_recommends changes don't need package rebuilds
[ci:skip-build]: already built successfully in CI
Ensure postmarketos-base-nofde is built before this package, otherwise
bootstrapping this on a new stable branch fails. This does not need to
be backported, as postmarketos-base-nofde has already been built for
v24.12.
Related: https://builds.sr.ht/~postmarketos/job/1384748
Actually Xfce4 is capable to use the "draw-user-backgrounds" option of
"slick-greeter", applying the users wallpaper on the greeter.
However, as it turns out, the users background in pmOS Xfce4 is set at first
login of the user. Therefore, the greeters background is black at the first
boot.
Therefore set the greeters background to the default postmarketOS wallpaper.
Move the polkit-elogind into depends= instead of pmb_recommends=, so
packages depending on postmarketos-base-ui-gnome can build successfully
again. The previous fix only helped for "pmbootstrap install", this fix
will help for both cases.
Without this, e.g. postmarketos-base-ui-gnome-mobile fails to build:
https://builds.sr.ht/~postmarketos/job/1384469
[ci:skip-build]: already built successfully in CI
Add polkit-elogind to _pmb_recommends, to help apk resolve the polkit
depends again. Otherwise it fails with a conflict since recent changes
in apk's dependency resolving code.
Fixes: issue 3349
[ci:skip-vercheck]: pmb_recommends change doesn't need rebuild
[ci:skip-build]: already built successfully in CI
Change <=…-r0 to <=…-r999 as it was just bumped to fix a build error and
might be bumped again in the future. I've also tried just removing -r0,
but that results in a conflict.
There might be additional kernel modules needed for the USB UDC to show up.
This used to work fine, but broke when the initramfs was unified with the
minimal one. We need to load modules/start udev before setting up USB.
Fix this by duplicating the setup calls in both init.sh and init_2nd.sh.
Both calls already have checks to allow calling them multiple times,
so we don't need to handle the initramfs-extra case in a special way.
[ci:skip-build]: already built successfully in CI
Split -nofde into a separate package to resolve the cyclic depenency:
postmarketos-base -> postmarketos-initramfs -> postmarketos-base-nofde
Fixes: issue 3236
[ci:skip-build]: already built successfully in CI
Fill out makedepends, so pmbootstrap and bpo know that these packages
need to be built before building postmarketos-cros-common, because it
has subpackages depending on these packages. Without this,
bootstrapping v24.12 currently fails:
https://builds.sr.ht/~postmarketos/job/1381582
This is intended behavior, abuild works the same way:
https://gitlab.alpinelinux.org/alpine/abuild/-/issues/10138
[ci:skip-build]: already built successfully in CI
Fix the following error during "pmbootstrap install":
ERROR: unable to select packages:
sudo-1.9.16_p1-r1:
conflicts: doas-sudo-shim-0.1.1-r1[cmd:sudo=1.9.16_p1-r1]
breaks: doas-sudo-shim-0.1.1-r1[!sudo]
satisfies: postmarketos-base-38-r0[sudo-virt]
postmarketos-base-nofde-38-r0[sudo-virt]
doas-sudo-shim-0.1.1-r1:
conflicts: sudo-1.9.16_p1-r1[cmd:sudo=0.1.1-r1]
satisfies: postmarketos-base-doas-38-r0[doas-sudo-shim]
postmarketos-base-38-r0[sudo-virt]
postmarketos-base-nofde-38-r0[sudo-virt]
How the error gets triggered:
* postmarketos-base depends on sudo-virt. During "pmbootstrap install",
pmbootstrap has to resolve this to a sudo implementation (sudo, doas,
...).
* pmbootstrap does this by looking at the packages that get installed
at the same time. Before this patch we did not install doas-sudo-shim
directly through _pmb_recommends, only indirectly through a
postmarketos-base-doas subpackage that pulls doas-sudo-shim in via
install_if.
* pmbootstrap cannot look at install_if as it resolves dependencies,
so it has to pick one and goes for "sudo".
* pmbootstrap tells apk to install a list of packages including "sudo",
and because apk also resolves install_if correctly, the solver fails
at the conflict between "doas-sudo-shim" and "sudo". (This only fails
since apk-tools-static 2.14.6-r0, apparently beforehand apk just
installed "doas-sudo-shim" in this scenario.)
Teaching pmbootstrap to look at install_if while resolving packages
would be one way to fix this. But it would be a lot of effort, not
feasible to quickly stop the problem at hand that breaks "pmbootstrap
install" for all edge installs. IMHO it is not worth implementing this
at all in pmbootstrap, as it is just supposed to do some more or less
basic package resolving until apk takes over and does it properly.
Put doas-sudo-shim in _pmb_recommends so pmbootstrap knows that this is
the sudo implementation we want without looking at install_if.
Remove the now obsolete postmarketos-base-doas subpackage. This will
lead to doas-sudo-shim getting removed for old installations on upgrade,
but it can easily be installed back (doas add doas-sudo-shim). I'll make
an edge post about it and put it in the v24.12 release notes. If we
don't remove it here, we would need to keep this legacy subpackage
around forever and I'd rather avoid that to reduce maintenance effort.
Another alternative to this was removing sudo-virt from depends="". But
that would lead to sudo getting uninstalled for users upgrading from
old releases from before we had doas in pmb_recommends, so I've decided
against it.
Fixes: pmaports issue 3340
The main goal of switching LightDM to slick-greeter is to ease
enabling/disabling autologin. With "lightdm-settings" installed, there
is an administration/settings GUI "Login Window" available that allows
among others to configure autologin. Contrary to its general purpose
name, it works on LightDM greeter "slick-greeter" only.
[ci:skip-build]: already built successfully in CI
Use install "-t" option, avoiding to repeat the file name and allowing to add
more than one file per command. Additionally sort the commands alphabetically
per path.
Exception is the lightdm autologin config file because it does a file renaming.
Put this command to the end.
Many parts of the Linux desktop (apps, tools, scripts, etc) all expect
xdg-open and friends to be installed.
Since these utilities are tiny and (usually) ubiquitous, let's make sure
our UIs all depend on them.
Signed-off-by: Caleb Connolly <caleb@postmarketos.org>
init_functions.sh makes use of the mass_storage and acm USB gadget
functions for error reporting, but the necessary kernel modules are not
included in the initramfs at the moment. Because of this, the functionality
works only on kernels where all these USB gadget functions are built-in and
not built as modules.
Add the missing modules and fix the sort order while at it.
[ci:skip-build]: bug in CI prevents build testing armv7, succeeded locally
Clayton Craft