From owner-freebsd-questions@freebsd.org Sun Feb 24 14:52:14 2019 Return-Path: Delivered-To: freebsd-questions@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 53091150042F for ; Sun, 24 Feb 2019 14:52:14 +0000 (UTC) (envelope-from trond@fagskolen.gjovik.no) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id C96226FF76 for ; Sun, 24 Feb 2019 14:52:13 +0000 (UTC) (envelope-from trond@fagskolen.gjovik.no) Received: by mailman.ysv.freebsd.org (Postfix) id 8CB79150042E; Sun, 24 Feb 2019 14:52:13 +0000 (UTC) Delivered-To: questions@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 79E58150042D for ; Sun, 24 Feb 2019 14:52:13 +0000 (UTC) (envelope-from trond@fagskolen.gjovik.no) Received: from smtp.fagskolen.gjovik.no (smtp.fagskolen.gjovik.no [IPv6:2001:700:1100:1:200:ff:fe00:b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.fagskolen.gjovik.no", Issuer "Fagskolen i Gj??vik" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C3DDB6FF74 for ; Sun, 24 Feb 2019 14:52:12 +0000 (UTC) (envelope-from trond@fagskolen.gjovik.no) Received: from mail.fig.ol.no (localhost [127.0.0.1]) by mail.fig.ol.no (8.15.2/8.15.2) with ESMTPS id x1OEq7gf037781 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Sun, 24 Feb 2019 15:52:07 +0100 (CET) (envelope-from trond@fagskolen.gjovik.no) Received: from localhost (trond@localhost) by mail.fig.ol.no (8.15.2/8.15.2/Submit) with ESMTP id x1OEq7vQ037778 for ; Sun, 24 Feb 2019 15:52:07 +0100 (CET) (envelope-from trond@fagskolen.gjovik.no) X-Authentication-Warning: mail.fig.ol.no: trond owned process doing -bs Date: Sun, 24 Feb 2019 15:52:06 +0100 (CET) From: =?ISO-8859-1?Q?Trond_Endrest=F8l?= Sender: Trond.Endrestol@fagskolen.gjovik.no To: FreeBSD Questions List Subject: Re: size of debug symbols In-Reply-To: <23666.41761.759191.463104@jerusalem.litteratus.org> Message-ID: References: <46040D79-BA05-43F5-9213-67094355B68A@cretaforce.gr> <23664.7723.844456.222198@jerusalem.litteratus.org> <23665.37618.281478.64929@jerusalem.litteratus.org> <23666.41761.759191.463104@jerusalem.litteratus.org> User-Agent: Alpine 2.21.9999 (BSF 287 2018-06-16) Organization: Fagskolen Innlandet OpenPGP: url=http://fig.ol.no/~trond/trond.key MIME-Version: 1.0 X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on mail.fig.ol.no Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2019 14:52:14 -0000 On Sun, 24 Feb 2019 08:58-0500, Robert Huff wrote: > Trond Endrestøl writes: > > > > > What happens if you confine WITH_DEBUG=yes to /etc/src.conf? This > > > > way it should only affect base unless I'm mistaken. > > > > I was a bit wrong, for base it's WITHOUT_DEBUG_FILES=yes. I'm not sure > > if the same applies to localbase aka ports. See make.conf(5) and > > src.conf(5). The latter describes among others, WITHOUT_DEBUG_FILES. > > On my system - r334207 - it's only in src.conf, and the man page > is ... imprecise ... about the consequemces of using it. "avoid > building standalone debug files" - does that mean no files are built, > or that there's some kind of unified file? And wouldn't the former > make it impossible to debug non-kernel stuff in base? Ever since WITH_DEBUG_FILES became the norm, I have set WITHOUT_DEBUG_FILES=yes in /etc/src.conf on some of my experimental VMs running head and stable/{11,12}. At $WORK I can afford the extra disk space. WITHOUT_DEBUG_FILES=yes leads to a normal build, but without most debug files. Kernel debug files will still be created and placed in /usr/lib/debug/boot/kernel during make installkernel. -- Trond. From owner-freebsd-questions@freebsd.org Sun Feb 24 15:11:01 2019 Return-Path: Delivered-To: freebsd-questions@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E1AC31500B09 for ; Sun, 24 Feb 2019 15:11:00 +0000 (UTC) (envelope-from jd1008@gmail.com) Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com [IPv6:2607:f8b0:4864:20::d2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9E43A7090E for ; Sun, 24 Feb 2019 15:10:59 +0000 (UTC) (envelope-from jd1008@gmail.com) Received: by mail-io1-xd2f.google.com with SMTP id v10so5560227iop.4 for ; Sun, 24 Feb 2019 07:10:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-transfer-encoding; bh=qrtaLs+v38lEHCrgCoyw20vs+df+gOJ9cdBsytFCe6g=; b=TkaCMo/eCb4SFkhkrRkNyVlZJ6FlJy0Rg4nlyOXL4V4dKWb0ezatrTE1ky5m0uYCmn 2wwWKZA56zXKMV6rm2mQXMhVQFx/0fd8Ad5ns22jkY3fuGlmqstfJM45vC0DyDQ6X/pj l32T5nIDGlxJHIy+N1FIV1uFhm7WYdxhFSAyf+/FbIc3e0FKW0XL331Tp1Jw5geKMnjY 55eu9AjyTq+Dm20YuxJSQpjAOy1uOgIJnM9eDZFB6jekBVIqb9bfdrxNo+iFq+ADgeQL bqthikxXfY5eTnIafghXLvywszwxfQuG/OUUC+EXR0XPwWN918wWD0FopRxbogUY6cCb xLGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-transfer-encoding; bh=qrtaLs+v38lEHCrgCoyw20vs+df+gOJ9cdBsytFCe6g=; b=PAlAhN/GWnw2qqadQhIfEQ9FXr79yZ5vUzmrEqSvE0wRneiAJJRAXII7OhuiZA0WiR K/xeOaTvahHQY1STwjzv5WtA4hvwUDnax7eWqe6AuXyXTa2+DAeDXw/9UZQkuOw762bh FTHk4zCeSyJDyJmerSrkj6TgjbGfwj7qpVYdn1xJN66MZy9VKsadgJZ8REPxs8XKAxMC DQoDZYYTaeNLD8olFaLnvj/YxDIAbDwh/Zz5XKyU9/vHwPBUIhiXutAhTRIBCOv8jMZH jLldUzze0ChyfUM7J7eZ3ijxFxyPGMQX8JO2KfCoTOCqntbDI97hF/NlYVpFTqWV51N3 YLxw== X-Gm-Message-State: AHQUAubkIzxNXX3VhK33ukFdCJjrrp0AoGgDjv6rjKl1qXByz/BELSNm oJfJJLh+gGD8e+RrjUC9gTlZWBcEds8= X-Google-Smtp-Source: AHgI3IZceM9oVMWIiRa0iNgc+nBvgep0qR1x5iYfmj47L6YI9ERVP0HDpXwij/WSXZ5gz4OO1WlrTQ== X-Received: by 2002:a6b:500a:: with SMTP id e10mr6745256iob.127.1551021058490; Sun, 24 Feb 2019 07:10:58 -0800 (PST) Received: from localhost.localdomain (50-243-4-3-static.hfc.comcastbusiness.net. [50.243.4.3]) by smtp.gmail.com with ESMTPSA id v5sm2846347iof.39.2019.02.24.07.10.56 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 24 Feb 2019 07:10:57 -0800 (PST) Message-ID: <5C72B3FF.7020002@gmail.com> Date: Sun, 24 Feb 2019 08:10:55 -0700 From: JD User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: freebsd-questions@freebsd.org Subject: Re: Recover failed SD card References: <2341a9ac-42aa-737e-441f-b69cccc826c6@netfence.it> <20190224055321.14e7e462.freebsd@edvax.de> In-Reply-To: <20190224055321.14e7e462.freebsd@edvax.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 9E43A7090E X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=TkaCMo/e; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of jd1008@gmail.com designates 2607:f8b0:4864:20::d2f as permitted sender) smtp.mailfrom=jd1008@gmail.com X-Spamd-Result: default: False [-6.74 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-0.96)[-0.962,0]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-questions@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; IP_SCORE(-2.77)[ip: (-9.15), ipnet: 2607:f8b0::/32(-2.64), asn: 15169(-2.00), country: US(-0.07)]; RCVD_IN_DNSWL_NONE(0.00)[f.2.d.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0] X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2019 15:11:01 -0000 There is a free utility called testdisk. I used it to recover files from a dead drive that would not mount and would not re-format. I recovered about 200+GB of important files. On 02/23/2019 09:53 PM, Polytropon wrote: > On Sat, 23 Feb 2019 17:50:27 +0100, Andrea Venturoli wrote: >> A customer of mine gave me an SD card which is quite surely failing. > >From what you're describing, it _has_ failed already. ;-) > > > >> I'm trying to recover what I can. > Did you ask your customer to recover from his backups? > Yes, of course you did. :-) > > Okay, let's see: > > > >> I first tried using an USB based reader: altough the SD card should be >> 4GB in size, dd just copies 121MB. So does recoverdisk. > This will probably apply to _any_ copying tool. For things > where dd fails, I often try dd_rescue and ddrescue (two > different programs). They can lower the block size and > perform several retries, but that won't help as the device > reports "end of medium" at 121 MB. And you cannot read > beyond the end of medium. That particular information is > provided by the medium itself. > > > >> "camcontrol readcap /dev/da3" gives: >>> Last Block: 248319, Block Length: 512 bytes >> which agains means about 121MB. > This is "correct" according to what the card identifies as. > > > >> I put the card in another box and i get: >>> mmcsd0: 127MB >>> at mmc0 0.4MHz/4bit/65535-block > Above assumption is confirmed. > > > >> Is there any way I can get beyond this 121-127MB limit and read what I >> can of the rest? >> I looked into camcontrol's man page, but came up with no idea. > That's probably not directly possible. The media controller > (the "computer" on the SD card) has decided to turn itself > into a 127 MB card, for whatever reason. A _possible_ reason > is that the card is worn out, causing malfunctions. The same > happens to SSDs, but those usually turn into "read-only media" > to preserve the existing information. But for the price of > an SD card, you cannot expect this. > > > >> The card should hold pictures, so I could go ahead with photorec once I >> got an even partial image. > That is the recommended approach. Maybe you can already recover > a fraction of the images stored on the card. > > > > There is another possibility, but it's actually _very_ hard > to do, and it's not guaranteed to work: > > Obtain an identical SD card. It has to be "as identical as > possible": same control unit, same memory unit, same firmware > revision (yes, there's "a whole computer with hard- and software" > on that thing!). Transplant the old memory chip to the new > card, removing its new memory chip (empty) beforehand. Then > try another identification. > > If it's a micro-SD card, don't inhale the chip. ;-) > > As I mentioned, this is quite problematic, because the new > controlller might see a worn-out memory chip and act the same > as the old one. The firmware is closed source, so you don't > have a chance to _know_ how it will act. > > > > >