svn commit: r307326 - head/sys/boot/efi/loader

[Warner Losh]

On Wed, Oct 19, 2016 at 11:34 AM, John Baldwin <jhb at freebsd.org> wrote:
> On Wednesday, October 19, 2016 02:01:18 AM Warner Losh wrote:
>> One of my systems would export these as sysctls:
>>
>> smbios.bios.reldate="07/05/2013"
>> smbios.bios.vendor="American Megatrends Inc."
>> smbios.bios.version="3.00"
>> smbios.chassis.maker="Supermicro"
>> smbios.chassis.serial="0123456789"
>> smbios.chassis.tag="To Be Filled By O.E.M."
>> smbios.chassis.version="0123456789"
>> smbios.memory.enabled="268435456"
>> smbios.planar.location="To be filled by O.E.M."
>> smbios.planar.maker="Supermicro"
>> smbios.planar.product="X9SRH-7F/7TF"
>> smbios.planar.serial="VM13CS028237"
>> smbios.planar.tag="To be filled by O.E.M."
>> smbios.planar.version="0123456789"
>> smbios.socket.enabled="1"
>> smbios.socket.populated="1"
>> smbios.system.family="To be filled by O.E.M."
>> smbios.system.maker="Supermicro"
>> smbios.system.product="X9SRH-7F/7TF"
>> smbios.system.serial="0123456789"
>> smbios.system.sku="To be filled by O.E.M."
>> smbios.system.uuid="00000000-0000-0000-0000-002590e4d0ec"
>> smbios.system.version="0123456789"
>> smbios.version="2.7"
>>
>> though some of them are silly due to the BIOS writer being silly...
>
> So are you planning to just duplicate the existing kenv vars as sysctl
> nodes?  Can't you parse the output of kenv instead?

I often get sysctl -a from ailing systems. I never or rarely get kenv.
This adds to the information available when I'm looking into problems
since it gives me more data about the system where the problem occurs.

Warner