[Cerowrt-devel] CeroWrt 3.10.18-1 Field Report
Sebastian Moeller
moeller0 at gmx.de
Fri Nov 15 07:35:58 EST 2013
Hi All,
small update, I have a hunch that comment 3 of https://dev.openwrt.org/ticket/13958
might be relevant for us:
> additional 2cents: turns out i had mount-utils installed, whose /usr/bin/mount had different output than the busybox one. this broke the function rootfs_type() in /lib/upgrade/common.sh, causing the sysupgrade script to switch something unswitchable...
indeed we have a binary in /usr/bin/mount and:
export PATH=/usr/bin:/usr/sbin:/bin:/sbin
in /etc/profile
So, it might be enough to replace the following in /lib/upgrade/commons.sh
rootfs_type() {
mount | awk '($3 ~ /^\/$/) && ($5 !~ /rootfs/) { print $5 }'
}
with
rootfs_type() {
busy box mount | awk '($3 ~ /^\/$/) && ($5 !~ /rootfs/) { print $5 }'
}
to get sys upgrade to work again.
But I have not tested that (and most likely will not be able to do so before next week); yet I wanted to document this potential fix for the greater public...
Best Regards
Sebastian
On Nov 13, 2013, at 00:11 , Sebastian Moeller <moeller0 at gmx.de> wrote:
> Hi All,
>
> it turns out that not being able/willing to read can make you do busy work. It seems I forgot to add "firmware" as device to my mtd invocation… I guess I would never have tried the GUI if I had gotten the mtd command right the first time :)
>
>
> best
> Sebastian
>
>
> On Nov 13, 2013, at 00:06 , Sebastian Moeller <sebastian.moeller at gmail.com> wrote:
>
>> Hi Richard, hi Dave, hi list,
>>
>> so I could not resist the lure of 3.10.18-1 and upgraded my 3.10.11-2.; which turned out to be slightly more involved than I had expected.
>>
>> 1) SYSUPGRADE
>> root at nacktmulle:/# sysupgrade -d 60 -n /home/persistent/cerowrts/3.10.18-1/openwrt-ar71xx-generic-wndr3700v2-squashfs-sysupgrade.bin
>>
>> killall: watchdog: no process killed
>> Sending TERM to remaining processes ... netifd dynamic_dns_upd sleep minissdpd lighttpd crond lighttpd pimd snmpd xinetd dbus-daemon dnsmasq zebra babeld watchquagga smbd nmbd avahi-daemon ahcpd rngd ntpd ubusd askfirst
>> Sending KILL to remaining processes ... ubusd askfirst
>> Switching to ramdisk...
>> mount: /proc is not a block device
>> umount: /tmp/root: not mounted
>> Failed to switch over to ramfs. Please reboot.
>>
>> Rebooting still returned me back to 3.10.11-2
>>
>> 2) MTD
>> root at nacktmulle:/tmp# mtd -r write /tmp/firmware.img
>> Usage: mtd [<options> ...] <command> [<arguments> ...] <device>[:<device>...]
>>
>> The device is in the format of mtdX (eg: mtd4) or its label.
>> mtd recognizes these commands:
>> unlock unlock the device
>> refresh refresh mtd partition
>> erase erase all data on device
>> write <imagefile>|- write <imagefile> (use - for stdin) to device
>> jffs2write <file> append <file> to the jffs2 partition on the device
>> fixtrx fix the checksum in a trx header on first boot
>> Following options are available:
>> -q quiet mode (once: no [w] on writing,
>> twice: no status messages)
>> -n write without first erasing the blocks
>> -r reboot after successful command
>> -f force write without trx checks
>> -e <device> erase <device> before executing the command
>> -d <name> directory for jffs2write, defaults to "tmp"
>> -j <name> integrate <file> into jffs2 data when writing an image
>> -p write beginning at partition offset
>> -o offset offset of the image header in the partition(for fixtrx)
>> -F <part>[:<size>[:<entrypoint>]][,<part>...]
>> alter the fis partition table to create new partitions replacing
>> the partitions provided as argument to the write command
>> (only valid together with the write command)
>>
>> Example: To write linux.trx to mtd4 labeled as linux and reboot afterwards
>> mtd -r write linux.trx linux
>>
>> Still no upgrade performed, but at least it is clearer why, my command was incomplete… BUT I seem to recall that it was exactly this command that actually allowed me to install 3.10.11-2 in the first place, weird.
>>
>> 3) LUCI (http://gw.home.lan:81/cgi-bin/luci/;stok=19113c7f25269daca52ed92ef4d4b802/admin/system/flashops/)
>> I disabled the Keep Settings checkbox, uploaded the image (after making sure /tmp had enough space) followed the "flash image…" link e voila, 3.10.18-1 up and running in no time
>>
>> I have no idea what the GUI actually does differently from calling sysupgrade on the command line.
>>
>>
>> So the upshot is Juergen Botz is right and the GUI seems to work, at least if one does not keep the old configuration. (And for that problem I followed caves advice and just saved /overlay before upgrading, so I could see the old configuration files and compare.)
>>
>> Since I am using cerowrt as secondary router I have no input on the PPPoE issues….
>>
>> best
>> Sebastian
>>
>>
>>
>>
>> On Nov 12, 2013, at 22:17 , Sebastian Moeller <moeller0 at gmx.de> wrote:
>>
>>> Hi Richard,
>>>
>>>
>>> On Nov 12, 2013, at 18:26 , Richard E. Brown <richb.hanover at gmail.com> wrote:
>>>
>>>>> On Nov 12, 2013, at 4:11 AM, Sebastian Moeller <moeller0 at gmx.de> wrote:
>>>>>
>>>>>>> - Had to enable and set AQM parameters, since they’re saved differently from the QoS settings in the 3.7.5-2 firmware. Set parameters to ~ 90% of link speeds
>>>>>>
>>>>>> Just curious, did you specify overhead and encapsulation?
>>>>
>>>> No, I simply used the defaults on that page.
>>>
>>> Ah, you might want to try setting the link layer adaptation mechanism to tc_stab, the link layer to adls or atm and the overhead to 40 (or look at http://ace-host.stuart.id.au/russell/files/tc/tc-atm/ to figure out the fixed per packet overhead of your link). This should allow you to specify a larger percentage of your link rate as shaped rate… But see the attached screenshot of my AQM tab
>>>
>>>
>>> <PastedGraphic-1.tiff>
>>>
>>>>
>>>>>>> - The kernel.log shows lots of the stack traces below: 2-5 per second on a long-term basis.
>>>>>>
>>>>>> These look quite weird, the error is a slow patch warning from hfsc_schedule_watchdog . But, hfsc is the queuing discipline used by stock OpenWrt, cerowrt , so far, has only used HTB (last I checked was cerowrt 3.10.11-3). So my guess is that you were running the default QOS system instead (or worse in addition) to cerowrt's. It would be great to see the output of:
>>>>>> tc -d qdisc ; tc -s class show dev ifb0 ; tc -s class show dev ge00
>>>>>> to check what is up with the AQM system...
>>>>>>
>>>>>> Did you by any change use the QOS tab in 3.7.5-2 instead of running AQM or simple_qos.sh from rc.local/ifup? If so did you direct sys upgrade to keep the old configuration files?
>>>>
>>>> Yes, I was using QoS in 3.7.5-2, and I kept the old configuration files (so I didn’t have to re-enter credentials for my DSL link, etc.) I guess it seems likely that I may have been running *both* (!)
>>>
>>> Probably just QOS, as I think both QOS and AQM start out by tearing down all discs… but the hfsc error should not affect AQM since it uses HTB.
>>>
>>>>
>>>> Would a better upgrade path be to start with 3.7.5-2, then disable the QoS, then flash with 3.10.18-1? (My intuition tells me that this would remove the QoS settings from the loop…)
>>>
>>> Mhhh, I guess that should work.
>>>>
>>>> It’s pretty easy to re-flash with 3.10.18-1 and run the tc commands. If disabling QoS makes sense, then after I do the ’tc’ experiment, I’ll re-flash with 3.7.5-2, turn off QoS, then reflash to 3.10.18-1.
>>>
>>> This should not fix your PPPoE issues though… so maybe it is not the best time to switch…
>>>
>>>> But it’ll have to wait ’til dark so no one else is using it. :-)
>>>
>>> Hihi, same issue on my side :) No "playing" with the network while my wife is using it
>>>
>>> Best
>>> Sebastian
>>>
>>>
>>>>
>>>> Rich
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Cerowrt-devel mailing list
>>> Cerowrt-devel at lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>>
>> --
>> Sandra, Okko, Joris, & Sebastian Moeller
>> Telefon: +49 7071 96 49 783, +49 7071 96 49 784, +49 7071 96 49 785
>> GSM: +49-1577-190 31 41
>> GSM: +49-1517-00 70 355
>>
>> Moltkestrasse 6
>> 72072 Tuebingen
>> Deutschland
>>
>
More information about the Cerowrt-devel
mailing list