NAS326 defaults after restart or shutdown

znas4home

NAS326 after reboot or shutdown defaults all settings and passwords etc.

Every time after reboot or shutdown I need to set new password and set it up again and again.

Is this by design behavior or there is solution?

Mijzelf

I must admit that I don't know much about ubi's. One of the blocks is in the middle of your config partition:

nand_read_bbt: bad block at 0x000000440000

0x000000400000-0x000000e00000 : "Config"

but I don't know if the filesystem on config should be able to handle that. Bad blocks in nand are normal, and somehow it's handled, but I don't know if a bad block on any place can be handled.

If the 'reset_and_reboot' script (executed as root!) doesn't solve your issue, and you box is still under warranty, I'd RMA it.

Mijzelf

That is not by design. The configuration should be stored on a flash partition. If that fails, then the configuration is stored on the mountpoint of that partition, which is on a ramdisk, and so volatile.

It might help to do a factory reset (press the reset button on the back for 25 seconds, until it has beeped 3 times), which puts a new filesystem on that partition.

znas4home

Unfortunately factory reset didn't help.

When I look into dmesg I found some information about NAND bad blocks:

--------dmesg cut--------------

armada-nand f10d0000.nand: Initialize HAL based NFC in 8bit mode with DMA Disabled using BCH 4bit ECC
NAND device: Manufacturer ID: 0xc2, Chip ID: 0xda (Macronix NAND 256MiB 3,3V 8-bit), 256MiB, page size: 2048, OOB size: 64
Bad block table found at page 131008, version 0x01
Bad block table found at page 130944, version 0x01
nand_read_bbt: bad block at 0x000000260000
nand_read_bbt: bad block at 0x000000440000
nand_read_bbt: bad block at 0x000008740000
nand_read_bbt: bad block at 0x00000e940000
7 ofpart partitions found on MTD device armada-nand
Creating 7 MTD partitions on "armada-nand":
0x000000000000-0x000000200000 : "U-Boot"
0x000000200000-0x000000400000 : "U-Boot env"
0x000000400000-0x000000e00000 : "Config"
0x000000e00000-0x000001d00000 : "Kernel-1"
0x000001d00000-0x000008700000 : "RootFS-1"
0x000008700000-0x000009600000 : "Kernel-2"
0x000009600000-0x000010000000 : "RootFS-2"
m25p80 spi0.0: unrecognized JEDEC id ffffff
<...skip..>

UBI: attaching mtd2 to ubi2
UBI: scanning is finished
UBI error: ubi_read_volume_table: the layout volume was not found
UBI error: ubi_attach_mtd_dev: failed to attach mtd2, error -22
UBIFS error (pid 1663): ubifs_mount: cannot open "ubi2:ubi_config", error -19
UBI: attaching mtd2 to ubi2
UBI: scanning is finished
UBI: empty MTD device detected
UBI: attached mtd2 (name "Config", size 10 MiB) to ubi2
UBI: PEB size: 131072 bytes (128 KiB), LEB size: 126976 bytes
UBI: min./max. I/O unit sizes: 2048/2048, sub-page size 2048
UBI: VID header offset: 2048 (aligned 2048), data offset: 4096
UBI: good PEBs: 79, bad PEBs: 1, corrupted PEBs: 0
UBI: user volume: 0, internal volumes: 1, max. volumes count: 128
UBI: max/mean erase counter: 0/0, WL threshold: 4096, image sequence number: 243037217
UBI: available PEBs: 36, total reserved PEBs: 43, PEBs reserved for bad PEB handling: 39
UBI: background thread "ubi_bgt2d" started, PID 1679
UBIFS: default file-system created
UBIFS: background thread "ubifs_bgt2_0" started, PID 1684
UBIFS: mounted UBI device 2, volume 0, name "ubi_config"
UBIFS: LEB size: 126976 bytes (124 KiB), min./max. I/O unit sizes: 2048 bytes/2048 bytes
UBIFS: FS size: 3301376 bytes (3 MiB, 26 LEBs), journal size 1015809 bytes (0 MiB, 6 LEBs)
UBIFS: reserved for root: 155931 bytes (152 KiB)
UBIFS: media format: w4/r0 (latest is w4/r0), UUID AE4331BC-9234-4C1B-8557-693926C9FD74, small LPT model
-------dmesg cut-------

Could it be the reason?

Mijzelf

I must admit that I don't know much about ubi's. One of the blocks is in the middle of your config partition:

nand_read_bbt: bad block at 0x000000440000

0x000000400000-0x000000e00000 : "Config"

but I don't know if the filesystem on config should be able to handle that. Bad blocks in nand are normal, and somehow it's handled, but I don't know if a bad block on any place can be handled.

If the 'reset_and_reboot' script (executed as root!) doesn't solve your issue, and you box is still under warranty, I'd RMA it.

znas4home

I had to RMA it. Replacement device has 7 bad blocks in nand, but at least it saves configuration. Thank you!

achlebek

dmesg.txt

Sorry for resurrecting but this is exactly my problem and I'm after the warranty.

Attached is my full dmesg and I have following worrying lines:

Bad block table found at page 131008, version 0x01
Bad block table found at page 130944, version 0x01
nand_read_bbt: bad block at 0x000005da0000
7 ofpart partitions found on MTD device armada-nand
Creating 7 MTD partitions on "armada-nand":
0x000000000000-0x000000200000 : "U-Boot"
0x000000200000-0x000000400000 : "U-Boot env"
0x000000400000-0x000000e00000 : "Config"
0x000000e00000-0x000001d00000 : "Kernel-1"
0x000001d00000-0x000008700000 : "RootFS-1"
0x000008700000-0x000009600000 : "Kernel-2"
0x000009600000-0x000010000000 : "RootFS-2"

UBI: attached mtd4 (name "RootFS-1", size 106 MiB) to ubi0
UBI: PEB size: 131072 bytes (128 KiB), LEB size: 126976 bytes
UBI: min./max. I/O unit sizes: 2048/2048, sub-page size 2048
UBI: VID header offset: 2048 (aligned 2048), data offset: 4096
UBI: good PEBs: 847, bad PEBs: 1, corrupted PEBs: 0
UBI: user volume: 1, internal volumes: 1, max. volumes count: 128
UBI: max/mean erase counter: 2/1, WL threshold: 4096, image sequence number: 4122008704
UBI: available PEBs: 0, total reserved PEBs: 847, PEBs reserved for bad PEB handling: 39

UBI: attached mtd6 (name "RootFS-2", size 106 MiB) to ubi6
UBI: PEB size: 131072 bytes (128 KiB), LEB size: 126976 bytes
UBI: min./max. I/O unit sizes: 2048/2048, sub-page size 2048
UBI: VID header offset: 2048 (aligned 2048), data offset: 4096
UBI: good PEBs: 840, bad PEBs: 8, corrupted PEBs: 0
UBI: user volume: 1, internal volumes: 1, max. volumes count: 128
UBI: max/mean erase counter: 2/1, WL threshold: 4096, image sequence number: 739781561
UBI: available PEBs: 0, total reserved PEBs: 840, PEBs reserved for bad PEB handling: 32

Is there anything I can do to have the configuration kept?

Mijzelf

Your problem is not exactly the same. znas4home had a bad block in the middle of the 'Config' partition. Your bad block is inside 'RootFS-1', and the bad PEB's are in 'RootFS-1' and 'RootFS-2'. Those partitions are only used when starting with fresh disks, or when updating firmware.

In your case there is a strange sequence when attaching the 'Config' partition:

UBI: attaching mtd2 to ubi2
UBI: scanning is finished
UBI: attached mtd2 (name "Config", size 10 MiB) to ubi2
UBI: PEB size: 131072 bytes (128 KiB), LEB size: 126976 bytes
UBI: min./max. I/O unit sizes: 2048/2048, sub-page size 2048
UBI: VID header offset: 2048 (aligned 2048), data offset: 4096
UBI: good PEBs: 80, bad PEBs: 0, corrupted PEBs: 0
UBI: user volume: 1, internal volumes: 1, max. volumes count: 128
UBI: max/mean erase counter: 2/1, WL threshold: 4096, image sequence number: 1497890039
UBI: available PEBs: 0, total reserved PEBs: 80, PEBs reserved for bad PEB handling: 40
UBI: background thread "ubi_bgt2d" started, PID 1566
UBIFS: background thread "ubifs_bgt2_0" started, PID 1570
UBIFS error (pid 1568): ubifs_recover_master_node: failed to recover master node
UBIFS: background thread "ubifs_bgt2_0" stops
UBI: detaching mtd2 from ubi2
UBI: mtd2 is detached from ubi2
UBI: attaching mtd2 to ubi2
UBI: scanning is finished
UBI: empty MTD device detected
UBI: attached mtd2 (name "Config", size 10 MiB) to ubi2
UBI: PEB size: 131072 bytes (128 KiB), LEB size: 126976 bytes
UBI: min./max. I/O unit sizes: 2048/2048, sub-page size 2048
UBI: VID header offset: 2048 (aligned 2048), data offset: 4096
UBI: good PEBs: 80, bad PEBs: 0, corrupted PEBs: 0
UBI: user volume: 0, internal volumes: 1, max. volumes count: 128
UBI: max/mean erase counter: 0/0, WL threshold: 4096, image sequence number: 1899997034
UBI: available PEBs: 36, total reserved PEBs: 44, PEBs reserved for bad PEB handling: 40
UBI: background thread "ubi_bgt2d" started, PID 1589
UBIFS: default file-system created
UBIFS: background thread "ubifs_bgt2_0" started, PID 1594
UBIFS: mounted UBI device 2, volume 0, name "ubi_config"
UBIFS: LEB size: 126976 bytes (124 KiB), min./max. I/O unit sizes: 2048 bytes/2048 bytes
UBIFS: FS size: 3301376 bytes (3 MiB, 26 LEBs), journal size 1015809 bytes (0 MiB, 6 LEBs)
UBIFS: reserved for root: 155931 bytes (152 KiB)
UBIFS: media format: w4/r0 (latest is w4/r0), UUID 0A079606-A8CB-43EB-9EDA-C4A58341FB0D, small LPT model

It attaches twice. The first attempt errors out on 'UBIFS error (pid 1568): ubifs_recover_master_node: failed to recover master node'. The second one reports: 'UBI: empty MTD device detected' and 'UBIFS: default file-system created'. So apparently the error causes the UBI system to reset the whole partition.

This is reproducible? Have you already tried a proper factory reset? A factory reset formats the Config partition in another way as the error handling does. I think.

achlebek

Interesting.

Yes it happens every time. I removed the disks and tried factory reset from UI and it's still the same. Then with RESET button and then on reboot it freezed, after power cycling it's still the same.

Mijzelf

[quote]I removed the disks <snip> and then on reboot it freezed[/quote]

That could be related to the bad block in rootfs 1. When I said it is only used on a fresh installation or firmware update, I was not complete. The partition contains a gzipped filesystem which contains a major part of the firmware, among which the webinterface. Normally it's decompressed to the harddisk once. On next boot it uses the filesystem blob on harddisk. (Nand is slow to read, so boottime is significantly shortened by this cache).

When booting without disks, the firmware creates a ramdisk in which the gzipped file is extracted. But of course that fails if the file is corrupted. In that case there is no webinterface, nor ssh. I think the firmware will set the flag to use the other rootfs next boot.

achlebek

On subsequent RESET button factory reset it managed to boot but it still loses configuration.

Is there anything reasonable I can do to make it work?

If not, what are alternative NAS systems I can install on it? I know about Debian on USB and then maybe OMV. Something else? More straightforward?

Thank you.

Mijzelf

Maybe some aggressive erasing will do the trick?

su
umount /etc/zyxel
ubidetach -m 2
flash_eraseall /dev/mtd2

And else, as the vanilla kernel supports the NAS326, provided you pass the right dts file, in theory you can install any Linux distro, provided it supports headless and Armv7. Arch and Debian come to my mind. You mention 'on USB', but there is no reason why you couldn't install it on harddisk. The only limitation is that u-boot needs to be able to find&load uImage and uInitrd.

I'm not aware of any available NAS os, except OMV, which is basically a Debian package.