NAS326 defaults after restart or shutdown

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?

Accepted Solution

  • Mijzelf
    Mijzelf Posts: 2,764  Guru Member
    250 Answers 2500 Comments Friend Collector Seventh Anniversary
    Answer ✓
    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.



«1

All Replies

  • Mijzelf
    Mijzelf Posts: 2,764  Guru Member
    250 Answers 2500 Comments Friend Collector Seventh Anniversary
    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.
  • 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
    Mijzelf Posts: 2,764  Guru Member
    250 Answers 2500 Comments Friend Collector Seventh Anniversary
    Answer ✓
    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.



  • I had to RMA it. Replacement device has 7 bad blocks in nand, but at least it saves configuration. Thank you!
  • achlebek
    achlebek Posts: 5  Freshman Member
    First Comment
    edited July 24

    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
    Mijzelf Posts: 2,764  Guru Member
    250 Answers 2500 Comments Friend Collector Seventh Anniversary

    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
    achlebek Posts: 5  Freshman Member
    First Comment
    edited July 24

    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
    Mijzelf Posts: 2,764  Guru Member
    250 Answers 2500 Comments Friend Collector Seventh Anniversary

    [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
    achlebek Posts: 5  Freshman Member
    First Comment

    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
    Mijzelf Posts: 2,764  Guru Member
    250 Answers 2500 Comments Friend Collector Seventh Anniversary

    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.

Consumer Product Help Center