jmarya/knowledge
jmarya/knowledge
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity

remove non ascii whitespaces

Browse source
This commit is contained in:
JMARyA 2024-01-17 09:44:04 +01:00
parent 598a10bc28
commit 5a6d6c4d13
Signed by: jmarya
GPG key ID: 901B2ADDF27C2263
117 changed files with 1928 additions and 1928 deletions
Download patch file Download diff file Expand all files Collapse all files

2
technology/linux/Arch Linux.md
View file

@ -8,5 +8,5 @@ Arch is a very minimal [Linux](Linux.md) Distribution. It features many [package
Installation of Arch Linux is typically done manually following the Wiki. Additionally there are install scripts like this one:
```shell
curl -L matmoul.github.io/archfi | bash
curl -L matmoul.github.io/archfi | bash
```

12
technology/linux/Linux.md
View file

@ -17,7 +17,7 @@ A typical Linux system has, among others, the following directories:
| ---------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `/` | This is the root directory. This is where the whole tree starts. |
| `/bin` | This directory contains executable programs which are needed in single user mode and to bring the system up or repair it. |
| `/boot` | Contains static files for the boot loader. This directory holds only the files which are needed during the boot process. The operating system kernel (initrd for example) must be located in either `/` or `/boot`. |
| `/boot` | Contains static files for the boot loader. This directory holds only the files which are needed during the boot process. The operating system kernel (initrd for example) must be located in either `/` or `/boot`. |
| `/dev` | Special or device files, which refer to physical devices. |
| `/etc` | Contains configuration files which are local to the machine. |
| `/home` | On machines with home directories for users, these are usually beneath this directory, directly or not. |
@ -26,15 +26,15 @@ A typical Linux system has, among others, the following directories:
| _`/lost+found`_ | This comes from [Ext4](filesystems/Ext4.md). This directory contains items lost in the filesystem. |
| `/media` | This directory contains mount points for removable media such as CD and DVD disks or USB sticks. |
| `/mnt` | This directory is a mount point for a temporarily mounted filesystem. |
| `/proc` | This is a mount point for the _proc_ filesystem, which provides information about running processes and the kernel. |
| `/proc` | This is a mount point for the _proc_ filesystem, which provides information about running processes and the kernel. |
| `/root` | This directory is usually the home directory for the root user (optional). |
| `/run` | This directory contains information which describes the system since it was booted. Once this purpose was served by `/var/run` and programs may continue to use it. |
| `/sbin` | Like `/bin`, this directory holds commands needed to boot the system, but which are usually not executed by normal users. |
| `/sys` | This is a mount point for the _sysfs_ filesystem, which provides information about the kernel like _/proc_, but better structured, following the formalism of kobject infrastructure. |
| `/run` | This directory contains information which describes the system since it was booted. Once this purpose was served by `/var/run` and programs may continue to use it. |
| `/sbin` | Like `/bin`, this directory holds commands needed to boot the system, but which are usually not executed by normal users. |
| `/sys` | This is a mount point for the _sysfs_ filesystem, which provides information about the kernel like _/proc_, but better structured, following the formalism of kobject infrastructure. |
| `/tmp` | This directory contains temporary files which may be deleted with no notice, such as by a regular job or at system boot up. |
| `/usr` | This directory is usually mounted from a separate partition. It should hold only shareable, read-only data, so that it can be mounted by various machines running Linux. |
| `/usr/bin` | This is the primary directory for executable programs. Most programs executed by normal users which are not needed for booting or for repairing the system and which are not installed locally should be placed in this directory. |
| `/usr/etc` | Site-wide configuration files to be shared between several machines may be stored in this directory. However, commands should always reference those files using the `/etc` directory. Links from files in `/etc` should point to the appropriate files in `/usr/etc`. |
| `/usr/etc` | Site-wide configuration files to be shared between several machines may be stored in this directory. However, commands should always reference those files using the `/etc` directory. Links from files in `/etc` should point to the appropriate files in `/usr/etc`. |
| `/usr/include` | Include files for the C compiler. |
| `/usr/lib` | Object libraries, including dynamic libraries, plus some executables which usually are not invoked directly. More complicated programs may have whole subdirectories there. |
| `/usr/share` | This directory contains subdirectories with specific application data, that can be shared among different architectures of the same OS. |

4
technology/linux/filesystems/MergerFS Tools.md
View file

@ -59,7 +59,7 @@ $ mergerfs.fsck -v -f manual /path/to/dir
```
## mergerfs.dup
Duplicates files & directories across branches in a pool. The file selected for duplication is picked by the `dup` option. Files will be copied to drives with the most free space. Deleted from others if `prune` is enabled.
Duplicates files & directories across branches in a pool. The file selected for duplication is picked by the `dup` option. Files will be copied to drives with the most free space. Deleted from others if `prune` is enabled.
```shell
usage: mergerfs.dup [<options>] <dir>
@ -91,7 +91,7 @@ optional arguments:
```
## mergerfs.dedup
Finds and removes duplicate files across mergerfs pool's branches. Use the `ignore`, `dedup`, and `strict` options to target specific use cases.
Finds and removes duplicate files across mergerfs pool's branches. Use the `ignore`, `dedup`, and `strict` options to target specific use cases.
```shell
usage: mergerfs.dedup [<options>] <dir>

36
technology/linux/filesystems/MergerFS.md
View file

@ -3,7 +3,7 @@ repo: https://github.com/trapexit/mergerfs
obj: filesystem
---
# MergerFS
**mergerfs** is a union filesystem geared towards simplifying storage and management of files across numerous commodity storage devices. It is similar to **mhddfs**, **unionfs**, and **aufs**.
**mergerfs** is a union filesystem geared towards simplifying storage and management of files across numerous commodity storage devices. It is similar to **mhddfs**, **unionfs**, and **aufs**.
Usage: `mergerfs -o<options> <branches> <mountpoint>`
@ -54,7 +54,7 @@ WantedBy=default.target
```
## Options
These options are the same regardless of whether you use them with the `mergerfs` commandline program, in fstab, or in a config file.
These options are the same regardless of whether you use them with the `mergerfs` commandline program, in fstab, or in a config file.
| mount option | description |
| ----------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
@ -132,29 +132,29 @@ These options are the same regardless of whether you use them with the `mergerf
### branches
The 'branches' argument is a colon (':') delimited list of paths to be pooled together. It does not matter if the paths are on the same or different filesystems nor does it matter the filesystem type (within reason). Used and available space will not be duplicated for paths on the same filesystem and any features which aren't supported by the underlying filesystem (such as file attributes or extended attributes) will return the appropriate errors.
Branches currently have two options which can be set. A type which impacts whether or not the branch is included in a policy calculation and a individual minfreespace value. The values are set by prepending an `=` at the end of a branch designation and using commas as delimiters. Example: `/mnt/drive=RW,1234`
Branches currently have two options which can be set. A type which impacts whether or not the branch is included in a policy calculation and a individual minfreespace value. The values are set by prepending an `=` at the end of a branch designation and using commas as delimiters. Example: `/mnt/drive=RW,1234`
#### branch mode
- RW: (read/write) - Default behavior. Will be eligible in all policy categories.
- RO: (read-only) - Will be excluded from `create` and `action` policies. Same as a read-only mounted filesystem would be (though faster to process).
- NC: (no-create) - Will be excluded from `create` policies. You can't create on that branch but you can change or delete.
- RO: (read-only) - Will be excluded from `create` and `action` policies. Same as a read-only mounted filesystem would be (though faster to process).
- NC: (no-create) - Will be excluded from `create` policies. You can't create on that branch but you can change or delete.
#### globbing
To make it easier to include multiple branches mergerfs supports [globbing](http://linux.die.net/man/7/glob). **The globbing tokens MUST be escaped when using via the shell else the shell itself will apply the glob itself.**
To make it easier to include multiple branches mergerfs supports [globbing](http://linux.die.net/man/7/glob). **The globbing tokens MUST be escaped when using via the shell else the shell itself will apply the glob itself.**
```
# mergerfs /mnt/hdd\*:/mnt/ssd /media
```
The above line will use all mount points in /mnt prefixed with **hdd** and **ssd**.
The above line will use all mount points in /mnt prefixed with **hdd** and **ssd**.
To have the pool mounted at boot or otherwise accessible from related tools use **/etc/fstab**.
To have the pool mounted at boot or otherwise accessible from related tools use **/etc/fstab**.
```
# <file system> <mount point> <type> <options> <dump> <pass>
/mnt/hdd*:/mnt/ssd /media fuse.mergerfs minfreespace=16G 0 0
```
## Functions, Categories and Policies
The POSIX filesystem API is made up of a number of functions. **creat**, **stat**, **chown**, etc. For ease of configuration in mergerfs most of the core functions are grouped into 3 categories: **action**, **create**, and **search**. These functions and categories can be assigned a policy which dictates which branch is chosen when performing that function.
The POSIX filesystem API is made up of a number of functions. **creat**, **stat**, **chown**, etc. For ease of configuration in mergerfs most of the core functions are grouped into 3 categories: **action**, **create**, and **search**. These functions and categories can be assigned a policy which dictates which branch is chosen when performing that function.
### Functions and their Category classifications
| Category | FUSE Functions |
@ -171,22 +171,22 @@ A policy's behavior differs, as mentioned above, based on the function it is use
| Policy | Description |
| --------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| all | Search: For **mkdir**, **mknod**, and **symlink** it will apply to all branches. **create** works like **ff**. |
| epall (existing path, all) | For **mkdir**, **mknod**, and **symlink** it will apply to all found. **create** works like **epff** (but more expensive because it doesn't stop after finding a valid branch). |
| all | Search: For **mkdir**, **mknod**, and **symlink** it will apply to all branches. **create** works like **ff**. |
| epall (existing path, all) | For **mkdir**, **mknod**, and **symlink** it will apply to all found. **create** works like **epff** (but more expensive because it doesn't stop after finding a valid branch). |
| epff (existing path, first found) | Given the order of the branches, as defined at mount time or configured at runtime, act on the first one found where the relative path exists. |
| eplfs (existing path, least free space) | Of all the branches on which the relative path exists choose the branch with the least free space. |
| eplus (existing path, least used space) | Of all the branches on which the relative path exists choose the branch with the least used space. |
| epmfs (existing path, most free space) | Of all the branches on which the relative path exists choose the branch with the most free space. |
| eppfrd (existing path, percentage free random distribution) | Like **pfrd** but limited to existing paths. |
| eprand (existing path, random) | Calls **epall** and then randomizes. Returns 1. |
| eppfrd (existing path, percentage free random distribution) | Like **pfrd** but limited to existing paths. |
| eprand (existing path, random) | Calls **epall** and then randomizes. Returns 1. |
| ff (first found) | Given the order of the branches, as defined at mount time or configured at runtime, act on the first one found. |
| lfs (least free space) | Pick the branch with the least available free space. |
| lus (least used space) | Pick the branch with the least used space. |
| mfs (most free space) | Pick the branch with the most available free space. |
| msplfs (most shared path, least free space) | Like **eplfs** but if it fails to find a branch it will try again with the parent directory. Continues this pattern till finding one. |
| msplus (most shared path, least used space) | Like **eplus** but if it fails to find a branch it will try again with the parent directory. Continues this pattern till finding one. |
| mspmfs (most shared path, most free space) | Like **epmfs** but if it fails to find a branch it will try again with the parent directory. Continues this pattern till finding one. |
| msppfrd (most shared path, percentage free random distribution) | Like **eppfrd** but if it fails to find a branch it will try again with the parent directory. Continues this pattern till finding one. |
| msplfs (most shared path, least free space) | Like **eplfs** but if it fails to find a branch it will try again with the parent directory. Continues this pattern till finding one. |
| msplus (most shared path, least used space) | Like **eplus** but if it fails to find a branch it will try again with the parent directory. Continues this pattern till finding one. |
| mspmfs (most shared path, most free space) | Like **epmfs** but if it fails to find a branch it will try again with the parent directory. Continues this pattern till finding one. |
| msppfrd (most shared path, percentage free random distribution) | Like **eppfrd** but if it fails to find a branch it will try again with the parent directory. Continues this pattern till finding one. |
| newest | Pick the file / directory with the largest mtime. |
| pfrd (percentage free random distribution) | Chooses a branch at random with the likelihood of selection based on a branch's available space relative to the total. |
| rand (random) | Calls **all** and then randomizes. Returns 1 branch. |
| rand (random) | Calls **all** and then randomizes. Returns 1 branch. |

18
technology/linux/filesystems/RAID.md
View file

@ -3,30 +3,30 @@ arch-wiki: https://wiki.archlinux.org/title/RAID
obj: concept
---
# RAID
Redundant Array of Independent Disks (RAID) is a storage technology that combines multiple disk drive components (typically disk drives or partitions thereof) into a logical unit. Depending on the RAID implementation, this logical unit can be a file system or an additional transparent layer that can hold several partitions. Data is distributed across the drives in one of several ways called RAID levels, depending on the level of redundancy and performance required. The RAID level chosen can thus prevent data loss in the event of a hard disk failure, increase performance or be a combination of both.
Redundant Array of Independent Disks (RAID) is a storage technology that combines multiple disk drive components (typically disk drives or partitions thereof) into a logical unit. Depending on the RAID implementation, this logical unit can be a file system or an additional transparent layer that can hold several partitions. Data is distributed across the drives in one of several ways called RAID levels, depending on the level of redundancy and performance required. The RAID level chosen can thus prevent data loss in the event of a hard disk failure, increase performance or be a combination of both.
## RAID Levels
### RAID 0
Uses striping to combine disks. Even though it _does not provide redundancy_, it is still considered RAID. It does, however, _provide a big speed benefit_. If the speed increase is worth the possibility of data loss, choose this RAID level. On a server, RAID 1 and RAID 5 arrays are more appropriate. The size of a RAID 0 array block device is the size of the smallest component partition times the number of component partitions.
Uses striping to combine disks. Even though it _does not provide redundancy_, it is still considered RAID. It does, however, _provide a big speed benefit_. If the speed increase is worth the possibility of data loss, choose this RAID level. On a server, RAID 1 and RAID 5 arrays are more appropriate. The size of a RAID 0 array block device is the size of the smallest component partition times the number of component partitions.
### RAID 1
The most straightforward RAID level: straight mirroring. As with other RAID levels, it only makes sense if the partitions are on different physical disk drives. If one of those drives fails, the block device provided by the RAID array will continue to function as normal. The example will be using RAID 1 for everything except swap and temporary data. Please note that with a software implementation, the RAID 1 level is the only option for the boot partition, because bootloaders reading the boot partition do not understand RAID, but a RAID 1 component partition can be read as a normal partition. The size of a RAID 1 array block device is the size of the smallest component partition.
The most straightforward RAID level: straight mirroring. As with other RAID levels, it only makes sense if the partitions are on different physical disk drives. If one of those drives fails, the block device provided by the RAID array will continue to function as normal. The example will be using RAID 1 for everything except swap and temporary data. Please note that with a software implementation, the RAID 1 level is the only option for the boot partition, because bootloaders reading the boot partition do not understand RAID, but a RAID 1 component partition can be read as a normal partition. The size of a RAID 1 array block device is the size of the smallest component partition.
### RAID 5
Requires 3 or more physical drives, and provides the redundancy of RAID 1 combined with the speed and size benefits of RAID 0. RAID 5 uses striping, like RAID 0, but also stores parity blocks _distributed across each member disk_. In the event of a failed disk, these parity blocks are used to reconstruct the data on a replacement disk. RAID 5 can withstand the loss of one member disk.
Requires 3 or more physical drives, and provides the redundancy of RAID 1 combined with the speed and size benefits of RAID 0. RAID 5 uses striping, like RAID 0, but also stores parity blocks _distributed across each member disk_. In the event of a failed disk, these parity blocks are used to reconstruct the data on a replacement disk. RAID 5 can withstand the loss of one member disk.
### RAID 6
Requires 4 or more physical drives, and provides the benefits of RAID 5 but with security against two drive failures. RAID 6 also uses striping, like RAID 5, but stores two distinct parity blocks _distributed across each member disk_. In the event of a failed disk, these parity blocks are used to reconstruct the data on a replacement disk. RAID 6 can withstand the loss of two member disks. The robustness against unrecoverable read errors is somewhat better, because the array still has parity blocks when rebuilding from a single failed drive. However, given the overhead, RAID 6 is costly and in most settings RAID 10 in far2 layout (see below) provides better speed benefits and robustness, and is therefore preferred.
Requires 4 or more physical drives, and provides the benefits of RAID 5 but with security against two drive failures. RAID 6 also uses striping, like RAID 5, but stores two distinct parity blocks _distributed across each member disk_. In the event of a failed disk, these parity blocks are used to reconstruct the data on a replacement disk. RAID 6 can withstand the loss of two member disks. The robustness against unrecoverable read errors is somewhat better, because the array still has parity blocks when rebuilding from a single failed drive. However, given the overhead, RAID 6 is costly and in most settings RAID 10 in far2 layout (see below) provides better speed benefits and robustness, and is therefore preferred.
## Using RAID
Software RAID is the easiest implementation as it does not rely on obscure proprietary firmware and software to be used. The array is managed by the operating system either by:
- an abstraction layer (e.g. mdadm);
- a logical volume manager (e.g. [LVM](LVM.md));
- a component of a file system (e.g. [ZFS](ZFS.md), [Btrfs](Btrfs.md))
- an abstraction layer (e.g. mdadm);
- a logical volume manager (e.g. [LVM](LVM.md));
- a component of a file system (e.g. [ZFS](ZFS.md), [Btrfs](Btrfs.md))
## Installation
_mdadm_ is used for administering pure software RAID using plain block devices: the underlying hardware does not provide any RAID logic, just a supply of disks. _mdadm_ will work with any collection of block devices. Even if unusual. For example, one can thus make a RAID array from a collection of thumb drives.
_mdadm_ is used for administering pure software RAID using plain block devices: the underlying hardware does not provide any RAID logic, just a supply of disks. _mdadm_ will work with any collection of block devices. Even if unusual. For example, one can thus make a RAID array from a collection of thumb drives.
**Erase disks**
```shell

2
technology/linux/filesystems/SquashFS.md
View file

@ -2,7 +2,7 @@
obj: filesystem
---
# SquashFS
**Squashfs** is a compressed read-only [file system](Filesystems.md) for [Linux](../Linux.md).
**Squashfs** is a compressed read-only [file system](Filesystems.md) for [Linux](../Linux.md).
## Creation
```shell

2
technology/linux/filesystems/ZFS.md
View file

@ -6,7 +6,7 @@ obj: filesystem
---
# ZFS
[ZFS](https://en.wikipedia.org/wiki/ZFS "wikipedia:ZFS") is an advanced filesystem.
[ZFS](https://en.wikipedia.org/wiki/ZFS "wikipedia:ZFS") is an advanced filesystem.
## ZPool
**Create a pool***

32
technology/linux/mkinitcpio.md
View file

@ -3,10 +3,10 @@ obj: concept
---
# mkinitcpio
The initial ramdisk is in essence a very small environment (early userspace) which loads various kernel modules and sets up necessary things before handing over control to `init`. This makes it possible to have, for example, encrypted root file systems and root file systems on a software [RAID](filesystems/RAID.md) array. _mkinitcpio_ allows for easy extension with custom hooks, has autodetection at runtime, and many other features.
The initial ramdisk is in essence a very small environment (early userspace) which loads various kernel modules and sets up necessary things before handing over control to `init`. This makes it possible to have, for example, encrypted root file systems and root file systems on a software [RAID](filesystems/RAID.md) array. _mkinitcpio_ allows for easy extension with custom hooks, has autodetection at runtime, and many other features.
## Configuration
The primary configuration file for _mkinitcpio_ is `/etc/mkinitcpio.conf`. Additionally, preset definitions are provided by kernel packages in the `/etc/mkinitcpio.d` directory (e.g. `/etc/mkinitcpio.d/linux.preset`).
The primary configuration file for _mkinitcpio_ is `/etc/mkinitcpio.conf`. Additionally, preset definitions are provided by kernel packages in the `/etc/mkinitcpio.d` directory (e.g. `/etc/mkinitcpio.d/linux.preset`).
`MODULES`
Kernel modules to be loaded before any boot hooks are run.
@ -24,40 +24,40 @@ Hooks are scripts that execute in the initial ramdisk.
Used to compress the initramfs image.
### MODULES
The `MODULES` array is used to specify modules to load before anything else is done.
The `MODULES` array is used to specify modules to load before anything else is done.
Modules suffixed with a `?` will not throw errors if they are not found. This might be useful for custom kernels that compile in modules which are listed explicitly in a hook or configuration file.
Modules suffixed with a `?` will not throw errors if they are not found. This might be useful for custom kernels that compile in modules which are listed explicitly in a hook or configuration file.
### BINARIES and FILES
These options allow users to add files to the image. Both `BINARIES` and `FILES` are added before hooks are run, and may be used to override files used or provided by a hook. `BINARIES` are auto-located within a standard `PATH` and are dependency-parsed, meaning any required libraries will also be added. `FILES` are added _as-is_. For example:
These options allow users to add files to the image. Both `BINARIES` and `FILES` are added before hooks are run, and may be used to override files used or provided by a hook. `BINARIES` are auto-located within a standard `PATH` and are dependency-parsed, meaning any required libraries will also be added. `FILES` are added _as-is_. For example:
```
FILES=(/etc/modprobe.d/modprobe.conf)
BINARIES=(kexec)
```
Note that as both `BINARIES` and `FILES` are Bash arrays, multiple entries can be added delimited with spaces.
Note that as both `BINARIES` and `FILES` are Bash arrays, multiple entries can be added delimited with spaces.
### HOOKS
The `HOOKS` array is the most important setting in the file. Hooks are small scripts which describe what will be added to the image. For some hooks, they will also contain a runtime component which provides additional behavior, such as starting a daemon, or assembling a stacked block device. Hooks are referred to by their name, and executed in the order they exist in the `HOOKS` array of the configuration file.
The `HOOKS` array is the most important setting in the file. Hooks are small scripts which describe what will be added to the image. For some hooks, they will also contain a runtime component which provides additional behavior, such as starting a daemon, or assembling a stacked block device. Hooks are referred to by their name, and executed in the order they exist in the `HOOKS` array of the configuration file.
The default `HOOKS` setting should be sufficient for most simple, single disk setups. For root devices which are stacked or multi-block devices such as [LVM](filesystems/LVM.md), [RAID](filesystems/RAID.md), or [dm-crypt](filesystems/LUKS.md), see the respective wiki pages for further necessary configuration.
#### Common Hooks
| Hook | Feature |
| --------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **base** | Sets up all initial directories and installs base utilities and libraries. Always keep this hook as the first hook unless you know what you are doing, as it provides critical busybox init when not using **[systemd](systemd/Systemd.md)** hook. Optional when using the **[systemd](systemd/Systemd.md)** hook as it only provides a busybox recovery shell. |
| **base** | Sets up all initial directories and installs base utilities and libraries. Always keep this hook as the first hook unless you know what you are doing, as it provides critical busybox init when not using **[systemd](systemd/Systemd.md)** hook. Optional when using the **[systemd](systemd/Systemd.md)** hook as it only provides a busybox recovery shell. |
| **udev** | Adds udevd, udevadm, and a small subset of udev rules to your image. |
| **usr** | Adds support for /usr on a separate partition. |
| **resume** | Tries to resume from the "suspend to disk" state. |
| **btrfs** | Sets the required modules to enable [Btrfs](filesystems/Btrfs.md) for using multiple devices with [Btrfs](filesystems/Btrfs.md). You need to have btrfs-progs installed to use this. This hook is not required for using [Btrfs](filesystems/Btrfs.md) on a single device. |
| **autodetect** | Shrinks your initramfs to a smaller size by creating a whitelist of modules from a scan of sysfs. Be sure to verify included modules are correct and none are missing. This hook must be run before other subsystem hooks in order to take advantage of auto-detection. Any hooks placed before 'autodetect' will be installed in full. |
| **modconf** | Includes modprobe configuration files from `/etc/modprobe.d/` and `/usr/lib/modprobe.d/`. |
| **block** | Adds all block device modules, formerly separately provided by the _fw_, _mmc_, _pata_, _sata_, _scsi_, _usb_, and _virtio_ hooks. |
| **modconf** | Includes modprobe configuration files from `/etc/modprobe.d/` and `/usr/lib/modprobe.d/`. |
| **block** | Adds all block device modules, formerly separately provided by the _fw_, _mmc_, _pata_, _sata_, _scsi_, _usb_, and _virtio_ hooks. |
| **net** | Adds the necessary modules for a network device. |
| **dmraid** | Provides support for fakeRAID root devices. You must have dmraid installed to use this. Note that it is preferred to use mdadm with the mdadm_udev hook with fakeRAID if your controller supports it. |
| **keyboard** | Adds the necessary modules for keyboard devices. Use this if you have an USB or serial keyboard and need it in early userspace (either for entering encryption passphrases or for use in an interactive shell). As a side effect, modules for some non-keyboard input devices might be added too, but this should not be relied on. Supersedes old _usbinput_ hook. |
| **keymap** | Adds the specified keymap(s) from `/etc/vconsole.conf` to the initramfs. If you use system encryption "[Dm-crypt](filesystems/LUKS.md)/Encrypting an entire system"), especially full-disk encryption, make sure you add it before the `encrypt` hook. |
| **encrypt** | Adds the `dm_crypt` kernel module and the `cryptsetup` tool to the image. |
| **lvm2** | Adds the device mapper kernel module and the `lvm` tool to the image. |
| **fsck** | Adds the fsck binary and file system-specific helpers to allow running fsck against your root device (and `/usr` if separate) prior to mounting. If added after the **autodetect** hook, only the helper specific to your root file system will be added. Usage of this hook is **strongly** recommended, and it is required with a separate `/usr` partition. It is highly recommended that if you include this hook that you also include any necessary modules to ensure your keyboard will work in early userspace. |
| **filesystems** | This includes necessary file system modules into your image. This hook is **required** unless you specify your file system modules in `MODULES`. |
| **keyboard** | Adds the necessary modules for keyboard devices. Use this if you have an USB or serial keyboard and need it in early userspace (either for entering encryption passphrases or for use in an interactive shell). As a side effect, modules for some non-keyboard input devices might be added too, but this should not be relied on. Supersedes old _usbinput_ hook. |
| **keymap** | Adds the specified keymap(s) from `/etc/vconsole.conf` to the initramfs. If you use system encryption "[Dm-crypt](filesystems/LUKS.md)/Encrypting an entire system"), especially full-disk encryption, make sure you add it before the `encrypt` hook. |
| **encrypt** | Adds the `dm_crypt` kernel module and the `cryptsetup` tool to the image. |
| **lvm2** | Adds the device mapper kernel module and the `lvm` tool to the image. |
| **fsck** | Adds the fsck binary and file system-specific helpers to allow running fsck against your root device (and `/usr` if separate) prior to mounting. If added after the **autodetect** hook, only the helper specific to your root file system will be added. Usage of this hook is **strongly** recommended, and it is required with a separate `/usr` partition. It is highly recommended that if you include this hook that you also include any necessary modules to ensure your keyboard will work in early userspace. |
| **filesystems** | This includes necessary file system modules into your image. This hook is **required** unless you specify your file system modules in `MODULES`. |

2
technology/linux/systemd/Systemd-Mounts.md
View file

@ -2,7 +2,7 @@
obj: concept
---
Mounts are _systemd_ unit files with a suffix of _.mount_. A unit configuration file whose name ends in ".mount" encodes information about a file system mount point controlled and supervised by systemd.
Mounts are _systemd_ unit files with a suffix of _.mount_. A unit configuration file whose name ends in ".mount" encodes information about a file system mount point controlled and supervised by systemd.
Mount Unit files like every unit file include the `[Unit]` and `[Install]` sections. Additionally all mount information is in the `[Mount]` section.

16
technology/linux/systemd/Systemd-Timers.md
View file

@ -4,12 +4,12 @@ arch-wiki: https://wiki.archlinux.org/title/Systemd/Timers
---
# Systemd Timers
Timers are _systemd_ unit files with a suffix of _.timer_. Timers are like other unit configuration files and are loaded from the same paths but include a `[Timer]` section which defines when and how the timer activates. Timers are defined as one of two types:
Timers are _systemd_ unit files with a suffix of _.timer_. Timers are like other unit configuration files and are loaded from the same paths but include a `[Timer]` section which defines when and how the timer activates. Timers are defined as one of two types:
- **Realtime timers** (a.k.a. wallclock timers) activate on a calendar event, the same way that cronjobs do. The option `OnCalendar=` is used to define them.
- **Monotonic timers** activate after a time span relative to a varying starting point. They stop if the computer is temporarily suspended or shut down. There are number of different monotonic timers but all have the form: `On_Type_Sec=`. Common monotonic timers include `OnBootSec` and `OnUnitActiveSec`.
- **Realtime timers** (a.k.a. wallclock timers) activate on a calendar event, the same way that cronjobs do. The option `OnCalendar=` is used to define them.
- **Monotonic timers** activate after a time span relative to a varying starting point. They stop if the computer is temporarily suspended or shut down. There are number of different monotonic timers but all have the form: `On_Type_Sec=`. Common monotonic timers include `OnBootSec` and `OnUnitActiveSec`.
For each _.timer_ file, a matching _.service_ file exists (e.g. `foo.timer` and `foo.service`). The _.timer_ file activates and controls the _.service_ file. The _.service_ does not require an `[Install]` section as it is the _timer_ units that are enabled. If necessary, it is possible to control a differently-named unit using the `Unit=` option in the timer's `[Timer]` section.
For each _.timer_ file, a matching _.service_ file exists (e.g. `foo.timer` and `foo.service`). The _.timer_ file activates and controls the _.service_ file. The _.service_ does not require an `[Install]` section as it is the _timer_ units that are enabled. If necessary, it is possible to control a differently-named unit using the `Unit=` option in the timer's `[Timer]` section.
List timers:
```shell
@ -36,7 +36,7 @@ WantedBy=timers.target
### Realtime timer
A timer which starts once a week (at 12:00am on Monday). When activated, it triggers the service immediately if it missed the last start time (option `Persistent=true`), for example due to the system being powered off:
A timer which starts once a week (at 12:00am on Monday). When activated, it triggers the service immediately if it missed the last start time (option `Persistent=true`), for example due to the system being powered off:
`/etc/systemd/system/foo.timer`
```
@ -51,12 +51,12 @@ Persistent=true
WantedBy=timers.target
```
When more specific dates and times are required, `OnCalendar` events uses the following format:
When more specific dates and times are required, `OnCalendar` events uses the following format:
`DayOfWeek Year-Month-Day Hour:Minute:Second`
An asterisk may be used to specify any value and commas may be used to list possible values. Two values separated by `..` indicate a contiguous range.
An asterisk may be used to specify any value and commas may be used to list possible values. Two values separated by `..` indicate a contiguous range.
In the below example the service is run the first four days of each month at 12:00 PM, but _only_ if that day is a Monday or a Tuesday.
In the below example the service is run the first four days of each month at 12:00 PM, but _only_ if that day is a Monday or a Tuesday.
`OnCalendar=Mon,Tue *-*-01..04 12:00:00`

44
technology/linux/systemd/Systemd.md
View file

@ -34,12 +34,12 @@ systemctl --failed
Start unit:
```shell
systemctl start unit
systemctl start unit
```
Stop unit:
```shell
systemctl stop unit
systemctl stop unit
```
Restart unit:
@ -54,14 +54,14 @@ systemctl daemon-reload
Enable/Disable (Start at boot) unit:
```shell
systemctl enable unit
systemctl disable unit
systemctl enable unit
systemctl disable unit
```
Mask (forbid running) unit:
```shell
systemctl mask unit
systemctl unmask unit
systemctl mask unit
systemctl unmask unit
```
## Power Management
@ -87,14 +87,14 @@ Stored in:
- `~/.config/systemd/user/`: units used by local users
### Service types
There are several different start-up types to consider when writing a custom service file. This is set with the `Type=` parameter in the `[Service]` section:
There are several different start-up types to consider when writing a custom service file. This is set with the `Type=` parameter in the `[Service]` section:
- `Type=simple` (default): _systemd_ considers the service to be started up immediately. The process must not fork. Do not use this type if other services need to be ordered on this service, unless it is socket activated.
- `Type=forking`: _systemd_ considers the service started up once the process forks and the parent has exited. For classic daemons use this type unless you know that it is not necessary. You should specify `PIDFile=` as well so _systemd_ can keep track of the main process.
- `Type=oneshot`: this is useful for scripts that do a single job and then exit. You may want to set `RemainAfterExit=yes` as well so that _systemd_ still considers the service as active after the process has exited.
- `Type=notify`: identical to `Type=simple`, but with the stipulation that the daemon will send a signal to _systemd_ when it is ready. The reference implementation for this notification is provided by _libsystemd-daemon.so_.
- `Type=dbus`: the service is considered ready when the specified `BusName` appears on DBus's system bus.
- `Type=idle`: _systemd_ will delay execution of the service binary until all jobs are dispatched. Other than that behavior is very similar to `Type=simple`.
- `Type=simple` (default): _systemd_ considers the service to be started up immediately. The process must not fork. Do not use this type if other services need to be ordered on this service, unless it is socket activated.
- `Type=forking`: _systemd_ considers the service started up once the process forks and the parent has exited. For classic daemons use this type unless you know that it is not necessary. You should specify `PIDFile=` as well so _systemd_ can keep track of the main process.
- `Type=oneshot`: this is useful for scripts that do a single job and then exit. You may want to set `RemainAfterExit=yes` as well so that _systemd_ still considers the service as active after the process has exited.
- `Type=notify`: identical to `Type=simple`, but with the stipulation that the daemon will send a signal to _systemd_ when it is ready. The reference implementation for this notification is provided by _libsystemd-daemon.so_.
- `Type=dbus`: the service is considered ready when the specified `BusName` appears on DBus's system bus.
- `Type=idle`: _systemd_ will delay execution of the service binary until all jobs are dispatched. Other than that behavior is very similar to `Type=simple`.
#### Example
```
@ -117,32 +117,32 @@ LimitNOFILE=4096
WantedBy=multi-user.target
```
### The `[Unit]` section
### The `[Unit]` section
The Unit sectoin contains details and description about the unit itself. In our case, it contains details about the service. Details like 'what is it's description', 'what are it's dependencies' and more.
Below are the fields the Unit section has:
- `Description`: Human-readable title of the systemd service.
- `After`: Set dependency on a service. For example, if you are configuring Apache web server, you want the server to start after the network is online. This typically includes targets or other services.
- `Before`: Start current service before specified service. This too, like `After`, includes targets or other services.
- `Before`: Start current service before specified service. This too, like `After`, includes targets or other services.
### The `[Service]` section
### The `[Service]` section
The Service section contains details about the execution and termination of service.
Below are the fields the Service section can have:
- `ExecStart`: The command that needs to be executed when the service starts.
- `ExecReload`: This is an optional field. It specifies how a service is restarted. For services that perform disk I/O (especially writing to disk, like a database), it is best to gracefully kill them and start again. Use this field in case you wish to have a specific restart mechanism.
- `Type`: The process start-up type for this systemd service. Options are `simple`, `exec`, `forking`, `oneshot`, `dbus`, `notify` and `idle`.
- `Restart`: This is another optional field but one that you will very likely use. This specifies if a service should be restarted--depending on circumstances--or not. The available options are `no`, `on-success`, `on-failure`, `on-abnormal`, `on-watchdog`, `on-abort` and `always`.
- `Type`: The process start-up type for this systemd service. Options are `simple`, `exec`, `forking`, `oneshot`, `dbus`, `notify` and `idle`.
- `Restart`: This is another optional field but one that you will very likely use. This specifies if a service should be restarted--depending on circumstances--or not. The available options are `no`, `on-success`, `on-failure`, `on-abnormal`, `on-watchdog`, `on-abort` and `always`.
- `Environment`: [Environment Variables](Environment%20Variables.md)
- `User`: The user that should run the process
- `WorkingDirectory`: Working directory of the process
### The `[Install]` section
The Install section, as the name says, handles the installation of a systemd service/unit file. This is used when you run either `systemctl enable` and `systemctl disable` command for enable/disable a service.
### The `[Install]` section
The Install section, as the name says, handles the installation of a systemd service/unit file. This is used when you run either `systemctl enable` and `systemctl disable` command for enable/disable a service.
Below are the fields the Install section has:
- `WantedBy`: This is similar to the `After` and `Before` fields, but the main difference is that this is used to specify systemd-equivalent "runlevels". The `default.target` is when all the system initialization is complete--when the user is asked to log in. Most user-facing services (like Apache, cron, GNOME-stuff, etc) use this target.
- `RequiredBy`: This field might feel very similar to `WantedBy`, but the main difference is that this field specifies _hard dependencies_. Meaning, if a dependency, this service will fail.
- `WantedBy`: This is similar to the `After` and `Before` fields, but the main difference is that this is used to specify systemd-equivalent "runlevels". The `default.target` is when all the system initialization is complete--when the user is asked to log in. Most user-facing services (like Apache, cron, GNOME-stuff, etc) use this target.
- `RequiredBy`: This field might feel very similar to `WantedBy`, but the main difference is that this field specifies _hard dependencies_. Meaning, if a dependency, this service will fail.
### Other Unit Types
Systemd supports other unit types than `.service`.

4
technology/linux/systemd/systemd-boot.md
View file

@ -20,7 +20,7 @@ bootctl update
```
## Configuration
The loader configuration is stored in the file `_esp_/loader/loader.conf`
The loader configuration is stored in the file `_esp_/loader/loader.conf`
Example:
```
default arch.conf
@ -30,7 +30,7 @@ editor no
```
### Adding loaders
_systemd-boot_ will search for boot menu items in `_esp_/loader/entries/*.conf`
_systemd-boot_ will search for boot menu items in `_esp_/loader/entries/*.conf`
Values:
- `title` : Name