After settings lost on reboot, box gets unstable (RC4)

[Kevin Roberts]

Greetings!

After rebooting where sda2 (Volume_1) received an automatic integrity check, my RC4 box came back with out it's setting and I was presented with the first time password dialog. The weird thing is, the Alt F folder isn't on Volume_1, it's on sdb2 (Volume_2). Not sure what happened but rebooting again didn't help. Looks like I lost the whole setup. Even worse, the box is now unstable and many functions failing.

So. reload the setting from the file I saved on Jul 25, I think to myself...Not. Attempting to reload the previously saved settings fails. Not only that but I can't save settings either (so rebooting loses everything). And finally trying to create Users is also failing. Seems like my box is pretty hosed? Seems like it may be time for starting with a clean setup? 

Icing on the cake? Minidlna didn't lose it's configuration and is running happy as pie.

On the settings issue:

Hovering over the 'when done you must save settings' You see the popup text 'The following files have changed since the last save'...but no files are shown.

The top of the settings Management page shows this text:

mount: mounting /dev/mtdblock0 on /tmp/tmp.KjuHnW failed: Invalid argument

Attempting to save the settings gets this page:

Attempting to upload the settings file gets this message:

Creating a User also generates some unexpected errors regarding the Group. I haven't looked at much else except to note the loss of my samba configuration and the User service config to run the disk status fix script. I won't post details unless the information is requested. Rather than trying to fix the current setup, I expect the best bet may be to do a reset of AltF RC4 to defaults and clean out the old RC3 to RC4 setup. Is that possible? Very frustrating.

[João Cardoso]

On Sunday, August 17, 2014 3:18:50 PM UTC+1, Kevin Roberts wrote:

Greetings!

After rebooting where sda2 (Volume_1) received an automatic integrity check, my RC4 box came back with out it's setting and I was presented with the first time password dialog. The weird thing is, the Alt F folder isn't on Volume_1, it's on sdb2 (Volume_2). Not sure what happened but rebooting again didn't help. Looks like I lost the whole setup. Even worse, the box is now unstable and many functions failing.

So. reload the setting from the file I saved on Jul 25, I think to myself...Not. Attempting to reload the previously saved settings fails. Not only that but I can't save settings either (so rebooting loses everything). And finally trying to create Users is also failing. Seems like my box is pretty hosed? Seems like it may be time for starting with a clean setup? 

Icing on the cake? Minidlna didn't lose it's configuration and is running happy as pie.

On the settings issue:

Hovering over the 'when done you must save settings' You see the popup text 'The following files have changed since the last save'...but no files are shown.

The top of the settings Management page shows this text:

mount: mounting /dev/mtdblock0 on /tmp/tmp.KjuHnW failed: Invalid argument

The flash memory where settings is stored got corrupted, you have to fsck it (it is done at boot time)

loadsave_settings -ck

if that fails, you have to reformat it (losing all its contents)

loadsave_settings -fm

[Kevin Roberts]

I got ahead of you...

Found these commands in another thread with a similar problem:

login as: root

root-192.168.1.109's password:

COLUMNS=80;LINES=24;export COLUMNS LINES;

[root@dns323]# loadsave_settings -ck; echo $?

fsck 1.41.14 (22-Dec-2010)

fsck.ext2: Bad magic number in super-block while trying to open /dev/mtdblock0

/dev/mtdblock0:

The superblock could not be read or does not describe a correct ext2

filesystem.  If the device is valid and it really contains an ext2

filesystem (and not swap or ufs or something else), then the superblock

is corrupt, and you might try running e2fsck with an alternate superblock:

    e2fsck -b 8193 <device>

8

[root@dns323]# fsck -av /dev/mtdblock0

fsck 1.41.14 (22-Dec-2010)

fsck.ext2: Bad magic number in super-block while trying to open /dev/mtdblock0

/dev/mtdblock0:

The superblock could not be read or does not describe a correct ext2

filesystem.  If the device is valid and it really contains an ext2

filesystem (and not swap or ufs or something else), then the superblock

is corrupt, and you might try running e2fsck with an alternate superblock:

    e2fsck -b 8193 <device>

[root@dns323]# blkid

/dev/sda2: LABEL="Volume_1" UUID="104cc6e5-a638-40c0-a10b-98340de64f36" TYPE="ext3"

/dev/sdb2: LABEL="Volume_2" UUID="a7891e11-1aff-43e4-9127-610ebbd5a69a" SEC_TYPE="ext2" TYPE="ext3"

/dev/mtdblock1: TYPE="minix"

/dev/sdb1: TYPE="swap"

/dev/sda1: TYPE="swap"

/dev/loop0: TYPE="squashfs"

[root@dns323]# mkfs.minix /dev/mtdblock0

32 inodes

64 blocks

Firstdatazone=5 (5)

Zonesize=1024

Maxsize=268966912

[root@dns323]#

I can save settings after this.