With the default argument values removed, the step logic is more
centralized in the install method which makes the code a bit less
brittle and easier to follow.
This adds a new commandline flag -E / --extra-space for
specifying the amount of additional space to be added to
the image size to work around cases where the automatically
determined size turns out to not actually be enough.
The value is also asked for in the "Additional options"
section of the interactive mode.
Fixes: #1904
Put all install_packages related lines into one block and fix up the
comments:
* The list of packages to be installed is not listed at this point (and
it does not make sense there, if we would want to list it, it should
be done in the next block at 'if args.build_pkgs_on_install).
* Remove "including the ones specified by --add", as it doesn't add any
value.
Don't have the set_user() call weirdly between multiple commands
building the install_packages list. Move it up, together with the log
message announcing that the device rootfs is being built.
Update the comment above set_user(): there is no 'build' user anymore,
and at this point we only call it before actually installing the
packages for legacy reasons.
Do not attempt to upgrade packages in the rootfs chroot when running
"pmbootstrap install".
This was responsible for placing every single package in /etc/apk/world
(which should only hold the packages explicitly installed), because the
upgrade function was literally implemented as getting a list of
installed packages and explicitly running pmb.chroot.apk.install on each
of them. The intention was to rebuild these packages if they were outdated,
I guess I didn't realize that this makes /etc/apk/world unusable when I
introduced this three years ago in 51bdc243 ("Properly rebuild/install
packages when something changed").
Remove pmb.chroot.apk.upgrade altogether, because:
1) pmb.install.install builds and upgrades outdated pmaports
2) pmb.install.install is the only user of pmb.chroot.apk.upgrade
3) 'pmbootstrap init' is warning that the chroots do not get upgraded
automatically, so let's not go against that expectation. users who
want an updated rootfs chroot can simply run zap and install again.
Replace it with a call to pmb.helpers.repo.update, because we still need
to update the APKINDEX files before attempting to build/install the
generated list of packages.
The Nokia n900 XkbLayout is a bit peculiar and sometimes
join two keymaps into one, for example:
Option "XkbLayout" "fise"
For the combined finnish/swedish layout. Add the common
joined keymaps, even if not all of these countries are
yet supported.
For details see:
https://gitlab.freedesktop.org/xkeyboard-config/xkeyboard-config/-/blob/master/symbols/nokia_vndr/rx-51
I also include this link in the code so no-one gets confused.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Do not fail in "pmbootstrap setup" if a keymap was selected, but no
/etc/X11/xorg.conf.d path exists in the rootfs chroot. The grep output
is not empty in that case (it would be empty if the directory exists and
there are no matches), so we need to add this extra check:
(rootfs_nokia-n900) % grep -rl XkbLayout /etc/X11/xorg.conf.d/
grep: /etc/X11/xorg.conf.d/: No such file or directory
Let UI meta-packages specify apps in "pmb_recommends" to be explicitly
installed by default, and not implicitly as dependency of the UI
meta-package ("depends"). Therefore make these apps uninstallable,
without removing the meta-package.
Add pmbootstrap install --no-recommends to disable this feature.
Add a question at the end of "pmbootstrap init", to ask if the user
wants to build outdated packages during "pmbootstrap install". Store the
result in the new pmbootstrap.cfg key "build_pkgs_on_install". I've put it at
the end, because it is a rather complicated question compared to the rest.
This is useful to speed up the installation for casual users who can now
avoid compiling packages. But also for the official images where we only
want to ship the official binary packages and not build anything
on-the-fly.
Put a minimum version check for postmarketos-ondev in the pmbootstrap
install code and verify it before starting the installation. This avoids
using incompatible versions, similar to the pmaports.cfg version check
we already have. Set the minimum required version to 0.2.0.
Do not pass the arguments to ondev-prepare as command-line arguments in
a specific order, but instead as environment variables. New arguments
will be added in a follow-up patch.
Add initial support for the on-device installer in pmbootstrap. Let
pmbootstrap create a regular split image, then prepare a new installer
rootfs and copy the previously generated rootfs image into the installer
rootfs. Put the installer rootfs into a new image, with reserved space.
There is more to do from here, such as disabling the generation of the
user account when using --ondev. But this requires support in
postmarketos-ondev first, so let's build that iteratively.
Related: https://wiki.postmarketos.org/wiki/On-device_installer
Related: https://gitlab.com/postmarketOS/postmarketos-ondev/-/issues
Move code that prints flashing information from install_system_image()
to its own function. For the on-device installer, we'll need to call
install_system_image() twice, without printing the flashing information
each time. While at it, add "step" and "steps" parameters.
Prepare for a future patch, that adds reserved space in MiB, by changing
size_boot and size_root from bytes to MB everywhere. This is what we need
most of the time and allows to drop some /1024**2 statements.
Do not substract the estimated size of the home and boot directories
from the root directory size. While that would be the correct way if we
were able to get exact sizes, it isn't helpful with the very rough
estimates we are getting from pmb.helpers.other.folder_size. Replace
"calculate" wording with "estimate".
In the future, device ports will be located in a subdirectory
below device/... (e.g. device/testing/device-...).
Replace all occurrences of device/* with a glob that checks the
subdirectories instead.
Note: To ensure that this always works properly we should also add some
checks that all devices are indeed located under one of the supported
subdirectories (i.e. testing/community/main).
Change the glob for pmaports to <aports>/**/APKBUILD.
This allows using subdirectories for organization outside of device/
as well.
mesa-dri-swrast and mesa-dri-virtio are both provided by mesa-dri-gallium
now, so this option does not have much use anymore. With both selections,
exactly the same packages are installed.
While at it, also remove unnecessary "#!/usr/bin/env python3" in files
that only get imported, and adjust other empty/comment lines in the
beginnings of the files for consistency.
This makes files easier to read, and makes the pmbootstrap codebase more
consistent with the build.postmarketos.org codebase.
asus-me176c has a Fastboot interface that can be used for flashing,
but in postmarketOS we do not use Android boot images for it.
This is because is it not very practical - the boot partition is
quite small and there is a (custom) EFI bootloader that can boot
directly from any other FAT32 partition.
At the moment the installation process is manual:
1. pmbootstrap install --split to have separated boot (FAT32)
and rootfs images
2. pmbootstrap export
3. Flash boot and rootfs images manually using Fastboot
The "fastboot-bootpart" flasher implements that process in a more
convenient way. When a device uses the "fastboot-bootpart" flasher:
- We generate --split images on "pmbootstrap install" by default.
(This can be disabled using --no-split instead.)
- pmbootstrap flasher flash_kernel flashes the raw boot partition
(not an Android boot image) using Fastboot, just like the rootfs.
There are some limitations that could be improved in the future:
- "fastboot-bootpart" is not offered in the device wizard.
I think it is special enough that no-one will be starting with it,
and the difference to normal "fastboot" might be confusing.
- Support "pmbootstrap flasher boot". asus-me176c does not support
"fastboot boot" properly, but theoretically we could still generate
Android boot images to use when booting an image directly.
- At the moment the boot partition image is not regenerated when
using "pmbootstrap flasher flash_kernel" (unlike when using Android
boot images). "pmbootstrap install" needs to be run manually first.
At the moment, sparse images are generated if the device sets
deviceinfo_flash_sparse="true". But for testing purposes it can be
useful to specifically enable or disable the default behavior.
Add a --sparse and --no-sparse option that enables or disables
sparse image generation.
Now that the qemu-user binary is bind-mounted, we no longer copy
the binary to the device rootfs. However, there is still the empty
stub file that we used as a destination mount point.
Let's remove it before copying it to the device rootfs.
It is automatically re-created the next time the qemu-user binary
is needed.
This adds a new deviceinfo parameter, 'boot_part_start' which accepts an
int and indicates the number of sectors from the start of the drive to
place the boot partition.
The librem5 devkit (and actual phone) u-boot has grown beyond the 2048
sector space previously before the boot partition, so this is necessary in
order to boot pmos on this device.
With the nokia N900 the user can choose between different keyboard
layouts and during the install the setup-keymap installs the choosen
layout.
This only changes the keyboard layout of the console, while installing
a UI using xorg, the layout was hardcoded to "us".
With a simple check for the existence of an xorg config containing
XkbLayout, this will run sed to replace the default with the layout
chosen by the user.
Tested with a clean install of the nokia N900 with the xfce4 UI.
Johannes Marbach
Oliver Smith
Linus Walleij
Martijn Braam
HenriDellal
Anjandev Momi
Luca Weiss
Daniele Debernardi
Antoine Fontaine
Alexey Min
Minecrell
KuroLevin
Clayton Craft
Drew DeVault