Information about directory structure - File Hierarchy System (FHS)

The candidate must know the basic file system structure.
The basic file structure of unixoid operating systems is shown below, using Arch Linux as an example:

/ // root
├── bin // programs executable for all users
├── boot // static part of the kernel as well as dynamic parts of the bootloader
├── dev // device files of the system
├── etc // global configuration files
│   ├── default // default settings for daemons (SysVinit)
│   ├── init // start scripts & stop scripts for the daemons (SysVinit)
│   └── init.d // start scripts & stop scripts for the daemons (SysVinit)
├── home // home directories of regular users
├── lib // link of the kernel modules
├── media // link removable media
├── mnt // regular mountpoint
├── opt // manually installed software
├── proc // virtual directory of the current Sysconfig as well as process management
├── root // home directories of the root user
├── run // run-time variable data
├── sbin // directory of programs for root
├── srv // server base folder
│   ├── ftp
│   ├── http
│   └── tftp
├── sys // virtual directory of system settings as well as system accesses
├── tmp // temporary program files and system files
├── usr // content of system tools, system programs as well as program libraries.
└── var // variable data like logs and so on

NOTE about /usr/local and its subdirectories

Historically and strictly according to the standard, /usr/local/ is for data that must be stored on the local host (as opposed to /usr/, which may be mounted across a network). Most of the time /usr/local/ is used for installing software/data that are not part of the standard operating system distribution (in such case, /usr/ would only contain software/data that are part of the standard operating system distribution). It is possible that the FHS standard may in the future be changed to reflect this de facto convention.
From: Wikipedia

see FHS documentation on: https://refspecs.linuxfoundation.org/FHS_3.0/fhs.pdf


Management of modules in the system

In this section we will learn how to handle, query, load and unload system modules!


Information about kernel modules:

  • extension .o - standart object is a program library for a program
  • extension .ko - kernel-object is a kernel module (among other things also “driver”)
  • extension .so - shared-object are shared module libraries (comparable to the .dll files in the Microsoft world)

usage command modinfo

returns detailed information about a system library

Syntax:
	modinfo [ switch ] <module> # specification of the module with path

switch:
 -a outputs the author of the module
 -l license information of the module
 -d description of module functionality
 -n exact name of the module
 -p possibly with transferable parameters

usage command lsmod

Query all modules currently loaded in the system and their dependencies

Syntax:

	lsmod

The output shows, among other things, which other module is necessary
for the operation of this module and also by which process this module is used.

usage command insmod

The command insmod allows to load (not install!) a module
it must therefore be present on the system in the correct directory and
this must also be specified '/lib/modules/<kernelversion>/*'

insmod cannot resolve dependencies!

Syntax:

		insmod </path/to/modules-file.ko>

As usual, there is no output if the execution is error-free!
[additional info: the insmod command enters the module name
into the /proc/modules file after a successful load]

usage command rmmod

With the command rmmod it is possible to UNLOAD a module loaded in RAM!
The module itself remains on the system.
It only releases the memory area in RAM!

Syntax:
	rmmod <module name>

When using rmmod it is not necessary to specify the full path of the module,
because rmmod looks directly into the file '/proc/modules',
which module is loaded and which module it is in detail!

Before the actual unloading of the module from RAM
rmmod checks whether the module to be unloaded
is still dependent on one or more other modules.
If the module is necessary for the function of another module,
rmmod will abort the request with an error message and will not unload the module!

If the unloading process is successful you will not get any feedback here either!
If you still want to get a feedback, you can add the babble switch!

Force unloading: It can happen that you have to unload a crashed module,
even if it is necessary for the operation of other modules.
For this you have to use the switch -f!
rmmod will give an error message, but unload the module anyway!

If the forced unloading should lead to a malfunction of the system,
one can reload this module at any time!

usage command depmod

The depmod command creates a file named modules.dep
in the directory structure '/lib/modules/$(uname -r)/'
in which all dependencies of the individual modules are stored.
Also depmod checks if there are newer versions
of a module or if a new module has been added.
The modprobe and insmod commands also use the information from the file.

Background:
depmod goes through every single module during the creation
and looks in the field `depends`
of the single module files and puts them into this very file!

Syntax:
	depmod [switch]

Switch:
 -v verbose
 -n DryRun (dry run with output of all dependencies on the screen
 -A no new modules.dep file is created (quick info)

usage command modprobe

The modprobe command combines all the above-mentioned commands
for module control and administration as a kind of Swiss army knife
and brings a very helpful feature
- modprobe resolves the dependencies of the modules themselves.

Also the specification of the path is omitted when loading a module.
This is achieved by modprobe by querying the currently
running kernel version (uname -r)
and then jumping to the correct path accordingly.

Syntax:
		modprobe [ switch ] [ option ]

Switch:
 -a load all passed modules > insmod
 -t type specification of the module
 -l lists all available modules
    the -l switch is no longer present in the current implementation
    of modprobe on Ubuntu version 13.10 > lsmod
 -d <ver> passes a different path
    otherwise modprobe always uses '/lib/modules/$(uname -r)'
 -f force operation
 -n run dry - the operation is only simulated
 -r unloads specified modules > rmmod
 -q suppresses any output and also possible error messages
 --show-depends show all dependencies for the specified module > depmod