Date: Sun, 24 Feb 2019 15:52:06 +0100 (CET) From: =?ISO-8859-1?Q?Trond_Endrest=F8l?= <Trond.Endrestol@fagskolen.gjovik.no> To: FreeBSD Questions List <questions@freebsd.org> Subject: Re: size of debug symbols Message-ID: <alpine.BSF.2.21.9999.1902241546160.1450@mail.fig.ol.no> In-Reply-To: <23666.41761.759191.463104@jerusalem.litteratus.org> References: <46040D79-BA05-43F5-9213-67094355B68A@cretaforce.gr> <23664.7723.844456.222198@jerusalem.litteratus.org> <alpine.BSF.2.21.9999.1902231625350.1450@mail.fig.ol.no> <23665.37618.281478.64929@jerusalem.litteratus.org> <alpine.BSF.2.21.9999.1902240850100.1450@mail.fig.ol.no> <23666.41761.759191.463104@jerusalem.litteratus.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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: <owner-freebsd-questions@freebsd.org>
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 <freebsd-questions@mailman.ysv.freebsd.org>;
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 <freebsd-questions@freebsd.org>; 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 <freebsd-questions@freebsd.org>; 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 <freebsd-questions@freebsd.org>
(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 <jd1008@gmail.com>
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 <freebsd-questions.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-questions>,
<mailto:freebsd-questions-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-questions/>;
List-Post: <mailto:freebsd-questions@freebsd.org>
List-Help: <mailto:freebsd-questions-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-questions>,
<mailto:freebsd-questions-request@freebsd.org?subject=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 <SD 0.0 SN 00000000 MFG 00/0000 by 0x0000>
>>> 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.
>
>
>
>
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.21.9999.1902241546160.1450>