You were right with your asumption regardind early alpha ext4. I did try to follow your recommendations on Lenny, where e2fsprogs 1.41.0 is currently standard. Issued followig commands:
-------------------
ingo@pp:~$ tune2fs -E test_fs /dev/sdc3
bash: tune2fs: command not found
ingo@pp:~$ su
Passwort:
pp:/home/ingo# tune2fs -E test_fs /dev/sdc3
tune2fs 1.41.0 (10-Jul-2008)
Setting test filesystem flag
pp:/home/ingo# mount -t ext4dev /dev/sdc3 /mnt
pp:/home/ingo#
---------------------------
Great: it mounts and I can smoothly access the data on /dev/sdc3 - see here:
---------------------------
ingo@pp:~$ ls -l /mnt
insgesamt 48
-rw------- 1 root root 6144 16. Jul 18:45 aquota.user
drwx------ 2 root root 16384 16. Jul 18:44 lost+found
drwxrwxrwx 3 root root 4096 17. Jul 22:08 Public
drwxrwxrwx 2 root root 4096 16. Jul 18:45 Qdownload
drwxrwxrwx 2 root root 4096 16. Jul 18:45 Qmultimedia
drwxrwxrwx 2 root root 4096 16. Jul 18:45 Qrecordings
drwxrwxrwx 2 root root 4096 16. Jul 18:45 Qusb
drwxrwxrwx 2 root root 4096 16. Jul 18:45 Qweb
ingo@pp:~$ ls -l /mnt/Public
insgesamt 4
drwxr-xr-x 2 500 crontab 4096 17. Jul 22:44 backup
ingo@pp:~$ ls -l /mnt/Public/backup
insgesamt 4
-rw-rw-rw- 1 ingo users 1958934821 17. Jul 22:27 sda5.tgz.000
-rw-r--r-- 1 root root 47 17. Jul 22:44 sda5.tgz.000.md5
ingo@pp:~$
-------------------------------
1e3 THANKS to YOU - all data are still there - that will be honoured by many QNAP TS-209 users!
========================================================
Now to your recent request regarding the image:
it still crashes on Hardy, see this output:
and I found this file in /var/crash:
50868 2008-08-14 19:45 _sbin_e2fsck.0.crash
I do attach the crash report here as well
What is amazing:
I also get crash reports from Apport in Nautilus at the same occasion, but those reports are incomplete/defect, so I cannot file a bug report for them. Appears to me that is its related or similar or even identical to the many reports on https://bugs.launchpad.net/bugs/182345
So maybe, the origin for the crash lies in Nautilus not beheaving correctly???
Please excuse if I conclude nonsense, I am not familiar with any programming, just an attentive user and fan of Ubuntu/Debian,
Ingo
Congratulations Ted!
You were right with your asumption regardind early alpha ext4. I did try to follow your recommendations on Lenny, where e2fsprogs 1.41.0 is currently standard. Issued followig commands: ------- ------- ------
-------------------
ingo@pp:~$ tune2fs -E test_fs /dev/sdc3
bash: tune2fs: command not found
ingo@pp:~$ su
Passwort:
pp:/home/ingo# tune2fs -E test_fs /dev/sdc3
tune2fs 1.41.0 (10-Jul-2008)
Setting test filesystem flag
pp:/home/ingo# mount -t ext4dev /dev/sdc3 /mnt
pp:/home/ingo#
-------
Great: it mounts and I can smoothly access the data on /dev/sdc3 - see here: ------- ------- ------ ------- ------- ------- ---
-------
ingo@pp:~$ ls -l /mnt
insgesamt 48
-rw------- 1 root root 6144 16. Jul 18:45 aquota.user
drwx------ 2 root root 16384 16. Jul 18:44 lost+found
drwxrwxrwx 3 root root 4096 17. Jul 22:08 Public
drwxrwxrwx 2 root root 4096 16. Jul 18:45 Qdownload
drwxrwxrwx 2 root root 4096 16. Jul 18:45 Qmultimedia
drwxrwxrwx 2 root root 4096 16. Jul 18:45 Qrecordings
drwxrwxrwx 2 root root 4096 16. Jul 18:45 Qusb
drwxrwxrwx 2 root root 4096 16. Jul 18:45 Qweb
ingo@pp:~$ ls -l /mnt/Public
insgesamt 4
drwxr-xr-x 2 500 crontab 4096 17. Jul 22:44 backup
ingo@pp:~$ ls -l /mnt/Public/backup
insgesamt 4
-rw-rw-rw- 1 ingo users 1958934821 17. Jul 22:27 sda5.tgz.000
-rw-r--r-- 1 root root 47 17. Jul 22:44 sda5.tgz.000.md5
ingo@pp:~$
-------
1e3 THANKS to YOU - all data are still there - that will be honoured by many QNAP TS-209 users! ======= ======= ======= ======= ======= ======= =======
=======
Now to your recent request regarding the image:
it still crashes on Hardy, see this output:
# /sbin/e2fsck ./qnap-sdc3.img s):Segmentation fault (core dumped) /home/ingo/ data/temp/ QNAP-ext3+ #
e2fsck 1.40.8 (13-Mar-2008)
./qnap-sdc3.img has unsupported feature(
root@pp:
and I found this file in /var/crash: 0.crash
50868 2008-08-14 19:45 _sbin_e2fsck.
I do attach the crash report here as well
What is amazing: /bugs.launchpad .net/bugs/ 182345
I also get crash reports from Apport in Nautilus at the same occasion, but those reports are incomplete/defect, so I cannot file a bug report for them. Appears to me that is its related or similar or even identical to the many reports on
https:/
So maybe, the origin for the crash lies in Nautilus not beheaving correctly???
Please excuse if I conclude nonsense, I am not familiar with any programming, just an attentive user and fan of Ubuntu/Debian,
Ingo