Cfrtjryk

The uname utility gets its information from the uname() system call. It populates a struct like this (see man 2 uname):

       struct utsname {

           char sysname;    /* Operating system name (e.g., "Linux") */

           char nodename;   /* Name within "some implementation-defined

                                 network" */

           char release;    /* Operating system release (e.g., "2.6.28") */

           char version;    /* Operating system version */

           char machine;    /* Hardware identifier */

       #ifdef _GNU_SOURCE

           char domainname; /* NIS or YP domain name */

       #endif

       };

This comes directly from the running kernel. I would assume all of the information is hard-coded into it, except perhaps domainname (and as it turns out, also nodename, machine, and release, see comments). The release string, from uname -r, can be set via configuration at compile time, but I doubt very much the sysname field can -- it's the Linux kernel and there's no conceivable reason for it to use anything else.

However, since it is open source, you could change the source code and recompile the kernel to use whatever sysname you want.

The data is stored in init/version.c:

struct uts_namespace init_uts_ns = {

        .kref = {

                .refcount       = ATOMIC_INIT(2),

        },

        .name = {

                .sysname        = UTS_SYSNAME,

                .nodename       = UTS_NODENAME,

                .release        = UTS_RELEASE,

                .version        = UTS_VERSION,

                .machine        = UTS_MACHINE,

                .domainname     = UTS_DOMAINNAME,

        },

        .user_ns = &init_user_ns,

        .proc_inum = PROC_UTS_INIT_INO,

};

EXPORT_SYMBOL_GPL(init_uts_ns);

The strings themselves are in include/generated/compile.h:

#define UTS_MACHINE "x86_64"

#define UTS_VERSION "#30 SMP Fri Apr 11 00:24:23 BST 2014"

and in include/generated/utsrelease.h:

#define UTS_RELEASE "3.14.0-v2-v"

UTS_SYSNAME may be defined in include/linux/uts.h

#ifndef UTS_SYSNAME

#define UTS_SYSNAME "Linux"

#endif

or as a #define in makefiles

Finally, the hostname and domainname can be controlled by /proc/sys/kernel/{hostname,domainname}. These are per UTS namespace:

# hostname

hell

# unshare --uts /bin/bash

# echo test > /proc/sys/kernel/hostname 

# hostname

test

# exit

# hostname

hell

With the help of a Linux Cross Reference and your mention of /proc/sys/kernel/ostype, I tracked ostype to include/linux/sysctl.h,
where a comment says that names are added by calling register_sysctl_table.

So where is that called from? One place is kernel/utsname_sysctl.c, which includes include/linux/uts.h, where we find:

/*

 * Defines for what uname() should return 

 */

#ifndef UTS_SYSNAME

#define UTS_SYSNAME "Linux"

#endif

So, as the kernel documentation states:

The only way to tune these values is to rebuild the kernel

:-)

As commented elsewhere, the information come with the uname syscall, which information is hard-coded in the running kernel.

The version part is normally set when compiling a new kernel by the Makefile:

VERSION = 3

PATCHLEVEL = 15

SUBLEVEL = 0

EXTRAVERSION =

when I had time to play compiling my kernels, I used to add things over there in EXTRAVERSION; that gave you uname -r with things like 3.4.1-mytestkernel.

I do not fully understand it, but I think that the rest of the information is setup in the Makefile also around line 944:

# ---------------------------------------------------------------------------



# KERNELRELEASE can change from a few different places, meaning version.h

# needs to be updated, so this check is forced on all builds



uts_len := 64

define filechk_utsrelease.h

    if [ `echo -n "$(KERNELRELEASE)" | wc -c ` -gt $(uts_len) ]; then 

      echo '"$(KERNELRELEASE)" exceeds $(uts_len) characters' >&2;    

      exit 1;                                                         

    fi;                                                               

    (echo #define UTS_RELEASE "$(KERNELRELEASE)";)

endef



define filechk_version.h

    (echo #define LINUX_VERSION_CODE $(shell                         

    expr $(VERSION) * 65536 + 0$(PATCHLEVEL) * 256 + 0$(SUBLEVEL)); 

    echo '#define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c))';)

endef



$(version_h): $(srctree)/Makefile FORCE

    $(call filechk,version.h)



include/generated/utsrelease.h: include/config/kernel.release FORCE

    $(call filechk,utsrelease.h)



PHONY += headerdep

headerdep:

    $(Q)find $(srctree)/include/ -name '*.h' | xargs --max-args 1 

    $(srctree)/scripts/headerdep.pl -I$(srctree)/include

For the rest of the data, the sys_uname syscall is generated using macros (in a quite convoluted way), you can start from here if you feel adventurous.

Probably the best way to change such information is writing a kernel module to override the uname syscall; I never did that but you can find info in this page at section 4.2 (sorry, no direct link). Notice however that that code is referring to a quite old kernel (now Linux kernel has uts namespaces, whatever they mean) so you will need to change it probably a lot.

While I couldn't find anything in the source to indicate this, I believe it uses the uname syscall.

man 2 uname

should tell you more about it. If that's the case it's getting the information directly from the kernel and changing it would probably require recompilation.

You could change the binary for you uname to do whatever you want though, just write over it with w/e program you please. The downside being some scripts rely on that output.

Proper way to change uname would be to change compile headers and re-compile like others suggested. But I am not sure why you would want to go through that much trouble when you can do something like,

alias uname 'uname \!* | sed s/2.6.13/2.6.52/'

or even

alias uname 'echo whatever'

Rmano's answer got me partway, but the real magic is easier discovered by passing the Q= option in your make commandline in the kernel source directory. it lets you see the details, one of which is a call to a script: echo "4.4.19$(/bin/sh ./scripts/setlocalversion .)". executing that same snippet gives the kernel release number, 4.4.19-00010-ge5dddbf. if you look at the script, it determines the number from the versioning system, and running it with bash -x shows the exact process:

+++ git rev-parse --verify --short HEAD

++ head=e5dddbf

+++ git describe --exact-match

++ '[' -z '' ']'

++ false

+++ git describe

++ atag=release/A530_os_1.0.0-10-ge5dddbf

++ echo release/A530_os_1.0.0-10-ge5dddbf

++ awk -F- '{printf("-%05d-%s", $(NF-1),$(NF))}'

++ git config --get svn-remote.svn.url

++ git diff-index --name-only HEAD

++ grep -qv '^scripts/package'

++ return

+ res=-00010-ge5dddbf

+ echo -00010-ge5dddbf

-00010-ge5dddbf

what this shows me is that if I want to build a kernel module to work with my running kernel, I'm on the wrong tagged release and the wrong commit. I need to fix that, and build at least the DTBs (make dtbs) in order to create the generated files with the right version number.

turns out, even that wasn't enough. I had to replace scripts/setlocalversion to one that simply does:

#!/bin/sh

echo -0710GC0F-44F-01QA

then rebuild the autogenerated files:

make Q= ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- dtbs

then I could build Derek Molloy's sample driver and was able to insmod it successfully. apparently the warning about Module.symvers not being present didn't matter. all Linux was using to determine if the module would work was that localversion string.