On 12/19/2009 03:27 AM, fedora-list-request@redhat.com wrote:
Subject: Re: Tar oddity... From: Chris racerx@makeworld.com Date: Fri, 18 Dec 2009 17:16:47 -0600
To: fedora-list@redhat.com
On Fri, 18 Dec 2009 14:47:26 +0100 DBFreddog_de@yahoo.co.uk wrote:
On 12/18/2009 01:23 PM,fedora-list-request@redhat.com wrote:
Subject: Re: Tar oddity... From: Ralf Corsepiusrc040203@freenet.de Date: Fri, 18 Dec 2009 07:28:09 +0100
To: "Community assistance, encouragement, and advice for using Fedora." fedora-list@redhat.com
On 12/17/2009 11:51 PM, DB wrote:
> Hi All, > > I've just (re)installed F12 on my laptop,& tried to copy my home > directory (F11) from my desktop using tar. > > The create went OK,& I can do tar tvh on the desktop no probs. > But when I connect the external drive to the laptop, tar tvh says > it's closing because of previous errors; ark refuses to open > the .tar.gz file as it has errors.
Please show us the actual error message. You are not providing sufficient details to be able to help.
Ralf
Hi Ralf,
ark puts up a dialog box reading the archive "xxxx.tar.gz" failed with the error 'The archive reading failed with message: Damaged tar archive'
and tar tvf reads 45 entries and then
tar: skipping to next header tar: exiting with failure status due to previous errorsbut doesn't say what previous errors!
TIA
Dave
Why not use tar -zxvf xxx.tar.gz unless, its just xxx.tar, then it would be tar -xvf xxx.tar
Otherwise, perhaps your archive never finished correctly or is corrupt. it would be interesting to see the command you used to create the archive.
-- Best regards, Chris
Hi Chris,
The original command was
tar cvzf F11_Home_Dave_20091217.tar.gz /home/Dave
and the "problem" is that tar tvh F11*gz lists all the files on the F11 desktop, but when the external HDD is transferred to the F12 laptop, tar tvh (and ark) give the errors quoted...
The reason I went with tar tvh was (to try) to check the contents of the file after "open with ark" in Dollphin spat out the errors. I guess that actually trying to extract the files when the table of contents fails would not be any more successful?
Thanks
Dave
DB wrote:
The reason I went with tar tvh was (to try) to check the contents of the file after "open with ark" in Dollphin spat out the errors. I guess that actually trying to extract the files when the table of contents fails would not be any more successful?
Run
md5sum F11_Home_Dave_20091217.tar.gz
on both machines. If you get two different results, something bad is happening.
On Mon, 21 Dec 2009 00:45:13 +0100 Roberto Ragusa mail@robertoragusa.it wrote:
DB wrote:
The reason I went with tar tvh was (to try) to check the contents of the file after "open with ark" in Dollphin spat out the errors. I guess that actually trying to extract the files when the table of contents fails would not be any more successful?
Run
md5sum F11_Home_Dave_20091217.tar.gz
on both machines. If you get two different results, something bad is happening.
I agree with the above! I take it one step beyond that. During my nightly backups, I have it create the hash for all my tarballs. Pretty simple to do. As an example:
if you have backup /home/you, /etc and /root to tarballs:
home.you.tar.gz etc.tar.gz root.tar.gz
Doing something like md5sum *.gz > checksum.md5 will create and store the hash info in the file, checksum.md5
Then to verify, md5sum -c checksum.md5 If all goes well, you'll see something like:
home.you.tar.gz OK etc.tar.gz OK root.tar.gz OK
Of course, you probably knew all this anyways.
2009/12/21 DB Freddog_de@yahoo.co.uk
Hi Chris,
The original command was
tar cvzf F11_Home_Dave_20091217.tar.gz /home/Dave
and the "problem" is that tar tvh F11*gz lists all the files on the F11 desktop, but when the external HDD is transferred to the F12 laptop, tar tvh (and ark) give the errors quoted...
Make sure that you are "safely removing" your drive before you unplug it.
Copy the file, run the "sync" command and then unmount. Make sure that it is definitely unmounted before you unplug it. It could be that you are removing it before it has *actually* synchronises the data.
I agree with the checksum suggestions below and I'm sure they will show a difference. If so, try the above. Copy, run sync, run checksum.
-c
On 12/21/2009 12:45 AM, Roberto Ragusa wrote:
DB wrote:
The reason I went with tar tvh was (to try) to check the contents of the file after "open with ark" in Dollphin spat out the errors. I guess that actually trying to extract the files when the table of contents fails would not be any more successful?
Run
md5sum F11_Home_Dave_20091217.tar.gz
on both machines. If you get two different results, something bad is happening.
Ahhhhh that gives 2 entirely different 32-digit numbers....
on the F11 desktop cee716a79cc7af0ee8f5f2613ca50578
and on the F12 laptop 802d5ea893af6f936e77b81cf00a45fb
Rusult of uname -ar on each: Desktop Linux Fedora-Blue 2.6.30.9-102.fc11.i586 #1 SMP Thu Dec 3 23:46:37 EST 2009 i686 athlon i386 GNU/Linux
Laptop Linux Fedora_Toshi 2.6.31.6-166.fc12.i686 #1 SMP Wed Dec 9 11:14:59 EST 2009 i686 i686 i386 GNU/Linux
Thanks for the suggestion Roberto..... where to next?????
Dave
On 12/21/2009 12:45 AM, Roberto Ragusa wrote:
DB wrote:
The reason I went with tar tvh was (to try) to check the contents of the file after "open with ark" in Dollphin spat out the errors. I guess that actually trying to extract the files when the table of contents fails would not be any more successful?
Run
md5sum F11_Home_Dave_20091217.tar.gz
on both machines. If you get two different results, something bad is happening.
Ahhhhh that gives 2 entirely different 32-digit numbers....
on the F11 desktop cee716a79cc7af0ee8f5f2613ca50578
and on the F12 laptop 802d5ea893af6f936e77b81cf00a45fb
Rusult of uname -ar on each: Desktop Linux Fedora-Blue 2.6.30.9-102.fc11.i586 #1 SMP Thu Dec 3 23:46:37 EST 2009 i686 athlon i386 GNU/Linux
Laptop Linux Fedora_Toshi 2.6.31.6-166.fc12.i686 #1 SMP Wed Dec 9 11:14:59 EST 2009 i686 i686 i386 GNU/Linux
Thanks for the suggestion Roberto..... where to next?????
Dave
Are the two files the same size? Did you do the copy via a memory stick? If so, did you 'unmount' the memory stick on the source machine before unplugging it?
Cheers, Terry
DB wrote:
On 12/21/2009 12:45 AM, Roberto Ragusa wrote:
DB wrote:
The reason I went with tar tvh was (to try) to check the contents of the file after "open with ark" in Dollphin spat out the errors. I guess that actually trying to extract the files when the table of contents fails would not be any more successful?
Run
md5sum F11_Home_Dave_20091217.tar.gz
on both machines. If you get two different results, something bad is happening.
Ahhhhh that gives 2 entirely different 32-digit numbers....
on the F11 desktop cee716a79cc7af0ee8f5f2613ca50578
and on the F12 laptop 802d5ea893af6f936e77b81cf00a45fb
Rusult of uname -ar on each: Desktop Linux Fedora-Blue 2.6.30.9-102.fc11.i586 #1 SMP Thu Dec 3 23:46:37 EST 2009 i686 athlon i386 GNU/Linux
Laptop Linux Fedora_Toshi 2.6.31.6-166.fc12.i686 #1 SMP Wed Dec 9 11:14:59 EST 2009 i686 i686 i386 GNU/Linux
Thanks for the suggestion Roberto..... where to next?????
Copy the file back. See if it changes. Find out where the difference is with cmp.
Andrew.
2009/12/22 DB Freddog_de@yahoo.co.uk:
Ahhhhh that gives 2 entirely different 32-digit numbers....
on the F11 desktop cee716a79cc7af0ee8f5f2613ca50578
and on the F12 laptop 802d5ea893af6f936e77b81cf00a45fb
Did you run the sync command before you unmounted and unplugged the usb drive?
Also, a stupid question, is the tar too big to fit on the USB device (which is only 4GB).
Are you overclocking your desktop's CPU?
-c
On 12/21/2009 01:53 AM, Chris Smart wrote:
2009/12/21 DB <Freddog_de@yahoo.co.uk mailto:Freddog_de@yahoo.co.uk>
Hi Chris, The original command was tar cvzf F11_Home_Dave_20091217.tar.gz /home/Dave and the "problem" is that tar tvh F11*gz lists all the files on the F11 desktop, but when the external HDD is transferred to the F12 laptop, tar tvh (and ark) give the errors quoted...Make sure that you are "safely removing" your drive before you unplug it.
Copy the file, run the "sync" command and then unmount. Make sure that it is definitely unmounted before you unplug it. It could be that you are removing it before it has *actually* synchronises the data.
I agree with the checksum suggestions below and I'm sure they will show a difference. If so, try the above. Copy, run sync, run checksum.
-c
Did you run the sync command before you unmounted and unplugged the usb drive?
Also, a stupid question, is the tar too big to fit on the USB device (which is only 4GB).
Are you overclocking your desktop's CPU?
Ok....
I used the "Safely unmount" (or disconnect?) in Dolphin. Tried copying the 'faulty' tar.gz & safely disconnecting, sysn sync with same results.... I've since tried making a new tar.gz, followed by 2 sync commands (a distant memory from 1987 GNX/SysV!). With similar results - the F12 tar tvh still crashes , but MUCH further on.
The original file was 1.7GB on both machines.
To the best of my knowledge(!) I'm running my DT CPU as specified by the MB maker (Elite k7S5A 133MHz for an AMD XP2K+)
Are the two files the same size? Did you do the copy via a memory stick? If so, did you 'unmount' the memory stick on the source machine before unplugging it?
Cheers, Terry
Hi Terry,
As above, both files are 1.7GB, transfer device is a Maxtor One-Touch 500GB ext HDD, & yes, I used "safely unplug" in Dolphin before unplugging
Just tried to copy the file on the F12 laptop... only 324MB of 1.7GB get copied.
I'm beginning to wonder whether my F12 installation is without error, as I keep losing my (KDE) panels. Each time I add a new one (so that I can open these files etc) the widget-adder show x copies of the widgets being in use - but I can't find a way of materialising the invisible panels.... Also, if I "zoom out" I see 2 "screens", one plain blue, one the (for want of a better term) "blue blobby one" - or is this somethinf=g to do with disabling the laptop screen with Marko's xrandr script???
Confusion reigns supreme!
Thanks all for your help & suggestions
Dave
DB wrote:
Just tried to copy the file on the F12 laptop... only 324MB of 1.7GB get copied.
I'm beginning to wonder whether my F12 installation is without error, as I keep losing my (KDE) panels. Each time I add a new one (so that I can open these files etc) the widget-adder show x copies of the widgets being in use - but I can't find a way of materialising the invisible panels.... Also, if I "zoom out" I see 2 "screens", one plain blue, one the (for want of a better term) "blue blobby one" - or is this somethinf=g to do with disabling the laptop screen with Marko's xrandr script???
Confusion reigns supreme!
It looks like you could have some stability issues.
I would try some basic test for your hardware. For example:
while true; do md5sum somefilewithdimensionabout50MB; done
Are the checksum all the same or do they change? If they change, causes could be: overclocking, bad power supply, bad RAM, bad CPU or software issues (bad kernel, unstable drivers).
Try then with a bigger file, so it will have to read the disk. You can try the external disk, so you will test the USB part too. Create a file of 500MB with:
dd if=/dev/urandom of=myfile bs=1048576 count=500
(replace 500 with what you want), then checksum it
while true; do md5sum myfile; done
use a dimension bigger than the RAM you have on your machine, so you defeat the caching that Linux will try to do.
Another test could be
[create some file called a] cp filea fileb while true; do cmp -l a b;done
The idea is do have the machine do a lot of work for which you already know the results. If you get a bad answer (a and b are different??) you know the machine is not working well.
On Mon, 2009-12-21 at 11:53 +1100, Chris Smart wrote:
2009/12/21 DB Freddog_de@yahoo.co.uk Hi Chris,
The original command was tar cvzf F11_Home_Dave_20091217.tar.gz /home/Dave and the "problem" is that tar tvh F11*gz lists all the files on the F11 desktop, but when the external HDD is transferred to the F12 laptop, tar tvh (and ark) give the errors quoted...Make sure that you are "safely removing" your drive before you unplug it.
Copy the file, run the "sync" command and then unmount. Make sure that it is definitely unmounted before you unplug it. It could be that you are removing it before it has *actually* synchronises the data.
I agree with the checksum suggestions below and I'm sure they will show a difference. If so, try the above. Copy, run sync, run checksum.
AFAIK in modern Linux systems running "sync" doesn't actually guarantee anything beyond what "umount" is already doing.
poc
Il giorno mer, 23/12/2009 alle 08.46 +0000, Patrick O'Callaghan ha scritto:
AFAIK in modern Linux systems running "sync" doesn't actually guarantee anything beyond what "umount" is already doing.
poc
The umount command does the "sync" so if you run "umount /media/My_External_HDD" and then you get back to the shell, you are safe to remove the HDD. I've experienced file corruption and oddity with reiserfs on a 400Gb HDD, nothing important was lost, but it was quite annoying. Which FS are you using on the HDD?
Pietro
2009/12/23 Pietro "m0nt0" Montorfano monto84@gmail.com:
The umount command does the "sync" so if you run "umount /media/My_External_HDD" and then you get back to the shell, you are safe to remove the HDD.
My point was to run the sync command and then run the checksum before unmounting This ensures that the data is written to the disk so that it can be read off the physical device.
-c
Il giorno mer, 23/12/2009 alle 20.23 +1100, Chris Smart ha scritto:
2009/12/23 Pietro "m0nt0" Montorfano monto84@gmail.com:
The umount command does the "sync" so if you run "umount /media/My_External_HDD" and then you get back to the shell, you are safe to remove the HDD.
My point was to run the sync command and then run the checksum before unmounting This ensures that the data is written to the disk so that it can be read off the physical device.
Well that's not totally true, the data could be in cache (for read) so with the sync command you are sure that all the bits are written to the physical device, but when you read the data may comes from the OS cache, may be that you can do a large copy (eg. copy 10-12Gb of data depending on your RAM/SWAP configuration) and then make a checksum of the data. you can umount the device, run fsck on it, reboot, remount the device and then issue an md5. If everything is right you should have the same checksum.
Pietro
2009/12/23 Pietro "m0nt0" Montorfano monto84@gmail.com:
Well that's not totally true, the data could be in cache (for read) so
That's true.
-c
On 12/22/2009 09:51 PM, Roberto Ragusa wrote:
DB wrote:
Just tried to copy the file on the F12 laptop... only 324MB of 1.7GB get copied.
It looks like you could have some stability issues.
I would try some basic test for your hardware. For example:
while true; do md5sum somefilewithdimensionabout50MB; done
Are the checksum all the same or do they change? If they change, causes could be: overclocking, bad power supply, bad RAM, bad CPU or software issues (bad kernel, unstable drivers).
Try then with a bigger file, so it will have to read the disk. You can try the external disk, so you will test the USB part too. Create a file of 500MB with:
dd if=/dev/urandom of=myfile bs=1048576 count=500
(replace 500 with what you want), then checksum it
while true; do md5sum myfile; done
use a dimension bigger than the RAM you have on your machine, so you defeat the caching that Linux will try to do.
Another test could be
[create some file called a] cp filea fileb while true; do cmp -l a b;done
The idea is do have the machine do a lot of work for which you already know the results. If you get a bad answer (a and b are different??) you know the machine is not working well.
Ciao Roberto,
Thanks for the testing suggestions!
So.. what I get is: -no problems when running on the F11 Desktopfor either the md5sum or the cmp, run in a while loop for a long time; -variable numbers of md5sum errors running on the F12 laptop (for example, will run 3 times with same checksum then 1 error); variable cmp errors(again, one or two clear runs then a pile of miscompares, then again several ok runs); -Ran memtest overnight without error; -tried the F12-KDE Livecd, sometimes ark opens the files, sometimes not (also tried various USB ports both direct & via a powered 7port hub with same results); -tried F11-KDE Livecd, ark opens all files without error.....
On the F11 Desktop, the ark "help-about" gives ARK Version 2.13 using KDE 4.3.4, on the F12 Laptop gives ARK version 2.13 using KDE 4.3.4, F11 Livecd gives ARK versio 2.12, using KDE 4.2.2, with yumex, I find that tar on the F12 is 1:22-10.fc12 arch 1686, on F11 is 2:1.22-4.fc11 arch i586, as I couldn't find any ark info through yumex, I had a look at /usr/bin/ark on both machines: on the F12 machine it is 54.7 KiB, on F11 is 143.2 Kib.
If /usr/bin/ark is fubared, any idea how I can best put it right?
Again, many thanks for your help
Dave
DB wrote:
On 12/22/2009 09:51 PM, Roberto Ragusa wrote:
-variable numbers of md5sum errors running on the F12 laptop (for example, will run 3 times with same checksum then 1 error); variable cmp errors(again, one or two clear runs then a pile of miscompares, then again several ok runs);
That is really bad. If the machine is unreliable, any kind of hard computation (such as data compression) will have problems. Maybe the problem is caused by something bad in the F12 distro (such as new graphics drivers). I suppose you tried the LiveCD on the laptop, and it looks like F11=good, F12=bad.
If /usr/bin/ark is fubared, any idea how I can best put it right?
yum reinstall of the correct rpm (kdeutils?).
Try also "rpm -V" to check.
But if md5sum and cmp randomly fail, the problem is not ark. The machine is unstable, for hardware or software reasons.
2010/1/7 Roberto Ragusa mail@robertoragusa.it:
That is really bad. If the machine is unreliable, any kind of hard computation (such as data compression) will have problems.
I agree. Have you run memtest on it, Dave? It should be in the repo or already an option from the boot menu. You can download the live CD from http://www.memtest.org if you prefer.
If your memory passes, it could be faulty/overclocked CPU or overheating. Check these things too.
-c
-
Andrew Haley -
Chris -
Chris Smart -
DB -
Patrick O'Callaghan -
Pietro "m0nt0" Montorfano -
Roberto Ragusa -
Terry Horsnell