From owner-freebsd-current@FreeBSD.ORG Thu Oct 30 14:24:52 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 55C88B96 for ; Thu, 30 Oct 2014 14:24:52 +0000 (UTC) Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com [209.85.212.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D58F911A for ; Thu, 30 Oct 2014 14:24:51 +0000 (UTC) Received: by mail-wi0-f179.google.com with SMTP id h11so7560480wiw.6 for ; Thu, 30 Oct 2014 07:24:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=xNfFTxufkJma8vPbEN6tY2dS1f5yf7qrRJd0Z45L820=; b=c1bKumrRI8kp4+sDWgKwKkzl9QEAGcXQrTDaI5NifTdwNsQnNBE3OsxQrdWgzpUQSS HGexF4yM+PicZNUc75utxEAthhxPBp+KsX3gjixW4ciGa/zW/j8VFMS1jJxchYWp8PL5 hnNN7HBnoqEw7bSeif2/D0ribEePs/ulZmaGUKEPFEDqElx21mkAbL1IDu7PKGOxFrkE mOqVuC0lKBP8RHM6EWDW7Tn6UyHCb4g6HJ0dVaFI1dpZA+KwPs3bYBmczz7aRgzG/Coj sCmHueeCcnWGzW4IZ3r2Od8GAnNCnvHdbJs7q1gaxyHIujGlM57rdl/Rvk22u71/q/Y7 V4hQ== X-Gm-Message-State: ALoCoQn5ZuDE2uH9FH7JTomlpHNpRgeCrhXwpkHoQTQkXZ6lsuoKmQ6ea9sg2c1BMb6KjJfHwQbO X-Received: by 10.180.221.129 with SMTP id qe1mr20748803wic.21.1414679089475; Thu, 30 Oct 2014 07:24:49 -0700 (PDT) Received: from [10.10.1.68] (82-69-141-170.dsl.in-addr.zen.co.uk. [82.69.141.170]) by mx.google.com with ESMTPSA id bg10sm8840982wjc.47.2014.10.30.07.24.47 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Oct 2014 07:24:48 -0700 (PDT) Message-ID: <54524A9F.8000400@multiplay.co.uk> Date: Thu, 30 Oct 2014 14:26:39 +0000 From: Steven Hartland User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Ed Maste Subject: Re: HEADS UP: Standalone kernel debug files moving out of /boot/kernel/ References: <54511A7E.1020307@multiplay.co.uk> <20141030023224.GA42236@troutmask.apl.washington.edu> <5451A843.90805@multiplay.co.uk> <076D8745-53C6-4AFE-86D3-FF9B94F4EC76@emc.com> <54520177.5000008@multiplay.co.uk> <44A64906-CB05-4B52-A797-596D3A0DF897@emc.com> <54523B57.1010802@multiplay.co.uk> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 14:24:52 -0000 On 30/10/2014 14:15, Ed Maste wrote: > On 30 October 2014 09:21, Steven Hartland wrote: >> On 30/10/2014 12:10, Bjoern A. Zeeb wrote: >>> (a) symbol files are for developers. Developers are clever people, often >>> with custom systems, they know how to deal with them as they already do >>> whatever they want anyway in 7 different ways. >> Yes and no, generating useful information from a users panic issue is >> something we really need to ensure is still possible. As where they aren't >> the developer, they are the source of the information. >> >> So maybe some sort of post processing utility? > We're also going to make debug data for userland (libraries and > binaries) available. On my system there's about 360MB of kernel debug > and 1.5GB of userland debug, and we definitely don't want to > unconditionally install all of that. Thus we're going to have to > provide the capability of installing debug data at install time or > later anyway, > > We already have some limited post-processing involved in kernel crash > handling - /etc/rc.d/savecore to pull the crash out of the swap/dump > partition, and crashinfo to extract useful information using kgdb. > There are many useful improvements we could make in kernel crash > handling, including having the process support on-demand fetching of > the kernel debug data. Yer that's the process that was in my head, if debug symbols aren't available when savecore runs we're going to need a way to update / rerun when they are available, or even better give it the ability to do the same job with remote symbols? > Sounds like having a way to not install symbols to the root partition for > *binary* installs is the real requirement? > That is a requirement, yes. > > Moving the debug data to a separate partition also opens up some > compelling use cases for large scale deployments, where multiple > systems run the same release. The machines can run from their own > install on disk, but have the infrequently-used debug data NFS mounted > from a common location. The / and /boot partitions may be mounted > read-only. Sound like a good idea :) > >>> The entire cp -pR kernel kernel.good solution is nothing I’d expect a user >>> to ever do. But I am aware that’s a “developer standard”. Maybe we just >>> need to improve the situation for ourselves rather than pessimising 98% of >>> users out there. >> Indeed. > ... >> I think overall there's options to move forward, we just need to ensure its >> not at the expense of usability for those that do have space. > Setting DEBUGDIR= in /etc/src.conf will retain the current behaviour > of installing the debug data beside the kernel and modules (and > userland binaries and libraries). Does this adequately address your > use case? Yep that works :) > >>> Whether that is /boot/kernel/symbols/* >>> or /usr/lib/***, I couldn’t care less > Note that if they go in /boot/kernel/symbols/ then we have to teach > GDB, LLDB, and other tools to look there; if they go in /usr/lib/debug > they're found automatically by the debuggers. > > We may have to add standalone debug path support to other tools, but > it's very little additional work. One thing to check would be to ensure that /usr is mounted when savecore runs. Regards Steve