**** BEGIN LOGGING AT Wed Oct 21 10:59:57 2020 Oct 21 11:36:16 https://gist.github.com/damex/1eaded34bf11dc940beb3bc19997ede1 so figured out how to make sfp detect but there is 3 gpio pins that gets pulled low when you plug it in and they get high on plugging out Oct 21 12:06:37 damex: oh, that looks like nice progress if you get sfp module name there. Does ethtool -m work now? Oct 21 12:09:46 PaulFertser: nope :( Oct 21 12:11:25 PaulFertser: now i need a way to trigger sfp fault :D Oct 21 12:11:39 to test other options Oct 21 12:28:40 PaulFertser: problem is that we need to enable completely irrelevant options in kernel to get to CONFIG_SFP Oct 21 12:29:28 anyway, hopefully someone could point me to something that could help test sfp module gpios (3 of them) Oct 21 12:46:33 damex: you can use / in menuconfig and that will show not only the location of an option you're interested in but also the full list of what it depends on. Oct 21 12:47:06 PaulFertser: yeah, i did that. there is a dependency on either DSA or hardware that is not present on this platform. Oct 21 12:47:39 i did deeper and deeper checks of that dependencies and just enabled one of the ethernet controllers that will let me enable sfp support Oct 21 12:47:46 s/did/dig Oct 21 12:47:59 oh Oct 21 14:16:35 >KGB-1< https://tests.reproducible-builds.org/openwrt/openwrt_mediatek.html has been updated. (100.0% images and 99.7% packages reproducible in our current test framework.) Oct 21 15:32:53 build #405 of bcm47xx/generic is complete: Failure [failed updatefeeds] Build details are at http://buildbot.openwrt.org/master/images/builders/bcm47xx%2Fgeneric/builds/405 blamelist: Daniel Golle , Markov Mikhail Oct 21 16:44:10 PaulFertser: i checked code - what you describe about actual supported servers with actual supported hardware where ethtoom -m ethX could return something reasonable - this is not the case with cavium due to cavium-octeon state in kernel. i checked their driver in staging tree and it is... bad. there is also no phylink. so message i get from sfp module is just a notification about sfp module and sfp module can't be tied to any adapter (phy/mii) Oct 21 16:44:10 without patching up (i.e. refactor/rewrite) octeon-ethernet driver. Oct 21 16:44:24 i think this is as much as 5.4 linux kernel support octeons Oct 21 16:45:53 i think its time to make a MR. Oct 21 16:46:20 does anyone know if it is possible to have subtarget with FPU while main target does not support it ? Oct 21 16:52:48 damex: I don't see why not. bcm27xx has subtargets with arm vs aarch64 even Oct 21 16:54:45 stintel: oh sure Oct 21 16:54:52 i will go this way then Oct 21 17:15:56 uh... why there is octeontx target but no devices there? Oct 21 17:45:36 Hmpf… the SLOB allocator is still broken on Linux 5.4 (for ath79, at least). Oct 21 18:30:12 >KGB-1< https://tests.reproducible-builds.org/openwrt/openwrt_kirkwood.html has been updated. (100.0% images and 100.0% packages reproducible in our current test framework.) Oct 21 18:51:09 No, wait! SLOB is ok! Something broke elsewhere and I had to boot in failsafe mode, but it's all good, false alarm. Oct 21 19:01:47 I think the latest ubus update is breaking sysupgrade. Oct 21 19:02:22 Since /etc/groups is one of the preserved files, it doesn't contain the ubus uid. Oct 21 19:04:47 (Or so I think… I don't have another explanation for not being able to boot normally after a sysupgrade, but after failsafe/firstboot the system booted fine.) Oct 21 19:08:45 if thats true then should be easy enough to confirm with sysupgrade -F -n? Oct 21 19:09:23 wouldnt be surprised though, i mentioned here no long ago how fragile centralized ipc can be Oct 21 19:10:18 grift: Sure, but I just had to reset two machines, I'm not going to test on the last production one. :P Oct 21 19:11:56 I'm experimenting with the SLOB allocator on a 4/32 device. I knew it was broken on 4.14, but it got fixed meanwhile. That's how I stumbled upon this. Oct 21 19:13:28 will be interesting to see how that ubusd strategy play's out Oct 21 19:14:42 although i guess shouldnt be a problem with such broad permissions on the socket 0666 Oct 21 20:08:41 hi, how can I build all images of all targets at once? Oct 21 20:13:31 you can't, the different targets are mutually exclusive Oct 21 20:14:13 you can only build one after another, including changing the build configs inbetween Oct 21 20:21:02 depending on how often you're going to use it, you may want to look into setting up a local buildbot instance - or some simpler orchestration Oct 21 20:23:51 but neither of those can build multiple targets at once, they're merely starting multiple /independent/ build on multiple clients in parallel Oct 21 20:45:49 https://gist.github.com/damex/fc75c78dab265d6bac4bc946982347af after this commit https://github.com/openwrt/openwrt/commit/6a56a6eb30799fcec9eecc3ee860dc4d8a5d952a Oct 21 20:46:18 is it expected? Oct 21 21:04:25 mwarning: I have a GitHub CI setup here which builds all targets and uploads them to a S3 store Oct 21 21:04:28 would that help? Oct 21 21:05:09 https://github.com/aparcar/openwrt/commit/6ad9d3cfcc992c70871a8577e44e0508c097caec Oct 21 21:06:52 pretty neat, let them do all the heavy lifting Oct 21 21:07:34 how many cpu are utilized. ie how long does it take to do a target? Oct 21 21:08:23 grift: 2 cpus and about 2 hours per target Oct 21 21:09:27 neat Oct 21 21:13:22 grift: yea 40 targets are building in parallel so it's actually done quite fast Oct 21 21:13:47 i dont want to even thing about the storage that requires Oct 21 21:13:50 think Oct 21 21:14:53 aparcar[m]: neat. Oct 21 21:53:55 Finally... got the GPL sources from Cambium Networks https://cloud.tnkoch.de/s/kQDPzmQmcNor9TJ Oct 21 21:58:45 n4gi0s: why would you share a screenshot rather than the actual link? Oct 21 22:37:45 finally the button on the apu2 works. Oct 21 22:37:49 so last commits on master break octeon boot from flash. https://gist.github.com/damex/fc75c78dab265d6bac4bc946982347af we have this errors when booting from initramfs Oct 21 22:37:53 n4gi0s: can you send me a link or upload it? Oct 21 22:40:17 >KGB-0< https://tests.reproducible-builds.org/openwrt/openwrt_x86.html has been updated. (100.0% images and 100.0% packages reproducible in our current test framework.) Oct 21 22:53:50 https://gist.github.com/damex/b472788a8fdf08a0dfbe09756166b422 so here is the detailed log Oct 21 22:59:24 could someone revert 6a56a6eb30799fcec9eecc3ee860dc4d8a5d952a commit since we have broken master? Oct 21 22:59:33 lemmi: here^ Oct 21 23:57:38 damex: Oo.. You don't see the kernel just crap the bed like that often hehe Oct 21 23:59:07 damex: this one? https://github.com/openwrt/openwrt/commit/2dffadece9a7243a236ce7d91719787a671e23d4 Oct 22 06:13:12 Grommish_: maybe, but actual commit that broke it is the one that enabled procd-ujail procd-seccomp globally (for 'non-small-flash devices') Oct 22 09:59:48 hello, what do you consider the best embedded platform to start learning OpenWrt development? i.e. hich one has the best support and implementation? Oct 22 10:01:05 eduardas: you can learn OpenWrt development without an embedded platform, it runs nicely on amd64 targets. Oct 22 10:02:12 PaulFertser: I understand that... that is why explicitly stated I'm looking for an embedded target because I want to learn some embedded specifics too Oct 22 10:02:42 like how raw NAND is managed under OpenWrt, etc. Oct 22 10:03:34 it is more like Oct 22 10:04:21 damex: yes, but as far as I know OpenWrt has some non-mainline patches for MTD Oct 22 10:04:44 eduardas: it differs by device. it is highly prefferable to not patch anything Oct 22 10:05:23 damex: yes, so perhaps you can suggest an embedded platform that does not require those Oct 22 10:06:03 eduardas: but if the target you choose has already everything working properly then you won't have much motivation to learn. It's probably better to get some poorly supported (in the area of your interest, e.g. NAND) target and work on adding support for it. Oct 22 10:07:56 I guess damex learnt a lot while trying to make those boards supported :) Oct 22 10:08:32 PaulFertser: makes sense Oct 22 10:08:58 PaulFertser: what would you consider the best OEM OpenWrt fork? Oct 22 10:09:18 PaulFertser: I'm currently considering to buy the Turris Omnia router Oct 22 10:09:34 PaulFertser: since they boast they use open firmware Oct 22 10:10:10 eduardas: it's probably nice and all, but probably a bit overpriced, and also I'm personally a bit disappointed that they're not trying harder to be closer to mainline. Oct 22 10:11:15 OTOH it might be a good learning opportunity if you add the missing bits (like SFP support) properly I guess. Oct 22 10:11:48 eduardas: gl.inet sticks pretty close to vanilla openwrt as well afaik Oct 22 10:12:39 I'd say it's just that their boards are so simple that they do not need any special support :) Oct 22 10:12:55 :P Oct 22 10:14:41 btw, I've recently tried using an SFP module that has regular RJ-45 for wired GigE. Pretty handy for testing. Oct 22 10:14:49 Borromini: good to know... thanks... have not even heard of this company and product before Oct 22 10:16:18 Borromini: sadly they don't always give you option with PoE Oct 22 10:17:16 https://store.gl-inet.com/collections/smart-home-gateway-mesh-router/products/gl-b1300-home-ac-router?variant=29498754007134 that one has PoE :) Oct 22 10:17:18 damex: you mean no PoE in their line-up? Oct 22 10:17:45 ok :) Oct 22 10:17:49 Borromini: there is PoE but not for every board and sometime there is a more performant version but lacks PoE Oct 22 10:18:29 ok Oct 22 10:19:29 https://store.gl-inet.com/products/gl-s1300-smart-home-gateway so against that one Oct 22 10:19:32 no PoE :( Oct 22 10:45:53 Hi people just tryed to flash a build of master to my 3200acm and it will not boot Oct 22 10:46:00 It was build r14736-6a56a6eb30 Oct 22 10:46:13 Tapper: latest ujail commit seems to blame. Oct 22 10:46:20 OK Oct 22 10:46:31 Thanks I will wate for a fix Oct 22 10:47:00 https://lists.openwrt.org/pipermail/openwrt-devel/2020-October/031838.html Oct 22 10:47:48 Tapper: you can revert last commit in a tree (should fix the issue) Oct 22 10:48:00 so which one to revert? Oct 22 10:48:17 this one 6a56a6eb30799fcec9eecc3ee860dc4d8a5d952a? Oct 22 10:48:44 yeah, i reverted that one and it worked again on octeons Oct 22 10:49:01 can you add your suggested-by: ? Oct 22 10:49:03 ynezz I will just hang on for a fix Oct 22 10:50:52 ynezz: you can revert commit? Oct 22 10:50:59 yes, doing that right now Oct 22 10:51:09 Suggested-by: Roman Kuzmitskii is that ok? Oct 22 10:51:20 ynezz: sure Oct 22 10:51:37 This basically broke sysupgrade everywhere, I see. Oct 22 10:51:59 Yesterday I has problems with two ath79 devices. Oct 22 10:52:13 so i did only test on octeons and reverting 6a56a6eb30799fcec9eecc3ee860dc4d8a5d952a brings them back. fresh install from ram and sysupgrade too Oct 22 10:52:23 ok, thanks a lot Oct 22 10:52:40 gotta go Oct 22 10:54:12 Wait, I still think this revert won't fix the underlying issue. Oct 22 10:55:30 Like I wrote yesteday, ubus started running under a dedicated user, not root. On sysupgrade, /etc/{groups,passwd,shadow} are unconditionally backed-up and restored. When they're restored, they don't have the new user. Oct 22 10:55:57 Does this make sense? Oct 22 10:56:48 sounds like a there's a migration mechanism missing Oct 22 10:56:59 rsalvaterra: yeah, it probably won't fix it completely but sysupgrade should work after that revert. Oct 22 10:57:06 rsalvaterra: this is a very old and very known issue Oct 22 10:57:54 Borromini: definitely. Oct 22 10:58:12 stintel: Yes, I can see that now, after being bitten twice by it. :) Oct 22 10:58:19 annoying rightr Oct 22 10:58:32 I wrote about it in some ticket Oct 22 10:58:43 So, we need to boot in failsafe mode, tweak the groups/passwd/shadow files manually and reboot. Oct 22 10:59:18 https://github.com/openwrt/packages/issues/12084#issuecomment-637597311 Oct 22 10:59:45 damex: It works because the flash was reset and the correct files were read from /rom/etc. After a reset, everything will work again. Oct 22 10:59:54 but apparently I don't speak English because I don't they got it **** ENDING LOGGING AT Thu Oct 22 10:59:57 2020