NAS542 stuck in a boot loop

Mijzelf · May 2021

@GandalfTheGrey : I think your problem is different than the OP's one. To get the script running you need at least a partial boot. The script is executed by the firmware.

As the boxes were powered off when the mains disappeared, it cannot hurt the box. I think (hope) one of the power supplies cannot provide enough juice anymore to spinup the disks. To test this you can remove the disks, and try to powerup, or try to exchange the supplies.

GandalfTheGrey · May 2021

@Mijzelf: Thanks for the quick reply.

I had already tried powering up without disks, and have just tried your suggestion of using the other NAS's power supply. No improvement, unfortunately. Still the same situation.

A little extra info, perhaps: the power button lights up, but it doesn't work at all. The only way to turn off the machine is by pulling the power plug.

I read on another forum that people were having problems with reboots and timekeeping (?), and someone suggested it might be a depleted buffer battery. Could THAT be it? I don't think so, since the unit gets power, obviously, and the battery is only there to keep dates current when power is off, which is irrelevant right now.

I've ordered a new unit, anyway, so unless you - or anyone else - can think of a genius solution, I think I can consider this machine bricked, no? In other words, don't sweat it, unless it's an easy task for you to look for a fix.

GandalfTheGrey · May 2021

Tried unzipping the contents of
http://zyxel.diskstation.eu/Users/Mijzelf/RescueSticks/NAS540_521AATB3C0_Upgradekey.zip
onto a FAT32 USB drive and tried re-powering up the NAS with the USB in the front and back USB ports, alternatively. In either case, nothing happens. The USB drive has an LED that turns on to show it's "connected/recognized/mounted". In both cases, it stays off.

footstep · June 2021

@GandalfTheGrey: Have you already tried to boot the NAS with the following script? http://zyxel.diskstation.eu/Users/Mijzelf/universal_usb_key_func-2015-10-12.zip

After extracting the files to the stick, you'll have to rename the desired shell script (in may case usb_key_func.sh.network_telnet.2). That way I was able to access my broken NAS and fix the missing parts.

lovideo · August 2021

Hi everyone. This thread is the one that resembles the most to my case, and it seems you can help me revive my NAS542, which is out of warranty and shows the same bootloop issue like footstep 's. I have tried to list environment variables with the help of the rescue usb key but I get the wrong magic message:

/firmware/sbin/info_printenv
envfs: wrong magic on /dev/mtd2

Dear Mijzelf, could you please pm me with the mtd2 dump file?

Mijzelf · August 2021

Sure.

lovideo · August 2021

Dear Mijzelf, thank you so much! My NAS542 went through a complete recovery.

But it happened in a peculiar way, due to my clumsiness. First, after erasing and writing the mtd2 partition with your copy, I changed the modelid_1 and modelid_2 variables to B403, the eth0.serverip and MAC adresses. Just later I realized that there Is another variable, MODEL_ID, which remained with the NAS540 name.

With the recovery key in place, the NAS booted just fine. The log complained about a mismatch in md5 hashes, I don't know why, maybe because I used a windows app to calculate it, and it had all the letters in caps, but the NAS booted properly. I don't know really what happened, seeing the log I theorize that the key didn't flash the firmware and the only thing my machine needed to get over the boot loop was a functional mtd2 partition.

I realized that the firmware version is specific to a NAS540 machine. As a firmware update specific to the NAS542 presented itself in the web interface, I have tried to do an update. It didn't work. Also the unit was not able to mount the hdd. Then I checked the info_printenv output. The hashes were the same, no update. So I changed the MODEL_ID to B403 and the fwversion variables from

fwversion_1=V5.04(AATB.0)
fwversion_2=V5.11(AATB.2)

to

fwversion_1=V5.21(ABAG.5)

fwversion_2=V5.21(ABAG.6)

After that, the update worked. Everything came to normal.

Now I have these values, the first one being generated by the firmware update

fwversion_1=V5.21(ABAG.7)
fwversion_2=V5.21(ABAG.6)

Also:
next_bootfrom=1
curr_bootfrom=1

And the checksum hashes changed just for the first position, as you can see:

core_checksum_1=1f2eb228a8a8e84b5ca60decb61d8128
core_checksum_2=0eaa12517d117ff7dd2f68502b7f961d
zld_checksum_1=b3372b8ae6011ca193af3aeac794e373
zld_checksum_2=44485b00ede541d4f27db02f0da490f9
romfile_checksum_1=AB6B
romfile_checksum_2=28C8
img_checksum_1=6e7bbe813643b2e9cf434cba783ba56d
img_checksum_2=83d14a443096a8284b07e3f3a91b1673

The hdd's are now mounted, and the box works normally, as if nothing happened.

I guess I will leave these variables like that, unless there is a reason (unknown to me) to change them.

By the way, what is the meaning of the two values for the installed firmware? Are they both versions of firmware present on the machine as a failsafe mechanism just in case un update goes wrong? Or the second line is there just to inform the system about which update to accept? Do you recommend changing something there?

Thank you again, and sorry for the long post.

Mijzelf · August 2021

I guess I will leave these variables like that, unless there is a reason (unknown to me) to change them.

If it boots, and accepts updates, it's OK. You won't have to worry about the checksums, those are written by the update mechanism, and so they are correct now. (for firmware 1)

By the way, what is the meaning of the two values for the installed firmware? Are they both versions of firmware present on the machine as a failsafe mechanism just in case un update goes wrong? Or the second line is there just to inform the system about which update to accept? Do you recommend changing something there?

Indeed, there are 2 firmwares installed, and if the box fails to boot, it automatically changes to 'the other', in normal use the previous firmware. This to protect agains bad flashes.

AFAIK the firmware version strings are not used at all. There is a mechanism which prevents downgrading, but that uses the revision number (which you can see in the URL of the webinterface, something like 50000), which is stored in the firmware itself, not in the u-boot environment.

For upgrading further only the modelid is important, as that has to match the modelid stored in the firmware file, to prevent flashing an incompatible firmware. As your box refused to flash 542, I suppose it's stored in MODEL_ID, and I suppose modelid_1 and _2 are more descriptions of the installed firmwares than descriptions of the NAS.

lovideo · August 2021

Hi everyone. This thread is the one that resembles the most to my case, and it seems you can help me revive my NAS542, which is out of warranty and shows the same bootloop issue like footstep 's. I have tried to list environment variables with the help of the rescue usb key but I get the wrong magic message:

/firmware/sbin/info_printenv
envfs: wrong magic on /dev/mtd2

Dear Mijzelf, could you please pm me with the mtd2 dump file?

archigraf · August 2021

Dear Mijzelf, could you please pm me to with the mtd2 dump file?

NAS542 stuck in a boot loop

All Replies

Categories

Consumer Product Help Center