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.
The sparse image tools (simg2img, img2simg, append2simg) are now
part of Alpine's android-tools where they are continously updated.
(See https://github.com/nmeum/android-tools/pull/8)
Therefore, "libsparse" now conflicts with "android-tools", which
causes the fastboot flasher to fail if "libsparse" is already
installed.
Install "android-tools" instead of "libsparse" before generating
a sparse image to avoid this problem.
At the moment, attempting to install to SD card when
flash_sparse is set to "true" will always fail because
/home/pmos/rootfs does not exist in that case.
Sparse images are only useful to speed up Fastboot flashing.
Nothing will be able to read it from the SD card.
The problem can therefore be avoided by simply skipping the
generation of the sparse image when SD card installation is used.
From https://docs.python.org/3/library/re.html
"Backslashes are not handled in any special way
in a string literal prefixed with 'r'."
Signed-off-by: Steffen Pankratz <kratz00@gmx.de>
This allows embedding multiple firmware binaries into SD images.
Firmware images for most devices that require this functionality consist
mainly of u-boot, but some devices (e.g. librem5) have multiple firmware
images that need to be embedded in the SD image created by pmbootstrap.
This functionality uses two new deviceinfo parameters:
- deviceinfo_sd_embed_firmware: a comma-separated list of
binary:offset (where binary is under /usr/share/firmware)
- deviceinfo_sd_embed_firmware_step_size: The number of bytes for
each increment of the offset specified in the
deviceinfo_sd_embed_firmware (typically 1024 or 2048)
deviceinfo_write_uboot_spl has been obsoleted by these new parameters.
Follow-up to !1373, where `pmbootstrap flasher flash_system` was
replaced with `pmbootstrap flasher flash_rootfs`. We still had used
terms like "system partition" in a lot of places.
This commit replaces it everywhere, so it's clear that we're talking
about the pmOS rootfs (which may or may not be installed to Android's
system partition).
* Travis and Coveralls badges
* aports: instead of <https://github.com/postmarketOS>, use
<https://postmarketos.org>
* References to full URLs to issues and pull requests replaced with
a hash and the number
* grsec check: simplify error message, remove link to github issue
(nobody is using that anymore anyway)
This allows the user to talk to networkmanager to manage the system
connections. As it is mentioned in networkmanager pre-install.
```
Executing networkmanager-1.10.6-r0.pre-install
*
* To setup system connections, regular users must be member of 'plugdev' group.
```
The plugdev group gets created in the post-install hook of
networkmanager. Not all UIs depend on networkmanager, which means that
the group may not exist at installation time when we try to add the
user to the group in the python code. Therefore we create the group
first.