Dead Zyxel NSA211after deleting partition - is it possible to boot it from a USB rescue stick?

Mijzelf

I'm not 100% sure of the last bullet since the label on my thumb drive is "USB DISK" which should show up in the line

I don't think it's the label here. The label is written on the disk, and sg_map works on a lower level. It will be some vendor string.

However, it also strikes me the format of the output in "any_usb" is different to that I expected -- I thought (by picking off a single column via the "awk { print $7 }", it would just be a single device value, like "/dev/sda"??

Yes. Later it tries to mount each 1st partition:

<p>for usb in ${any_usb}<br>&nbsp;&nbsp;&nbsp; do<br>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; mount "${usb}"1 /mnt/parnerkey<br></p>

Where do you read any_usb contains something different?

If all else fails, I was wondering if the procedure documented here could be used to replace everything that is missing: ftp://ftp.zyxel.it/guide/nas/nsa220_recovery_firmware.pdf via tftp?

For some reason I can't reach that document from here. But the nsa220 is completely different from the nsa221. It doesn't have uboot, for instance, so I wouldn't be surprised if it doesn't work. But if needed I can extract a firmware for you.

OrlandoScarlet

Hi Mijzelf,

Thanks for keeping me honest - sadly, I was looking at the wrong block of code (it was late for me -- that's my excuse and I'm sticking to it ).

When I tested at the command line I realized the block of code I had been looking at was running "grep -v" to exclude all the lines containing "USB DISK":

/ # export NAND_DISK="USB DISK"
/ # echo $NAND_DISK
USB DISK

/ # sg_map -x -i|grep -v " 0 0 0 0"|grep -v " 1 0 0 0"|grep -v "${NAND_DISK}"|awk '{print $7}'

/ #  sg_map -x -i
/dev/sg0  0 0 0 0  0  /dev/sda  HGST      HGST HDN724040AL  MJAO
/dev/sg2  2 0 0 0  2  /dev/sdb  ZyXEL     USB DISK 2.0      PMAP
/dev/sg3  3 0 0 0  3  /dev/sdc            USB DISK 2.0      PMAP

/ # sg_map -x -i|grep -v " 0 0 0 0"|grep -v " 1 0 0 0"|grep -v "${NAND_DISK}"
/ #

What I was seeing in the logs started to make more sense when reviewed against the correct block of code

When I manually step though the right block, which you had already steered me to, I think this illustrates where things come of the rails. This is the code:

### Find NAND Flash
/bin/mkdir -m 777 -p ${NAND_PATH}

any_usb=`cat /proc/scsi/scsi_zyxel | grep "${NAND_DISK}"  | awk '{print $7}'`
if [ -n "${any_usb}" ]; then
	for usb in ${any_usb}
	do
		ls -l /"$usb"1 ${NAND_PATH} > /dev/null 2>&1
		chmod -R 777  ${NAND_PATH}
                ...

and these are my results from the command line:

/ # export NAND_PATH="/zyxel/mnt/NAND"
/ # echo $NAND_PATH
/zyxel/mnt/NAND

/ # cat /proc/scsi/scsi_zyxel | grep "${NAND_DISK}"  | awk '{print $7}'
/dev/sdb
/dev/sdc

/ # mkdir -p /zyxel/mnt/NAND
/ # ls -l ${NAND_PATH}
/ #

/ # /bin/mount -t ext3 /dev/sdb1 ${NAND_PATH}
mount: mounting /dev/sdb1 on /zyxel/mnt/NAND failed: No such file or directory
/ # ls -l /dev
-rw-r--r--    1 0        0                0 Jan  1 00:04 null

Although "sg_map" successfully lists the USB disks present, the script is failing to mount them (as it redirects the output to /dev/null, we weren't getting the clue we needed).

Does this strike you as the "timing issue"?

Regarding the alternate approach, it is strange I can still get to ftp://ftp.zyxel.it/guide/nas, but it stalls when attempting to retrieve "nsa220_recovery_firmware.pdf" so I've attached it.

However, on a more positive side it does seem NSA-221 does offer "U-Boot" as I can get to a prompt when I press a key early enough in the boot cycle to stop the autoboot:

System halted.


1.00 U-Boot 1.1.2 (Apr 11 2010 - 20:23:49)

U-Boot code: 48D00000 -> 48D172F4  BSS: -> 48D1AFA4
RAM Configuration:
        Bank #0: 48000000 256 MB
SRAM Configuration:
        128KB at 0x58000000
Flash:  4 MB
In:    serial
Out:   serial
Err:   serial
Hit any key to stop autoboot:  0
$
$ help
?       - alias for 'help'
base    - print or set address offset
bdinfo  - print Board Info structure
bootm   - boot application image from memory
bootp   - boot image via network using BootP/TFTP protocol
cmp     - memory compare
cp      - memory copy
crc32   - checksum calculation
echo    - echo args to console
erase   - erase FLASH memory
exit    - exit script
flinfo  - print FLASH memory information
go      - start application at address 'addr'
help    - print online help
iminfo  - print header information for application image
loop    - infinite loop on address range
md      - memory display
mm      - memory modify (auto-incrementing)
mtest   - simple RAM test
mw      - memory write (fill)
nm      - memory modify (constant address)
ping    - send ICMP ECHO_REQUEST to network host
printenv- print environment variables
protect - enable or disable FLASH write protection
rarpboot- boot image via network using RARP/TFTP protocol
reset   - Perform RESET of the CPU
run     - run commands in an environment variable
saveenv - save environment variables to persistent storage
setenv  - set environment variables
test    - minimal test like /bin/sh
tftpboot- boot image via network using TFTP protocol
version - print monitor version
$

I think this does open the door to a potential reflash via TFTP and, if you are kind enough to help me get the firmware files, would probably like to do this in the long term so the boot from flash will work in the future.

However, my first stop will be removing the physical drive to my linux box to re-instate the sysdisk.img.gz you were kind enough to share. If the md5sum matches what's on the INFOPATH (mounted from "/dev/mtdblock4" to "/zyxel/mnt/info/"), then I could be back in business booting from the hard disk.

Thanks again - will keep you posted.

Cheers,
Orlando

OrlandoScarlet

Hi Mijzelf,

I inserted one of the original HDD's from the NAS into a linux box so I could mount it and copy the sysdisk.img you provided (md5sum: 12427e0a1c921f9bd7819a3736228628). The sysdisk.img was the only file on the HDD.

I was concerned this might not work since the 12427e0a1c921f9bd7819a3736228628 md5sum does not match the "a54c703439224f1ab395b24004edc395" value in /zyxel/mnt/info/image_checksum:

/ # for file in /zyxel/mnt/info/*; do printf '\n--- %s ---\n' ${file}; cat $
{file}; done

--- /zyxel/mnt/info/core_checksum ---
9382

--- /zyxel/mnt/info/fwversion ---
4.41(AFM.0)

--- /zyxel/mnt/info/image_checksum ---
a54c703439224f1ab395b24004edc395 sysdisk.img      <=====

--- /zyxel/mnt/info/initrd_checksum ---
104C

--- /zyxel/mnt/info/modelid ---
DC01

--- /zyxel/mnt/info/revision ---
39717

--- /zyxel/mnt/info/romfile_checksum ---
E863

--- /zyxel/mnt/info/zld_checksum ---
F304

However, although it sees the HDD, it seems unable to successfully mount it at /zyxel/mnt/sysdisk. Here's what I see in the logs:

INITRD: Trying to mount NAND flash as Root FS.egiga0: PHY is Realtek RTL8211BGR
egiga0: link down
...scsi 2:0:0:0: Direct-Access     ZyXEL    USB DISK 2.0     PMAP PQ: 0 ANSI: 0 CCS
sd 2:0:0:0: [sdb] 247808 512-byte hardware sectors (127 MB)
sd 2:0:0:0: [sdb] Write Protect is off
sd 2:0:0:0: [sdb] Assuming drive cache: write through
sd 2:0:0:0: [sdb] 247808 512-byte hardware sectors (127 MB)
sd 2:0:0:0: [sdb] Write Protect is off
sd 2:0:0:0: [sdb] Assuming drive cache: write through
 sdb:
sd 2:0:0:0: [sdb] Attached SCSI removable disk
sd 2:0:0:0: Attached scsi generic sg1 type 0

umount: can't umount /zyxel/mnt/NAND: Invalid argument
/bin/storage_gen_mntfw.sh: line 110: e2fsck: not found	  <====
bsname}: skip changing partition name because parted command not available yet
Filesystem label=
OS type: Linux
Block size=1024 (log=0)
Fragment size=1024 (log=0)
124928 inodes, 498688 blocks
0 blocks (0%) reserved for the super user
First data block=1
Maximum filesystem blocks=524288
61 block groups
8192 blocks per group, 8192 fragments per group
2048 inodes per group
Superblock backups stored on blocks:
        8193, 24577, 40961, 57345, 73729, 204801, 221185, 401409
/dev/sda1 /zyxel/mnt/sysdisk ext2 ro 0 0
 Flag_HD_Exists = 0
Boot from disk
System disk image does NOT exist on HDD! Extract new firmware from NAND flash ...
bsname}: skip changing partition name because parted command not available yet
Filesystem label=
OS type: Linux
Block size=1024 (log=0)
Fragment size=1024 (log=0)
124928 inodes, 498688 blocks
0 blocks (0%) reserved for the super user
First data block=1
Maximum filesystem blocks=524288
61 block groups
8192 blocks per group, 8192 fragments per group
2048 inodes per group
Superblock backups stored on blocks:
        8193, 24577, 40961, 57345, 73729, 204801, 221185, 401409
/dev/sda1 /zyxel/mnt/sysdisk ext2 rw 0 0
gzip: /zyxel/mnt/NAND/sysdisk.img.gz: No such file or directory
Checksum of sysdisk.img : d41d8cd98f00b204e9800998ecf8427e <= md5sum of 0 byte file
Checksum from INFO  : a54c703439224f1ab395b24004edc395
Checksum of sysdisk.img does NOT match!
WARNING: No valid partition on HDD or no HDD plugged
Booting from ramdisk

It's curious why it can longer find "e2fsck" to be logging the following error:

/bin/storage_gen_mntfw.sh: line 110: e2fsck: not found

The above is probably the result of the partition deletion that initiated these troubles, but I'm I not sure that should be a road block to it booting from HDD.

Uploading the full boot log so you can review more broadly but it seems, from the following log fragment much earlier in the boot process, that it sees the HDD:

scsi 0:0:0:0: Direct-Access     HGST     HGST HDN724040AL MJAO PQ: 0 ANSI: 5
sd 0:0:0:0: [sda] Very big device. Trying to use READ CAPACITY(16).
sd 0:0:0:0: [sda] 7814037168 512-byte hardware sectors (4000787 MB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
sd 0:0:0:0: [sda] Very big device. Trying to use READ CAPACITY(16).
sd 0:0:0:0: [sda] 7814037168 512-byte hardware sectors (4000787 MB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
 sda: sda1 sda2
sd 0:0:0:0: [sda] Attached SCSI disk
sd 0:0:0:0: Attached scsi generic sg0 type 0

but somehow the boot process is electing not to mount the HDD at /zyxel/mnt/sysdisk to see the restored sysdisk.img file I copied there.

Consequently an empty file somehow gets created at /zyxel/mnt/sysdisk/sysdisk.img, which gives rise to the following message:

Checksum of sysdisk.img : d41d8cd98f00b204e9800998ecf8427e

The above checksum is the same checksum as a zero byte file created by "touch":

$ touch zeroByteFile

$ ls -l zeroByteFile
-rw-rw-r--+ 1 ORLANDO  None 0 Jul 19 23:36 zeroByteFile

$ ls zeroByteFile
zeroByteFile

$ md5sum zeroByteFile
d41d8cd98f00b204e9800998ecf8427e *zeroByteFile

I tried running "/bin/storage_gen_mntfw.sh" with the appropriate arguments as soon as I could reach a prompt:

/ # export DISKPATH="/zyxel/mnt/sysdisk"
/ # echo $DISKPATH
/zyxel/mnt/sysdisk
/ # sh -x /bin/storage_gen_mntfw.sh ${DISKPATH}; echo $?
+ bsname=storage_gen_mntfw.sh
+ mkdir -p -m 777 /zyxel/mnt/sysdisk
+ [ ! -d /zyxel/mnt/sysdisk ]
+ devsdx=
+ mkfsed1=
+ mkfsed2=
+ cat /etc/modelname
cat: can't open '/etc/modelname': No such file or directory
+ MODEL=
+ [ 1 -ne 1 ]
+ clean1=
+ sg_map -x -i
+ grep  0 0 0 0
+ awk {print $7}
+ cut -c 6-8
+ swap1=sda
+ [ sda !=  ]
+ get_part sda
+ ls /sys/block/sda/
+ grep sda
+ wc -l
+ twopart=2
+ cat /sys/block/sda/size
+ hddsize=7814037168
+ let hddsize=7814037168/2048
+ [ 3815447 -ge 2097152 ]
+ [ 2 -eq 2 ]
+ fwpart=no_parted_in_initrd
+ swappart=no_parted_in_initrd
+ PARTED=1
+ [ no_parted_in_initrd !=  ]
+ [ 2 -eq 2 ]
+ e2fsck -n /dev/sda1
/bin/storage_gen_mntfw.sh: line 110: e2fsck: not found
+ clean1=127
+ devsdx=/dev/sda
+ [ 127 -eq 0 ]
+ sg_map -x -i
+ grep  1 0 0 0
+ awk {print $7}
+ cut -c 6-8
+ swap2=
+ [  !=  ]
+ [ sda ==  ]
+ cat /proc/mounts
+ grep /zyxel/mnt/sysdisk
+ whymounted=/dev/sda1 /zyxel/mnt/sysdisk ext2 rw 0 0
none /zyxel/mnt/sysdisk ramfs rw 0 0
+ [ /dev/sda1 /zyxel/mnt/sysdisk ext2 rw 0 0
none /zyxel/mnt/sysdisk ramfs rw 0 0 !=  ]
+ echo storage_gen_mntfw.sh: why /zyxel/mnt/sysdisk is already mounted
storage_gen_mntfw.sh: why /zyxel/mnt/sysdisk is already mounted
+ exit 1
1

The problem is the boot process goes on to try RAM disk before I can stop it, which results in an extra entry in /proc/mounts ("/zyxel/mnt/sysdisk ramfs rw 0 0" in addition to "/zyxel/mnt/sysdisk ext2 rw 0 0" so the above ends with an error not encountered during the boot itself.

Finally, and I'm not sure if this plays into it, when comparing the above against a reference boot log for NSA-221 when disk containing "sysdisk.img" are present, my HDD partition currently seems ext2 rather than ext3.

These disks were the original disks (they were not in the NAS when I did whatever bonehead partition deletion) so the fact that they are different now (ext2 filesystem and previously a zero byte "sysdisk.img") seems to have transpired during the recovery efforts.

Any thoughts on the above or switching to the TFTP recovery approach would be welcome but I'm becoming increasingly resigned to not being able to recover this

Cheers,
Orlando

Mijzelf

I have read that nsa220 recovery document. As we expect from ZyXEL, it's actually not about the 220, but about the 221. It's very interesting. Have you read it? Actually only the kernel is tftp'ed. The rest of the data is handled from a booted system.

<quote>

10. After bootup, Press “Ctrl + C” after you see this message “INITRD: Trying to mount
NAND flash as Root FS.”
11. In BusyBox shell, enter the below commands to format and mount NAND flash
-> mke2fs -j /dev/sda1
-> mkdir -p /zyxel/mnt/NAND
-> mount /dev/sda1 /zyxel/mnt/NAND

<snip>

-> cp /e-data/1234/DATA_1004 /zyxel/mnt/NAND/sysdisk.img.gz

</quote>

How nice is that?

Does this strike you as the "timing issue"?

No. I once saw a bootlog of a 'timing issue'. You could see the firmware enumerating the disks (It was a 310, on which all disks are probed for usb_key_func.sh, including the internal disks), and after that the kernel log from an detected scsi device popped up. So sg_map wouldn't have seen it at all.

It's curious why it can longer find "e2fsck" to be logging the following error:

I think storage_gen_mntfw.sh was copied from the 220/210, and nobody bothered to remove the disk check.

Your bootlog shows the firmware puts a filesystem somewhere. So I think somehow your partition was not recognized as valid, and got a new filesystem. Then of course the sysdisk.img was gone.

These disks were the original disks

Really? Does the 221 support >2TB disks?

I uploaded the files to http://zyxel.diskstation.eu/Users/Mijzelf/NSA/221/

BTW, there is another way out. The SoC, an oxnas, is designed to be unbrickable. It tries first to boot from harddisk, before it falls back to flash. Here you can find instructions how to create a disk for an Iomega Home Media, which happens to have the same SoC. It should work on a 221 too (and on a 210), although the leds and stuff won't work. The fan will work, I think, as the oxnas kernel has a special module for it. The needed files are here.