Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Install on Sony Xperia XZ2 Compact running LineageOS 21 fails #569

Closed
ChoosingUsernameIsDifficult opened this issue Jul 27, 2024 · 8 comments · Fixed by #570
Closed

Install on Sony Xperia XZ2 Compact running LineageOS 21 fails #569

ChoosingUsernameIsDifficult opened this issue Jul 27, 2024 · 8 comments · Fixed by #570
Assignees
Labels
bug Bug in BCR itself

Comments

@ChoosingUsernameIsDifficult

I've got a fresh install of LineageOS 21 (21-20240712-NIGHTLY-xz2c) on a Sony Xperia XZ2 Compact, and I'm unable to install BCR on it.

I've tried installing 1.66, 1.65, 1.64, 1.63, 1.58, and 1.57. They all fail in the exact same way.

I'm trying to follow the instructions "For unrooted custom firmware".

I reboot the phone with the power and volume down buttons pressed. It boots into recovery. When I connect the USB cable, and run adb devices, the phone is listed but its status is unauthorized. I select Apply update and then Apply from ADB on the phone, and the screen tells me to Now send the package you want to apply to the device with "adb sideload <filename".... Running adb devices from my Linux terminal window now says the phone has status sideload.

Next I run adb -d sideload BCR-1.66-release.zip. The output in the Linux terminal stops at 1%, and on the phone screen I have an error message saying Signature verification failed Install anyway?. I select Yes but the install fails with another error: ERROR: recovery: Error in /sideload/package.zip (status 1). Meanwhile, the adb command in the terminal window goes up to 4% and then aborts and says Total xfer: 0.09x.

This is the full output on the phone, [with my comments in square brackets]:

Now send the package you want to apply
to the device with "adb sideload <filename>"...
Supported API: 3
Finding update package...
Verifying update package...
ERROR:   recovery: footer is wrong
Update package verification took 0.5 s (result 1).
ERROR:   recovery: Signature verification failed
ERROR:   recovery: error: 21
[this is where I get the "Signature verification failed Install anyway?" question, and answer yes]
Installing update...
Mounting system

- Device uses static partitions

- System block device: /dev/block/bootdevice/by-name/system

- System mount point: /mnt/system

- Root directory: /mnt/system

ERROR:   recovery: Error in /sideload/package.zip (status 1)


Install aborted with status 1.
Installation aborted.

Any hints on how to troubleshoot this? Does LineageOS 21 use erofs for the system partiotion (how do I check this?)? Is there a recommended way to install BCR on Lineageos (21)? I really need automatic call recording which is why I've installed LineageOS, and from what I've read it seems BCR is the best solution.

@chenxiaolong chenxiaolong self-assigned this Jul 27, 2024
@chenxiaolong
Copy link
Owner

Thanks for all the info! Can you try flashing it again and then while you're still in recovery mode, grab the log file with adb pull /tmp/recovery.log and upload it here?


I downloaded the OS (lineage-21.0-20240726-nightly-xz2c-signed.zip) and took a look at the system partition:

❯ avbroot ota extract -i lineage-21.0-20240726-nightly-xz2c-signed.zip -a
  0.001s  INFO Extracting from the payload: boot, dtbo, system, vbmeta, vendor
  3.748s  INFO Successfully extracted OTA

It is an ext2/3/4 filesystem, not erofs:

❯ file system.img                                                        
system.img: Linux rev 1.0 ext2 filesystem data, UUID=a7ebc3e7-822b-5546-8a08-904ee1510fab (extents) (large files) (huge files)

and it does not use the shared_blocks feature:

❯ dumpe2fs -h system.img | grep features
dumpe2fs 1.47.0 (5-Feb-2023)
Filesystem features:      ext_attr dir_index filetype extent sparse_super large_file huge_file uninit_bg dir_nlink extra_isize

The good news is that the system partition is not read-only. The issue is likely something else, which the log file should hopefully help identify.

@ChoosingUsernameIsDifficult
Copy link
Author

ChoosingUsernameIsDifficult commented Jul 27, 2024

Hi, I'm having problems pulling the log:

root:~# adb pull /tmp/recovery.log
adb: error: failed to get feature set: device unauthorized.
This adb server's $ADB_VENDOR_KEYS is not set
Try 'adb kill-server' if that seems wrong.
Otherwise check for a confirmation dialog on your device.
root:~# adb devices -l
List of devices attached
XXXXXXXXXX             unauthorized usb:2-1.2 transport_id:23

root:~# adb kill-server
root:~# adb devices -l
* daemon not running; starting now at tcp:5037
* daemon started successfully
List of devices attached
XXXXXXXXXX             unauthorized usb:2-1.2 transport_id:1

root:~# adb pull /tmp/recovery.log
adb: error: failed to get feature set: device unauthorized.
This adb server's $ADB_VENDOR_KEYS is not set
Try 'adb kill-server' if that seems wrong.
Otherwise check for a confirmation dialog on your device.
root:~#

(Device ID masked with XXXXXXXXXX.)

I'm not too familiar with Android debugging, adb, and LineageOS. I've tried a few steps to get past the "unauthorized" thing, but failed. I've deleted the ~/.android/adbkey and ~/.android/adbkey.pub files, connected the phone to the computer again and got the popup on the phone asking about saving the key, but I still get the same results/errors as above. How do I get rid of the "unauthorized" status?

(I tried replying via mail first but couldn't get the formatting correct so I deleted that comment and wrote this through github's web interface instead.)

@chenxiaolong
Copy link
Owner

Hmm, looking at some discussions about LineageOS, it seems like LineageOS's recovery mode has an Enable ADB option under an Advanced options menu. Could you give that a try?

@ChoosingUsernameIsDifficult
Copy link
Author

Thanks, there was an option under Advanced to enable ADB (weird, as I'm using to adb to sideload, but oh well...). After that I managed to pull the log. Attaching it to this message (device ID replaced with XXXXXXXXXX): recovery.log.20240727.txt

It seems this is the error which makes the install fail:

[   50.411793] mount: '/dev/block/bootdevice/by-name/system'->'/mnt/system': No such file or directory

Strange, since (as far as I understand the earlier log lines) /dev/block/bootdevice/by-name/system is returned by the system and thus should be a valid path. Or is block_dev simply set to /dev/block/bootdevice/by-name/system by the installer? Is the mountpoint -q /mnt/system check broken? I've never programmed for Android, and have never dealt with sideloading before, so I'm not used to parsing these kinds of log messages.

chenxiaolong added a commit that referenced this issue Jul 27, 2024
There are devices using static partitions, only have a single slot, but
still have an A/B slot suffix. Fortunately, `ro.boot.slot_suffix` is set
appropriately on these devices, so we can just always append that to the
name.

Fixes: #569

Signed-off-by: Andrew Gunnerson <[email protected]>
@chenxiaolong
Copy link
Owner

Thanks for the log. So this is a unique setup I haven't seen before.

On devices with A/B partitions, the system block device is /dev/block/mapper/system<suffix>, where <suffix> is _a or _b. On device without A/B partitions, the system block device is normally /dev/block/bootdevice/by-name/system.

On your device though, it looks like it uses the A/B naming style, but still lives in /dev/block/bootdevice/by-name/. There's only a single slot, so it's always system_a.

I think #570 should make this setup work. Can you give it a try? Test build: BCR-1.66.r7.ga19a8d2-release.zip

weird, as I'm using to adb to sideload, but oh well...

Ahh, yeah, sideload is a special mode. It actually shuts down the normal adbd process if it's running and restarts it in sideloading mode.

@ChoosingUsernameIsDifficult
Copy link
Author

Thanks, that worked, I could install that version of BCR.

I'm roughly 99.7% sure I've seen slot b mentioned during some step when installing LineageOS (seen it on the phone, not in instructions). But perhaps it's still a single slot phone, and it was just a quirk in the installation. Shouldn't the XZ2 Compact be recent enough to use a/b partitions?

One last(?) thing: I can't get the pm install /system/priv-app/com.chiller3.bcr/app-release.apk command to work:

root:~# adb shell
xz2c:/ # pm install /system/priv-app/com.chiller3.bcr/app-release.apk
/system/bin/sh: pm: inaccessible or not found
127|xz2c:/ # ^D
root:~# adb shell pm install /system/priv-app/com.chiller3.bcr/app-release.apk
/system/bin/sh: pm: inaccessible or not found

adb shell ps works, so it seems the pm command is missing.

@chenxiaolong
Copy link
Owner

Great!

I'm roughly 99.7% sure I've seen slot b mentioned during some step when installing LineageOS (seen it on the phone, not in instructions).

I'm an idiot. It didn't occur to me that there could be just 2 static system partitions. Yeah, I bet both system_a and system_b exist.


For pm, just to double check: are you booted into Android or recovery mode? It should be run when booted into Android. (I'll update the docs to mention this.)

chenxiaolong added a commit that referenced this issue Jul 27, 2024
There are devices using A/B with static partitions. Since the
`ro.boot.slot_suffix` property is unset on non-A/B devices, we can just
always append it to the block device name.

Fixes: #569

Signed-off-by: Andrew Gunnerson <[email protected]>
@ChoosingUsernameIsDifficult
Copy link
Author

Booting into Android fixed the pm problem.

Thanks a lot for all help. Time to play around with the new functionality...

@chenxiaolong chenxiaolong added the bug Bug in BCR itself label Jul 27, 2024
chenxiaolong added a commit that referenced this issue Jul 27, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Bug in BCR itself
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants