NAS542: How do I establish serial connection?

bugblatterbeast

Hi,

I don't exactly know what went wrong... I booted a debian sd card, flashed the kernel and everything was working fine.

I've used this image: debian-nas-bullseye-21.218-armhf.img.gz
and the firmware: linux-image-3.2.102-1-nas5xx-armhf.zip

Then, after a few reboots the system seemed to start, but ethernet didn't come up anymore. Also, there was an error in the syslog on the sd card:

modprobe: FATAL: Module comcerto_wdt not found in directory /lib/modules/3.2.0-6-nas5xx

I've tried to repeat the whole procedure, beeing extra cautious not to miss any error messages. I've booted the sd card (reset to the debian image) again and flashed the kernel once more. There were no errors at all. Everything seemed fine. I tried to reboot the system and now it seems that I have that hopeless boot-loop-issue that some other people mentioned here.

I've read something about a serial console and also about a telnet interface. It doesn't seem that I'm getting to a point were telnet could be working but a serial console might be my last hope. I do have a USB2Serial converter but I have no idea how to connect it to the NAS542.

Thanks in advance for any helpful suggestions
best regards

EDIT: changed title

bugblatterbeast

Hi again,

the recovery-stick mentioned in this post https://community.zyxel.com/en/discussion/comment/24474#Comment_24474  might be a chance.

The dropbox link in that post is dead though. Can I download the recovery content somewhere else or do I have to make a support request?

This link here http://seafile.servator.de/nas/zyxel/NAS540_521AATB0C0/ looks promising.

Can I make it worse by trying to reset the firmware with a rescue stick???

Does NAS542 make a difference between usb and sd during boot or would it be OK if I put the content on a card? And if a card is OK, should the rescue-process be able to deal with a 128 GB card or would it help to use a smaller one?

Best regards

bugblatterbeast

Well, I've found this http://zyxel.diskstation.eu/Users/Mijzelf/RescueSticks/NAS540_521AATB3C0_Upgradekey.zip and I've tried it on sd card and on usb stick (both fat16 formatted) but the device doesn't seem to respond to it.

EDIT: it seems the device doesn't even mount the usb stick

bugblatterbeast

I would really like to try what chrismxnr described here:
https://community.zyxel.com/en/discussion/7134/debian-omv-on-nas540-gone-wrong#Comment_21535

Is the serial interface somehow accessable from the outside?
If I have to open the thing up, is the serial interface easy to find? How would I know which pins(?) to use?

Mijzelf

You can't access the serial interface from outside. Here are some instructions. When I remember well you'll have to remove the thermal sink from the CPU to access the serial port, so be careful not to overheat it.

and the firmware: linux-image-3.2.102-1-nas5xx-armhf.zip

Then, after a few reboots the system seemed to start, but ethernet didn't come up anymore. Also, there was an error in the syslog on the sd card:

modprobe: FATAL: Module comcerto_wdt not found in directory /lib/modules/3.2.0-6-nas5xx

Did you flash another kernel before? As 3.2.102-1 shouldn't try to load from /lib/modules/3.2.0-6, so it seems it switched kernel, and the rootfs doesn't provide the right modules. You could try to extract the 3.2.0-6 modules from an older rootfs, and put them in the right place.

bugblatterbeast

Mijzelf said:

Did you flash another kernel before?

No, after that. I thought I could fix the issue by just repeating the whole procedure I've found in this tutorial https://techdudes.de/1930/zyxel-nas-520-540-542-mit-debian-und-openmediavault-omv/

I had no idea about the alternating kernels then. I still don't fully understand how that works and how it could lead to the boot-loop-issue.

I don't like the idea of removing the thermal sink from the CPU. Until now I didn't touch any hardware and since I bought the device just last week I might still have a slight chance of warranty. Is there maybe any other chance that I can try?

Mijzelf

It still won't hurt to try to put the 3.2.0-6-nas5xx modules in your rootfs. Further it's shooting in the dark, as the box will either boot or not.

About warranty, you killed it yourself, how can you claim warranty then?

bugblatterbeast

Mijzelf said:

It still won't hurt to try to put the 3.2.0-6-nas5xx modules in your rootfs. Further it's shooting in the dark, as the box will either boot or not.

You're right, I'm gonna give it a try.

Mijzelf said:

About warranty, you killed it yourself, how can you claim warranty then?

Yeah, I've already come to the conclusion that it would be unethical and that I don't want to do it. I've already opened it up and undeniably voided the warranty. I'll try the modules and if that doesn't work, I'm quite sure that I can reach the serial port without removing the heat sink.

bugblatterbeast

Mijzelf said:

Did you flash another kernel before? As 3.2.102-1 shouldn't try to load from /lib/modules/3.2.0-6, so it seems it switched kernel, and the rootfs doesn't provide the right modules. You could try to extract the 3.2.0-6 modules from an older rootfs, and put them in the right place.

What your saying sounds absolutely reasonable but strange as it may seems, it looks as though the 3.2.102-1 kernel does indeed load from /lib/modules/3.2.0-6



PS: I am having trouble posting this comment... I've just scaled down the image. Hope it helps.

EDIT: I removed some stuff from this post because I was totally wrong, thinking that the module was missing in the newest kernel.

That watchdog timer is listed as a buildin module.

3.2.0-6-nas5xx/modules.builtin:150:kernel/drivers/watchdog/comcerto_wdt.ko

Mijzelf

What your saying sounds absolutely reasonable but strange as it may seems, it looks as though the 3.2.102-1 kernel does indeed load from /lib/modules/3.2.0-6

I can hardly imagine that. Normally modules are loaded by modprobe, and modprobe asks the kernel for it's version to know where to look. This way it's possible to have several kernels installed (on a system with a mature bootloaded like grub), and having the corresponding modules installed. With the same rootfs/scripts the system will without difficulty load the right modules.

In your logline it's modprobe who is complaining.

It's not clear to me what you want to show me with that zip listing. Can't you mount the SD card to see what is installed there?

That watchdog timer is listed as a buildin module.

3.2.0-6-nas5xx/modules.builtin:150:kernel/drivers/watchdog/comcerto_wdt.ko

Where is it listed that way? It is possible that somewhere (in /etc/modules for instance)  the module is listed as necessary, while it isn't. But I don't know if modprobe would classify that as fatal error, or as warning. In most cases a missing module will mean you won't have sound or network, or something like that. Nothing fatal.

bugblatterbeast

Is it possible that the kernel installed from the zip file linux-image-3.2.102-1-nas5xx-armhf.zip is not "3.2.102-1" but "3.2.0-6-nas5xx"? Currently I can't get to a point where I could run "uname -r" but the deb packages in the zip file do kinda look like it to me.

That's why I posted the content of the zip file. I wanted to show that the deb package for the linux image is not named "linux-image-3.2.102-1*" but instead "linux-image-3.2.0-6-nas5xx_3.2.102-1*".
It only provides "/lib/modules/3.2.0-6-nas5xx" but not "/lib/modules/3.2.102-1".

I might have missed something here but so far I was unable to find any package that would provide "/lib/modules/3.2.102-1*"


linux-image-3.2.102-1-nas5xx-armhf.zip > linux-image-3.2.0-6-nas5xx_3.2.102-1_armhf.deb > /lib/modules/3.2.0-6-nas5xx/modules.builtin:L150 > "kernel/drivers/watchdog/comcerto_wdt.ko"

In the zip file linux-image-3.2.102-1-nas5xx-armhf.zip, the module comcerto_wdt is listed as a build in module in the content of the package "linux-image-3.2.0-6-nas5xx_3.2.102-1_armhf.deb" in the file "/lib/modules/3.2.0-6-nas5xx/modules.builtin" at line 150: "kernel/drivers/watchdog/comcerto_wdt.ko".

EDIT: That also corresponds with the content of my flash drive.