From owner-freebsd-questions@FreeBSD.ORG Fri Aug 27 13:20:43 2010 Return-Path: Delivered-To: FreeBSD-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B1BE110656AA for ; Fri, 27 Aug 2010 13:20:43 +0000 (UTC) (envelope-from sonicy@otenet.gr) Received: from rosebud.otenet.gr (rosebud.otenet.gr [83.235.67.42]) by mx1.freebsd.org (Postfix) with ESMTP id 389828FC1B for ; Fri, 27 Aug 2010 13:20:42 +0000 (UTC) Received: from pulstar.local (athedsl-4365974.home.otenet.gr [79.130.14.134]) by rosebud.otenet.gr (8.13.8/8.13.8/Debian-3) with ESMTP id o7RDKfse004419; Fri, 27 Aug 2010 16:20:41 +0300 Message-ID: <4C77BBA9.1030804@otenet.gr> Date: Fri, 27 Aug 2010 16:20:41 +0300 From: Manolis Kiagias User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Matthias Apitz 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> In-Reply-To: <20100827121727.GA4224@current.Sisis.de> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: FreeBSD-questions@freebsd.org Subject: Re: installing FreeBSD in VMWare-player X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2010 13:20:43 -0000 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...