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 <moell...@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.moel...@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@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@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 <moell...@gmx.de> wrote:
>>
>>> Hi Richard,
>>>
>>>
>>> On Nov 12, 2013, at 18:26 , Richard E. Brown <richb.hano...@gmail.com>
>>> wrote:
>>>
>>>>> On Nov 12, 2013, at 4:11 AM, Sebastian Moeller <moell...@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@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
>>
>
_______________________________________________
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel
