dumpe2fs/dump/restore not working correctly for ext4?
Justin Piszcz
I need to look into this more obviously and try other dumps etc, but I
even tried extracting a single (smaller) directory and it also segfaulted,
has dump been tested properly with ext4?
# restore -f ../p34-root-2010-03-02.ext4dump -r .
Segmentation fault (core dumped)
(gdb) bt full
#0 0x000000000040d03d in ?? ()
No symbol table info available.
#1 0x000000000040d336 in ?? ()
No symbol table info available.
#2 0x000000000040e1a4 in ?? ()
No symbol table info available.
#3 0x0000000000408d5b in ?? ()
No symbol table info available.
#4 0x0000000000407d92 in ?? ()
No symbol table info available.
#5 0x00007f8df3361abd in __libc_start_main () from /lib/libc.so.6
No symbol table info available.
#6 0x0000000000403019 in ?? ()
No symbol table info available.
#7 0x00007fffa98b8bb8 in ?? ()
No symbol table info available.
#8 0x000000000000001c in ?? ()
No symbol table info available.
#9 0x0000000000000005 in ?? ()
No symbol table info available.
#10 0x00007fffa98b8e18 in ?? ()
No symbol table info available.
#11 0x00007fffa98b8e20 in ?? ()
No symbol table info available.
#12 0x00007fffa98b8e23 in ?? ()
No symbol table info available.
#13 0x00007fffa98b8e43 in ?? ()
No symbol table info available.
#14 0x00007fffa98b8e46 in ?? ()
No symbol table info available.
#15 0x0000000000000000 in ?? ()
No symbol table info available.
(gdb)
Justin.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Justin Piszcz
On Thu, 4 Mar 2010, Justin Piszcz wrote:
> Hi,
>
> I need to look into this more obviously and try other dumps etc, but I even
> tried extracting a single (smaller) directory and it also segfaulted, has
> dump been tested properly with ext4?
>
> # restore -f ../p34-root-2010-03-02.ext4dump -r .
> Segmentation fault (core dumped)
And from another day:
p34:/x2/bup/p34/2010-03-01/d# restore -f ../p34-root-2010-03-01.ext4dump
-r .
Segmentation fault (core dumped)
p34:/x2/bup/p34/2010-03-01/d# ls
a/ core.restore.18181 l2/ nfs/ sbin/ var/
app@ dev/ lib/ opt/ selinux/ x@
appc@ etc/ lib64@ proc/ sys/ x2@
bin/ home/ lost+found/ r1/ tmp/ x3@
boot/ initrd/ media/ restoresymtable usr/ x4@
cdrom@ l1/ mnt/ root/ vapp@ x5@
p34:/x2/bup/p34/2010-03-01/d#
Does anyone use dump/restore with ext4?
ty...@mit.edu
> Hi,
>
> I need to look into this more obviously and try other dumps etc, but
> I even tried extracting a single (smaller) directory and it also
> segfaulted, has dump been tested properly with ext4?
Was dump/restore statically or dynamically linked? And with which
version of libext2fs from e2fsprogs?
- Ted
Justin Piszcz
On Thu, 4 Mar 2010, ty...@mit.edu wrote:
> On Thu, Mar 04, 2010 at 10:19:57AM -0500, Justin Piszcz wrote:
>> Hi,
>>
>> I need to look into this more obviously and try other dumps etc, but
>> I even tried extracting a single (smaller) directory and it also
>> segfaulted, has dump been tested properly with ext4?
>
> Was dump/restore statically or dynamically linked? And with which
> version of libext2fs from e2fsprogs?
>
> - Ted
>
Hi,
I tried restoring from two different datasets on one machine <10GB and another
one ~30GB, all files are corrupted, other users report the same problem:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=511651
https://lists.ubuntu.com/archives/universe-bugs/2009-June/098729.html
Per your requests:
They are dynamically linked.
This is standard Debian Testing x86_64, nothing custom (in the
distribution).
p34:~# ldd `which dump`
linux-vdso.so.1 => (0x00007fff93192000)
libext2fs.so.2 => /lib/libext2fs.so.2 (0x00007f0bdf559000)
libcom_err.so.2 => /lib/libcom_err.so.2 (0x00007f0bdf356000)
libblkid.so.1 => /lib/libblkid.so.1 (0x00007f0bdf141000)
libuuid.so.1 => /lib/libuuid.so.1 (0x00007f0bdef3d000)
libc.so.6 => /lib/libc.so.6 (0x00007f0bdebe9000)
libpthread.so.0 => /lib/libpthread.so.0 (0x00007f0bde9cc000)
/lib64/ld-linux-x86-64.so.2 (0x00007f0bdf79a000)
p34:~# ldd `which restore`
linux-vdso.so.1 => (0x00007fff857ed000)
libext2fs.so.2 => /lib/libext2fs.so.2 (0x00007f5b5c3cd000)
libcom_err.so.2 => /lib/libcom_err.so.2 (0x00007f5b5c1ca000)
libe2p.so.2 => /lib/libe2p.so.2 (0x00007f5b5bfc3000)
libreadline.so.5 => /lib/libreadline.so.5 (0x00007f5b5bd83000)
libncurses.so.5 => /lib/libncurses.so.5 (0x00007f5b5bb3e000)
libc.so.6 => /lib/libc.so.6 (0x00007f5b5b7e9000)
libpthread.so.0 => /lib/libpthread.so.0 (0x00007f5b5b5cd000)
/lib64/ld-linux-x86-64.so.2 (0x00007f5b5c60e000)
libdl.so.2 => /lib/libdl.so.2 (0x00007f5b5b3c9000)
p34:~# dpkg -l | grep libext2fs
p34:~# dpkg -l | grep libe2fs
p34:~# dpkg -l | grep e2fs
ii e2fslibs 1.41.10-1 ext2/ext3/ext4 file system libraries
ii e2fsprogs 1.41.10-1 ext2/ext3/ext4 file system utilities
p34:~#
p34:~# dpkg -S /lib/libext2fs.so.2
e2fslibs: /lib/libext2fs.so.2
p34:~#
Justin.