Improving the Identication of Linux Distributions when Dumping

[Paulo César Pereira de Andrade]

Dr Andrew John Hughes wrote:
> It makes sense to include the distro-pkg-dev list on this discussion
> rather than keeping it hidden away on this list that most distro
> vendors won't be on.  CCing it.
>
> On 4 April 2011 02:51, Robert Ottenhag <robert.ottenhag at oracle.com> wrote:
>>
>> I am about to improve the identification of popular Linux distros during
>> dumping, see bug [1] and [2], that states that we should "correctly
>> identify Ubuntu as the operating system in crash report instead of
>> 'Debian'".
>>
>>
>>
>> I am somewhat reluctant to directly apply the suggested patch though
>> which only adds to the existing problematic implementation where some
>> distros not are identified at all, or are identified as a different
>> distro.
>>
>>
>>
>> The current implementation [4] relies on the fact that most Linux
>> distros have /etc/XXX-release files, where some distros have multiple
>> files (see [3]). It then checks a fixed set of these files in order, and
>> stops at the first matching file, so the order is important.
>>
>>
>>
>> (0) the current order is "/etc/mandrake-release", "/etc/sun-release",
>> "/etc/redhat-release", "/etc/SuSE-release", "/etc/turbolinux-release",
>> "/etc/gentoo-release", "/etc/debian_version", "/etc/ltib-release",
>> "/etc/angstrom-version", and the proposed patch is to insert
>> "/etc/lsb-release" right before "/etc/debian_version".

  I think in mandrake, conectiva and madriva, /etc/redhat-release
has been always a symlink to, mandrake-release or conectiva-release,
and lately, mandriva-release, so, order of search is not important.

  The lsb solution would require adding a requires, e.g:
$ urpmq --whatrequires lsb-release
cfengine3-base
codeina
dkms-minimal
facter
gnome-system-monitor
lsb-release
perl-Sys-Info-Driver-Linux
smolt
vodafone-mobile-connect
xbmc

(urpmq tells about software not installed)

$ cat /etc/redhat-release
Mandriva Linux release 2011.0 (Cooker) for x86_64

>> If we instead of (0) replace it by (1) and (2) below it will be improved
>> in many ways.
>>
>>
>>
>> (1) call the "lsb_release" tool, if it exists, which returns distro
>> specific info based on either /etc/lsb_release or /etc/XXX-release, and
>> that also knows which of multiple /etc/XXX-release files to check first,
>> e.g. /etc/enterprise-linux before /etc/redhat-linux.
>>
>
> This also won't work if the tool isn't installed.  Most of the time,
> it isn't.  We found this when support was added to IcedTea to use its
> content in the HotSpot crash dump and added it as a dependency in
> distro packages as a result.
>
>>
>>
>> (2) list all /etc/*-release and /etc/*_version files, headed by the
>> respective file names
>>
>
> That would appear to create a lot of empty fields with no information.
>
>>
>>
>> The problem with (1) is that it calls an external process during a phase
>> with might be very critical on resources, and it might not be available
>> on specific old or embedded distros.  Thus we still need (2) for which
>> we need to verify that directory listing does not violate similar
>> resource contraints.  Regarding (2) the order of listed files should
>> also be considered if it simplifies parsing of the dump output.
>>
>>
>>
>> The new solution would look something like
>>
>> Â  OS:
>>
>> Â Â Â  /etc/debian_version
>>
>> Â Â Â Â Â Â  <content>
>>
>> Â Â Â  /etc/lsb-release
>>
>> Â Â Â Â Â Â  <content>
>>
>>
>>
>> Fundamentally, instead of having the JVM to try identify the Linux
>> distro, it becomes up to the reader/parser of the dump output, but with
>> the benefit of having all data available.
>>
>
> I really don't see why the current solution is such a problem.  This
> sounds like it's just going to make the output messy.
>
>>
>>
>> References:
>>
>>
>>
>> [1] https://bugs.openjdk.java.net/show_bug.cgi?id=100137
>>
>> [2] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6986195
>>
>> [3] http://linuxmafia.com/faq/Admin/release-files.html
>>
>> [4] hotspot/src/os/linux/vm/os_linux.cpp:os::print_os_info().
>>
>>
>>
>> I appreciate any comments and ideas.

  I think most information that matters is already available via
uname (syscall or utility), or would need to be requested to
properly handle a bug report. E.g.

$ uname -srm
Linux 2.6.38.2-desktop-1mnb x86_64

>> Thanks
>>
>>
>>
>> /Robert

Paulo