~/.local/var/pmbootstrap/log.txt
logread
tool in BusyBox. The syslog is currently not preserved across reboots.musl-*
/busybox-static-*
fails to build with a 404 errorRun pmbootstrap aportgen musl-armhf musl-aarch64
. The reason why this fails from time to time is, that we use Alpine's binary musl
lib c package for armhf
/aarch64
in the native chroot, to get the cross-compiler working. So the download URL inside the aports/cross/musl-*/APKBUILD
file must be in sync with the upstream version. This pmbootstrap command safely gets the new version, uses apk
to verify the signature of the package, generates the hash, and updates the APKBUILD
file. To make sure, that pmbootstrap aportgen
receives the latest musl
version, delete your HTTP cache right before executing this command: pmbootstrap zap -hc
. Don't bother making a pull-request for this, as the fix is really trivial (see this commit). Just report it as issue, if it happens.
Sorry! Revert to the last commit, that was known to work (git checkout $commit) and report an issue, if there is not already one. Consult with others in the IRC/matrix channel to find out, which commit was the last one that worked.
Add rc_logging=YES
to /etc/rc.conf
to have openrc log all its steps to /var/log/rc.log
. If you managed to get the system to boot far enough to have telnet access, add [[the port 24 telnet listener|Inspecting-the-initramfs]] and you can mount the root device to view said log.
DEVTMPFS
is enabled in your kernel config. Do not enable DEVTMPFS_MOUNT
.cat /dev/random > /dev/fb0
returns: cat: write error: No such device
Example: unzip in BusyBox doesn't extract symlinks like the normal unzip implementation (#82).
Solution: Simply add unzip
to the makedepends in the APKBUILD, and the "real" unzip will be used (or in that case, try to get the sources in another archive format, such as .tar.bz2
, .tar.xz
, .tar.gz
).
When your "work" folder is inside an ecryptfs mounted folder, /dev/random
may not work inside the chroot and you may have other issues. Try to move your work folder to another location, you can use /tmp
to test if this resolves the issue. You can change the location in pmbootstrap init
. See also: #61. (This doesn't seem to be an issue with newer versions of ecryptfs anymore.)
postmarketOS is based on Alpine Linux testing. Maybe they have triggered a rebuild and it failed, so now the package is not available. You could try to install the latest stable package, as a workaround (although that may introduce other bugs!). Here's an example.
For some devices it's possible to get early boot output using a debug cable that provides access to the UART. Unfortunately manufacturers don't use to publish the details and it is endusers who in some cases have figured it out:
On fastboot devices, you may have to enable UART debugging with fastboot oem uart-on
.
By default, all output from the initramfs get redirected to /pmOS_init.log
. If you want the output through the debug cable you need to add PMOS_NO_OUTPUT_REDIRECT
to your kernel command line.
See Serial debugging.
Many devices require proprietary blobs for enabling certain peripherals (wifi/bluetooth/cellular/GPS). These repositories appear to contain blobs for a large percentage of devices out there.
On some phones, you can hold down the power button for ten seconds to force a reboot. If that does not work: On other phones, you have to hold the power button down for a full minute (or hold it together with volume down). On some phones, it might take even longer (3 minutes or so).
dhcpcd
on the usb network device (check with ip a
)telnet 172.16.42.1
(yes, the IP has changed!)pmbootstrap build mkbootimg
pmbootstrap build unpackbootimg
pmbootstrap chroot
apk add mkbootimg unpackbootimg
# 1. download a full LineageOS image
# 2. extract it
# 3. extract the kernel with unpackbootimg
# 4. there's the kernel image!
# 5. either try to overwrite the image generated by postmarketOS in /boot and use 'pmbootstrap flasher....'
# Or: create a bootimg with "mkbootimg" inside "pmbootstrap chroot" and try to flash the image on your host GNU/Linux system with fastboot/heimdall
There is a known bug where if you execute cat /sys/class/graphics/fb0/modes > /sys/class/graphics/fb0/mode
exactly one frame is drawn, and the screen isn't updated otherwise.
Specify a tty in weston's commandline. The correct syntax is: weston --tty=1
.
If Weston returns an error because it could not access /dev/tty1
, even when you specify it on the command line as above, you may need to enable Virtual Terminals in the kernel config.
You can enable CONFIG_VT
using pmbootstrap menuconfig
and checking under Device Drivers -> Character devices -> Virtual terminal
There are some buggy framebuffer drivers (e.g. in LG Nexus 5) that report incorrect data. You can override it with:
weston --pixman-type=2
More information on issue #54
See: [[Troubleshooting:grsec]]
Normal behavior. it means, that your "user" repository (the repository with all custom compiled packaged from pmOS, such as your device package and kernel) does not have the dependencies from the official Alpine Linux repositories (such as cryptsetup
, iw
, htop
, ...) when indexing it. But these dependencies are in the official repositories, so they will be found when you try to install something. Usually the package indexing is done on all repositories at once in Alpine (then you wouldn't get the error), but pmOS does it only on the "user" repository.
Normal behavior. We use a x86_64 version of apk
to set up the chroots. When setting up the armhf chroot, the armhf post-installation code can't be executed, and that's where the errors come from. But we run "apk fix" right afterwards - with the armhf architecture, because we have an armhf version of apk installed inside the chroot now - and this runs the installation scripts again.
This issue is known to happen in Alpine Virthardened. These commands should fix it:
sudo modprobe binfmt_misc
sudo mount -t binfmt_misc none /proc/sys/fs/binfmt_misc
If it still does not work, it is probably not supported by your host Linux distribution's kernel (CONFIG_BINFMT_MISC
). Try to use another kernel.
The reason is somewhat unknown but looks like the following workaround solves it
./pmbootstrap zap -p -hc
./pmbootstrap shutdown
See issue #270 for more information and don't hesitate to reopen if this didn't work for you.
Maybe you need to install udev rules on your host Linux distribution. Arch has the android-udev package for example, which uses the rules from here.
In some devices (e.g.: bullhead, titan), when flashing the system (pmbootstrap flasher flash_system
), it works but fastboot complains of Invalid sparse file format at header magi
.
$ ./pmbootstrap.py flasher flash_system
[23:02:58] (native) install android-tools
[23:02:58] (native) flash system image
target reported max download size of 536870912 bytes
Invalid sparse file format at header magi
sending sparse 'system' 1/1 (274101 KB)...
OKAY [ 9.452s]
writing 'system' 1/1...
OKAY [ 12.584s]
finished. total time: 22.036s
[23:03:20] Done
It happens when your device expects a sparse system image. The workaround is as follows:
deviceinfo_flash_sparse=true
in deviceinfolibsparse
to depends=
.For more information, see issue #299