[SOLVED] Can't connect to Android phone after recent Slackware64-current updates

bitfuzzy · 01-18-2021, 11:03 AM

Quote:

Originally Posted by ljb643

Update: I reverted to libusb-1.0.23 and blocked future upgrades so it it won't install 1.0.24. Everything worked, and then it didn't work. The reason it broke is that there was a new aaa_elflibs package released on Jan 9 and it contains the 1.0.24 version of libusb. This overwrote the library version link from libusb-1.0.23 so even though libusb-1.0.23 was still installed, libusb-1.0.24 from aaa_elflibs was active, breaking access to the phone.

I fixed it by deleting libusb-1.0.so.0.3.0 and pointing the link libusb-1.0.so.0 back to libusb-1.0.so.0.2.0

Maybe re-installing libusb-1.0.23 again would have fixed it but I'm not sure.

Meanwhile, the libusb project "roadmap" says 1.0.25 is due out "by July 31, 2021" which is not good.

This worked for me as well, however I did notice something odd

While libusb-1.0.so.0 is linked to libusb-1.0.so.0.3.0 in "/usr/lib64", it's linked to libusb-1.0.so.0.2.0 in "/boot/initrd-tree/usr/lib64/"

I'm wondering if this isn't the problem..

Can files and symlinks be replaced in this location? or will it cause issues??

ljb643 · 01-18-2021, 07:16 PM

/boot/initrd-tree is only used while making a ramdisk for booting the kernel. I don't think it will make much difference at all which version of libusb is in the boot ramdisk - it is only used for a short time while booting, then everything switches to your root disk.

bitfuzzy · 01-18-2021, 07:34 PM

Quote:

Originally Posted by ljb643

/boot/initrd-tree is only used while making a ramdisk for booting the kernel. I don't think it will make much difference at all which version of libusb is in the boot ramdisk - it is only used for a short time while booting, then everything switches to your root disk.

Yea, I found the documentation shortly after posting and came to that same realization

Thanks for confirming though

ljb643 · 02-21-2021, 07:29 PM

Quote:

Originally Posted by gmgf

A patch for libusb-1.0.24, is available here:

https://github.com/archlinux/svntogi..._parsing.patch

I tried that patch for libusb-1.0.24 but it didn't help. lsusb still won't show the phone, and trying to open or mount it from the Xfce desktop still gets that error. So I'm back to libusb-1.0.23 again.

bitfuzzy · 02-22-2021, 07:35 AM

Quote:

Originally Posted by ljb643

I tried that patch for libusb-1.0.24 but it didn't help. lsusb still won't show the phone, and trying to open or mount it from the Xfce desktop still gets that error. So I'm back to libusb-1.0.23 again.

Did you reboot?

The patch worked fine for me.

Patched the source, built a new pkg, installed and rebooted

Also blacklisted libusb-1.0.24 so it won't (or shouldn't) try to install that version, but should install 1.0.25 when it's released

ljb643 · 02-22-2021, 03:38 PM

Yes. It shouldn't have needed a reboot since it was just lsusb being tested, but I tried after login, and again after reboot. Didn't work. I'm going to try something else now: libusb "master" which contains the latest commits.

From what I've seen, they are not in much of a rush to release 1.0.25, and in fact still have pending fixes they want to put in there.

ljb643 · 02-22-2021, 04:35 PM

Building libusb from the current 'git master' worked. The phone is seen by lsusb, thunar can mount and open it, everything works.

So apparently it is a different change that fixes my issue.

For anyone trying to see if they have the same issue, here are a few lines from lsusb with debug logging when it fails with my Android phone. Here I'm using libusb-1.0.24 as provided by slackware64-current. The command I used was:

Code:

$ LIBUSB_DEBUG=4 lsusb -s 002:010

Where syslog told me my phone was on bus 2, device 10, so 002:010. Here is where libusb rejects my phone:

Code:

libusb: debug [linux_get_device_address] bus=2 dev=10
libusb: debug [linux_enumerate_device] busnum 2 devaddr 10 session_id 522
libusb: debug [linux_enumerate_device] allocating new device for 2/10 (session 522)
libusb: warning [parse_config_descriptors] config length mismatch wTotalLength 39 real 30
libusb: error [parse_config_descriptors] descriptor is not a config desc (type 0x00)
libusb: debug [libusb_unref_device] destroy device 2.10

bitfuzzy · 02-22-2021, 05:26 PM

Quote:

Originally Posted by ljb643

Yes. It shouldn't have needed a reboot since it was just lsusb being tested

Yea, but I've had issues where after updating it worked then didn't after a reboot heh

So I just got into the habit of rebooting with this one

bassmadrigal · 02-22-2021, 05:35 PM

Quote:

Originally Posted by ljb643

Building libusb from the current 'git master' worked. The phone is seen by lsusb, thunar can mount and open it, everything works.

If you want to try and track down the commit that fixed it, you could use git bisect to allow you to find what commit fixed your issue. This could also allow Pat to apply the patch if he feels it is necessary.

dadcompton · 02-22-2021, 06:00 PM

I found a way around this. Clone the libusb git repository (git clone https://github.com/libusb/libusb)
cd libusb
./configure --disable-static
make

After make is finished cd into libusb/.libs. Its a hidden folder. copy the libusb-1.0* from there to /usr/lib64.

That helped me get my phone connected.

edit: I have a tar archive containing the three libs if anyone is interested.

ljb643 · 02-22-2021, 09:32 PM

Quote:

Originally Posted by dadcompton

I found a way around this. Clone the libusb git repository (git clone https://github.com/libusb/libusb)
cd libusb
./configure --disable-static
make

After make is finished cd into libusb/.libs. Its a hidden folder. copy the libusb-1.0* from there to /usr/lib64.

That helped me get my phone connected.

edit: I have a tar archive containing the three libs if anyone is interested.

Yes that is essentially what I did too. But I used the github "Download as .zip" feature rather than cloning it, unzip and run bootstrap.sh, then used the same configure line as in the Slackware build script. Then I just copied libusb/.libs/libusb-1.0.so.0.3.0 over the one installed by Slackware's libusb-1.0.24 package. But you have to replace the file again if it gets overwritten by installation of aaa_libraries or libusb-1 packages.

dadcompton · 02-23-2021, 12:12 AM

Sorry , should have read your post first. The files have to be replaced after slackpkg upgrade-all?

ljb643 · 04-17-2021, 11:08 AM

Followup: From the Slackware64-current ChangeLog:

Code:

Fri Apr 16 23:29:36 UTC 2021
l/libusb-1.0.24-x86_64-4.txz:  Rebuilt.
  Fix parsing of descriptors for multi-configuration devices. Thanks to acbff0.

This patched version of libusb fixed the problem I was having with my Android phone.

ljb643 · 02-03-2022, 06:57 PM

Finally, libusb-1.0.25 was released at https://github.com/libusb/libusb/releases

I assume this includes the patch that was applied to 1.0.24 in Slackware64-current last April 2021 to make it work again with my phone and other devices. Unfortunately, this missed making it into the Slackware-15.0 release yesterday.

I don't know if it would be an appropriate patch update to 15.0 or not.

bitfuzzy · 02-10-2022, 02:02 PM

Quote:

Originally Posted by ljb643

Finally, libusb-1.0.25 was released at https://github.com/libusb/libusb/releases

I assume this includes the patch that was applied to 1.0.24 in Slackware64-current last April 2021 to make it work again with my phone and other devices. Unfortunately, this missed making it into the Slackware-15.0 release yesterday.

I don't know if it would be an appropriate patch update to 15.0 or not.

Why not just wait for the update?
Though that being said, libusb-1.0.24-x86_64-4 works just fine (for me anyway), I'd have to imagine 1.0.25 would be the same. That is assuming they don't break it again