NAS542 bootloop after Debian/OMV (get a new firmware) (solved)

Triu

Oh yes, then i was completely wrong. Thought i have to change a script.

"printenv" shows me like you said: "next_bootfrom=1" and "curr_bootfrom=2"

"setenv next_bootfrom 2" and "next_bootfrom 2" doesn*t work.

"setenv" is no command i have here, but i have found "saveenv"

I saw in one script next_bootfrom="1", so i tried these and it worked. (for next and curr)

After that i saved it with "saveenv" and then booted with "bootm uImage.521". Unfortunately with the same result. Complete output with all steps are attached.

Mijzelf

No setenv? I'm wondering what they were thinking.

Well, /etc/init.d/rcS the check for the ubi partition is after the check for the usb_key_func thumb. So if you plugin a 'Universal usb_key_func' usb stick, where you have enabled the 'telnet+set ip+stop' function (read the readme), you should be able to boot the uImage, then login over telnet, and use /firmware/sbin/info_setenv and .../info_printenv binaries to switch to the other ubi block.

Triu

Sry for the delay, i didn't had time the last days.

I formated the USB Stick with FAT32 and extracted universal_usb_key_func-2015-10-12.zip to it. I renamed the file usb_key_func.sh.network_telnet_stop to usb_key_func.sh.2

Then i changed the IP in that file to fit my network. I plugged it into the NAS and started it. Now i have no "Kernel panic" but also a reboot. Something has changed, but i don't understand the serial output. (attached)

Mijzelf

It seems I have pointed you in the wrong direction.

First, your USB thumb doesn't work because it's to slow in initializing. All /dev/sd* partitions are probed between the 'Mount system partition...' and 'ubiattach: error!', which is around 9.8 sec. But the thumb as blockdevice is added at 10.694. (The thumb itself much earlier, at  8.397). Unfortunately it's hard to predict how fast a thumb will initialize. It's not related to the r/w speed, which is generally the only spec'd parameter. In my experience the odds are better with a smaller thumb. Maybe the flash has to initialized, or something like that.

Having said that, the 'thumb trick' won't work anyway. When carefully comparing your bootlog to /etc/init.d/rcS, to find out why the thumb failed, I found that the line 'change boot image and reboot !!' is spawned by

&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; if [ "${CURR_BOOTFROM}" == "1" ]; then<br>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; ${INFO_SETENV} next_bootfrom 2<br>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; else<br>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; ${INFO_SETENV} next_bootfrom 1<br>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; fi<br><br>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; echo "change boot image and reboot !!"

So the firmware already switches the environment setting! But it doesn't work. When comparing your bootlog to this one , I found it doesn't list the flash partitions. So the environment can't be changed, as there is no entry.

The problem is the kernel command line, in which the flash partitions should be specified. That command line is now

console=ttyS0,115200n8, init=/etc/preinit pcie_gen1_only=yes  mac_addr=,, 

while it is

console=ttyS0,115200n8, init=/etc/preinit pcie_gen1_only=yes  mac_addr=,, ip=dhcp root=ubi0:rootfs ubi.mtd=2,2048 rootfstype=ubifs rw noinitrd mtdparts=spi0.0:256k(uloader)ro,512k(barebox)ro,256k(env);comcertonand:10M(config),10M(kernel1),110M(rootfs1),10M(kernel2),110M(rootfs2),-(reserved) usb3_internal_clk=yes 

on my 520. Here the 'mtdparts=' block specifies the flash partitions. So you should look in the scripts how the command line is set. I think that is 'bootargs="$bootargs mtdparts=..."', but the scripts you uploaded are not complete.
When the mtdparts is provided, I expect the firmware either to boot, or to switch partitions.

Triu

Will go through all scripts to search for the mtdparts stuff, but i am pretty shure i posted everything what was found under /env. Maybe there is something in /dev.

Mijzelf

I don't think you didn't upload them all, but they are truncated. Either by you, or by this stupid forum software.

Triu

I have made a misstake, the "_update" file i posted earlier is correct, but the "update" was wrong. The correct one is here:

#!/bin/sh

type=""
device_type=""
check=n
mode=tftp

. /env/config

while getopt "ht:d:f:a:s:m:c" Option
do
if [ ${Option} = t ]; then
        type=${OPTARG}
elif [ ${Option} = d ]; then
        device_type=${OPTARG}
elif [ ${Option} = f ]; then
        imagename=${OPTARG}
elif [ ${Option} = a ]; then
        address=${OPTARG}
elif [ ${Option} = s ]; then
        size=${OPTARG}
elif [ ${Option} = c ]; then
        check=y
elif [ ${Option} = m ]; then
        mode=${OPTARG}

But in this file is nothing with mtdpart.

Everything else in /env on my NAS is exactly as it is shown in this forum. (checked every file). There is also a /dev folder. Inside:

zero                 defaultenv           mem
phy0                 spi0                 env0
nand0                nand_oob0            self_raw
self0                spi0.uloader         spi0.barebox
spi0.env             nand0.config         nand0.kernel1
nand0.rootfs1        nand0.kernel2        nand0.rootfs2
nand0.reserved       nand0.reserved.bb    nand0.rootfs2.bb
nand0.kernel2.bb     nand0.rootfs1.bb     nand0.kernel1.bb
nand0.config.bb

I can't look inside these files, most of them give me an "out of memory" error.

What i don't understand, if i told him to boot from 1 and he can't do it becaus of checksum errors, then he is switching to the second one, now everything should work as before if i give him the SD card back. I have found an image of my SD card which should be the one who worked. But there is no difference between them. (attached the two logs, with and without SD card)

Mijzelf

I can't look inside these files, most of them give me an "out of memory" error.

As barebox reuses Linux device drivers, I guess these files are device nodes, just as in Linux. So no real files, but 'pointers' to raw flash and things like that.

What i don't understand, if i told him to boot from 1 and he can't do it becaus of checksum errors, then he is switching to the second one, now everything should work as before

AFAIK only the initramfs in the ZyXEL kernel does so. And that couldn't switch because the flash layout isn't specified in the kernel command line.

Your bootlogs do not show the SD card, and so it can't boot from it. The kernel command line specifies root=ubi0:rootfs. So it won't boot from it anyway. Don't know if some more time would be granted to the SD card to appear if the right rootfs was specified.

Anyway, this bootlog shows the flash partitions in the command line:

Starting kernel ...

commandline: console=ttyS0,115200n8, init=/etc/preinit pcie_gen1_only=yes  mac_addr=,, ip=dhcp root=ubi0:rootfs ubi.mtd=2,2048 rootfstype=ubifs rw noinitrd mtdparts=spi0.0:256k(uloader)ro,512k(barebox)ro,256k(env);comcertonand:10M(config),10M(kernel1),110M(rootfs1),10M(kernel2),110M(rootfs2),-(reserved) usb3_internal_clk=yes

As the bootlog of your tftp loaded kernel didn't show this, the script starting the Debian kernel definitely adds it. The files you uploaded are all short, and don't end in a logical way. For instance the last 'update' you uploaded contains

<p>while getopt "ht:d:f:a:s:m:c" Option<br>do</p>

but the closing 'done' or 'loop' is not there. I think you somehow have to scroll

Triu

I worked with a big serial monitor, so i really saw the complete output. Attached are some screenshots.

This drives me crazy, i don't understand all this kernel stuff. I wish it could be as easy as flashing the debian kernel to it. (i mean having a Zyxel kernel, connect to tftp and flash it straight to .......whatever it is called, the chip on the board)

Mijzelf

I worked with a big serial monitor, so i really saw the complete output.

Nope. Depends on the tool you use to show the content. If that is 'cat', the output should scroll down to the end of the file. If that is a tool like 'more', 'less' or 'vi', it will show as many lines as the system thinks the terminal has. Your screenshots all have 25 lines, which happens to be the default number of lines for a terminal.
On Linux you can overrule that by executing

LINES=40 less /path/to/file

but I don't know if barebox supports environment settings this way.

This drives me crazy

Can imagine that. And all because ZyXEL removed the setenv function.