Date: Fri, 27 Aug 2010 16:20:41 +0300 From: Manolis Kiagias <sonicy@otenet.gr> To: Matthias Apitz <guru@unixarea.de> Cc: FreeBSD-questions@freebsd.org Subject: Re: installing FreeBSD in VMWare-player Message-ID: <4C77BBA9.1030804@otenet.gr> In-Reply-To: <20100827121727.GA4224@current.Sisis.de> References: <20100823070819.GB2539@current.Sisis.de> <4C7241C2.2000305@otenet.gr> <20100823112621.GA4367@current.Sisis.de> <4C725BFC.90006@otenet.gr> <20100824084225.GA2160@current.Sisis.de> <4C739A78.4070303@otenet.gr> <20100827072416.GA2516@current.Sisis.de> <4C778001.3030809@otenet.gr> <20100827121727.GA4224@current.Sisis.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On 27/08/2010 3:17 μ.μ., Matthias Apitz wrote: > El día Friday, August 27, 2010 a las 12:06:09PM +0300, Manolis Kiagias escribió: > >> On 27/08/2010 10:24 ??.??., Matthias Apitz wrote: >>> Is it possible that the data gets corrupt on an USB key after some time? >>> I'm wondering why the system even is intact to be booted from... >>> >>> Will prepare the key again or just fill in the dumps I have... >>> >>> matthias >>> >> I've heard of stories of data 'fading out' from USB flash drives after >> some period of complete inactivity. >> Haven't experienced this myself though. Otherwise your procedure looks >> fine and it shouldn't fail. > A dump of the key gives several error messages: > > # dump -0au -f usb8.dmp /dev/da0s1a > DUMP: Date of this level 0 dump: Fri Aug 27 14:06:04 2010 > DUMP: Date of last level 0 dump: the epoch > DUMP: Dumping /dev/da0s1a to usb8.dmp > DUMP: mapping (Pass I) [regular files] > DUMP: mapping (Pass II) [directories] > DUMP: estimated 3980686 tape blocks. > DUMP: dumping (Pass III) [directories] > DUMP: dumping (Pass IV) [regular files] > DUMP: 52.81% done, finished in 0:04 at Fri Aug 27 14:15:35 2010 > DUMP: DUMP: read error from /dev/da0s1a: Input/output error: [block > 4992928]: count=8192 > read error from /dev/da0s1a: Input/output error: [block 4992870]: > count=10240 > DUMP: read error from /dev/da0s1a: Input/output error: [block > 4992896]: count=7168 > DUMP: DUMP: read error from /dev/da0s1a: Input/output error: [sector > 4992928]: count=512 > DUMP: read error from /dev/da0s1a: Input/output error: [sector > 4992870]: count=512 > read error from /dev/da0s1a: Input/output error: [sector 4992896]: > count=512 > DUMP: DUMP: read error from /dev/da0s1a: Input/output error: [sector > 4992899]: count=512 > DUMP: read error from /dev/da0s1a: Input/output error: [sector > 4992931]: count=512 > read error from /dev/da0s1a: Input/output error: [sector 4992873]: > count=512 > DUMP: DUMP: read error from /dev/da0s1a: Input/output error: [block > 5032906]: count=10240 > read error from /dev/da0s1a: Input/output error: [block 5032928]: > count=9216 > DUMP: read error from /dev/da0s1a: Input/output error: [block > 5032946]: count=7168 > > I will re-create the key or even use another media; > > matthias > Try recreating, preferably newfs the key first. Don't be surprised if you find out you need a new USB key. This reminds me of a recent incident I had with another key (of a respected brand as well) which failed and disappeared(!) from the bus while I was writing to it, plugged in on my freebsdgr.org server. Not only I had to umount -f, but subsequently seems the whole USB subsystem got 'stuck' and I had to reboot the server for it to work again. As I said, I have not witnessed 'data fading' in USB flash drives, but this the third one I throw away due to total hardware failure...
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4C77BBA9.1030804>