Debian/OMV on NAS540 gone wrong?

ombre33
ombre33 Posts: 11  Freshman Member
edited December 2018 in Personal Cloud Storage
Hi forum,

recently I tried to get OMV and therefore also Debian on the NAS540 according to this tutorial. Something must have went wrong, however, because now the NAS is just stuck in a approx. 30 second boot loop, no matter whether there is a usb drive, sd-card or nothing attached.

I can only assume that the boot loader got a knock over the head it didn't particularly care for? Any chance to revive the box?

Thank you for any tips.

#NAS_Nov_2018
«1

Comments

  • Mijzelf
    Mijzelf Posts: 2,137
    100 Answers 1000 Comments Friend Collector Fifth Anniversary
     Guru Member
    Did you flash the kernel? Do you have serial access?
  • ombre33
    ombre33 Posts: 11  Freshman Member
    Hi Mijzelf,

    I was hoping this would catch your attention; still remember you from zyxel-forum.de, which apparently, while I wasn't looking, went the way of the dodo. Shame though.

    Yes, I did flash the kernel. In hindsight, I don't really think that was necessary, but it was part of the tutorial.. Silly, I know.

    I still have the console log from when I did it. Long story very short: Resized the thumb drive, flashed the kernel, reboot, now stuck in reboot loop.

    No, currently don't have serial access to the box, but I'm sure I can utilize one of my Raspberries to get there.

    Thanks,

    ombre

  • Mijzelf
    Mijzelf Posts: 2,137
    100 Answers 1000 Comments Friend Collector Fifth Anniversary
     Guru Member
    Well, I don't think much can be done before you have serial access. It can tell why the box is rebooting (kernel panic, probably). Before that it's shooting in the dark.
  • ombre33
    ombre33 Posts: 11  Freshman Member
    Establishing the serial connection stopped the reboot cycling, but the output to console looks rather odd..
  • Mijzelf
    Mijzelf Posts: 2,137
    100 Answers 1000 Comments Friend Collector Fifth Anniversary
     Guru Member
    Wrong baudrate?
  • ombre33
    ombre33 Posts: 11  Freshman Member
    edited December 2018
    Nope. Apparently I was mostly struggling with the fact that the boards pin-out is | --- | TX | RX |     | GND |, which not also kinda feels backwards, but also contradicts the sparse information that can be found online.

    First run was without interrupting, then reboot, then stopping autoboot by pressing the any-key. Glanced over it, but don't really know what to do with "ERROR: out of memory".

    What do you think? Any chance to revive?
  • Mijzelf
    Mijzelf Posts: 2,137
    100 Answers 1000 Comments Friend Collector Fifth Anniversary
     Guru Member
    What do you think? Any chance to revive?

    The bootloader is still working, so yes. Unfortunately I have no experience with bootbox. I think the easiest way to get the box running again is to upload a stock kernel+rootfs over tftp, and boot that. Then you can flash stock firmware using the webinterface, and it should work again.

    Unless the bootscript is changed in a way it can't boot the stock kernel anymore, in that case it will be more challenging.

    Do you know which firmware was on it?

  • ombre33
    ombre33 Posts: 11  Freshman Member
    Yeah, the latest one. So that should be V5.21(AATB.1)C0..
  • Mijzelf
    Mijzelf Posts: 2,137
    100 Answers 1000 Comments Friend Collector Fifth Anniversary
     Guru Member
    edited January 2019
    OK, I've put the uImage here. On u-boot the command would be something like this:
    <div>set ipaddress <ip1></div><div><br></div><div>set tftpserver <ip2></div><div><br></div><div>tftp uImage <some-address></div><div><br></div><div>mboot <some-address></div>
    This sets the environment variabeles ipaddress and tftpserver (maybe not their real names, can be shown with printenv), and downloads the file uImage from the tftp server to memory address <some-address>. Again, look at the environment to see a suitable address.
    And finally boot the module on <some-address>
    Don't know what is should be on bootbox. Try help.

  • Hi, I think I got the same issue on NAS542 (should be basically similar to NAS540) and finally resolved it... In case someone else experiences the same problem:

    After the barebox autoboot got aborted and you are in the console, you can cd into /env/bin and execute b1:

    Barebox-C2K >/ cd env
    Barebox-C2K >/env cd bin
    Barebox-C2K >/env/bin b1

    Afterwards it should boot the Zyxel Firmware. To repair autoboot, you can SSH to the NAS after boot (and enabling SSH service), su and execute /firmware/sbin/info_setenv next_bootfrom 1

    ~ $ su
    ~ # /firmware/sbin/info_setenv next_bootfrom 1
    Erasing 64 Kibyte @ 30000 -- 100 % complete

    No warranty, but for me it worked and everything seems to be Ok again...

    Regards

Consumer Product Help Center