[15:51] So hey waveform you haven't tested these images on a CM4 at all yet, right? [15:51] correct [15:52] I'm just finishing off the desktop tests, and will get to them after that if you haven't beaten me to it :) [15:52] having an issue with USB inputs on arm64. config.txt looks reasonable to me, so I'm going to go get a different keyboard to try, and also try the armhf image [15:52] hopefully this is PEBKAC [15:52] this on the official IO board? [15:53] yes [15:53] (and yes, there should be a [cm4] section in config.txt that sets the dwc2 overlay into host mode, which is required for the USB2 ports on the IO board to operate) [15:55] yeah that was the first thing I checked [15:56] other keyboard didn't work, let's try flashing armhf [15:57] I seem to recall this happening on a previous image [15:58] okay, all done with desktop testing, I'll dig out my CM4 and see if I can replicate [15:59] I'm flashing armhf now but you know how slow this eMMC is... [15:59] oh yeaaaaah [16:14] USB keyboards aren't working on armhf either. Gonna ssh in and poke around [16:15] just as soon as I figure out which of the Pis on my home network this is... [16:24] okay, finished flashing my CM4, will fire it up and see if I can replicate [16:25] let me know, I'm starting to wonder if my IO board is fried [16:30] I'm gonna flash lunar as a baseline check [16:30] okay, working for me [16:31] (this is on arm64) [16:32] huh [16:33] specifically, this is with an rpi keyboard (which has a USB hub in it, but nothing plugged into the hub) [16:52] jawn-smith, okay, I have to take a break from testing and go parent but if you can figure out what's up with the keyboard issue the armhf image on CM4 is the last thing I haven't certified yet (or either arch on the CM4 lite because I don't have one) so either of those is a priority. I think everything else I can do is now done though [16:53] jawn-smith, oh one other thing in case you have a 3B+ (specifically) lying around is any investigation (or replication of) LP: #2038964 is most welcome! [16:53] Okay, I'm flashing lunar now. And I have plenty of 3B+ laying around [18:02] right, I'm back, taking another look at the 3B+ issue [18:06] oh ... there's two issues here. Firstly, that the 6.5 kernel seems to be re-initializing the lan78xx driver, where the 6.2 kernel didn't (per Juerg's addition to the issue) but secondly that this causes the device to rename (yet again). But ... oh no, I've got an idea how to fix this (or at least workaround it) [18:06] (I say "oh no" because if this work's the release team is liable to kill me :) [18:07] *works [18:08] the reason it's flip-flopping is that the end state of the rename ("eth0") no longer matches the required state to trigger the rename ("en*"), while the later rule to decide MAC-based naming *does* still match and so the system flip-flops between the two rules. If the first rule matched *both* states it won't flip-flop anymore [18:12] it works ... now I have to go talk to the release team ... >.< [18:21] jawn-smith, specific fix: in /lib/systemd/network/10-raspi-eth0.link OriginalName=en* eth0 [18:23] want me to jam that in to test it? [18:28] sure, can't hurt to double-check (I've just tried it on my 3B+ and it worked happily -- I *should* check it on other Pis as well, but I'll wait to hear from the release team is another re-spin is even possible at this stage) [18:29] proposed change is here: https://code.launchpad.net/~waveform/ubuntu/+source/ubuntu-settings/+git/ubuntu-settings/+merge/453340 [18:41] okay I'm in a meeting at the moment but will give it a spin after [18:42] ta -- I've got to go parent again for a while, will be back later