**** BEGIN LOGGING AT Wed Apr 14 02:59:56 2010 Apr 14 06:26:34 דןןה לןסםיםד Apr 14 06:26:39 good morning Apr 14 06:26:46 http://www.lanready.com/spec/GN5-43UP-Prelimitary.pdf Apr 14 06:26:50 http://www.flexcomm.com.cn/pdf/en/FlexMaxProductBrief.pdf Apr 14 08:12:38 May I ask, what is the reason for a diffirent preinit ip address? Apr 14 08:15:46 What's the reson to set an ip address at the preinit time at all? Apr 14 08:16:23 <[florian]> to broadcast the message that the device is in preinit mode Apr 14 08:18:49 Is there some documentation describing this functionality? Apr 14 08:19:14 <[florian]> I am afraid no, but you already knew that before asking the question did not you ;) ? Apr 14 08:19:39 No, I've got no idea why broadcasting this is needed. Apr 14 08:20:05 <[florian]> to inform an user that the device has been successfully put in preinit mode Apr 14 08:20:18 I've got little experience _using_ openwrt on hardware it already supports. ;) Apr 14 08:20:18 <[florian]> suppose you have no console output and/or no LED indication? Apr 14 08:20:51 Can we make this optional? Apr 14 08:21:04 <[florian]> sure we can Apr 14 08:23:03 K, this is required for nfsroot. It's a bad idea to change the ip when your rootfs is mounted over the net. ;) Apr 14 08:24:00 Btw, why is the preinit ip not set to the image ip by default, but to 192.168.1.1? Apr 14 08:24:30 <[florian]> because we missed that Apr 14 08:24:36 <[florian]> it should be set to the configured IP address Apr 14 08:55:08 hey florian Apr 14 10:00:50 mb__: ping Apr 14 10:01:19 KanjiMonster: pong Apr 14 10:02:33 florian said I should ask you - what do you think about http://page.mi.fu-berlin.de/jgorski/openwrt/wip/trunk/0008-ar71xx-Make-Broadcom-cards-usable-on-RS-RS-Pro.patch ? Apr 14 10:02:41 any suggestions? Apr 14 10:03:33 (I am aware that this will never make it into the mainline kernel, this is for until the pci bug gets fixed/worked around) Apr 14 10:07:05 Uh, I dunno. Apr 14 10:08:28 KanjiMonster: did you follow the discussion about the different sprom offsets on the linux wireless list? Apr 14 10:08:45 maybe this card has a working sprom, but only at a different offset Apr 14 10:09:26 <[florian]> KanjiMonster: I said you should ask mb__ :) Apr 14 10:10:41 I'm actually pretty much ignoring all that SPROM fuzz. Because It's really braindead and I don't really want to get into it. So I don't really care in the end Apr 14 10:11:37 nbd: no, since I normally don't read linux wireless - do you have a link by chance? Apr 14 10:11:57 mb__: I would be too, if it weren't producing pci errors ;) Apr 14 10:12:13 see https://dev.openwrt.org/ticket/6801 Apr 14 10:14:48 the thread is here: http://thread.gmane.org/gmane.linux.kernel.wireless.general/48117 Apr 14 10:15:09 maybe try the last patch in there Apr 14 10:15:24 KanjiMonster: Please read the list. There's a discussion about the SPROM and they found out that sometimes the SPROM is mapped somewhere else Apr 14 10:16:42 thanks Apr 14 10:19:12 I'll take a look at it Apr 14 10:50:35 nbd * r20853 /trunk/tools/mtd-utils/patches/130-lzma_jffs2.patch: mtd-utils: remove bogus include statement to make it more portable Apr 14 10:54:23 Just wonder, do the people who write over-complicated code actually believe, that the potential readers would prise their intelligence? Apr 14 10:55:17 does that apply to sentences aswell ? Apr 14 10:55:39 Nope. Apr 14 11:16:02 xl0: some people write over-complicated code because it's easier than writing simple code to do the same thing ;) Apr 14 12:24:12 nbd: the patch didn't help directly, but through printk-debugging I found out that the chipcommon core is rev 13, and the bit for the SPROM isn't set in the capabilities register Apr 14 12:26:55 nbd: but the comment doesn't quite make it clear whether all cores >= 11 < 31 should have an sprom, or the capability bit is only defined for revision 31 and later Apr 14 14:36:43 nico * r20854 /trunk/ (3 files in 3 dirs): target/ixp4xx: fix image building after r20834 (closes: #7157) Apr 14 15:05:06 cshore: ping Apr 14 15:06:05 [florian]: ping Apr 14 15:12:27 <[florian]> rtz2: pong Apr 14 15:16:46 [florian]: I have a .32 kernel Apr 14 15:17:03 <[florian]> rtz2: \o/ Apr 14 15:18:23 [florian]: I didn't run too many tests, but it seems to work and it's 760kb with the improved lzma options, so it should work# Apr 14 15:18:56 [florian]: should I post a patch to the mailinglist? Apr 14 15:19:06 <[florian]> rtz2: yes please Apr 14 15:19:26 [florian]: ok Apr 14 15:19:50 <[florian]> rtz2: it helps me keeping track of patches when I switch between machines ;) Apr 14 15:22:07 [florian]: no problem Apr 14 15:31:49 pong rtz2 Apr 14 15:34:44 xl0: the preinit IP is configurable under Image Options|preinit options Apr 14 15:35:06 cshore: you did play around with qemu some time ago, or do I mix something up? Apr 14 15:35:20 rtz2: I have used qemu Apr 14 15:35:28 cshore: Yeah, I see. The problem is, the init scrips are not at all designed to fun from nfsroot. ;) Apr 14 15:35:36 *run Apr 14 15:36:05 cshore: only for x86 or also for mips? (or something else?) Apr 14 15:36:11 Had to add a few hacks to get them going. Apr 14 15:36:24 xl0: well, at least for the preinit stuff, I was basically copying the existing setup into the modular method Apr 14 15:36:47 xl0: so if you have patches that will work in both cases, feel free to submit Apr 14 15:37:10 I might, but only hacks currently. ;) Apr 14 15:37:14 xl0: I haven't don't a lot with the init scripts Apr 14 15:37:21 xl0: just the preinit Apr 14 15:37:26 rtz2: just x86 Apr 14 15:37:43 Well, they try to get the interface down a few times, and this kind of breaks the nfs. ;) Apr 14 15:37:58 ahh crap Apr 14 15:39:02 xl0: hmm...the problem is that preinit was designed to not get in the way of the real init's network setup Apr 14 15:39:39 cshore: It assumes that the network was not yet configured, and feels itself at home there. Apr 14 15:39:40 xl0: so the preinit network is deconfigured so that the real init has a clean slate Apr 14 15:39:59 Yep, but the root is mounted over nfs. ;) Apr 14 15:40:08 Once you deconfigure the net, you die. Apr 14 15:40:26 xl0: but what I would do for the nfs root is override the deconfig function with an empty functions Apr 14 15:40:39 xl0: with the module preinit you can do that from a package Apr 14 15:40:55 xl0: let me find the docs for you Apr 14 15:41:10 What is tihs module preinit? Apr 14 15:42:18 preinit a) has to be in the image (because it runs before the rootfs) and b) is responsible for bringing things up, including the rootfs, to the point where regular init can work Apr 14 15:42:56 And I also had to remove lib/preinit/10_indicate_preinit. Apr 14 15:43:20 http://wiki.openwrt.org/doc/techref/preinit_mount Apr 14 15:43:36 Don't remove them, do some that is named higher and override the function Apr 14 15:44:18 xl0: that way you can include it in a package rather than modifying the base system Apr 14 15:44:46 cshore: I'll look at this, thank you for the link. Apr 14 15:44:49 xl0: preinit first source all the /lib/preinit/* scripts, then executes the hooks Apr 14 15:46:25 xl0: the objective is to be able to change the behaviour of preinit without modifying the base system (i.e. so you can do drop-in packages for nfs root) Apr 14 15:47:48 Why can't we have a simple minimalistic preinit that would not touch the net (and not perform most of the other things), and extend it when needed? Apr 14 15:48:49 xl0: because it's harder to add functionality or for third parties to add functions. Also drop-in packages affect all builds instead of only users who want them Apr 14 15:48:56 I mean not using Apr 14 15:49:12 for example extroot is a package Apr 14 15:49:27 if you don't want extroot you don't have extroot code Apr 14 15:50:07 Can we also make indicate_preinit and the overlay stuff optional? Apr 14 15:50:09 xl0: also I'm working on some failsafe stuff that won't interest most users Apr 14 15:50:45 xl0: certainly....like I said override it Apr 14 15:51:19 No, can't we split it to a package and just not include it when not needed? Apr 14 15:51:46 xl0: well the overlay is kind of core....it's how 90% of systems work Apr 14 15:52:13 Yep, and all system inslude the busybox package. ;) Apr 14 15:52:25 *include Apr 14 15:52:36 *systems, damn Apr 14 15:53:22 xl0: and indicate_preinit needs to have preinit_echo functions else it's not much use, which means that the core system needs to be able to use preinit_echo Apr 14 15:53:28 preinit_net_echo? Apr 14 15:53:30 don't remember Apr 14 15:53:42 anyway: like I said you can override it Apr 14 15:53:51 so it's like it's not there Apr 14 15:54:47 Well, not everyone needs them. ;) Apr 14 15:54:57 ie. 10_some_preint_file defines function do_some_essential_thing and 15_override_preinit_file do_some_essential_thing { :; } which comments it out Apr 14 15:55:44 xl0: it was in the previous preinit, so I presume someone wanted it enough to make it part of preinit to being with Apr 14 15:56:00 xl0: I just made it possible to override Apr 14 15:56:22 xl0: and added the possibility of more messages for debugging Apr 14 15:56:24 I see why people want it, jest not everyone. Why override, whe you can just not imclude it? Apr 14 15:56:46 xl0: because there is no easy way to just not include it Apr 14 15:57:12 cshore: Ok, that's a good point. ;) Apr 14 15:58:21 Thank you for the pointers, I'll look at them later. Apr 14 15:58:38 xl0: ok....if you have questions, feel free to ask Apr 14 16:29:48 updated openwrt/upstream, http://home.comcast.net/~sdwalker/uscan/uscan.shtml Apr 14 16:36:06 nbd: I complained about vlan "issues" on the mailing list, but there is another thing yet Apr 14 16:36:58 example: configuring 2 vlans, VLAN 0 - "0 1 4" (4 is the CPU), VLAN 1 - "2 3" Apr 14 16:37:39 I get different virtual switch on 0-1 and 2-3, but while I would hope to connect to 0-1 with eth0.0, it only works with eth0 Apr 14 16:38:10 the eth0.x notation only kicks in when I have more than one VLAN connected to port 4 Apr 14 16:38:14 avoid vlan 0 Apr 14 16:38:18 try vlan 1, vlan 2, ... Apr 14 16:38:21 don't use eth0 at all Apr 14 16:38:24 only use eth0.* interfaces Apr 14 16:38:49 I think it's the same with vlan 1 and 2 Apr 14 16:39:08 this issue doesn't limit functionality, because anyway I only have one vlan connected to the CPU Apr 14 16:39:17 but it's not a consistent notation Apr 14 16:39:29 port 4 should be marked with 't' Apr 14 16:39:33 in the right vlan Apr 14 16:42:07 nbd: looks that was the problem Apr 14 16:42:26 (using VLAN 0) Apr 14 17:04:29 nbd: the issue I reported in the mailing list, now also tested without vlan0, is that the "LAN" vlan must have the "*" and not "t" Apr 14 17:04:30 http://pastebin.com/yJ7TJyqU Apr 14 17:04:37 this config don't work Apr 14 17:04:56 you can see that there are no packets flowing from eth0.1 or eth0.2 Apr 14 17:32:44 nbd: would it be true if firstboot has run, and say someone typed firstboot again it would blow away /etc ? Apr 14 17:34:04 yes Apr 14 17:34:09 yikes Apr 14 17:34:29 is there a reason we dont say remove firstboot after its done its work Apr 14 17:34:52 OutBackDingo: it allows to revert to factory defaults Apr 14 17:35:07 since i just accidently typed firstboot on a radio 180 feet of the ground :( Apr 14 17:35:09 (factory being OpenWRT flashing) Apr 14 17:35:47 so0000000 i guess im climbing the tower huh! Apr 14 17:36:25 OutBackDingo: yep...if you don't have access to copy files back to it before rebooting, you're SOL Apr 14 17:37:05 F&%$ me Apr 14 17:37:06 i think we should remove firstboot and replace it with something that asks for confirmation, then nukes rootfs_data Apr 14 17:37:24 nbd: well right now id 100% agree with that Apr 14 17:37:35 nbd: that's a good idea....it should be able to be controlled by LuCI automatically though Apr 14 17:37:48 we do mtd -r erase rootfs_data Apr 14 17:37:50 luci could just call the mtd erase command by itself Apr 14 17:37:58 it does not need to access firstboot as a command Apr 14 17:38:07 and I always tell users that command Apr 14 17:38:09 the only reason we'd still keep the command around is for users that use the command line Apr 14 17:38:19 nbd: ok Apr 14 17:38:20 it does not sound as harmless as "fisrtboot" ;) Apr 14 17:38:58 nbd: is firstboot a shell script? Apr 14 17:39:05 yes Apr 14 17:39:29 hrmmmm Apr 14 17:40:04 can i rebuild /etc from a remote radio via scp -r ip:/etc / Apr 14 17:40:09 letes see Apr 14 17:40:49 OutBackDingo: it might work Apr 14 17:41:41 well if it doesnt im up the tower..... Apr 14 17:42:08 I hope you're better with heights than I am Apr 14 17:42:32 xMff: doesnt sound as harmless as even chmod 400 firstboot :) Apr 14 17:43:29 cshore: heaights... 180 feet ? no worries mate im good too about 350 with climbing gear on Apr 14 17:53:31 xMff: so after firstboot is run, does the unit reset itself ? Apr 14 17:53:54 hrmm wrong question, need to dig deeper, what calls firstboot Apr 14 17:55:10 nevermind found it Apr 14 17:55:58 OutBackDingo: the answer is no Apr 14 17:56:09 cshore: yeah i see it Apr 14 18:27:04 build #65 of ppc40x is complete: Failure [failed compile_4] Build details are at http://tksite.gotdns.org:8010/builders/ppc40x/builds/65 Apr 14 20:39:34 cshore: ping Apr 14 20:47:34 luci looks great :) Apr 14 21:01:40 rtz: pong Apr 14 21:01:58 ping xMff Apr 14 21:02:51 pong cshore Apr 14 21:03:42 xMff: how about making the uhttp: tv.timeout = 10 change? Apr 14 21:03:51 it seems to be problem for a few people Apr 14 21:04:15 cshore: yeah Apr 14 21:04:31 cshore: will commit it along with a few other changes Apr 14 21:04:42 awesome Apr 14 21:04:54 later that is Apr 14 21:05:08 need to solve some symlink issues too Apr 14 21:05:11 well it's not a rush...can't build right away anyway Apr 14 21:05:13 ah Apr 14 21:05:19 you mean like /etc/hosts? Apr 14 21:05:25 no Apr 14 21:06:03 sysmlinks that are below /www but point outside are forbidden because they're not within /www after normalizing with realpath() Apr 14 21:06:15 ah, I see Apr 14 21:06:29 this breaks various tools that put stuff in /tmp and symlink that to /www Apr 14 21:06:34 cshore: regarding the crc fixup stuff Apr 14 21:06:38 rtz2: yes? Apr 14 21:07:01 cshore: I notices a serious problem with the current concept Apr 14 21:07:10 cshore: basically sysupgrade will not work Apr 14 21:07:28 rtz2: ah, yes, I saw you talking to nbd about that Apr 14 21:07:45 cshore: because the jffs2 markers will get overwritten before the fixup gets called Apr 14 21:08:17 cshore: I reworked the current system and generally cleaned up mtd Apr 14 21:08:30 rtz2: cool Apr 14 21:08:35 cshore: and made it easier to add new fixups Apr 14 21:08:46 rtz: good, I'll need that Apr 14 21:08:47 cshore: I can give you a patch, but it's nearly untested Apr 14 21:09:03 rtz2: I won't be able to test until at least the weekend Apr 14 21:09:37 rtz2: and I might have visitors then (family) Apr 14 21:09:41 cshore: no problem Apr 14 21:10:00 rtz2: but if you want to fire it over, then I'll see if I have unexpected time Apr 14 21:10:10 You know my email, right? Apr 14 21:10:50 rtz2: I need peons Apr 14 21:11:11 cshore: yes Apr 14 21:11:17 cshore: peons? Apr 14 21:11:46 rtz2: serfs Apr 14 21:12:32 rtz2: peasants who server my every whim (or at least work on things I want them to) Apr 14 21:12:52 *serve Apr 14 21:13:39 cshore: who doesn't? Apr 14 21:13:47 rtz2: :) Apr 14 21:14:01 nico * r20855 /trunk/target/linux/adm5120/image/Makefile: target/adm5120: fix image building after r20834 Apr 14 21:20:09 cshore: ok, I did send it to you Apr 14 21:20:22 cshore: I may have an update before the weekend Apr 14 21:20:42 ok, feel free to send it if you do Apr 14 21:36:59 hey is anyone else not getting a default route with current trunk? (for WAN using DHCP?) Apr 14 21:37:29 I get an address, but the default route isn't set Apr 14 21:42:40 is a gateway set on the iface? Apr 14 21:42:46 in uci I mean Apr 14 21:42:54 I didn't change anything Apr 14 21:43:33 xMff: but no it's not...hmmm....that should be there by default, shouldn't it? Apr 14 21:45:41 xMff: lan doesn't contain option 'gateway' '' or option 'dns' '' that used to be there by default...could that be the problem? Apr 14 21:45:52 no problem Apr 14 21:46:15 xMff: I think it's udhcpcd Apr 14 21:46:24 add a set -x in /usr/share/udhcpc/default.script and see why it does not set a defgw Apr 14 21:50:39 xMff: I think the ralink soc versions of the dir-600/615 probably shouldn't be in the unsupportable section but in the possible, but not being worked on category (as it seems that the ralink platform will eventually be supported) - ok to move them there? Apr 14 21:50:49 in the toh Apr 14 21:50:54 yes Apr 14 21:52:04 xMff: http://openwrt.pastebin.com/gdmzLzmj Apr 14 21:52:32 xMff: that everything for gateway Apr 14 21:53:12 apparently there already was a gateway in the state vars, therfore it is not set again because it is still the same Apr 14 21:53:34 hmmm....there shouldn't be because there isn't one Apr 14 21:53:46 or rather it never sucessfully set one Apr 14 21:53:57 uci -P /var/state show network.wan Apr 14 21:55:20 http://openwrt.pastebin.com/h6pRrjvh Apr 14 21:55:31 there is a a lease_gateway Apr 14 21:55:51 uci -P /var/state revert network.wan and try again Apr 14 21:56:03 xMff: just a minor bug: when editing a section which is more then once in the page, it always jumps to the first on save/cancel - to reproduce, just edit http://wiki.openwrt.org/toh/start#d-link3 and click on cancel Apr 14 21:56:33 a bit annoying, but nothing serious Apr 14 21:56:45 KanjiMonster: hmm, I cannot do much about that without hacking the wiki code which I tried to avoid until now Apr 14 21:57:09 because it becomes unmaintainable then (no way to update) and we all know how secure the typicall php application is .... Apr 14 21:58:11 xMff: that worked....apparently /etc/network restart is broken Apr 14 21:58:16 probably best to send a patch upsteam, and fix it in the wiki through updating with the version containing the fix Apr 14 21:58:32 I mean /etc/inti.d/network Apr 14 21:58:55 cshore: I added reverting of iface state in ifup a while ago, apparently the init script needs the same Apr 14 21:59:03 ... fix Apr 14 22:00:09 xMff: ok Apr 14 22:00:44 xMff: also Marc says LuCI sysupgrade stlil doesn't work with uhttpd. He hasn't tried lucid though Apr 14 22:01:28 cshore: was unable to reproduce here, the issue he reports sounds strange, as if the sysupgrade scripts itself are broken, I suspect merge conflicts or something Apr 14 22:01:42 xMff: I'll let him know Apr 14 22:01:48 he already knows that Apr 14 22:02:09 hadn't time to examine the image he sent yet Apr 14 22:02:27 ok, I haven't had a chance to test yet myself Apr 14 22:02:28 ah nice, the tl-wr1043nd is twice in the toh, once as supported, once as wip - I'll remove the wip one Apr 14 22:04:49 hmmm...flash firmware is essentials dies with an error Apr 14 22:05:44 cshore: this is strange, I flashed the gw6000 five times in a row here, always worked Apr 14 22:05:53 I used the backfire release image Apr 14 22:05:59 http://openwrt.pastebin.com/9eir3LXc (trunk) Apr 14 22:06:27 I don't see Marc's error because I don't get that far Apr 14 22:06:27 never seen that one Apr 14 22:06:43 but I think his is a tv.timeout error Apr 14 22:07:17 don't fully understand that one yet anyway Apr 14 22:07:25 it only kicks in if something is actually sent Apr 14 22:07:47 at least it is supposed to Apr 14 22:21:18 nbd * r20856 /trunk/ (include/depends.mk scripts/timestamp.pl): fix timestamp checks for build system paths which have '.svn' in their directory name Apr 14 22:23:23 nbd * r20857 /branches/backfire/ (include/depends.mk scripts/timestamp.pl): [backfire] backport timestamp check fixes from r20856 Apr 14 22:27:14 xMff: /usr/lib/lua/luci/model/cbi/admin_system is empty. Shouldn't it have upgrade (since admin_system is trying to be called)? Apr 14 22:27:20 admin_system/upgrade Apr 14 22:27:22 I mena Apr 14 22:27:25 mean Apr 14 22:28:11 yeah it should not be empty Apr 14 22:28:56 upgrade is in /usr/lib/lua/luci/view/admin_system/upgrade.htm Apr 14 22:29:44 it is also empty Apr 14 22:29:53 this is unusual Apr 14 22:34:10 it looks like the subdirs are all empty Apr 14 22:34:16 not just admin_system Apr 14 22:35:15 they didn't get copied from the source directory Apr 14 22:35:46 are there precompile files somewhere else? Apr 14 22:36:28 no Apr 14 22:38:28 where is the copying of those files done (Makefile?) Apr 14 22:39:13 build_dir/.../luci-.../build/module.mk Apr 14 22:43:45 They get copied to dist Apr 14 22:44:21 yes and then there's a generic target which packs dist into ipkg stuff Apr 14 22:44:39 I mean dist has the files Apr 14 22:44:48 ah, k Apr 14 22:46:28 xMff: lua strip makes my eyes bleed Apr 14 22:46:45 don't like perl? ;) Apr 14 22:48:03 where the target that packs them into ipkg? Apr 14 22:49:06 nvm they're in the ipkg-brcm63xx dir Apr 14 22:49:16 they're not making it onto the system though Apr 14 22:52:52 nbd * r20858 /trunk/package/openssl/patches/190-remove_timestamp_check.patch: openssl: remove the makefile timestamp check, it breaks on some host systems Apr 14 22:53:31 cshore: very weird Apr 14 22:53:46 nvm. I was looking at the wrong thing Apr 14 22:54:30 there are files in usr/lib/lua/luci/model/cbi, but not in subdirs thereof Apr 14 22:54:40 there are not subdirs in the ipkg file Apr 14 22:54:49 dir I mean Apr 14 22:55:44 well the path I typed isn't quite right, there a mini in there Apr 14 22:56:07 nbd * r20859 /trunk/package/openssl/patches/190-remove_timestamp_check.patch: openssl: fix timestamp patch - previous version patched the wrong file Apr 14 22:56:13 usr/lib/lua/luci/view/mini has some *.htm files Apr 14 22:56:20 no subdirs Apr 14 22:58:00 have the dirs changed? Apr 14 23:01:17 not really Apr 14 23:02:31 there are no model/cbi/admin_xxx subdirs in dist Apr 14 23:04:19 nor in the source....where do they come from? Apr 14 23:06:04 hmmm..../usr/lib/lua/luci/model/cbi/mini has the files I'm looking for....it looks like there is something going on with the dirs Apr 14 23:06:44 well admin_* stuff comes from admin_full Apr 14 23:07:02 maybe the feature selection is inconstistent Apr 14 23:11:44 hmmm...ok, there is an error in mini then....it refers to the admin upgrade Apr 14 23:12:27 or maybe the wrong system.lua is included in the image....let me check Apr 14 23:14:30 this should not happen Apr 14 23:14:35 nope...controller/mini/system.lua has an error....let me see if I fix it on the router Apr 14 23:14:47 syntax error? Apr 14 23:15:04 no it calls admin_system/upgrade Apr 14 23:15:14 ah Apr 14 23:15:20 copy and paste error maybe Apr 14 23:15:25 probably Apr 14 23:15:29 easy to do Apr 14 23:17:22 there's also extraneous admin dirs all over the place Apr 14 23:17:28 that confused the issue Apr 14 23:17:35 full I mean Apr 14 23:17:49 yes, this happened when Cyrus switched to git ... Apr 14 23:18:02 does not clean up empty diras Apr 14 23:18:04 *dirs Apr 14 23:19:26 well, that fixed it....I'll apply it to the source and commit, if you don't mind Apr 14 23:20:29 yes, please Apr 14 23:21:46 I notice there are no messages in the message box Apr 14 23:22:09 but the flashing happened and I see on the serial it was successful Apr 14 23:22:10 mirko * r20860 /packages/ipv6/aiccu/files/aiccu.init: ensure it's started before ratvd Apr 14 23:22:49 but i have tv.timeout=10 and I increased the uhttpd timeout so I could use the network scan I did a while ago Apr 14 23:23:19 I'm pretty sure Marc's problem is a timeout issue Apr 14 23:25:31 he got a cgi timeout Apr 14 23:25:35 that is different Apr 14 23:26:13 I think the 60s timeout in uhttpd is what got him Apr 14 23:26:26 yes Apr 14 23:26:50 nico * r20861 /trunk/package/ipset/Makefile: package/ipset: update to 4.2 Apr 14 23:26:53 however that timeout is cleared as soon as the initial chunk of data is read from the cgi script Apr 14 23:27:23 well there are no messages appearing in the message box, so perhaps the messages aren't being seen from the CGI Apr 14 23:27:26 if he got the 60 second timeout triggered, that means that luci took mor than 60 seconds to even start sysupgrade Apr 14 23:27:39 nico * r20862 /trunk/package/iptables/ (Makefile patches/008-netfilter_include_linux_type_h.patch): package/iptables: update to 1.4.7 Apr 14 23:27:40 Yep, I see it now too Apr 14 23:27:45 weird Apr 14 23:27:46 I set the timeout to 60s Apr 14 23:28:18 you use admin mini? Apr 14 23:28:22 or rather I reverted to default Apr 14 23:28:28 this was for testing something Apr 14 23:28:49 we'll be using it for our application Apr 14 23:28:58 for the poor dumb end-user Apr 14 23:29:35 so yu see the cgi timeout? Apr 14 23:29:41 yes Apr 14 23:29:47 in admin mini? Apr 14 23:30:55 but sysupgrade is happening because the serial console is in the limited ramdisk that luci-flash uses Apr 14 23:31:07 yes Apr 14 23:31:11 strings /usr/lib/lua/luci/controller/mini/system.lua | grep 'Starting luci-flash' Apr 14 23:31:20 https://dev.openwrt.org/changeset/20860 <- doesn't increasing the start to 51 do exactly the opposite? (radvd has 50) Apr 14 23:31:28 is this message there? Apr 14 23:32:08 yes Apr 14 23:32:22 this should clear the timeout Apr 14 23:32:36 the message never appears Apr 14 23:32:40 I see Apr 14 23:32:59 there are *no* messages until the CGI timeout Apr 14 23:33:10 I think I have an idea wh Apr 14 23:33:12 y Apr 14 23:33:14 or when I had a longer timeout, no messages, just reboot Apr 14 23:33:18 why's that? Apr 14 23:33:31 buffered stdout Apr 14 23:34:02 makes sense....when/why is it buffered, and is that new? Apr 14 23:34:56 hm no Apr 14 23:36:03 xMff: obviously something has, and buffering acting differently would make sense Apr 14 23:36:39 http://paste.tksite.gotdns.org/d505ecbd5 Apr 14 23:36:40 what about threading? Apr 14 23:37:08 ok, I'll try that Apr 14 23:37:55 hmmm....it hasn't finished yet and I have no ps atm Apr 14 23:38:01 nico * r20863 /branches/backfire/ (4 files in 4 dirs): [backfire] backport r20831 Apr 14 23:38:18 but I also trapped SIGTERM, SIGPIPE, SIGCHLD in luci-flash Apr 14 23:38:28 it should survive Apr 14 23:39:15 what should survive? the process? I'm just wondering why it's taking so long....this is abnormal Apr 14 23:40:56 /bin/busybox ps should work in the ramdisk btw Apr 14 23:41:40 doh! yeah that worked Apr 14 23:41:58 the flashing had finished, but the system hadn't rebooted Apr 14 23:46:35 well the Staring luci-flash message appears now Apr 14 23:46:50 without the change? Apr 14 23:47:06 no with io.flush() Apr 14 23:47:10 k Apr 14 23:47:17 but no further messages? Apr 14 23:47:19 no other messages though Apr 14 23:47:22 right Apr 14 23:47:24 weird Apr 14 23:47:39 but it is running? Apr 14 23:47:51 nico * r20864 /trunk/target/linux/ (9 files in 9 dirs): [cleanup] remove empty directories (again) Apr 14 23:47:54 yep, it's rebooting now Apr 14 23:48:07 (I see it on serial) Apr 14 23:49:55 yep, that worked Apr 14 23:51:02 maybe lua's changed something? Apr 14 23:51:12 now I am curious why it does not show the luci-flash messages Apr 14 23:54:42 maybe the pump needs to do a flush after each luci.http.write Apr 14 23:54:52 be back in a bit...having supper Apr 14 23:55:04 that would be a bit extreme Apr 15 00:07:55 back Apr 15 00:09:02 xMff: or figure out why it's buffering Apr 15 00:09:34 did you execute the flash procedure via https ? Apr 15 00:09:46 no, http Apr 15 00:09:49 k Apr 15 00:10:15 don't have ssl in luci/uhttpd on this image Apr 15 00:16:11 committed the mini flash using admin-full fix Apr 15 00:21:45 mirko: https://dev.openwrt.org/changeset/20860 was the opposite of what you inteded Apr 15 00:25:41 cshore: http://paste.tksite.gotdns.org/d29b36790 Apr 15 00:26:04