Page MenuHomePhabricator

Create and verify the full image
Closed, DeclinedPublic

Description

Lets verify that everything works on the Raspberry Pi image.

Details

Other Assignee
dpifke

Event Timeline

Peter updated the task description. (Show Details)
Peter edited subscribers, added: larissagaulia; removed: Aklapper.

devicelab_rpi4_20220607.img.xz

@dpifke I've tested the image this morning and the Raspberry Pi just turns off on startup? When I test the same thing happens with the old version too, I've missed that because last time when I tested at the office, the ethernet led was on, but on the front the the led was off but I didn't check.

I verified that the Raspberry Pi is working by burning the Raspberry Pi OS its (64 bit) on the same card, with that it starts up. When you tried did you test it standalone without anything connected to it? I tried standalone + ethernet cable. I use a Raspberry Pi 4 Model B and use the Raspberry Pi Imager to burn the image.

Debian by default turns off the green and red LEDs to indicate booting has completed. So the Raspberry Pi itself is likely still on, just the LEDs are off.

We can override this behavior, and probably should, since it also threw me for a loop at first. I'll see if I can set it so the green LED is always on, and make the red LED blink if no phone is connected.

Ah great news then :) When I tried to access I used the network cable from my Mac but I could access it, However now when I added to my router it worked and I could ssh to it.

There's a couple of issues I've seen. When I log in I get:

  1. ADB
Could not chdir to home directory /home/wmf: No such file or directory

And that will be a problem when using ADB. If I start add:

$ adb devices
* daemon not running; starting now at tcp:5037
ADB server didn't ACK
Full server startup log: /tmp/adb.1000.log
Server had pid: 997
--- adb starting (pid 997) ---
adb I 06-15 05:43:17   997   997 main.cpp:60] Android Debug Bridge version 1.0.41
adb I 06-15 05:43:17   997   997 main.cpp:60] Version 28.0.2-debian
adb I 06-15 05:43:17   997   997 main.cpp:60] Installed as /usr/lib/android-sdk/platform-tools/adb
adb I 06-15 05:43:17   997   997 main.cpp:60] 
adb I 06-15 05:43:17   997   997 auth.cpp:405] adb_auth_init...
adb F 06-15 05:43:17   997   997 adb_utils.cpp:316] Cannot mkdir '/home/wmf/.android': No such file or directory

* failed to start daemon
adb: failed to check server version: cannot connect to daemon

I created the dir and can start adb but the device that is attached do not show up:

$ adb devices
* daemon not running; starting now at tcp:5037
* daemon started successfully
List of devices attached

If I attach the device to my desktop it shows up, so there's something going on there. Does it work for you?

  1. Geckodriver

It seems like geckodriver isn't in the path/or not installed:

$ geckodriver --version
-sh: 3: geckodriver: not found
  1. WebPageRapley

I couldn't find the WebPageReplay binary? Maybe it's there but I don't know where it's installed.

  1. Throttling the connection on the Raspberry:

Also when using throttle for setting the connection on the machine route is used to find the interface (I think that dependency is hidden and not super clear):

sudo: route: command not found

And the wmf user needs to have sudo without password for route and tc to be able to handle the throttling.

What I see is there and tested that I could get the version etc from:

  • scrcpy
  • chromedriver
  • dependencies for visual metrics: ffmpeg, imagemagick,pillow, SSIM
  • nodejs
  • sitespeed.io

I have not tested VNC, is there a password setup or how does that work?

New image is uploading now, with the following fixes:

  • Re-enables activity LED on boot
  • Fixes home directory (again - previous fix got accidentally reverted)
  • Installs WebPageReplay (didn't realize we were still using this for device lab)
  • NOPASSWD for sudo group
  • Installs geckodriver (latest version via cargo)

If I attach the device to my desktop it shows up, so there's something going on there. Does it work for you?

Yes, seems to just work on this end. Does it work for you as root? Does lsusb show it connected? Anything in dmesg output?

sudo: route: command not found

route is long deprecated, use ip route instead.

re: VNC, what are you wanting to use this for? Do you need the client or a server? If a server, for the console framebuffer or for X11?

Cool, with the fixes for the home dir ADB actually finds the device, so I could successful run the test.

route is long deprecated, use ip route instead.

yep I can do that, I'll make a PR to update it.

It seems like geckodriver do not work:

wmf@rpi4-20220616:~$ geckodriver --version
geckodriver: /lib/aarch64-linux-gnu/libc.so.6: version `GLIBC_2.33' not found (required by geckodriver)
geckodriver: /lib/aarch64-linux-gnu/libc.so.6: version `GLIBC_2.32' not found (required by geckodriver)

re: VNC, what are you wanting to use this for? Do you need the client or a server? If a server, for the console framebuffer or for X11?

Server., x11. We need to be able to see the screen from the Android device, that's why we have scrcpy. That way we can manually debug things and change settings directly on the phone.

It seems like geckodriver do not work:

wmf@rpi4-20220616:~$ geckodriver --version
geckodriver: /lib/aarch64-linux-gnu/libc.so.6: version `GLIBC_2.33' not found (required by geckodriver)
geckodriver: /lib/aarch64-linux-gnu/libc.so.6: version `GLIBC_2.32' not found (required by geckodriver)

Spent a bunch of time trying to work around this today. The general problem is that geckodriver requires a newer Rust to build than ships with bullseye, and cross-compiling on a system with the newer Rust version links the output against the wrong libc version. I thought I had a way to link against the older libc, but it doesn't seem to work.

I think the solution is going to be to downgrade geckodriver, will continue working on it tomorrow.

re: scrcpy-over-VNC, doesn't X11 forwarding (ssh -X or ForwardX11 yes in ~/.ssh/config) accomplish the same thing, or am I missing something? (Thinking about it, we could probably just pipe the Android debug bridge connection over SSH and just run scrcpy locally, but I'd have to experiment with that.)

Is either remaining issue blocking you from further testing or are we otherwise good to go?

geckodriver

I remember when I tried it the last time, I also had problem with geckodriver but I don't remember if it was the same problem. However I remember that my problem got solved by installing Firefox on the Raspberry Pi. I asked Mozilla about it and they said it shouldn't need Firefox but I never filed that issue.

vnc

I did try it when I installed everything the last time, I'v added some docs here (at the end): https://www.sitespeed.io/documentation/sitespeed.io/installation/#raspberry-pi - however we can do it is fine, I just remember that it was super helpful at Kobiton to be able to see the actual screen

issue blocking

gnirehtet has top priority, if we can get it there, I can start running tests so we can check metrics and stability. I had problem with that last time, so I compiled it directly on the Pi (not recommended). And then the latest version of sitespeed.io with the fix using ip route, I'll release that this weekend.

I couldn't find that I added data from the test I did last time, only when I tried the gnirehtet on my Mac. There was one thing there was worrying at that it seems that sometimes it stopped to work see https://phabricator.wikimedia.org/T274237#6830535

I checked today and last time I tried I didn't actually test with gnirehtet from the Raspberry Pi (I had saved the old image). I started to try again today but haven't got the tethering to work. Note to myself for the next time: Test that it works by turning of the wifi on the phone.

I recompiled gnirehtet and got it to work, I think I used an old version that didn't match the apk or something. I'll run some tests in T279581 and then when your image got everything I can rerun them.

@dpifke Could you share the link for the documentation, please?

Also, there's a new image which resolves the Geckodriver/libc issue.

It turns out this was not simply a matter of Cargo using the wrong version because I was cross-compiling, but that it actually needs functions from the newer libc. See e.g.

Since Geckodriver explicitly requires a newer Rust than is available in bullseye, the solution was to pin libc to the version from bookworm. As far as I can tell, this didn't have any negative side effects, i.e. other software from bullseye runs fine.

I've uploaded a new image, incorporating some changes from the two weeks:

  • Added gnirehtet, which is configured to start via systemd either at boot or when an Android device is plugged in via USB.
  • Upgrades via apt should fully work.
  • VPN auto-provisioning should mostly work.
  • Some other small fixes and improvements.

Couldn't find the link for the image in this thread, so I'll add it here:
https://people.wikimedia.org/~dpifke/

I installed and tested devicelab_rpi4_20220630.img.xz today. I could run tests with Chrome and Firefox using using gnirehtet, so all good.

Added gnirehtet, which is configured to start via systemd either at boot or when an Android device is plugged in via USB.

That didn't work for me I needed to start it myself. I tested that by making sure the phone didn't have any connection to internet at all. However that doesn't matter so much, I think starting/stopping per test is ok.

VPN auto-provisioning should mostly work.

How do we test it?

@dpifke how much work do you think it is to get the image built in ci? Also did you see a way of getting vnc/scrcpy to work (I didn't fully understand that part)?

Signing over to you Dave when I'm on vacation.

Peter closed subtask T313932: CD for device lab image as Declined.

We will not move on with the Raspberry image.