Help needed to unbrick an Alibi-NVR5332P

[bbmre]

Hi All,

So I went to a support call to fix a camera and once finished I glanced over at the firmware version of the NVR and it was from 2016 (3.4.70), so I suggested to the owner to upgrade the firmware since these OEM hikvisions had some security issues the latest one is from July 2021(4.50), so I downloaded the firmware which was 3.4.98 from 2018, this version is the last of the 3.x series, after that the version changes to 4.x, once downloaded to a flash USB, I upgraded through the GUI and after the upgrade the DVR prompted that system will reboot, but after several minutes the screen was blank, so I did power on and off and same thing.

Long story short, the NVR won't show up in sadp, but it's connecting to the tftp, on 192.0.0.128, if I put the very first version of the firmware from their site which was 3.3.7, the download says complete but there is no beep and a blank screen the three led on the motherboard blinks periodically if I try any other version I don't get a complete prompt but after finishing the NVR again connects and start to download the firmware which keeps going on until I close the TFTP.

If I connect through the RS232, I do get u boot prompt attached is the screenshot, any help will be appreciated.

 

[alastairstevenson]

if I try any other version I don't get a complete prompt but after finishing the NVR again connects and start to download the firmware which keeps going on until I close the TFTP.

The Hikvision tftp updater will not handle file transfers larger than 32MB.
That's why it stops responding (with the T for timeout) when 32MB limit has been reached.
Presumably the firmware you are trying is larger than 32MB.
Instead of the Hikvision tftp updater, try a normal tftp server such as this one :

phjounin / tftpd64 / Downloads — Bitbucket

bitbucket.org

Also - the update to the NVR4.x firmware can be troublesome, resulting in a corrupted configuration depending on the start version and new version.
Hikvision published an update advisory on the topic.
I don't know if this applies to your OEM model - but see attached :

 

[bbmre]

The Hikvision tftp updater will not handle file transfers larger than 32MB.
That's why it stops responding (with the T for timeout) when 32MB limit has been reached.
Presumably the firmware you are trying is larger than 32MB.
Instead of the Hikvision tftp updater, try a normal tftp server such as this one :

phjounin / tftpd64 / Downloads — Bitbucket

bitbucket.org

Also - the update to the NVR4.x firmware can be troublesome, resulting in a corrupted configuration depending on the start version and new version.
Hikvision published an update advisory on the topic.
I don't know if this applies to your OEM model - but see attached :

Thanks for your suggestion, after changing the TFTP server software as you suggested I was able to send the firmware to the nvr completely, but its seems like in a boot loop, please refer to the picture.

 

[alastairstevenson]

its seems like in a boot loop, please refer to the picture.

Quite hard to make out what's happening with pictures of the console log as opposed to text.
Does nCom have the ability to copy / paste the transcript into a text file?
Or maybe use PuTTY instead, it can copy the rollback to the clipboard.

Download PuTTY: latest release (0.83)

www.chiark.greenend.org.uk

A transcript of the full firmware update through to the reboot would be helpful.

Where did you get the firmware from?
Is it correctly specific to the NVR model?

 

[bbmre]

Im downloading the firmware from

Alibi Witness Recorder Firmware and Manuals

Find the latest software for Alibi security video recorders including ACMS, firmware, power tools, Witness App and Mac and PC component downloads along with rel

www.alibisecurity.com

Alibi 5X & 7X Series Network Video Recorders
Includes SKUs - ALI-NVR5216P, ALI-NVR5232P, ALI-NVR5316P, ALI-NVR5332P, ALI-NVR7132R, ALI-NVR7164R, ALI-NVR7232R

started with the very first version but no go, I could try and convert it to a hikvision if that works, seems like a I series , since this also has a bnc video out.

 

[bbmre]

Hi all,
did anyone found a solution ?

Thank

 

[alastairstevenson]

did anyone found a solution ?

I've had a look through your substantial console transcript, and to be honest it's a puzzle to me what's going on.
On the face of it - the various firmware updates seem to proceed normally in terms of files validation, flash preparation and writing, for both primary and backup flash areas.
Then, following the successful update, there are variable and inconsistent errors in the subsequent boot activities for no obvious reason.
Presumably the file size variations are dues to the different versions of firmware in play.

The variable nature of the errors might usually suggest a hardware problem.
Against that is that the firmware update parts of the transcript look sound.

I can only offer some long-shot suggestions that aren't based on evidence, but you never know:

During the bootup, following the firmware update process, the kernel will be initiallising parts of the hardware.
After the device has been powered on, check the top-level power supply voltages to confirm they are OK.
You can find 12V and 5V on the HDD power connector.
Disconnect the HDD(s) and see if that changes anything.
Disconnect the cameras and see if that changes anything.

Some more fiddly things to try if you are so inclined :
Power on, interrupt the bootloader with Control-U to get the Update menu, and use the command b<Return> to reach the bootloader prompt.
Use the commands -

printenv
help

to display the existing bootloader variables and commands.
Save this transcript as a text file in a safe place for the 'as-is' status.

In the transcript, find the 'bootargs' variable value and copy / paste that line into a blank text file.
Duplicate the pasted line and edit it to append -

init=/bin/sh single

to it, and change the beginning so it starts as below, and finishes with all the original values after the '=' sign.

It may look a bit like this :
setenv bootargs mem=1148M console=ttyS0,115200n8 init=/bin/sh single

Use copy / paste from the text file to apply the command to the bootloader via your terminal emulator.
Then use the commands

saveenv
reset

and see what happens.

If it reaches a '#' prompt OK, use the command
/etc/init.d/rcS

and see what happens.

The above won't fix the device - but it might provide a little more info, and maybe others will comment also.

To put the bootloader bootargs variable back the way it was - repeat the setenv and saveenv commands above for the bootargs variable, but omit the 'init=/bin/sh single' commands from the end.