I am attempting to unlock the bootloader but cannot. adb reboot bootloader works, but fastboot flashing unlockdoesn’t, it says < waiting for any device > If I have the journalctl --follow open while connecting the device to the PC, I get the following errors in order over and over again:
Aug 04 18:41:27 skilopsarospc kernel: usb usb8-port1: attempt power cycle
Aug 04 18:41:28 skilopsarospc kernel: usb usb8-port1: unable to enumerate USB device
I’ve tried it from 3 different computers with several different cables. I ordered a new usb-c connector, but that still doesn’t work.
fastboot devices returns without seeing the device.
Any ideas about what might be causing the issue, or how to fix it?
I experienced that also, long ago. I think, some udev rules didn’t match (because devices were called differently), but I could connect with fastboot using sudo
It’s in fastboot so I don’t see how the android settings would change anything, but I did try revoking permissions in the developer options and it changed nothing.
As far as I can see I am not missing any udev rules. Is there something specific you’d like me to check?
[20648.575837] usb 1-10.1: new full-speed USB device number 15 using xhci_hcd
[20648.656857] usb 1-10.1: device descriptor read/64, error -32
[20648.838851] usb 1-10.1: device descriptor read/64, error -32
[20649.023836] usb 1-10.1: new full-speed USB device number 16 using xhci_hcd
[20649.105850] usb 1-10.1: device descriptor read/64, error -32
[20649.296844] usb 1-10.1: device descriptor read/64, error -32
[20649.397952] usb 1-10-port1: attempt power cycle
[20650.000836] usb 1-10.1: new full-speed USB device number 17 using xhci_hcd
[20650.000977] usb 1-10.1: Device not responding to setup address.
[20650.207006] usb 1-10.1: Device not responding to setup address.
[20650.414983] usb 1-10.1: device not accepting address 17, error -71
[20650.415172] usb 1-10.1: WARN: invalid context state for evaluate context command.
[20650.496828] usb 1-10.1: new full-speed USB device number 18 using xhci_hcd
[20650.496923] usb 1-10.1: Device not responding to setup address.
[20650.702001] usb 1-10.1: Device not responding to setup address.
[20650.910821] usb 1-10.1: device not accepting address 18, error -71
[20650.910987] usb 1-10.1: WARN: invalid context state for evaluate context command.
[20650.911037] usb 1-10-port1: unable to enumerate USB device
I assume you have a Linux os. If it’s on Windows, I don’t know how it works. My computer is on Fedora.
With the command lsusb on my Linux computer I find that my Fairphone is listed as:
Bus 001 Device 005: ID 18d1:4ee2 Google Inc. Nexus/Pixel Device (MTP + debug)
Now I know {idVendor}==“18d1”, {idProduct}==“4ee2”
Have a read at point 3.4 Fix Udev Rules (Critical Fix).
Hi, im having the same problem with my FP4 and checked multiple things assisted by an AI-chat on Linux / Fedora. At the end I was not successfull to solve the prolem but wanted to contribute the things i’ve tested.
[AI-generated summary]
Summary of diagnostic findings (Fairphone 4, previously CalyxOS)
Note: This diagnosis was conducted with the assistance of an AI assistant (Claude), which guided a step-by-step troubleshooting process. Posting the full findings here in case they help pinpoint the root cause of this and similar reports.
Background:
CalyxOS was installed successfully on this Fairphone 4 a while ago (bootloader unlock/fastboot worked at that time). I recently attempted to switch to /e/OS, first via the e/OS web installer (macOS + Chrome), which failed to detect the device once it entered bootloader mode. I then attempted a manual command-line reinstall of CalyxOS on Fedora Linux — same result: device not detected in bootloader/fastboot mode.
Steps taken and results:
lsusb while device is in bootloader mode: only shows generic “Linux Foundation root hub” entries — no distinct device with a Fairphone/Google vendor ID ever appears.
journalctl -f while plugging in via the laptop’s Thunderbolt/USB4-C port: shows a full PCIe re-enumeration of the xHCI host controller itself, including bridge window ... failed to assign / can't assign; no space errors — but no actual per-device enumeration of the phone.
Ruled out cables: tested multiple USB-C and USB-A cables/adapters.
Ruled out host ports: tested both the laptop’s Thunderbolt/USB4-C port and a plain USB-A port (via adapter).
Ruled out host/adapter/cable chain entirely: a Pixel 10 was tested with the exact same cables/adapters and was detected correctly both in normal boot and in its own bootloader/fastboot mode.
Normal boot on the Fairphone (CalyxOS, USB debugging) works perfectly — adb devices detects it without issue.
Tested adb reboot fastboot (fastbootd / userspace fastboot, still running inside the Android kernel) instead of adb reboot bootloader: this works.
lsusb → ID 18d1:d00d Google Inc. Xiaomi Mi/Redmi 2 (fastboot) (generic Google fastboot protocol ID)
sudo fastboot devices → 50ad95b1 fastbootd
fastboot getvar unlocked → unlocked: no
fastboot getvar all → FAILED (remote: 'Device is locked')
fastboot flashing unlock → no response/hangs (neither terminal nor phone show any unlock confirmation prompt)
Conclusion:
The Android kernel-stage USB gadget driver works fine (normal boot + fastbootd both function correctly on this exact device, on this exact host, with these exact cables). However, the primary/first-stage bootloader (ABL) fails to properly enumerate over USB at all — no vendor/product ID is ever presented, and the PCI/xHCI controller behaves as if nothing valid was plugged in. Since bootloader-level unlock confirmation isn’t implemented in fastbootd, this leaves the device unable to be unlocked or reflashed via standard fastboot, despite otherwise functioning completely normally.
Given that fastboot/bootloader mode worked when CalyxOS was originally installed, this suggests something changed at the ABL/bootloader-firmware level — possibly related to the interrupted e/OS web installer attempt — rather than a pre-existing hardware fault.
Happy to provide further logs/output if useful for narrowing this down.
[/AI-generated summary]
i think the problem with the damaged bootloader dates back to the installtion of CalyxOS years ago, but i’m not sure about that.
