Copy process aborted, file corrupted afterwards ?

[Jocko]

I edited my post

[Leopold13]

Hi,

I used the fvdw-sl console only for installing the fvdw firmware.
But I have no idea how to use it to run e2fsck to repair sda5.

Regarding

Code: Select all

chmod 777 /tmp

After this command the firmware interface loads normal.

[Leopold13]

Hi Jocko,

please excuse my questions. I am really unexperienced with Linux.

I found some good information for e2fsck in the Net.
With this I tried to run e2fsck in Putty to repair sda5. But sda5 is mounted and e2fsck could not run.
As next step I tried to unmount it, but was not possible because it is busy.

My idea now:
I start the NAS with a standalone kernel (from fvdw-sl console). Than sda5 should be unmounted (?)
After that I run e2fsck in Putty to repair sda5.
Finally I restart the NAS with normal boot.

Would this work and lead to repair of sda5?
Or is there a better solution available?

[Jocko]

yes it is my idea.

Start fvdw-sl console and select the action "load and start standalone kernel". You have to select as kernel image: UIMAGE-3142-KIRKWOOD-171-standalone (kirkwood version)

So a telnet window should be displayed and then do

Code: Select all

./fvdw-sl-programs.sh

select the 4th item "Upload and extract glibc mini and tools" which will allow you to run e2fsck.
Run e2fsck on sda5:

Code: Select all

e2fsck -y /dev/sda5

After try to mount to see if there are some warnings

Code: Select all

mkdir /sda5
mount /dev/sda5 /sda5

(please to post the output)
and last job examine if nas database is still ok

Code: Select all

ls -l /sda5/etc

(please to post the output)

---edit---
About fvdw-sl console, to avoid any time out issue, you have to disable all iface except for the wire network card

[Leopold13]

Hi Jocko,

Thank you very much for your great help.
Due to your perfect guidance the repair could be easily done.

Here is the output from e2fsck

Code: Select all

root@fvdw-sta-kirkwood:/ # e2fsck -y /dev/sda5
e2fsck 1.41.14 (22-Dec-2010)
/dev/sda5: recovering journal
/dev/sda5 contains a file system with errors, check forced.
Pass 1: Checking inodes, blocks, and sizes
Deleted inode 8242 has zero dtime.  Fix? yes
Deleted inode 8243 has zero dtime.  Fix? yes
Deleted inode 32815 has zero dtime.  Fix? yes
Deleted inode 32816 has zero dtime.  Fix? yes
Deleted inode 32817 has zero dtime.  Fix? yes
Deleted inode 32818 has zero dtime.  Fix? yes
Deleted inode 32820 has zero dtime.  Fix? yes
Deleted inode 32821 has zero dtime.  Fix? yes
Deleted inode 32822 has zero dtime.  Fix? yes
Deleted inode 32823 has zero dtime.  Fix? yes
Deleted inode 32824 has zero dtime.  Fix? yes
Deleted inode 32825 has zero dtime.  Fix? yes
Deleted inode 32826 has zero dtime.  Fix? yes
Deleted inode 32827 has zero dtime.  Fix? yes

Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Inode bitmap differences:  -(8242--8243) -(32815--32818) -(32820--32827)
Fix? yes
Free inodes count wrong for group #1 (8111, counted=8113).
Fix? yes
Free inodes count wrong for group #4 (8180, counted=8192).
Fix? yes
Free inodes count wrong (49009, counted=49023).
Fix? yes
/dev/sda5: ***** FILE SYSTEM WAS MODIFIED *****
/dev/sda5: 129/49152 files (14.0% non-contiguous), 9236/196608 blocks

Mount did not give any warnings

Code: Select all

root@fvdw-sta-kirkwood:/ # mkdir /sda5
root@fvdw-sta-kirkwood:/ # mount /dev/sda5 /sda5
root@fvdw-sta-kirkwood:/ #

And here the output from ls comand

Code: Select all

root@fvdw-sta-kirkwood:/ # ls -l /sda5/etc
total 64
drwxr-xr-x    2 root     root          4096 Jan  1  2018 dropbear
-rw-r--r--    1 nobody   nobody        1712 May  9  2021 install-firmware.log
-rw-r--r--    1 nobody   nobody           0 Apr 18  2021 ledoffatboot
-rw-r--r--    1 root     root           128 Jan  1  2018 mdadm.conf
-rw-rw-rw-    1 nobody   nobody        8376 May  9  2021 nas_conf_db.xml
-rw-rw-rw-    1 nobody   nobody        8376 May  9  2021 nas_conf_db.xml.bak
-rw-rw-rw-    1 nobody   nobody        8375 May  9  2021 nas_conf_db.xmle
-rw-rw-rw-    1 nobody   nobody         125 Apr 22  2021 nas_ext_hdd_db.xml
-rw-r--r--    1 root     root            40 Oct  3  2009 ntp.conf
-rw-r--r--    1 nobody   nobody         311 Apr 24  2021 remote_rsync_db.xml
drwxrwxrwx    2 root     root          4096 Apr 15  2021 ssl
root@fvdw-sta-kirkwood:/ #

After that I run in Putty again

Code: Select all

dmesg

There were no errors any more.

I am convinced that the problem is solved now.
Thank you very much for your outstanding help.
Klaus

[Jocko]

So the issue on sda5 is fixed and you have now a clean fs on it.
But this does not explain why the permissions were wrong on tmp folder.

I am convinced that the problem is solved now.

In your first post, there was also issue with backups. So to be sure, you should repeat them and see if backup jobs stop again

[Leopold13]

The last two days I did a lot (really lot) of file copy actions for testing purposes. There was no failure any more til now.
Also the RSYNC-Backup did run now two times without any issue. Before I had copy failures with stop of the RSYNC-process at least every 2 days.

You are right, it does not explain the wrong permissions on tmp folder.
Probably it was a subsequent fault => it happened only after copy failure and was gone after NAS-reset.

The system seems now to be stable.
But I still will observe it in the next days.

Thank you very much.

[Leopold13]

Here a final update for my copy problem.

After check and repair with fsck (Jocko, thanks for your help) I was sure that the issue is solved.
But a few days later the problem came back.
I did again the repair with fsck, but the problem came back again...

Next action was to take out the harddisk from NAS and to built it in my PC for a deep check.
Result: defective blocks on the HDD.

I replaced the HDD with a new one, from that time no issue happened any more.
All running fast and reliable now. Really glad about fvdw-sl, which is faster and much better than the Lacie original.

Klaus