Date: Sun, 24 Feb 2019 08:53:19 +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.1902240850100.1450@mail.fig.ol.no> In-Reply-To: <23665.37618.281478.64929@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>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 23 Feb 2019 13:37-0500, Robert Huff wrote: > Trond Endrestøl writes: > > > On Fri, 22 Feb 2019 11:07-0500, Robert Huff wrote: > > > > > I can no longer build large programs - e.g. www/webkit*, devel/llvm* > > > - using "WITH_DEBUG=yes" because it will inevitably consume 22+ > > > gbytes of disk space. (I complained about this before, and had no > > > answer as to what was going on or how to fix it.) This did not > > > happen under 11.*. > > > > 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 about to say "I expect that would work.". But: given the > size of the kernel, it is a fact not in evidence it won't have the same > problems. > It would also leave me with applications that are ... difficult > ... to debug using traditional methods. > (And more generally, I am concerned something like this can > change to such a degree either without being noticed or without being > documented. (_Is_ there documentation, other than complaints on the > mailing lists? I don't see anything in src/UPDATING, ports/UPDATING, > or (after a quick skim) in the Handbook. I'd love to be wrong here.) > One of my selling points for FreeBSD is the high quality of the > documentation; this puts that in doubt.) 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. -- Trond. From owner-freebsd-questions@freebsd.org Sun Feb 24 04:53:27 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 739411511DF6 for <freebsd-questions@mailman.ysv.freebsd.org>; Sun, 24 Feb 2019 04:53:27 +0000 (UTC) (envelope-from freebsd@edvax.de) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.kundenserver.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D508A85D8D for <freebsd-questions@freebsd.org>; Sun, 24 Feb 2019 04:53:25 +0000 (UTC) (envelope-from freebsd@edvax.de) Received: from r56.edvax.de ([92.195.28.147]) by mrelayeu.kundenserver.de (mreue009 [212.227.15.167]) with ESMTPA (Nemesis) id 1MVNF1-1gYEQn0JXT-00SQyq; Sun, 24 Feb 2019 05:53:22 +0100 Date: Sun, 24 Feb 2019 05:53:21 +0100 From: Polytropon <freebsd@edvax.de> To: Andrea Venturoli <ml@netfence.it> Cc: "freebsd-questions@freebsd.org" <freebsd-questions@freebsd.org> Subject: Re: Recover failed SD card Message-Id: <20190224055321.14e7e462.freebsd@edvax.de> In-Reply-To: <2341a9ac-42aa-737e-441f-b69cccc826c6@netfence.it> References: <2341a9ac-42aa-737e-441f-b69cccc826c6@netfence.it> Reply-To: Polytropon <freebsd@edvax.de> Organization: EDVAX X-Mailer: Sylpheed 3.1.1 (GTK+ 2.24.5; i386-portbld-freebsd8.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:PmA2XgOJcqzFMdmVFzSa1hUwXGXjk04zh3jwUtDKHyoZwPjxCfp S9rDFnul5BANtdtM7R9zfSRSnDAiNzrl3hr9E0W9GEaFT/WtZsH2bcgJyiZwqkBqsSmbKvY E+CFfBXDdcEVCFtB6mbfdlELOADNcSW/ofVM3kvvi+h5KnXsBoZ0z3jB6UYP5W/j6X33j6+ n0j4781WPdK4/Jy6NFBEw== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:koWebz63C0I=:lU7gHm3S/w8FcpZxVBdWea LEuuo1D82g4+ZBnQJQ4+qqZkLuvKwlZ93E5YJ5//5zl6ilQ+/TKCvExY9cjo5SVIk0qfeAouS sS/40JRs8/YBj0j7JaIsXlRbFUt6Dlt8EwBG10QWpqIGKp0BbyWohP4Vcvowl/Q5uxEZ8Y+PQ CsODA/32m2Sm4Wc3+NnmLdvPfOwYKE8mr+R7NLUHZzEOXEATeNFBS9BlFp+CD3HXdkZ6FIuUZ Z5w2t7jP9IwtUbzUugEfTjnq+By0SRNfQEGCB3kAbyRxJaohSJdL9HdTFWj//Iz5TFvunb7xC 2Hcf398P8mGF+E+cnJO5s5YRpEq9BkrAvd81K9HN7n9y3pvM5fbOYOGAfWIZ6Min2sHQCMW+P ZRi//xzpFoTgWHbH4XXI6atACOpOMaWQyb111blbzgYJi2rzaxCL+X5w+iveHx1NZCGGSEMlw vudP3GpyiFVQcbI3+1vcYcBCfyeM+uAkIaFI4GqqiVNik79nqrfs+F7N2f3uWAz8LQGMnoWq3 CcESprAizRF+N0Y+I84AxbdWIF995Hld5sURxVP96l94xcR/+Yq2VpcyAYKYzqsqzOgVNioI9 WldpPKKh91UwYN6t3gVAcGeE09XJARiQKZoM0VntXJWSB3m6tPC11ZXoGQ6INzjfHP5qrgErB x1F6IsOSoN9sHMVRBytMXFfJULjstrHrKsR8E06cwyBPkbwnObmJUqiJZSfu0sc9siXp+TzKl H3qjyleeCCoc/eZnc3VA9CprWEbPLWQcnxd6HyBuf2azWmuJBb3JQWNu9SA= X-Rspamd-Queue-Id: D508A85D8D X-Spamd-Bar: +++++ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [5.78 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; HAS_REPLYTO(0.00)[freebsd@edvax.de]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; HAS_ORG_HEADER(0.00)[]; MX_GOOD(-0.01)[mx01.schlund.de,mx00.schlund.de]; RCPT_COUNT_TWO(0.00)[2]; RECEIVED_SPAMHAUS_PBL(0.00)[147.28.195.92.zen.spamhaus.org : 127.0.0.10]; RCVD_TLS_LAST(0.00)[]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:8560, ipnet:212.227.0.0/16, country:DE]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; ARC_NA(0.00)[]; REPLYTO_EQ_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(0.94)[0.941,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[edvax.de]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.99)[0.993,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.99)[0.993,0]; MID_CONTAINS_FROM(1.00)[]; RCVD_IN_DNSWL_NONE(0.00)[131.126.227.212.list.dnswl.org : 127.0.5.0]; R_SPF_NA(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[131.126.227.212.rep.mailspike.net : 127.0.0.17]; RCVD_COUNT_TWO(0.00)[2]; IP_SCORE(0.46)[ip: (1.29), ipnet: 212.227.0.0/16(-0.85), asn: 8560(1.87), country: DE(-0.01)] 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 04:53:27 -0000 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. -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ...
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.21.9999.1902240850100.1450>