Re: HEADS UP: Standalone kernel debug files moving out of /boot/kernel/

On 30/10/2014 14:15, Ed Maste wrote:
> On 30 October 2014 09:21, Steven Hartland <killing_at_multiplay.co.uk> 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