**** BEGIN LOGGING AT Sun Jun 23 02:59:57 2019 Jun 23 06:00:28 Hi people I still cant flash my wrt3200acm from r10263 Jun 23 06:00:34 I am stuck Jun 23 06:01:01 I tryed a new snapshot and 18.06 Jun 23 06:01:06 No joy Jun 23 06:01:31 it just reboots back to r10263 Jun 23 06:03:39 somebody was reporting a similar thing a few months ago. i forgot how they fixed it Jun 23 06:05:39 DonkeyHotei can you think about anything I can try? Jun 23 06:06:05 It's on k4.19.52 Jun 23 06:16:18 Tapper: well, you could try co confirm if your issues are with kernel 4.19 or have some different cause, e.g. by testing KERNEL_PATCHVER:=4.14 in target/linux/mvebu/Makefile Jun 23 06:17:59 judging by the symptoms, i can only speculate that the image generation is going wrong somewhere Jun 23 06:19:32 it might be another incarnation of libjson-c API issues, but that's the part testing with kernel 4.14 could easily confirm (because that would still be broken) Jun 23 06:32:03 Hi pkgadd I cant flash any build with any kernel Jun 23 06:33:23 I tryed 18.x a old snapshot with k4.14 and a new snapshot with k4.19 Jun 23 06:36:19 did you try building from a completely clean/ fresh git clone? Jun 23 06:36:39 --> that would avoid libjson-c issues Jun 23 06:37:01 not sure if that's your issue here, but it's one potential pitfall Jun 23 06:37:57 pkgadd yes mate I did a make distclean Jun 23 06:41:10 unfortunately I don't have any mvebu devices, so apart from pretty generic advice, I don't really know if there's something specific to your device Jun 23 06:42:11 (well. considering the current state of mwlwifi development and its future prospects, I'm not that sad about that anymore ;) Jun 23 06:44:22 pkgadd OK mate thanks anyway. I am with you about the wifi I use c7 s for my APs now Jun 23 09:47:27 current mt7621 config makes the er-x bootloop Jun 23 09:48:25 I haven't narrowed it down yet, but some kernel config options are now turned on (like SECCOMP) Jun 23 09:48:35 these defaults don't seem to be sane Jun 23 09:50:42 ssn: you could try if the fix from https://github.com/openwrt/openwrt/pull/2153 works for you Jun 23 09:52:00 thanks, I'll try Jun 23 09:52:37 KERNEL_NET_NS=y is already part of my config Jun 23 09:53:32 so disable I guess? Jun 23 09:54:14 that would be working around the issue - I mean the kernel patch that (should) make it work even with NET_NS enabled Jun 23 09:54:53 ah ok Jun 23 10:02:17 ssn: and if it works for you and you happen to have a github account, a confirmation there would be nice ;) Jun 23 10:03:48 Compiling right now, will test and put results on github/flyspray Jun 23 10:04:38 谢谢你 Jun 23 10:13:55 my chinese is too rusty to remember what a proper response for that is, so thank *you* for testing and reporting Jun 23 10:17:22 @KanjiMonster: Your suggestion worked. I am using ifeq ($(CONFIG_USE_UCLIBC),y) . thanks again. Jun 23 10:31:37 patch worked as expected, thanks! Jun 23 11:02:52 Ok, uclibc actually HAS libcrypt - but no crypt_r and no crypt_data struct Jun 23 11:03:16 That's why the haproxy build broke. Jun 23 14:21:55 which target should I use for a realtek WiSoC? Jun 23 14:22:05 https://www.realtek.com/en/products/communications-network-ics/item/rtl8197f specifically (it's MIPS) Jun 23 14:22:37 as far as I can tell, no other hardware with this exact SoC is supported on OpenWrt yet Jun 23 14:24:30 zorun: There isn't such a target in mainline OpenWrt yet. Jun 23 14:25:09 ah Jun 23 14:26:20 zorun: I remember that OpenWrt SDK from realtek could be found on Github. Jun 23 14:35:22 gch981213: looks like you're right https://github.com/cgoder/openwrt_rtk/blob/master/original/UserGuide Jun 23 14:36:09 but it looks like lots of work to get this to work mainline Jun 23 14:37:15 thanks for the pointer Jun 23 14:39:08 oh it's based on Barrier Breaker, not that old Jun 23 14:39:42 just 5 years Jun 23 16:29:00 zorun: lol. Jun 23 16:41:46 zorun: the big problem is that those chips are not supported in upstream gcc Jun 23 16:46:42 DonkeyHotei: yeah, nor in the upstream kernel Jun 23 16:46:57 I'll buy another model ;) Jun 23 17:15:28 DonkeyHotei did i send you the other source code for the remaining bsap models? Jun 23 17:16:25 [Fri 2019-04-05 07:05:24 AM PDT] https://s3.amazonaws.com/ADTN_Product_Downloads/vWLAN/OpenSourceRequest/OSR_BSAP.tar Jun 23 17:16:25 [Fri 2019-04-05 07:05:24 AM PDT] https://s3.amazonaws.com/ADTN_Product_Downloads/vWLAN/OpenSourceRequest/linux_sdk_freescale_yocto.tar Jun 23 17:16:45 okay i couldnt remember Jun 23 17:19:08 wish i could do it myself. :| Jun 23 17:41:53 seems i can't create an acct nor make any edits to wikidevi because captchas don't appear Jun 23 18:24:05 somebody could fix this, I think it is prety simple fix, guy got right, unbound-daemon is "broken" https://forum.openwrt.org/t/where-did-unbound-go/38867/7 Jun 23 18:25:14 here why is broken: http://sprunge.us/Nv7YQj Jun 23 18:25:56 it installing "libunbound-heavy" instead of just "libunbound" package Jun 23 18:36:40 updated openwrt/upstream, https://sdwalker.github.io/uscan/index.html Jun 23 18:39:25 MY_R: its not clear why it is broken from your log Jun 23 18:39:51 it downloading -heavy bersion of lib Jun 23 18:39:55 and the linked forum post seems to be about something completely nrelated Jun 23 18:40:00 and why is that a problem? Jun 23 18:40:44 heavy version is compiled with other libraries for heavy use... and it doesnt work together since somebody spit unbound in two packages normal and -heavy Jun 23 18:41:27 jow, sorry, look at last post with link on forum, guy fighting with installing unbound which stuck in loop crash, I have got same when install normal unbound-daemon and unbound-daemon-heavy working fine Jun 23 18:41:59 sorry, I do not understand it Jun 23 18:42:24 can you pastebin an "opkg install unbound" output showing the error? Jun 23 18:43:42 jow, the error is downloading "libunbound-heavy" it should download "libunbound" look, since this commit: https://github.com/openwrt/packages/commit/e6812324c66f98bd2f1481233dbc7a988513e6d5 Jun 23 18:43:51 yes, I understand that Jun 23 18:43:54 but why is it a problem? Jun 23 18:44:21 what is the actual problem? Jun 23 18:44:29 missing package? conflicting files? opkg crash? Jun 23 18:45:09 it's not an error. it's a malfunction. "unbound-daemon" should depend on "libunbound" and "unbound-daemon-heavy" should depend on "libunbound-heavy" Jun 23 18:45:21 libunbound-heavy is compiled with libevent2 and unbound-daemon doesnt use that Jun 23 18:45:42 dependencies are broken Jun 23 18:45:47 packaging is broken Jun 23 18:45:49 yes Jun 23 18:46:00 that is why said "broken" Jun 23 18:46:02 unbound-daemon-heavy PROVIDES:=unbound-daemon Jun 23 18:46:32 and unbound-dameon-light is called "unbound-daemon" too, so no way to choose the provder via opkg Jun 23 18:46:37 report the bug in the packages repo Jun 23 18:47:03 anyhow, I disagree, nothing is "borken" Jun 23 18:47:20 well, package is broken... at some point :D Jun 23 18:47:31 when you request opkg install unbound-daemon it will chose unbound-daemon-heavy as possible provider and install that Jun 23 18:47:44 and from what you pasted it appears to install cleanly Jun 23 18:47:49 installing "libunbound-heavy" with "unbound-daemon" == no worky Jun 23 18:48:01 DonkeyHotei: https://github.com/openwrt/packages/commit/e6812324c66f98bd2f1481233dbc7a988513e6d5#diff-a7dabd334839010ffd3ba195fa94ce06R58 Jun 23 18:48:22 its not installing "unbound-daemon", it will resolve "unbound-daemon" to "unbound-daemon-heavy" and install that Jun 23 18:48:48 oh. Jun 23 18:49:06 for what else is there package "libunbound" ? Jun 23 18:49:14 the package messed up Jun 23 18:49:16 *packager Jun 23 18:49:48 MY_R: jow is saying that by installing "unbound-daemon" you are actually installing "unbound-daemon-heavy" anyway Jun 23 18:49:55 so there is no light unbound at all and all point to heavy? Jun 23 18:50:50 more or less, yes Jun 23 18:51:55 the unbound package maintainer is not on irc, but he usually responds to bugs filed on github pretty quickly Jun 23 18:51:56 still under "libunbound" I see description: TITLE+= (library, light traffic) and library is smaller from the "heavy" one Jun 23 18:52:40 MY_R: you can force opkg to pick the light variant by passing the url of it directly Jun 23 18:52:51 opkg install http://downloads.openwrt.org/snapshots/packages/mips_24kc/packages/unbound-daemon_1.9.2-1_mips_24kc.ipk Jun 23 18:52:56 that should work Jun 23 18:53:13 but that will still be broken because it will use the wrong libunbound Jun 23 18:53:33 ye Jun 23 18:53:48 DonkeyHotei: not according to package metadata Jun 23 18:53:55 Package: unbound-daemon-heavy Jun 23 18:53:56 [...] Jun 23 18:54:03 sorry Jun 23 18:54:10 Package: unbound-daemon Jun 23 18:54:12 [...] Jun 23 18:54:16 Depends: libc, libopenssl1.1, libunbound Jun 23 18:54:51 and heavy depends on +libpthread +libevent2 +libevent2-pthreads Jun 23 18:55:05 the control file also contains "Depends: libc, libopenssl1.1, libunbound" Jun 23 19:03:54 jow, it still downloading libunbound-heavy together with libevent2 stuff but ye whatever, I will try report that tomorrow but not sure if anyone will be abble to understand me :D Jun 23 19:07:18 sure the maintainer will if you include what jow explained to you Jun 23 19:16:38 Greetings! Snapshots, brcm47xx/mips74k: Since quite some months there are drivers missing on the official download server. kmod-brcmsmac is what I am looking for, but others are missing as well. I don't know if it's a bug or if it happened intentionally. I asked in the forum, albeit probably in the wrong category, see https://forum.openwrt.org/t/sn Jun 23 19:16:39 apshot-kmod-brcmsmac-driver-and-others-missing-in-targets-brcm47xx-mips74k/34810 for links and details. What is the right way to address this? Post in IRC? :-) Jun 23 19:19:50 Guest60137: file a bug on bugs.openwrt.org works best probably Jun 23 19:20:03 i don't know if the buildbots are back in shape after the hiccup they experienced Jun 23 19:20:25 but if you're saying 'months', that suggests it's unrelated to the recent buildbot issue(s) Jun 23 19:22:30 They are missing since Oct 2018. Jun 23 19:23:25 Will file a bug. Thanks. Jun 23 19:23:46 yeah that has been quite a bit :) Jun 23 19:23:57 brcmsmac is not deprecated or anything is it? Jun 23 19:24:38 Hi jow can you help me out? Do you know why I cant falash any build over r10263 on my wrt3200acm? Jun 23 19:24:42 flash* Jun 23 19:25:07 I have tryed to flash 18.x a old snapshot and a latest snapshot. Jun 23 19:25:28 I cant even go back to stock. It just boots back to r10263 Jun 23 19:26:40 When I look in Advanced Reboot it shows the partion with the other build on but when I try to boot to it it says. Jun 23 19:27:07 Failed to execute call dispatcher target for entry '/admin/system/advanced_reboot/alternative_reboot'. Jun 23 19:27:07 The called action terminated with an exception: Jun 23 19:27:10 Borromini Well, in case it is I'm not aware of it. However, in the forum someone responded that he's missing kmod-rt..., so at least for now I suspect it's just some build configuration thing Jun 23 19:27:20 /usr/lib/lua/luci/controller/advanced_reboot.lua:119: in function Jun 23 19:27:20 (tail call): ? Jun 23 19:29:29 Tapper: I am sorre, I have no experience with mvebu devices at all Jun 23 19:29:53 Any one? OK jow Jun 23 19:30:16 Wheres diizzy Jun 23 19:31:40 not on irc i thought. Jun 23 19:31:54 wreacks havoc enough as-is :) Jun 23 19:32:06 s/wreacks/wreaks/ Jun 23 19:34:37 Guest60137: i think it was mips74k that was deprecated Jun 23 19:34:43 LOL I like diizzy he makes things a bit mad hahah Jun 23 19:35:18 let's just say it's a polarising figure. Jun 23 19:35:21 Do you have any thorghts on my prob Borromini? Jun 23 19:35:23 ;) Jun 23 19:35:33 Tapper: other than 'weird', no unfortunately. Jun 23 19:35:36 diizzy is a lean, mean FUD machine Jun 23 19:35:42 O crap! lol Jun 23 19:35:48 DonkeyHotei: hehe Jun 23 19:36:20 Tapper: any luci advanced reboot commits that might look suspicious? Jun 23 19:37:04 no It's not just that I have tryed flashing over ssh to and still reboots in to old build Jun 23 19:38:34 have you tried flashing an official 18.06 build? Jun 23 19:38:59 Yes and stock still reboots back in to old build Jun 23 19:40:06 if official 18.06 won't boot, it's not getting flashed properly by the running system Jun 23 19:40:14 How do I see what is on the flash Jun 23 19:40:26 over ssh Jun 23 19:41:02 So I can show you the flash layout Jun 23 19:41:50 So I can see if all the partions are there? Jun 23 19:42:21 Partitions* Jun 23 19:47:11 you can toggle the boot order manually, via fw_setenv Jun 23 19:48:09 https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/mvebu/base-files/lib/upgrade/linksys.sh;h=3f45d6cac5e879f050442b76cf7b4270dc177207;hb=HEAD#l24 Jun 23 19:49:04 DonkeyHotei: mips74k deprecated? Really? For the device in question (Asus RT-N16) there's an official mips74k 18.06.2 and there are current mips74k snapshot builds, in fact (almost?) all current Asus RT- devices seem to be mips74k Jun 23 19:49:38 ok, maybe it was mips34k that was deprecated Jun 23 19:50:39 deprecated is a harsh word, it was just found out that gcc doesn't treat mips24kc and mips34kc differently, so there's no need to treat them differently from OpenWrt's side eithr Jun 23 19:51:18 pkgadd how do I find out what Partition I am on? Jun 23 19:51:57 /usr/sbin/fw_printenv -n boot_part should tell you Jun 23 19:52:09 pkgadd: ah ok, thanks, I'm more relaxed now :-) Jun 23 19:53:48 It says Warning: Bad CRC, using default environment Jun 23 19:53:48 ## Error: "boot_part" not defined Jun 23 19:54:55 egrep ^mtd$(cat /sys/devices/virtual/ubi/ubi0/mtd_num): /proc/mtd | cut -d '"' -f 2 Jun 23 19:56:10 pkgadd what does that do? Jun 23 19:56:21 https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/mvebu/base-files/lib/upgrade/linksys.sh;h=3f45d6cac5e879f050442b76cf7b4270dc177207;hb=HEAD#l5 Jun 23 19:56:48 it should spew out either (kernel1 or rootfs1) || (kernel2 or rootfs2) Jun 23 19:57:37 "should", just guessing - don't have any linksys device doing it that way (sadly I just lost a bid on a ea6350v3 this evening) Jun 23 19:57:38 I just got a blank line Jun 23 19:58:18 pkgadd are you in the UK I have a wrt1900 you could have for postage? Jun 23 19:58:38 nope, germany Jun 23 19:58:41 o/ pkgadd Jun 23 19:58:50 crap! never mind then Jun 23 19:59:26 pkgadd: any experience with vlans on ipq40xx perchance? :P Jun 23 20:00:07 Borromini: not yet, sorry - looking for something cheap though (either ipq40xx or ipq806x, whatever blinks first ;) Jun 23 20:00:47 pkgadd: already supported or not? :) Jun 23 20:01:13 this is ipq40xx: https://www.varia-store.com/de/produkt/31828-mikrotik-hap-ac2-rbd52g-5hacd2hnd-tc-mit-716-mhz-cpu-128-mb-ram-5x-gbit-lan.html Jun 23 20:01:37 pkgadd That camand says ubi Jun 23 20:01:38 zorun: ea6350v3 would be supported in master already (but v1, v2 would be unusable/ Broadcom) Jun 23 20:01:46 pkgadd: ok. i can tell you ipq40xx switches seem to be some kind of dark magic ;) Jun 23 20:02:18 and vlans don't seem to be working Jun 23 20:02:34 Borromini: qca8k (the DSA alternative) should be further ahead, so that's 'just' an issue with the current driver Jun 23 20:02:41 pkgadd: ok, I haven't come across these Jun 23 20:02:59 pkgadd: another option is zyxel nbg6617, already supported Jun 23 20:03:04 Borromini: it's not an unfixable hardware defect Jun 23 20:03:22 pkgadd: hope so. i spent almost a day trying to 'fix' it and my friends got pretty angry with me :P Jun 23 20:03:40 i read even upstream doesn't know yet what's happening exactly with ipq40xx and vlans? Jun 23 20:03:51 zorun: I know, I'm not picky - 'anything' with 4+1 ethernet ports and being ipq40xx/ ipq806x based would do, it just has to be cheap enough ;) Jun 23 20:04:10 How do you list partitions in openwrt lsblk and fdisk don't work Jun 23 20:05:19 Tapper: cat /proc/mtd should work, ubinfo -a might provide further info in your case Jun 23 20:05:39 thanks Jun 23 20:06:44 Borromini: VLANs are working on ipq40xx when using the QSDK Jun 23 20:07:04 Borromini: the switch is a bit weird/ difficult, but it's possible Jun 23 20:07:06 yeah so just a problem in the linux kernel atm? Jun 23 20:07:44 I get https://pastebin.com/ttaxrsMG Jun 23 20:08:33 Borromini: more with the swconfig driver, I think qca8k/ DSA should already be working Jun 23 20:08:51 Tapper: what does cat /proc/cmdline say? Jun 23 20:10:02 console=ttyS0,115200 root=/dev/mtdblock6 ro rootdelay=1 rootfstype=jffs2 earlypr Jun 23 20:10:03 intk mtdparts=armada-nand:2048K(uboot)ro,128K(u_env),256K(s_env),256K@8064K(devi Jun 23 20:10:03 nfo),1920K@8320K(sysdiag),80m@10m(kernel),74m@16m(rootfs),80m@90m(alt_kernel),74 Jun 23 20:10:03 m@96m(alt_rootfs),160m@10m(ubifs),-@170m(syscfg) Jun 23 20:10:32 pkgadd: ok ty Jun 23 20:11:48 Tapper: hmm, I would have expected a rootfs=xxx entry or something there, do you get any better information with "fw_printenv"? Jun 23 20:15:05 pkgadd https://pastebin.com/hFwXgvvF Jun 23 20:15:53 Tapper: the "Warning: Bad CRC, using default environment" worries me a bit, that shouldn't happen Jun 23 20:16:11 * Tapper hangs head! Jun 23 20:16:36 O dear Jun 23 20:17:52 do you want to see what ubinfo - says? Jun 23 20:17:52 Just one more thing: I'm working with and on Linux since 1996, professionally since 1998. I'm using OpenWRT since WhiteRussian RC2, 2007 or so. Although it's a very specialized distrib to me OpenWRT is one of THE best and most important linux distributions available. Simply because it turns small crappy-unmaintained-OEM-software-devices into stable Jun 23 20:17:53 devices that you can actually use. THANK YOU! Jun 23 20:17:57 Tapper: that's not fatal, after all your device is still booting Jun 23 20:18:24 Tapper: no, that just shows how your NAND (respectively only the UBI part of it) is partitioned Jun 23 20:18:33 k Jun 23 20:19:13 I'm really lacking linksys/ mvebu experience here, so I don't really know what should be there (what would normally be set in ubootenv) Jun 23 20:19:32 me to lol Jun 23 20:20:02 you may be able to guesstimate based on your wrt1900 Jun 23 20:20:07 Should I wate for the morning and try and pester some one who has a wrt3200acm? Jun 23 20:20:21 that might help, yes Jun 23 20:20:52 OK thanks for trying to help me out anyway dude. I am going to get me a coffie now Jun 23 20:21:19 not an espresso i hope Jun 23 20:22:00 it's still 26°C over here, so I'd be more into cold beverages at the moment ;) Jun 23 20:22:51 yeah :( Jun 23 20:22:59 although apparently warm drinks help you cool off better somehow Jun 23 20:25:10 It is starting to cool down over here and I have to wate up for my wife she has tacken my mum to the dokters. Jun 23 20:25:58 i don't dare look at the thermometer Jun 23 20:26:12 and we'll be looking at multiple 30+ days for the coming week Jun 23 20:26:22 temp is 16 here in stoke Jun 23 20:26:40 Yeah I herd it will be hot in the eu Jun 23 20:26:59 Tapper: I 'think' your main problem is the broken ubootenv, not upgrading per se (just that the linksys upgrade code relies on ubootenv to be valid, in order to configure the boot order) Jun 23 20:27:12 I don't like the heat anything over 25 and I am a hot mess lol Jun 23 20:27:40 pkgadd yeah I think you mite be rite Jun 23 20:27:47 so if you ask another wrt3200acm for their fw_printenv output, you should be able to fix that manually, via fw_setenv Jun 23 20:27:48 16? Jun 23 20:28:12 yeah 16 degrees Jun 23 20:28:44 pkgadd OK thanks mate Jun 23 20:28:52 the weather forecasts for the upcoming week scare me (35-38 °C) Jun 23 20:29:05 * Tapper shudders Jun 23 20:29:16 That heat is nast Jun 23 20:29:21 nasty Jun 23 20:29:30 No AC over here. Jun 23 20:29:52 neither here Jun 23 20:30:41 And some people dont think that goble worming is a hokes! lol Jun 23 20:31:04 Not don't* Jun 23 20:31:43 *do think* Jun 23 20:41:28 pkgadd: yeah. i bought a fan... but that only does so much Jun 23 21:08:09 Borromini: if its not humid, use a wet towel in front of fan Jun 23 21:08:40 assuming the fan is for you and not your devices... Jun 23 21:15:33 hehe Jun 23 21:15:44 thanks Jun 23 21:15:49 going to call it a night - later guys Jun 23 21:50:32 Can anybody tell me how to rebuild the kernel headers (after modifying uapi stuff) without rebuilding the whole tree? Jun 23 21:51:06 I see toolchain/kernel-headers, but it isn't reinstalling whatever user kernel headers the packages are incuding Jun 23 22:08:13 hrmm, it looks like the answer is target/kernel-headers/install, but it's rebuilding my toolchain :( Jun 23 22:08:29 I suppose that's a legit dependency, although I know it doesn't affect my toolchain, oh well **** ENDING LOGGING AT Mon Jun 24 02:59:57 2019