Joe,
I picked up another hAP AC lite.
I loaded 3.19.3.0.elf.
Tried to update via browser to aredn-3.19.3.0-mikrotik-rb-nor-flash-16M-ac-sysupgrade.bin.
File uploads and then gets error that firmware not valid. I know the file is good, I've used it on other devices.
I looked at the supportdata file.
Previous device: machine : MikroTik RouterBOARD 952Ui-5ac2nD
New device: machine : MikroTik RouterBOARD RB952Ui-5ac2nD
Is different signature a problem?
Thanks,
John K2QA
'MikroTik RouterBOARD 952Ui-5ac2nD' => {
'name' => 'MikroTik RouterBOARD 952Ui-5ac2nD',
'comment' => '',
'supported' => '1',
'maxpower' => '22',
'pwroffset' => '0',
'usechains' => 1,
'rfband' => '2400',
},
'MikroTik RouterBOARD RB952Ui-5ac2nD' => {
'name' => 'MikroTik RouterBOARD RB952Ui-5ac2nD',
'comment' => '',
'supported' => '1',
'maxpower' => '22',
'pwroffset' => '0',
'usechains' => 1,
'rfband' => '2400',
},
Around 212 seconds after bootup, there's not enough RAM for the kernal to function, thus the out-of-memory program is picking a high value process and killing it. Not obvious why it would be running out of memory, let me look at the data more. Meanwhile, try to do the sysupgrade quickly after bootup.
Joe,
Seems like each one of these I buy presents different issues.
One before this was "Bad Gateway" but was eventually successful with scp.
With this one, I've tried scp many times with no luck.
I've tried both aredn-3.19.3.0-mikrotik-vmlinux-initramfs.elf and aredn-1022-412a1e5-mikrotik-vmlinux-initramfs.elf.
A few seconds after scp completes, the box reboots back to RouterOS, so I can't run sysupgrade.
I have time to run one ps command and then get "Killed" while trying to type sysupgrade.
===
root@NOCALL:~# ps
===
At what point does it kill tasks?
I watched top with scp running. Available memory dropped to 8192K free.
Got back to 8476K when scp ended, then rebooted to RouterOS.
Are there processes I can kill before running scp? Since I'm using scp, can I kill uhttpd?
Thanks,
John
1) turn off cron so snr logging and other processes don't consume memory: "/etc/init.d/cron stop"
2) directly trying to kill uhttpd, would likely trigger procd to automatically restart, shutdown with "/etc/init.d/uhttp stop"
3) /tmp doesn't need all that RAM space, re-mount smaller: "mount tmpfs /tmp -o remount,size=10240K" or sufficient size with the new image to be loaded.
I'll review, to add code into the nightly build: check firstboot condition to automatically do some of these commands.
Joe AE6XE
Using 3.19.3.0 files.
I've tried another half dozen times after stopping uhttpd.
Most times I got 'fwtool_check_image' failed / Killed
====
Another time I thought it was going to work:
run scp in another window
...
It rebooted back to RouterOS.
I even tried stopping dropbear after scp completed to free up more memory.
If you think it is a memory issue, are there more processes I can kill / shut down?
Is there a log file I can tail in another window or other diagnostics?
Joe AE6XE
The out of memory (OOM) is triggered when the kernel has a need to allocate memory to function, which I think also includes starting up new processes. OOM ranks the current running processes to determine which one, if killed, would free up the most resources, and kills it. I've seen OLSR at the top of the list. But in first boot state, OLSR is not needed for anything--not making links to other mesh nodes yet.
Joe AE6XE
Not sure what is different, but I was able to load 3.19.3.0 via browser on first try using a different PC.
Both are Win10. Failing PC was high-end workstation Xeon laptop, successful one was a low-end Surface clone.
I can understand where the PC that worked using browser upgrade might have different browser configuration.
But don't see where different configs could affect the scp/sysupgrade scenario on failing workstation laptop.
In any case, until I buy another MikroTik, I don't have one to play with.
Thanks for your help.
John K2QA
Joe AE6XE
Thank you!
Greg
W9IKU
greg@w9iku.net
I get a "connection reset" nearly every time I try to upload the .bin file, I have also gotten the "Bad Gateway" message, even when just reloading the admin page and *not* uploading anything. I am not sure what it going on here. I used the exact same procedure to Flash an LHG-XP-HP5 the other day without a problem. (no, I am not mixing up the .bin files, almost tho, almost! :) ) I can get the Hap lite to boot from tftp no problem. The status page shows me this though: Could that have something to do with it? I also tried to scp the file to the device and got a "broken pipe", the scp connection failed midway... I am just not having any luck today. I just thought I would share in case MikroTik changed something.... I am giving up for tonight and will try some other ideas in the morning.
I don't want to have to solder a connection to this suckers serial port! :S
73
Joe AE6XE
Here you are sir.
*edit* this might be it?
<strike>init: Can't open /sys/block/zram0/disksize: No such file or directory</strike>
nah, probably not.
Is it this?
m25p80 spi0.0: found w25q128jv, expected m25p80
googling shows that w25q128jv chip to be supported by openWRT 18.06.2, I also see patch files for it, yet still no flash space...
I tried a couple of things myself, no luck.
I know you can figure this out Joe!!
So after trying various ideas, I finally gave up and dragged out the old windows laptop.
After mucking around in that for an hour or so, mostly fighting windows of course, I was able to flash the HaP lite to 3.19.2 without issue!
I was then able to easily update to the latest nightly builds.
I am not sure *why* this worked, when for 2 days I got nowhere, maybe we are missing a needed option to dnsmasq when trying to perform this procedure from Linux.
I still could not get a fresh install from the newer nightly builds though, I would get a "Connection Reset" error after the firmware uploaded and the node would just sit there, I could tell that it has at least started the firmware loading process, as the nodes SSH server was shutdown.
If I tried the upload again, I would either get a "Bad Gateway" error or the same "Connection Reset" and I am pretty sure it rebooted back to routerOS at one point during my attempts to load a nightly from scratch.
In the next month or so I will probably buy another HaP just so I can try it again and see if I can't figure out why this happens on some installs and not others...