The GoboLinux Way
What makes GoboLinux unique
GoboLinux has a directory structure different from most other Linux
distributions. In GoboLinux, all files for a program, including executables,
headers and libraries, are installed below a single directory that belongs to
that program.
So the ping utility might reside in
/Programs/Netkit-Base/0.17/bin/ping
and libpng.so.3 in
/Programs/LibPNG/1.2.5/lib/libpng.so.3
To be visible to other software, these files are symlinked into standard
locations in the new directory hierarchy under /System/Index:
/System/Index/bin/ping
/System/Index/lib/libpng.so.3
Traditional Unix paths are also symlinks to the /System/Index directory
structure:
/bin -> /System/Index/bin
/usr/bin -> /System/Index/bin
/usr/lib -> /System/Index/lib
/etc -> /System/Settings
As a result, most things just work. For example, GoboLinux will correctly
dispatch scripts with shebang lines such as #!/usr/bin/env perl or
#!/usr/bin/python to the proper interpreter.
This architecture —installing each program under its own directory, and making
executables, headers other resources available via symlinks— has significant
advantages:
- different versions of libraries can coexist
- it’s trivial to uninstall software
- there’s no need for a database of installed files
The system is administered through a limited set of utility
programs. Tracking dependency relations among software
is accomplished through the GoboLinux build
system and its library of
“compile recipes”.
The “legacy” tree
Unfortunately, not all programs have the flexibility to be installed anywhere.
Occasionally, hardcoded paths creep in even in programs that belong to userland,
and should, at least theoretically, allow themselves to be installed inside,
say, a user’s home directory.
As much as we’d like to see this done in the long term, patching all
applications is not an option. For this reason, GoboLinux keeps, as stated
earlier, a legacy tree where all usual Unix paths are mapped to GoboLinux
equivalents. That way, if a Makefile looks for
/usr/X11R6/include/X11/Xaw3d/XawInit.h, it will find it, although it is really
at /Programs/Xaw3d/1.5/include/X11/Xaw3d/XawInit.h, where it belongs. When two
applications have a directory entry with the same name, the GoboLinux scripts
recursively expand them. Both Xorg and Xaw3d have X11 under include. A
directory /System/Index/include/X11 is created automatically, holding links
from both X11 directories.
Another interesting feature is that the GoboLinux scripts execute make install
using a special user id that only has write permissions inside the program’s
source directories and the program’s entry under /Programs. This way, files
can’t “escape” from the GoboLinux hierarchy and slip a directory into the legacy
tree.
A detail that might surprise you at first is that when you look at the root
directory (with ls or graphical tools), you don’t see the legacy directories,
even though you can cd into them. They are certainly there — they are just
kept hidden using GoboHide, a kernel modification
designed to conceal the legacy tree from the usual system view. (GoboHide is of
course optional — GoboLinux works just as well using standard Linux kernels.)
Influences and roots
As you read this, you have probably found many familiar concepts (not to mention
directory names). GoboLinux has clearly found inspiration in other operating
systems, like NeXT, BeOS and AtheOS, but it was the notion that they build
“something different” using an existing Unix base (be it using a BSD foundation
as in macOS, or using GNU tools as in AtheOS) was the most important influence
of all. There are several other projects, in various stages of development, that
use the Linux kernel as a foundation and feature alternative directory trees.
Interestingly, most of them are clones or heavily inspired by a specific
proprietary operating system. (At different points in time, we’ve seen clones of
RiscOS, NeXT, BeOS.)
GoboLinux, on the other hand, is not a clone of anything else. It uses standard
Linux desktop software. We believe that the well-organized directory structure
makes it a good testbed for new ideas — possibilities are wide open (see the
forum and moreso the mailing list for discussions, and to a lesser extent the
IRC channel #gobolinux on libera.chat).
Differences between GoboLinux and a traditional Linux system
What follows is not a thorough description of GoboLinux, but a quick cheat-sheet
of facts that are good to know when you are getting acquainted to the system.
In the GoboLinux hierarchy, files are grouped by their functional category
(executables, libraries, and so on). There are links at the classic
directories you are used to (/bin, /usr/bin, and so on), but remember
that they all point to the same place. This is a huge advantage, as it
means, for example, that you’ll never have to search for a library
throughout your filesystem again – it will always be in /lib (and in
/usr/lib, because they point to the same place! – no worries about
compatibility).
There are symbolic links relating most of the usual UNIX directories to the
GoboLinux tree. Therefore, you will find directories such as /etc,
/var/log and /usr/bin in the expected places. However, some directories,
such as the users’ directories, didn’t need to be linked to their “legacy”
locations. This way, for a given user called “joe”, you’ll have, instead of
/home/joe, /Users/joe. Notice also that the superuser’s directory is no
different than the ones from the other users, so, root’s directory is at
/Users/root. Mount points are under /Mount, not /mnt.
Another major difference between GoboLinux and most Linux distributions is
that it does not use a BSD nor a System V initialization procedure. Instead,
it has its own. At /System/Settings/BootScripts you will find a few files
that command the entire boot procedure: BootUp and Shutdown run at system
boot and shutdown, respectively; you can define custom “runlevel” scripts to
define different ways you want your system to be initialized (say, Single
and Multi for single and multi-user, Graphical for boot into graphic mode,
etc.) and control that from the boot loader menu. The
/System/Settings/BootOptions file separate site-specific settings from the
rest of the scripts. You can also find a library of application specific
tasks at /System/Tasks that can be used during boot (those are installed
by the apps).
For a better overview of how it looks and feels right, nothing beats giving the
LiveCD a spin. You’ll be running a full GoboLinux system without having to
install anything.
Just flash a USB-Drive and give it a go !!
GoboLinux Filesystem Hierarchy
Here is an overview of the GoboLinux filesystem tree. The legacy folders (on the
“:” part of the tree) are links to the corresponding GoboLinux folders. The
legacy folders are excluded from default directory view by
GoboHide.
/
|-- Data - for resources belonging to the system and to individual programs
| |-- Compile - sources, recipes and other files used by the Compile tool
| | |-- Archives
| | |-- LocalRecipes
| | |-- PackedRecipes
| | |-- Recipes
| | `-- Sources
| `-- Variable - for spool files, log files, temporary files, etc.
| |-- cache
| |-- empty
| |-- lib
| |-- lock
| |-- log
| |-- run
| |-- spool
| `-- tmp
|-- Mount - mountpoints for filesystems
|-- Programs - where programs (with all their files) are installed
|-- System
| |-- Aliens - files managed by programming language package managers
| |-- Environment - links to program files declaring environment variables
| |-- Index - links to files in each program's
| | |-- bin + bin/ and sbin/ directories
| | |-- include + include/ directory
| | |-- lib + lib/ directory
| | |-- libexec + libexec/ directory
| | `-- share + share/ directory
| | |-- consolefonts
| | |-- fonts
| | `-- man
| | |-- info + info/ directory
| | `-- man{1-9} + man{1-9}/ directories
| |-- Kernel
| | |-- Boot - kernel images, config files and programs needed to boot
| | |-- Devices - device files (managed by Udev).
| | |-- Modules - loadable kernel modules (device drivers)
| | |-- Objects - a view of the kernel's device tree
| | `-- Status - kernel status files (belonging to the /proc filesystem)
| |-- Settings - system config files and links to files in program's Settings/ directories.
| | `-- BootScripts - scripts used for boot, symlink to /Programs/BootScripts/Settings/BootScripts/
| `-- Tasks - links to programs' boot tasks (from their Resources/Tasks/ directory)
|-- Users - contains users' home directories
:
:
:-- etc -> System/Settings
:-- dev -> System/Kernel/Devices
:-- sys -> System/Kernel/Objects
:-- proc -> System/Kernel/Status
:-- var -> System/Variable
:-- tmp -> System/Variable/tmp
:-- sbin -> System/Index/bin
:-- bin -> System/Index/bin
:-- lib -> System/Index/lib
:-- lib64 -> System/Index/lib
`-- usr
|-- X11R6 -> .
|-- local -> .
|-- bin -> ../System/Index/bin
|-- sbin -> ../System/Index/bin
|-- include -> ../System/Index/include
|-- lib -> ../System/Index/lib
|-- lib64 -> ../System/Index/lib
|-- libexec -> ../System/Index/libexec
`-- share -> ../System/Index/share
System Index
Compiled programs in C and C++ typically have a lib/ directory and often also
a bin/ directory.
On GoboLinux, these will be symlinked into /System/Index such as for ping:
/System/Index/bin/ping
/System/Index/lib/libpng.so.3
Traditional Unix paths are also symlinks to the /System/Index directory
structure:
/bin -> /System/Index/bin
/usr/bin -> /System/Index/bin
/usr/lib -> /System/Index/lib
/etc -> /System/Settings
Installing GoboLinux
Installer is a program included on the GoboLinux Live-ISO that installs
GoboLinux to your hard drive.
It takes care of basic configuration, package selection, and boot
loader setup. It can be run from the command line or via the window manager
menu.
Graphical Install
The GoboLinux Live-ISO supports a complete graphical display environment.
In most cases, the X server automatically detects the keyboard and display
hardware, so you can start the graphical mode by typing:
Clicking on the top-left icon brings up a menu. Look under System Tools, select
“Install GoboLinux”, follow the instructions.
Console install
Type Installer in the console. Note the capital “i”. (GoboLinux utility
scripts are generally named with an initial capital and follow the CamelCase
convention.)
Subsections of Installing Software
Compiling from source
Introduction
With Compile, GoboLinux build utility, software sources can be downloaded,
compiled and installed in a single step. An example will follow next.
In order to install irssi, a text-based IRC client from the command line,
you would type the following instruction:
Depending on the speed of your computer, internet connection and what packages
you have installed, Irssi should download and install in a few minutes.
Compile manages the build process using GoboLinux recipes. Each recipe contains
a list of build directives and supplemental control files for compiling a
particular software library.
Finding recipes
Typically, you can just try the name of the recipe you want from the command
line. There is also an online recipe viewer,
listing the most recently uploaded recipes first.
Command-line options
Compile has a number of command-line options, which are listed
here. The following are especially useful.
When using the --batch or -b automatically attempts to process all
dependencies of the requested program.
Separating download and compile phases
The next two options are useful when working with intermittent internet access,
or if you’d like to run your compiling jobs at night when you’re asleep.
Calling Compile with the --no-build flag downloads sources only.
Later, in the event that you wish to use the --no-web flag, this will direct
Compile to search to your system’s own download cache and build the sources
found there instead. This commandline switch is obviously very useful if you do
not have a working internet connection for the time being.
Writing recipes
Main article: Writing recipes
Getting the latest Compile
- To use the development version of Compile, run
- To use the latest stable version, run
In general it is recommended to always use the latest stable version of
Compile. Compile is very important to GoboLinux so if
there is any problem in it, it is normally fixed very quickly.
Binary packages
Warning
We do not maintain a binary package repository at this time! |
Please build your packages from source using Compile!
Binary packages in GoboLinux are precompiled software packages built for the
GoboLinux directory tree and made available through the GoboLinux software
repository (recipe store). Since these packages are already compiled, you can
save the many hours needed to build larger applications. On the other hand, with
binary packages you don’t have the ability to set compile flags for optimization
or specific architectures.
Installing packages
InstallPackage is the GoboLinux script for
installing binary packages. If you want
InstallPackage to look for the most recent Gimp
package available, you can run
The script will check if the package is available in the GoboLinux repositories.
(See /System/Settings/GetAvailable.conf for the specific URLs scanned. You may
add your own repositories if you desire.)
If you want to select a specific version, you can pass it as the second
parameter:
InstallPackage Gimp 2.8.18
If you downloaded the package and want to install it, run:
InstallPackage Gimp--2.8.18--i686.tar.bz2
The script normally runs interactively, asking about each dependency of the
requested package before installing it. You can avoid these queries by adding
the --batch or -b flag. This is particularly useful with large packages such
as Gimp or Xorg, which have many dependencies.
Dependencies
InstallPackage will warn you if dependencies of a package you are trying to
install are unavailable and ask if you want to continue. This is valuable,
because some software may still work satisfactorily even if a particular plug-in
or other dependency is missing.
Installing packages from the LiveCD
See Installing Packages from the
LiveCD.
Removing packages
See Removing programs.
Creating packages
Structure
In GoboLinux, all binary packages (as well as all user-compiled software) is
installed under /Programs in a “program directory” provided for each version
of each application, for example:
When compiling software under GoboLinux the installation target directories such
as bin/, lib/, and etc/ that are required for a typical program are placed
inside the program directory.
With this self-contained directory structure, all that is needed to generate a
binary package is to make a tarball of the program directory, copy over the
Resources/ directory from the Compile recipe, and generate a few additional
files, which are also placed under Resources/.
This is accomplished by the CreatePackage command.
Preparation
Before creating a package, be careful to vet the contents of the program’s
Settings/ directory to ensure that it does not include personal information.
A package submitted for inclusion in the GoboLinux packages repository must have
sensible default settings, honoring the application defaults if possible.
The CreatePackage command
In order to create a package, run the
CreatePackage utility with the package name as a
parameter. For example,
will create a binary package in the current working directory.
Subsections of Package Management
Understanding and Maintaining system indices
The two main parts of GoboLinux are /Programs and /System. If you stick to
using InstallPackage and
Compile, these two parts will be implicitly kept in
sync by SymlinkProgram. But a lot of power lies
in the fact that you can tune how these two worlds interact.
Program entries under /Programs feature a Current symlink pointing to a
specific version that is “active” in the system. This Current version is taken
as the default version when you don’t specify a version in scripts, and the link
is updated when you install a new version with
InstallPackage or
Compile.
That doesn’t mean that you can only have one version linked into the system: you
can have files of multiple versions show up in /Programs. In fact, when you
install a new version with InstallPackage but
keep the old version in /Programs, files for which there’s no version with the
same name in the new package are still linked – this is especially useful for
libraries.
For example, say program Foo 1.0 looks like this:
/Programs/Foo/1.0/bin/foo
/Programs/Foo/1.0/include/foo.h
/Programs/Foo/1.0/lib/libfoo.so.1
/Programs/Foo/1.0/lib/libfoo.so -> libfoo.so.1
Now, say, you install a new version, 2.0, which looks like this:
/Programs/Foo/2.0/bin/foo
/Programs/Foo/2.0/include/foo.h
/Programs/Foo/2.0/lib/libfoo.so.2
/Programs/Foo/2.0/lib/libfoo.so -> libfoo.so.2
The default behavior of SymlinkProgram is to
replace symlinks under /Programs that belong to a different version of the
same program. So, now, we’ll have the following links related to Foo under
system:
/System/Index/bin/foo -> /Programs/Foo/2.0/bin/foo
/System/Index/include/foo.h -> /Programs/Foo/2.0/include/foo.h
/System/Index/lib/libfoo.so.2 -> /Programs/Foo/2.0/lib/libfoo.so.2
/System/Index/lib/libfoo.so -> /Programs/Foo/2.0/lib/libfoo.so.2
/System/Index/lib/libfoo.so.1 -> /Programs/Foo/1.0/lib/libfoo.so.1
So, now, when you run foo, it will fetch version 2.0 of the program through
your system $PATH (which looks at /System/Index/bin). But, as you can see,
libfoo.so.1 is still there. This way, if you have other programs installed in
the system that are linked specifically to version 1 of the libfoo library will
continue working.
This means you won’t have the old problem “I upgraded package Foo and now my
other apps are broken”. Of course, you can still break things when you remove
a version which other programs depend in (or if buggy programs link to a version
independent name of a library (libfoo.so) but depend on features of a specific
version).
Besides SymlinkProgram (see section “Compiling
manually” and its reference
entry for details on it), there are other scripts
that give you more control over what is linked in the system and what is not.
With DisableProgram, you can remove from
/System all links that refer to a specific version of a program, effectively
“turning it off” – it is as if it were not present in the system.
With RemoveProgram, you can remove a program
from /Programs and its references from /System in a single step.
See Removing programs for more details.
Updating programs
Overview
Use the UpdateRecipes command to refresh your
local cache of the GoboLinux recipe store.
You can query available updates using the utilities
SuggestUpdates and
SuggestDuplicates. The output of each of
these commands is suitable for piping into commands.
The FindPackage and
GetAvailable commands may also be useful.
Example Update Process
Keep in mind that most operations that change the file-system state in Gobo
require super user privileges:
Ensure that Scripts are up to date
cd /Programs/Scripts/Current
sudo git pull && sudo UpdateSettings --auto Scripts && sudo make
Ensure that Compile is up to date
cd /Programs/Compile/Current
sudo git pull && sudo UpdateSettings --auto Compile
UpdateRecipes - Update local copy of recipe store
cd /Data/Compile/Recipes
sudo UpdateRecipes
SuggestUpdates - List packages with an update available
cd /Data/Compile/Recipes
SuggestUpdates
Install updates
Currently, there is no way to update packages automatically. This used to be
done with the Freshen script, which is currently not
in working order.
Updates thus need to be installed manually via
InstallPackage or
Compile as appropriate.
Removing programs
In GoboLinux, all programs, whether binary packages or user-compiled software,
are installed into a single directory under the /Programs hierarchy, such as,
for instance, gimp:
Removing this program can be, in theory, as simple as:
But since this leaves behind dangling symlinks, GoboLinux offers the
RemoveProgram utility, which removes the program
and all links pointing to its files in /System/Index.
RemoveProgram Gimp 2.8.18
Sometimes you may want to “turn off” a program temporarily, without erasing it
from your hard disk. In other words, you want to remove program’s executables
from the execution path, and remove libraries and headers from the lookup path.
In GoboLinux, this can be accomplished by removing the associated symlinks for
/System/Index. The DisableProgram script facilitates this:
DisableProgram gimp 2.1.18
The version parameter given here, in this case 2.1.18, is optional. If it is
not provided, the Current link is used to determine the program version to
disable. Also note that the program name is case insensitive, but it appears to
be simpler to use a downcased variant - easier to type at the least.
To re-enable the program, all you need to do is recreate the symbolic links:
SymlinkProgram gimp 2.1.18
Maintaining symlinks
GoboLinux has a script called RemoveBroken. that
removes dangling symlinks from /System/Index tree. It can be useful to run
after manipulating directories under /Programs.
RemoveBroken takes a list of files, and removes
those that are dangling symlinks. If no arguments are provided, the script takes
filenames from standard input (typically through a pipe).
The usual procedure to clean up dangling links, is
cd /System/Index
find | RemoveBroken
Dependencies blacklist
Configuring Dependencies
Today there are many programs implementing a given feature in different ways.
One such example is the OpenGL API, with implementations floating in packages
such as Xorg, MesaLib and Nvidia. However, not every user owns a Nvidia card,
and here comes a problem: how should one mask Nvidia from the automated
Dependencies list generated after creating a recipe? This problem is now fixed
with a configurable file called
/Programs/Scripts/Settings/Scripts/Dependencies.blacklist.
Dependencies.blacklist
This file allows one to specify packages that should not appear in the
Dependencies file after creating a new recipe. Its format is pretty simple: one
package per line, without the need to specify its version.
A Dependencies.blacklist example
The following example blacklists the packages Glibc and Nvidia. Comments and
blank lines are ignored by the parser, so it’s ok to include them.
# Dependencies.blacklist is documented in detail at
# http://wiki.gobolinux.org/Dependencies
Glibc
Nvidia
Note: presently blacklisting specific versions is not supported, but the same
behaviour can be achieved by creating an empty directory in the /Programs
directory. For example, to blacklist GCC version 4.1.2 you may:
mkdir /Programs/GCC/4.1.2
Subsections of Configuration files
Compile.conf
Compile.conf is the file where you can configure the various paths and URLs used
by Compile.
It is stored at /Programs/Compile/Settings/Compile/Compile.conf – which, once
installed, has a link at /System/Settings/Compile/Compile.conf (if you’re used
to the GoboLinux tree, you should know by now that this is the same as
/etc/Compile/Compile.conf).
These are the usual contents of the file:
Your name here so that credit is added to recipes.
compileRecipeAuthor="Paul McCartney"
# example only! change the name (unless of course, you're Paul ;) )
The standard locations for your local Compile files.
compileArchivesDir="$compileDir/Archives"
compileSourcesDir="$compileDir/Sources"
compileRecipeDirs="$compileDir/Recipes"
Some of the main free software repositories are treated especially: recipes use
these variables in their url declarations, so that you can pick your favorite
mirror without having to edit recipes one by one:
ftpGnu=ftp://ftp.gnu.org/gnu/
ftpAlphaGnu=ftp://alpha.gnu.org/gnu/
httpSourceforge=http://unc.dl.sourceforge.net/sourceforge/
The Compile recipe tree is managed by Git. The git repository and the upstream
branch are both configurable through the following variables:
compileRecipesRepository=https://github.com/gobolinux/Recipes.git
compileUpstreamBranch=master
A variable to set the make command called by Compile. ColorMake provides the
highlighting that GoboLinux has by default:
compileMakeCommand="ColorMake"
Options to use with the make command. This can be used to run multiple threads
in parallel on different CPUs or for other customisation:
Environment variables
Some environment variables influence the behavior of some GoboLinux tools. You
may want to set them. Just remember that GoboLinux uses zsh (not bash) as its
default shell, so you should edit .zshrc (not .bashrc). Zsh is a
Bourne-style shell, though, so the syntax you’re used to is still valid.
Of course, if you really prefer bash (though we really recommend giving zsh a
try!), you can change your default shell using the chsh command. See the
chsh man page for details.
The $EDITOR variable should be set to your favorite text editor. Whenever a
GoboLinux tool needs to run an editor, it will run the one indicated in this
variable (in fact, this is not a GoboLinux variable, several programs use it).
GetAvailable
Warning
We do not maintain a binary package repository at this time! |
Please build your packages from source using Compile!
GetAvailable.conf is the file where you can configure paths and URLs used to
locate binary packages.
It is stored at /Programs/Scripts/Settings/Scripts/GetAvailable.conf – which,
once installed, has a link at /System/Settings/Scripts/GetAvailable.conf (if
you’re used to the GoboLinux tree, you should know by now that this is the same
as /etc/Scripts/GetAvailable.conf).
These are the usual contents of the file:
The timeout (in seconds) when trying to fetch the packages list from a sever.
The paths from which local packages will be automatically be found. Notice that
both compressed (e.g. /Depot/Packages/Qt--4.0.0--i686.tar.bz2) and
uncompressed (e.g. /Mount/SquashFS/Programs/Qt/4.0.0) packages can be matched.
defaultLocalPackagesPaths=(
"/Depot/Packages"
"/Mount/SquashFS/Programs"
"/Mount/CD-ROM/Depot/Packages/"
"."
)
The URLS from which lists of official binary packages (packed by some core
developer) will be retrieved.
officialPackagesLists=(
'http://kundor.org/gobo/packages/official/MANIFEST.bz2'
'http://gobo.calica.com/packages/official/MANIFEST.bz2'
)
The URLS from which lists of contributed binary packages (contributed by some
user, and placed, without garanties, at our servers) will be retrieved.
contribPackagesLists=(
'http://kundor.org/gobo/packages/contrib/MANIFEST.bz2'
'http://gobo.calica.com/packages/contrib/MANIFEST.bz2'
)
The URLS from which lists of tracked versions will be retrieved. A tracked
version is a program version that actually may not have a correspondent Recipe
or binary package, but that is already made available by the program developers
trackedVersionsLists=(
'http://gobolinux.org/version-tracker/TrackedVersions.bz2'
)
Linux Kernel Topics
Linux kernel under GoboLinux
The Linux kernel differs from standard packages. It has nothing to be linked
against the legacy tree: no libraries, no binaries, no headers, no manuals or
info pages. Moreover, there are many things on a regular system which are very
tied to the kernel itself, such as the proc and sys filesystems, the device
nodes and the boot loader files.
These characteristics led to the creation of a special directory for the kernel,
called /System/Kernel. This tree is organized in the following way:
/System/Kernel/Boot - Bootloader files, including the kernel image/System/Kernel/Devices - Device nodes, populated by Udev + Hotplug/System/Kernel/Modules - Kernel modules/System/Kernel/Objects - Sysfs, providing information gathered from Linux
2.6/System/Kernel/Status - The mounted proc filesystem
Installing a kernel
Thanks to Compile, installing a new kernel is pretty straightforward on
GoboLinux. The Linux recipe takes into account the existence of a file called
config.gz inside /System/Kernel/Status. This file contains the current
configuration for the running kernel, and is used thereby to feed the new kernel
options.
In short, running Compile Linux will fetch the latest available recipe
(which already contains GoboLinux optional patches). After doing that, the
kernel itself is automatically downloaded, patched and filled with the current
configuration, taken from config.gz.
The menuconfig entry then appears, and allows for the user to modify their
kernel options. Just selecting Exit and telling the script to save the changes
will finish the user’s interaction with the Linux kernel compilation. After
completed, a new entry will appear under
/System/Kernel/Modules/$KERNEL_RELEASE, and the new bzImage and System.map
files will get installed under /System/Kernel/Boot.
The old bzImage and System.map files aren’t overwritten, though. They’re just
symlinks to the current kernel image, and this guarantees that if something goes
wrong, a rollback can be done by simply modifying the kernel image at the GRUB’s
bootloader prompt, and later by reverting the symlink’s target to the previous
release.
To install a kernel which is newer than the available recipe, or one other than
vanilla, you may use NewVersion.
If you already have a kernel downloaded, or have a special source package, you
may place it in /Data/Compile/Archives.
- Use
NewVersion Linux <Version> https://kernel.org/pub/linux/kernel/v6.12/<your-archive-name>
to create a recipe. Using a fake URL is all right if you don’t intend to
distribute the recipe. - Place any custom patches you need to apply into the
/Data/Compile/LocalRecipes/Linux/<Version> directory. - Then
Compile as usual.
Kernel patches
The Linux recipe comes with a few patches in order to improve the user’s
experience with the system. The patchset includes, but is not restricted to, the
following modifications:
- GoboHide: allows the legacy tree to be hidden from
userspace applications
- SquashFS: A compressed filesystem which gets uncompressed on demand. This
filesystem is currently used on the GoboLinux ISO, and so it’s interesting
to have it in order to get the CD contents easily accessible through the
mount command
