Reimplement "pmbootstrap status" to be just a simple and useful status
overview. The previous version ran a bunch of checks every time, and
would fail on these even if pmaports was used for normal development:
* "non-official" branch checked out in pmaports
* pmaports.git is not clean
The information about aports.git was also considered not so useful upon
revisiting this command, since it is only used for "pmbootstrap
aportgen". Most users don't need this, and if the user runs this
command, it will tell if aports.git is outdated.
All of the above made the previous version unpleasant to use and I
suspect most people stopped using the command after trying it out a few
times and seeing the irrelevant but loud NOK complaints.
New version:
$ pmbootstrap status
Channel: edge (pmaports: master_staging_systemd)
Device: qemu-amd64 (x86_64, kernel: virt)
UI: console
systemd: no (default for selected UI)
Old version (without --details it only shows NOK checks):
$ pmbootstrap status --details
[00:55:20] *** CONFIG ***
[00:55:20] Device: qemu-amd64 (x86_64, "QEMU amd64")
[00:55:20] Kernel: virt
[00:55:20] User Interface: console
[00:55:20]
[00:55:20] *** GIT REPOS ***
[00:55:20] Path: /home/user/.local/var/pmbootstrap/cache_git
[00:55:20] - aports_upstream (master)
[00:55:20] - pmaports (master)
[00:55:20]
[00:55:20] *** CHECKS ***
[00:55:20] [OK ] Chroots zapped recently (or non-existing)
[00:55:20] [OK ] aports_upstream: on official channel branch
[00:55:20] [OK ] aports_upstream: workdir is clean
[00:55:20] [OK ] aports_upstream: tracking proper remote branch 'origin/master'
[00:55:20] [OK ] aports_upstream: up to date with remote branch
[00:55:20] [OK ] aports_upstream: remote information updated recently (via git fetch/pull)
[00:55:20] [OK ] pmaports: on official channel branch
[00:55:20] [OK ] pmaports: workdir is clean
[00:55:20] [OK ] pmaports: tracking proper remote branch 'origin/master'
[00:55:20] [OK ] pmaports: up to date with remote branch
[00:55:20] [OK ] pmaports: remote information updated recently (via git fetch/pull)
[00:55:20]
[00:55:20] NOTE: chroot is still active (use 'pmbootstrap shutdown' as necessary)
[00:55:20] DONE!
Make sure users don't set systemd to "true" or other not allowed values
(allowed are "always", "default", "never").
Check for it:
* after loading the config
* when using 'pmbootstrap config systemd <newvalue>'
For UI packages that have pmb:systemd-never set:
* do not ask in "pmbootstrap init" whether to use systemd or not
* do not install systemd, even if the systemd option is set to "always"
The point of this is to not add maintenance burden to Sxmo (and possibly
other UIs who not wish to support systemd with postmarketOS), so users
don't install with this unsupported use case and report issues with it.
Add the following question to "pmbootstrap init":
[22:12:57] Based on your UI selection, 'default' will result in installing systemd.
[22:12:57] Install systemd? (default/always/never) [default]:
Determine whether the UI prefers to have systemd or not, based on
"pmb:systemd" in the UI package's APKBUILD.
Determine whether the currently selected branch supports systemd, by
checking for a "[repo:systemd]" section in pmaports.cfg. This section
will also contain bootstrap information, to be used in future patches.
This drops the prompt for using non-free firmware in images. The logic
for searching/installing non-free fw subpackages for devices is kept,
and will always be installed. This is to support the many device
packages in pmaports that still have nonfree-firmware subpackages. Going
forward, device packages can list firmware in `depends=` (for required
fw) or `pmb_recommends` (for optional fw).
nonfree-userland wasn't used in pmaports as far as I could find.
we're not in the nftables only world yet, things like docker and
tailscale only work with the `iptables` command. those programs
expect iptable-modules, which we make available to nftables over
the nftables/iptables compat layer.
Currently, pmbootstrap checks if either the kernel or the ramdisk in a boot.img
contains the MediaTek header, and if one does, it assumes both do. It hardcodes
the label KERNEL for the kernel and ROOTFS for the ramdisk.
My Amazon Echo Dot (gen 2) has a boot.img where only the kernel has the header,
but not the ramdisk. These changes (as well as those in my new boot-deploy MR)
account for that situation (and any possible label an image has) by splitting
bootimg_mtk_mkimage into two variables for the kernel and the ramdisk labels.
Reviewed-by: Oliver Smith <ollieparanoid@postmarketos.org>
Link: https://lists.sr.ht/~postmarketos/pmbootstrap-devel/patches/46351
This is required for being able to boot compressed kernels via EFI stub
on aarch64.
As far as I can tell, EFI_ZBOOT was added in a050910972bb2, and
available in 6.1.0 or later. I'm not sure if it was backported to other
older LTS versions or not...
Reviewed-by: Anton Bambura <jenneron@postmarketos.org>
Reviewed-by: Oliver Smith <ollieparanoid@postmarketos.org>
Tested-by: Oliver Smith <ollieparanoid@postmarketos.org>
Link: https://lists.sr.ht/~postmarketos/pmbootstrap-devel/%3C20231011212433.17131-1-clayton@craftyguy.net%3E
Cache the compiler output of rust code with sccache, like we use ccache
for c code.
I've considered using sccache to completely replace ccache since it can
cache output of C/C++ code too. But let's not do it for now since ccache
doesn't need to run a daemon in the background that needs to be stopped
when shutting down / zapping. Also it would need more refactoring.
Reviewed-by: Luca Weiss <luca@z3ntu.xyz>
Link: https://lists.sr.ht/~postmarketos/pmbootstrap-devel/%3C20230806184729.4891-5-ollieparanoid@postmarketos.org%3E
Since we're using mtkclient a lot anyways, it makes sense to add
support for it to pmbootstrap.
This was originally implemented by JustSoup321, but they had issues
submitting the patch, so I've cleaned it up for upstream submission.
Co-Authored-By: JustSoup321 <brandonboese@protonmail.com>
Co-Authored-By: Oliver Smith <ollieparanoid@postmarketos.org>
Signed-off-by: hexaheximal <hexaheximal@proton.me>
Reviewed-by: Oliver Smith <ollieparanoid@postmarketos.org>
Link: https://lists.sr.ht/~postmarketos/pmbootstrap-devel/%3C20230712231807.22590-1-hexaheximal@proton.me%3E
With this code path, pmbootstrap would start a distccd + sshd in the
native chroot, and configure it so it runs the cross compiler. The
foreign arch chroots would then call this cross compiler from localhost
by calling the distcc client instead of gcc.
This code has been obsoleted by the much simpler crossdirect in 2019.
Let's finally remove it.
Fixes: issue 2179
Reviewed-by: Luca Weiss <luca@z3ntu.xyz>
Reviewed-by: Clayton Craft <clayton@craftyguy.net>
Link: https://lists.sr.ht/~postmarketos/pmbootstrap-devel/%3C20230613161437.570196-4-ollieparanoid@postmarketos.org%3E
A long time ago we renamed the flash_system action into flash_rootfs.
Since we still kept some variables around, it's finally time to clean
that up.
Keep backwards compatibility for now since we cannot update pmaports at
the same time since the new deviceinfo names won't be supported in older
pmbootstrap versions.
Reviewed-by: Oliver Smith <ollieparanoid@postmarketos.org>
Link: https://lists.sr.ht/~postmarketos/pmbootstrap-devel/%3C20230605220329.14328-3-luca@z3ntu.xyz%3E
In theory, the en_US locale is supposed to be aimed at people, while the
C locale is aimed as computers. In theory, one of the remarkable
differences is in sorting:
$ printf '%s\n' \| a \0 \^ \& B c C | LC_COLLATE=C.UTF-8 sort
&
0
B
C
^
a
c
|
The non-sense there is obvious, with "^" sorting in between the letters,
"|" afterwards and sorting of capitals and non-capitals split. The reason
is the ordering is based on the ascii table. In theory, an en_US locale
should be able to provide a sensitive ordering, but what takes care of it
is the libc, and musl does not have it properly implemented. So LC_COLLATE=en_US
will still give the same results. However, that's hopefully going to change
at some point, and there's no harm in setting a sensible locale by default.
Signed-off-by: Pablo Correa Gómez <ablocorrea@hotmail.com>
Reviewed-by: Oliver Smith <ollieparanoid@postmarketos.org>
Make sure that we disable legacy gadgets like USB_ETH. Our initramfs
uses configfs gadgets instead, currently RNDIS for USB networking.
In the future this can be expanded to more options like mass storage,
MIDI or whatever we're going to integrate into the OS that can be
configured by the user.
Reviewed-by: Oliver Smith <ollieparanoid@postmarketos.org>
Link: https://lists.sr.ht/~postmarketos/pmbootstrap-devel/%3C20230423163438.746054-1-luca@z3ntu.xyz%3E
When invoking pmbootstrap build most packages default to the host arch,
however depending on your workflow it might be preferrable to default to
the device arch.
Add a new config option "build_default_device_arch" which when set will
make "pmbootstrap build" prioritise the device arch over the native
arch.
Default to False to preserve the old behaviour and don't ask during
pmbootstrap init as this may not be relevant for most folks.
Reviewed-by: Oliver Smith <ollieparanoid@postmarketos.org>
Co-developed-by: Oliver Smith <ollieparanoid@postmarketos.org>
Link: https://lists.sr.ht/~postmarketos/pmbootstrap-devel/%3C20230418-build-default-arch-v5-2-5223fab65867@postmarketos.org%3E