**** BEGIN LOGGING AT Sat Jan 23 02:59:57 2021 Jan 23 03:00:14 from a different channel: Jan 23 03:00:16 02:57 <@DEATH> Would it hurt someone's feelings if OpenWRT wiki had factory flash instructions for ER-X that actually work? Jan 23 03:00:20 02:58 <@DEATH> initramfs.bin doesn't work, not the current one, not older ones. The .tar works. Apparently the problem is widely reported? Jan 23 03:00:59 03:01 <@DEATH> Doing exactly what the wiki tells you = zomg error. Jan 23 04:35:21 mangix: my feelings could endure a working er-x image. Jan 23 04:37:24 mangix: would you mind merging iperf and request the changes. That way we'd had the same state as now in the history Jan 23 05:18:03 * enyc meows Jan 23 05:18:47 I understand OpenWRT-DSA not to be complete in 20.xx, lantiq and some others still using swconfig... Jan 23 05:54:30 * mangix meows back Jan 23 05:54:41 enyc: this is true. patches welcome Jan 23 05:59:41 enyc: (afaik) the stated goal for 20.xx is not to have DSA everywhere (yet), but to have DSA support roughly feature complete with legacy swconfig (in netifd (mostly done) and luci (PR mostly functional, but not yet merged to luci/ master)) - and to move further targets as they get ready (ipq40xx and ipq806x aren't too far away from being ready, ath79/ ar8327n is imaginable, but will need quite some Jan 23 05:59:47 efforts) Jan 23 06:00:47 and yes, SDA for lantiq is being worked on as well (mainline) Jan 23 06:00:54 s/SDA/DSA/ Jan 23 06:01:50 pkgadd: i see, also seems to me like this is basically an inevitable-change and a 'tidy up' to complete later, no functional need to try to fully-complete or any of that. Jan 23 06:02:52 [at the moment] Jan 23 06:02:58 enyc: this https://github.com/openwrt/luci/pull/4307 is basically the major piece missing for (very rough) feature equivalence between swconfig support vs DSA support Jan 23 06:03:16 and yes, targets can be migrated one by one Jan 23 06:04:11 pkgadd: I'm using lantiq so many not see this much Jan 23 06:04:30 pkgadd: I notice example showing MTU's per interface pictured.... Jan 23 06:04:31 I've lightly tested it on realtek (rtl8382m) and was quite happy with it so far Jan 23 06:05:36 I've experienced the problems with inability to select MTU on vdsl/pppoe and all that... Jan 23 06:07:22 so far my ZyXEL gs1900-8 is my first and only device (really-) using the DSA framework so far, and that one never had swconfig drivers (nor do I need to bother about PPPoE and lower MTUs on a managed switch) Jan 23 06:07:46 pkgadd: hrrm my PPPoE/vdsl is probably not about the switch.... Jan 23 06:07:55 pkgadd: is PPPoE over lantiq DSL driver Jan 23 06:08:40 enyc: I haven't looked into DSA on lantiq so far (my bthub5 is just using plain master) Jan 23 06:09:41 pkgadd: how often do you update? Jan 23 06:11:14 hostapd - 2020-06-08-5a8b3662-28 -- hrrrm this is the other area holding-up openwrt-20 ? waiting for some extra drivers etc ...? Jan 23 06:11:29 patches i should say Jan 23 06:11:42 it depends, a lot - last time ~5h ago. I follow the commits going into master and update as I see important or interesting commits going in (respectively interesting/ unmerged patches being proposed), on average probably somewhere between 1-2 times a week to 6-8 weeks at most Jan 23 06:12:38 i've been testing mine doesn't crash ;p Jan 23 06:13:19 was in some tizwoz rebooting itself before, seems now to be ''stable'' .... I put on network log, and serial-console log with '4' debug selected at bootup...! Jan 23 06:13:28 hostapd is (imho) not contentious topic, any changes (apart from targetted fixes) would basically reset the clock and invalidate prior testing, so a bigger update (which is needed for proper 802.11ax support) will have to wait for post-2020-xy Jan 23 06:13:28 and now its not crashing ;p Jan 23 06:14:20 pkgadd: in any case are there 'supported devices' that would benefit *anyway* ? Jan 23 06:14:46 probably Jan 23 06:14:50 pkgadd: and could those 802.11ax devices simply have updated hostapd option for *them* i.e. a backport ? Jan 23 06:15:04 mangix: merge? Jan 23 06:15:05 no Jan 23 06:15:33 pkgadd: ok i'm used to handling debian ubuntu linuxmint ... packaging there, why does 'no' apply here in the openwrt-case ? Jan 23 06:16:27 it's not a reasonable option for 20.xy.X to retrofit 802.11ax support Jan 23 06:17:04 and it's not exclusively hostapd which would need- or profit from changes for 802.11ax support Jan 23 06:18:36 all that is $next_release (respectively master after branching off openwrt-2021.xy) Jan 23 06:19:38 pkgadd: ok so what needs sorting out in the social/political/people/etc matters to cause the openwrt-20 branch to be time to happen? Jan 23 06:19:44 contentious question too? Jan 23 06:20:09 enyc: I'm not an OpenWrt developer, nor can speak for the project - don't ask me Jan 23 06:21:22 I just see the code and realize what (imho) is missing/ needs doing, but that's it Jan 23 13:05:48 build #767 of tegra/generic is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/tegra%2Fgeneric/builds/767 Jan 23 18:46:34 enyc: https://openwrt.org/docs/guide-developer/releases/goals/20.xx see this Jan 23 18:54:05 aparcar[m]: have done, theres' a mail-thread about the DSA, i see LuCI commits in progress there... Jan 23 18:54:27 aparcar[m]: no links about the hostapd ... anything about 802.11ax controversies or so Jan 23 19:36:26 enyc: there isn't any controversies I'm aware of in regards to 802.11ax Jan 23 19:37:03 blocktrron: ok pkgadd was basicaly asying as a non-dev not sure if to keep backporting/updating hostapd in order to support 802.11ax etc Jan 23 19:39:16 i don't think this happens this close to the release. HE rates will be supported in the upcoming release, however te full WiFi 6 featureset might be absent. Also implementations in LuCI might not work that well Jan 23 19:41:33 There are only two WiFi 6 devices in OpenWrt at this point, one of which seems to be china only. So this shouldn't be that much of an issue currently. Jan 23 19:43:50 blocktrron: hrrrrrrrrrrrrrrm ok yes just found htat HE is name of 802.11ax =) Jan 23 19:45:22 There's more (TWT, BSS coloring) which is still missing from UCI to my knowledge Jan 23 19:45:47 However this might be due to them currently missing ion the driver side (not sure, haven't looked into) Jan 23 19:45:50 blocktrron: hrrm... nad how well supported ary drivers/devices/bugginess there of the 802.11ax devices etc etc anyhow! good question! Jan 23 19:46:15 blocktrron: in any case https://openwrt.org/docs/guide-developer/releases/goals/20.xx talks of still waiting for hostapd something-or-other ? Jan 23 19:46:24 I'm using a UniFi 6 Lite with OpenWrt since 3 weeks and haven't faced any issues since Jan 23 19:46:42 if there are to be 20.x forked test-images... Jan 23 19:47:02 I'd like to test them, vlans, etc... on many devices Jan 23 19:47:35 enyc: that last row makes no sense. I assume it should be mac80211 instead of hostapd. Jan 23 19:48:14 but afair this was supposed to happen later down the line Jan 23 19:48:47 hostapd - 2020-06-08-5a8b3662-28 Jan 23 19:49:00 hrrm I see yes, mac80211/kernel backports! Jan 23 19:49:19 I guess may be 2 thing- hakue on the kernel backports *and* john on hostapd commit maybe? Jan 23 19:52:54 hostapd / mac80211 is not set to be changed for the next release afair Jan 23 19:53:09 mac80211 is set to be updated in a service release in order not to stall the release Jan 23 19:56:49 adrianschmutzler, ping Jan 23 20:01:28 https://patchwork.ozlabs.org/project/openwrt/patch/20200915195655.13866-1-jacekowski@jacekowski.org/ Jan 23 20:01:48 would be great if this could be merged before 20.xx Jan 23 20:02:47 kudos to jacekowski, tested and confirmed by me and pkgadd Jan 23 20:03:19 somehow it ended up in /dev/idle on patchwork Jan 23 20:10:15 hmmm, trying to upgrade apu2 with image built from latest master, sysupgrade reporting "Device pc-engines-apu2 not supported by this image Supported devices: generic" Jan 23 20:23:41 shibboleth: well, as you see, it's marked "Changes Requested" Jan 23 20:23:46 so nobody will merge it Jan 23 20:24:53 i misread it as "changes being considered", basically. i should ask him to resubmit as ipq806x/general instead of the zyxel specifically? Jan 23 20:25:53 Well, ask him to address the requested changes. There are obvious formal shortcomings and then a discussion about the content which I didn't follow. Jan 23 20:26:10 adrianschmutzler: f52081bcf938efcd910832f3c3713ab9f3ca0738 has b0rked sysupgrade for me on an x86 apu2. Jan 23 20:26:59 I've reverted it in my tree for the moment. My guess is that "pc-engines-apu2" != "generic" Jan 23 20:27:30 which "format"/syntax would you suggest/advise for a "general" arch dts addition/change? Jan 23 20:27:57 patch each of the affected dts? Jan 23 20:28:19 ldir: strange. possibly something in x86 expects SUPPORTED_DEVICES to be empty? Jan 23 20:28:49 without having looked, this sounds to me like it's broken in x86 ...? Jan 23 20:29:36 shibboleth: the one requested in https://openwrt.org/submitting-patches , which partially is covered by the first response actually Jan 23 20:30:04 alright. jace happens to be online. jacekowski, thoughts? Jan 23 20:30:32 I don't know how it's supposed to work - I don't see individual build options for 'apu2' etc just 'generic' - so if we're expecting an image for all potential x86 boards then that isn't going to happen. Jan 23 20:31:15 ldir: try adding `SUPPORTED_DEVICES :=` to Device/Default in x86/image/Makefile Jan 23 20:31:50 ok I'll let you know Jan 23 20:32:12 but I still wonder how this breaks, I'd have expected x86 to completely ignore SUPPORTED_DEVICES Jan 23 20:32:59 I will try grep for where the message is generated, maybe I can find out more Jan 23 20:34:04 so what do you need me to do? Jan 23 20:35:02 jacekowski, looks to me: resubmit, change subject, add comments Jan 23 20:36:56 adrianschmutzler: this will take some time - a glibc patch has snuck in so make is rebuilding the toolchain as well - grrrr! Jan 23 20:37:10 ok, will look into doing that Jan 23 20:37:17 ty Jan 23 20:38:28 ldir: what I don't understand is why the device uses SUPPORTED_DEVICES at all; x86 has a custom platform_check_image, so it should not care about SUPPORTED_DEVICES at all ... Jan 23 20:39:59 I haven't looked at it at all, sorry - just reporting my experience....and reverting that one patch fixed it. Jan 23 20:41:02 ldir: ah, I've found it Jan 23 20:41:23 x86 uses append-metadata Jan 23 20:41:46 and that checks whether SUPPORTED_DEVICES is empty Jan 23 20:41:58 will have to have a closer look there Jan 23 20:42:18 so, setting SUPPORTED_DEVICES to empty as suggested above will almost certainly work Jan 23 20:42:32 at least until I've found a better way Jan 23 20:42:45 he he - great, thank you Jan 23 20:43:11 okay, now let's find out how many targets are affected :-( Jan 23 20:45:26 adrianschmutzler: always glad to be the 'regression canary' :-) Jan 23 20:45:42 better it be found early Jan 23 20:46:08 well, that's indeed very valuable here, because I still don't understand why this happens, only how Jan 23 20:46:23 so, I was totally unaware in the first place that this could break at all this way Jan 23 20:47:16 he he - a learning opportunity :-D Jan 23 20:47:48 would be nice if you could verify my workaround, then I would patch that into the affected targets Jan 23 20:48:48 I'll let you know - as I said unfortunately I'm having to rebuild the toolchain.... on my macbook. Jan 23 20:49:08 I won't really be available for the next 1-2 hours anyway Jan 23 20:49:22 just quickly going through targets now before I have to leave again Jan 23 20:52:32 oooh installing a native 'ccache' implementation has helped speed toolchain rebuilds a bit. Jan 23 20:59:04 okay, looks like the only other affected target is octeon for a single device, and this looks like a mistake to me Jan 23 21:06:30 aparcar[m]: do you know why x86 uses append-metadata? Jan 23 21:06:53 signatures are added in that step Jan 23 21:07:01 ucert/usign Jan 23 21:07:10 does it cause trouble? Jan 23 21:07:44 well, it adds SUPPORTED_DEVICES if they are not empty Jan 23 21:08:00 which breaks sysupgrade since they are not empty by default now anymore Jan 23 21:08:17 just wanted to make sure this is intentional, because essentially only x86 does this Jan 23 21:09:36 only x86 appends metadata? Jan 23 21:09:53 without using SUPPORTED_DEVICES for upgrade Jan 23 21:09:59 or at least setting it up properly Jan 23 21:10:33 so what's the proper procedure for having sysupgrade work on generic x86? Jan 23 21:10:43 in other words: x86 is the only target using append-metadata with adding the supported-devices json Jan 23 21:11:14 The fix for the current situation is simply adding `SUPPORTED_DEVICES :=` to Device/Default in the target. Jan 23 21:11:42 /tmp/sysinfo is never created if board_vendor and sys_vendor are empty Jan 23 21:11:47 I just wonder about how append-metadata is used here. Jan 23 21:12:12 hm product name and board name exist though (continues reading) Jan 23 21:12:35 note that supported_devices is about images, you are looking at the other side of the match Jan 23 21:14:55 i just ran into this since building a new image for the first time in 240 days Jan 23 21:15:02 in lib/preinit/01_sysinfo [ -n "$vendor" -a -n "$product" ] || return Jan 23 21:15:20 so /tmp/sysinfo is never made Jan 23 21:15:46 cat: can't open '/tmp/sysinfo/board_name': No such file or directory Jan 23 21:15:46 Sat Jan 23 16:09:53 EST 2021 upgrade: Device not supported by this image Jan 23 21:15:55 Sat Jan 23 16:09:53 EST 2021 upgrade: Supported devices: generic Jan 23 21:16:08 oh Jan 23 21:16:11 yes, and that's why comparing it with "generic" in metadata yields false Jan 23 21:16:19 nothing != generic Jan 23 21:17:28 so, one could also just provide the proper board_name and would not have to change the image Jan 23 21:18:06 I just would not have expected the whole mechanism to be active at all, with platform_check_image set inside x86. Jan 23 21:19:29 well, board name and product name exist Jan 23 21:19:32 well, I think I will just add SUPPORTED_DEVICES and then somebody actually using x86 should check whether the upgrade mechanism can be improved Jan 23 21:19:33 but board vendor and sys vendor are empty Jan 23 21:19:40 so 01_preinit just bails without writing anything Jan 23 21:23:40 on my apu2 sysinfo/board_name & model are set Jan 23 21:24:02 probably the cleanest way would be to split out the ucert stuff from append-metadata so it can be called separately Jan 23 21:24:40 The current problem is actually caused because append-metadata now actually appends metadata Jan 23 21:25:20 build getting closer to finishing.... Jan 23 21:25:28 maybe aparcar can have a look into that Jan 23 21:25:52 I will have dinner now ... Jan 23 21:27:04 so i have a build that supports any x86 device as well as apu2, if i set supported_devices to something other than empty, how is it supposted to work in this case? Jan 23 21:27:06 this is silly :/ Jan 23 21:27:28 adrianschmutzler: sure can Jan 23 21:28:25 preinit should probably be dumping 'generic' into /tmp/sysinfo instead of empty Jan 23 21:28:38 or something Jan 23 21:29:10 adrianschmutzler: this hack has worked for me https://git.openwrt.org/?p=openwrt/staging/ldir.git;a=commit;h=f12b2107a0879ff58c1f47d90b846bae534bc084 Jan 23 21:29:31 aparcar: https://github.com/openwrt/openwrt/blob/master/include/image-commands.mk#L54 Jan 23 21:29:59 would be nice, I have no experience with x86, and it's quite special in OpenWrt Jan 23 21:30:38 * ldir goes to bed Jan 23 21:30:44 ldir: thanks for testing, I will prepare and push myself (the 64.mk change should not be required) Jan 23 21:30:51 good night Jan 23 21:31:49 why not just modify lib/preinit/01_sysinfo to fill the file with generic instead of not creating Jan 23 21:32:15 well, then there's 02_Sysinfo which checks the device tree Jan 23 21:32:25 i guess would have to make another file to ensure it's created as generic if it doesnt exist Jan 23 21:35:09 yeah, seems best way to do this would be to create something like 03_sysinfo, and if /tmp/sysinfo doesn't exist, can then create it with generic Jan 23 21:35:13 root@rooter:~# mkdir /tmp/sysinfo Jan 23 21:35:15 root@rooter:~# echo generic > /tmp/sysinfo/board_name Jan 23 21:35:17 since after doing that, upgrade works fine Jan 23 21:35:47 * nyt shrugs Jan 23 21:37:46 or rather, just patch ./x86/base-files/lib/preinit/01_sysinfo Jan 23 21:37:49 to dump generic instead of empty Jan 23 21:40:50 and that's exactly something I cannot decide, because I do not use x86 so don't know what reasonable and/or expected there Jan 23 21:41:56 yeah not sure the proper way to handle Jan 23 21:42:48 x86 shouldn't need an exact board type match Jan 23 21:42:58 imo Jan 23 21:43:22 so i just tested and if i fill in the missing vendor with 'generic' Jan 23 21:43:25 it does find a board name Jan 23 21:44:11 then populates with generic-whatever Jan 23 21:44:17 Sat Jan 23 16:43:54 EST 2021 upgrade: Device generic-yl-skul6 not supported by this image Jan 23 21:44:21 and that still fails Jan 23 21:44:28 even though it's a generic image :/ Jan 23 21:44:40 so maybe the empty string is the correct way to go? Jan 23 21:45:02 im just worried that will fail somewhere when there is actually a device name Jan 23 21:45:05 i'll give it a test really quick Jan 23 22:05:07 well, updated, but no joy Jan 23 22:05:09 might have to dirclean Jan 23 22:07:16 +++ b/target/linux/x86/image/generic.mk Jan 23 22:07:20 + SUPPORTED_DEVICES := Jan 23 22:09:51 maybe better approach is to patch fwtool to change empty to generic Jan 23 22:10:01 i dunno just spitting out ideas while this runs Jan 23 22:11:24 [nyt@cc:~/archive/openwrt/x86]: make -j30 Jan 23 22:33:51 finally Jan 23 22:33:53 testing again Jan 23 22:39:28 no joy, trying to add to 64.mk Jan 23 22:46:46 well Jan 23 22:46:48 that worked Jan 23 22:46:50 Sat Jan 23 17:44:46 EST 2021 upgrade: Image metadata not present Jan 23 22:47:05 so that had to be in 64.mk as well Jan 23 22:47:16 that's an ugly kludge lol Jan 23 22:47:24 but it works Jan 24 01:53:10 test **** ENDING LOGGING AT Sun Jan 24 02:59:57 2021