Alpine Linux - User contributions [en]

Alpine local backup

2021-12-02T19:13:07Z

Dfen: /* Saving and loading ISO image customizations */ link to relevant section

When Alpine Linux boots in diskless mode, it initially only loads a few required packages from the boot device.

However, local adjustments to what-gets-loaded-into-RAM are possible, e.g. by [[Alpine_package_management|installing a package]] or adjusting the configuration files in {{path|/etc}}. The modifications can be saved to an overlay file (.apkovl) that can be automatically loaded when booting, to restore the saved state.

The .apkovl file that contains the custom configuration can be saved to writable storage with Alpine's local backup utility <code>lbu</code>. By configuring a [[Alpine_Linux_package_management#Local_Cache|local package cache]] the additional packages the configuration depends on, can also be kept available on local, writable storage.

{{Note|If you installed Alpine in "sys" disk mode, you don't need to use <code>lbu</code> to save the system state. With a system disk, all modifications are
written directly to disk. Nevertheless, <code>lbu</code> can be useful for some maintenance tasks.}}

__TOC__

{{Warning|
'''By default, an <code>lbu commit</code> only stores modifications below {{Path|/etc}}''', with the exception of the {{Path|/etc/init.d/}} directory.

However, [[#Include_special_files.2Ffolders_to_the_apkovl|lbu include]] enables modifying that set of included files, and can be used to specify additional files or folders.
}}

== Saving and loading ISO image customizations ==

Besides supporting a boot parameter to load customizations from a web server, Alpine's "diskless mode" ISO images try to load an .apkovl volume from system partitions. It is therefore possible to save customized running states to a .apkovl file on a writable partition, and have these automatically loaded when booting the ISO image.

{{Note|When the machine reboots, the remote repositories will not be available until after networking has started. That means packages newer than on your local boot media would not be available after a reboot, unless they were made to persistent, by having a [[#Local Cache|local package cache]] available on a local, writable, storage device.}}

The local package cache, which enables additional and updated packages to automatically be copied into RAM during boot, may be stored on the same partition as the .apkovl file.

To use partitions on '''internal disks''', however, you need to prepare a specific /etc/fstab entry manually, and save the configuration, as follows (setup-alpine does not list them for saving configs or package cache):

1. Boot the diskless system from ISO (as shown at [[Installation]]) 
2. If necessary, create and format a partition as in [[Setting_up_disks_manually#For_.22diskless.22_and_.22data.22_disk_mode_installs_2]]. For the examples we will use /dev/sdXY 
* Bug: [https://gitlab.alpinelinux.org/alpine/mkinitfs/-/issues/5 Initramfs-init does not respect apkovl device fstab entry], so the partition can not be mounted to /boot. The workaround given there does not seem to work (e.g. <code>mkdir -p /boot/ovl_dev/cache ; touch /boot/ovl_dev/cache/.boot_repository</code>) 
=> Alternative: Configure the /etc/fstab to mount the writable partition to /media/sdXY instead of /boot (i.e. conforming to the hot/cold-plug mountpoints): 
3. <code>mkdir /media/sdXY</code> 
4. <code>echo "/dev/sdXY /media/sdXY ext4 noatime,ro 0 0" >> /etc/fstab</code> (Mounting read-only is possible, because the tools temporarily remount it writable for their operation.) 
5. Use <code>mount -a</code> to load the partitions listed in /etc/fstab. Look at the output of <code>mount</code> to verify that the /etc/fstab changes have been applied correctly. 
6. If setup-alpine has not run before, it may be used and should now enable you to choose the partition for saving the local configs and package cache. (If asked, there is no need to first unmount the partition, that would only be needed to allow installing on its parent disk.) 
If setup-alpine has already been used to configure the diskless system, the storage settings may be modified directly with <code>setup-lbu sdXY</code> and <code>mkdir /media/sdXY/cache ; setup-apkcache /media/sdXY/cache</code> 
7. If the partition is large enough, it can be useful to edit lbu.conf to uncomment and set <code>BACKUP_LIMIT=3</code>. For example, to allow reverting to a previous, working state if needed.
{{cmd| # apk add nano
# nano /etc/lbu/lbu.conf
}}
8. Finally, generate the first .apkovl file containing all the previous changes with [https://wiki.alpinelinux.org/wiki/Alpine_local_backup Alpine_local_backup], by executing <code>lbu commit</code>, so the customizations that were just made will persist a reboot.

From then on, whenever packages are installed or newly configured, and the changes should be kept, execute <code>lbu commit</code> again.

Notes:

* For a virtual machine, the '''[[QEMU#Live_mode|QEMU example]]''' shows how an ISO image can automatically boot with .apkovl customizations.
* The [[Alpine_local_backup#Include_special_files.2Ffolders_to_the_apkovl|Include special files section]] explains how to include custom files outside of <code>/etc</code> in the .apkovl file.
* [[Alpine_Linux_package_management#Local_Cache]] covers managing a local package cache.
** The packages get listed in /etc/apk/world which gets saved with the lbu, for them to be automatically installed when the live system boots.
* It's possible to load an APKOVL file from a webserver, by supplying a custom url with the <code>APKOVL</code> kernel boot parameter.
** If you don't have a web server you can run busybox's httpd temporarily to serve an .apkovl - <code>busybox httpd -p 127.0.0.1:80</code>.
* To customize the boot sequence further, one may refer to [[PXE_boot#Specifying_an_apkovl]] and [[How_to_make_a_custom_ISO_image_with_mkimage]].

== Committing changes ==

The <code>lbu</code> tool has several subcommands to manage the .apkovl:
* lbu
* lbu commit ''(Same as 'lbu ci')''
* lbu package ''(Same as 'lbu pkg')''
* lbu status ''(Same as 'lbu st')''
* lbu list ''(Same as 'lbu ls')''
* lbu diff
* lbu include ''(Same as 'lbu inc' or 'lbu add')''
* lbu exclude ''(Same as 'lbu ex' or 'lbu delete')''
* lbu list-backup ''(Same as 'lbu lb')''
* lbu revert

In the examples below, you will find some characters with special meaning:
* '''|''' = '''or''' ''('lbu commit|ci' means that you can type ether 'lbu commit' or 'lbu ci')''
* '''[ ]''' = '''optional''' ''(In 'lbu commit|ci [-nv]' you can skip the '-n', '-v' or '-nv' part if you don't want it)''

=== Basic "commit" command ===
When you "commit" or save changes you've made to your system, <code>lbu</code> will generate a file named something like {{Path|<var>myboxname</var>.apkovl.tar.gz}} ''('myboxname' will be the same as the hostname)''.
The file (which contains your modifications) is called your "apkovl".
You will need to save your apkovl on suitable media (floppy, usb, cf, etc.).
<pre>
usage: lbu commit|ci [-nv] [<media>]

Options:
-d Remove old apk overlay files.
-e Protect configuration with a password.
-n Don't commit, just show what would have been committed.
-p <password> Give encryption password on the command-line
-v Verbose mode.

The following values for <media> are supported: floppy usb
If <media> is not specified, the environment variable LBU_MEDIA will be used.

Password protection will use aes-256-cbc encryption. Other ciphers can be
used by setting the DEFAULT_CIPHER or ENCRYPTION environment variables.
For possible ciphers, try: openssl -v

The password used to encrypt the file, can be specified with the -p
option or by using the PASSWORD environment variable.

The environment variable can also be set in /etc/lbu/lbu.conf
</pre>

=== Creating an .apkovl "package" elsewhere than on the configured media ===

To "commit" changes, but override the destination of the generated apkovl file, use <code>lbu package</code> instead of <code>lbu commit</code>:

<pre>
usage: lbu package|pkg -v [<dirname>|<filename>]

Options:
-v Verbose mode.

If <dirname> is a directory, a package named <hostname>.apkovl.tar.gz will
be created in the specified directory.

If <filename> is specified, and is not a directory, a package with the
specified name will be created.

If neither <dirname> nor <filename> is specified, a package named
<hostname>.apkovl.tar.gz will be created in the current working directory.
</pre>

=== Creating and saving an apkovl from a remote host ===

To create an apkovl from a client on a remote server, it's possible to use <code>lbu package</code> via SSH with {{Path|-}} as the apkovl name:

On the server:
<pre>
ssh root@client "lbu package -" >client.apkovl.tar.gz
</pre>

== Checking what will be added to your apkovl ==

<code>lbu status</code> lists what will be saved the next time you run <code>lbu commit</code>. Its default output is incremental, that is, it shows
only the files that have changed since the last commit. 
This can be overridden with the <code>-a</code> flag:

<pre>
usage: lbu status|st [-av]

Options:
-a Compare all files, not just since last commit.
-v show include and exclude lists.
</pre>

Another option is <code>lbu list</code>. This works like <code>lbu status -a</code> but the format of the output is a bit different. (It's strictly equivalent to <code>lbu package -v /dev/null</code>).

usage: lbu list|ls

A third option is <code>lbu diff</code>. This shows the same incremental changes that <code>lbu status</code> (without <code>-a</code>) does, but in a different format.

usage: lbu diff

== Include special files/folders to the apkovl ==
Assume you have some files you want to save permanently, but they are not located in {{Path|/etc}}. 
e.g. {{Path|/root/.ssh/authorized_keys}} (used by <code>sshd</code> to authenticate ssh-users). Such files/folders can be added to lbu's ''include'' list with the following command:

<pre>
usage: lbu include|inc|add [-rv] <file> ...
lbu include|inc|add [-v] -l

Options:
-l List contents of include list.
-r Remove specified file(s) from include list.
-v Verbose mode.
</pre>

{{Note|This information used to be maintained in {{Path|/etc/lbu/include}}. Now it's maintained together with the ''exclude'' list in {{Path|/etc/apk/protected_paths.d/lbu.list}}. Either way, the command <code>lbu include</code> only modifies lbu's configuration.
You will need to run <code>lbu commit</code> to actually create/modify your apkovl.}}

== Exclude specific files/folders from the apkovl ==
Assume you have some files located in {{Path|/etc}} or one of its subfolders you ''do not'' want to save.
It could be a log file or status file that for some reason isn't in {{Path|/var/log/}} but in a location that would otherwise be tracked by <code>lbu</code>.
Such files/folders can be added to lbu's ''exclude'' list by manually editing the file or using the following command:
<pre>
usage: lbu exclude|ex|delete [-rv] <file> ...
lbu exclude|ex|delete [-v] -l

Options:
-l List contents of exclude list.
-r Remove specified file(s) from exclude list.
-v Verbose mode.
</pre>
{{Note|As stated above, this information is now maintained in {{Path|/etc/apk/protected_paths.d/lbu.list}}. The command <code>lbu exclude</code> also only modifies lbu's configuration. 
You will need to run <code>lbu commit</code> to actually create/modify your apkovl.}}

== Execute a script as part of a backup ==

Sometimes it's necessary to run a script before or after a backup. Scripts in two optional directories enable that:

/etc/lbu/pre-package.d
/etc/lbu/post-package.d

Files in those directories are run using run-script rules (meaning they must have the executable bit set, they are run in alphabetical order, and cannot contain an extension. e.g. {{Path|runme}} works, but {{Path|runme.sh}} does not.)

The scripts in {{Path|pre-package.d}} are run before apkovl is created. Scripts in {{Path|post-package.d}} are run after apkovl is created.

=== Example ===

Rather than adding the raw database directories to {{Path|/etc/lbu/include}}, you can do a "database dump". e.g. {{Pkg|postgresql}}:

* Create {{Path|/etc/lbu/pre-package.d/sqldump}} with the following contents: <pre>pg_dumpall -U postgres | gzip -c >/root/pgdatabases.gz</pre>
* Mark the file executable: <code>chmod +x /etc/lbu/pre-package.d/sqldump</code>
* Create {{Path|/etc/lbu/post-package.d/sqldumpdelete}} with the following contents: <pre>rm -f /root/pgdatabases.gz</pre>
* Mark the file executable: <code>chmod +x /etc/lbu/post-package.d/sqldumpdelete</code>
* Finally, add the database dump file to the list of files to back up: <code>lbu include root/pgdatabases.gz</code>

Now when you do a <code>lbu commit</code>, the sql databases are dumped and gzipped to {{Path|/root/pgdatabases.gz}}.
The temporary file is deleted at the end of the lbu commit.

On a catastrophic restore, the databases are not automatically restored (that's not lbu's job), but you will find a complete database dump in the {{Path|/root}} directory, where it can be restored manually.

== Multiple backup versions ==
Lbu can now keep multiple backups so you can revert back to older configurations.
Set BACKUP_LIMIT in {{Path|/etc/lbu/lbu.conf}} to the number of backups you want
to keep.

If you've set BACKUP_LIMIT, then the previously active .apkovl will be renamed before creating the new file.

You can list the currently available backups with:

{{Cmd|lbu list-backup [<media>]}}

and you can revert to an older one with:

{{Cmd|lbu revert <filename> [<media>]}}

NOTE: Nothing is changed on your running system when "reverting", it only affects which apkovl is considered active at the next boot.

== See also ==
* [[Back Up a Flash Memory Installation]]
* [[Manually editing a existing apkovl]]

[[Category:Installation]]

[[Category:Booting]]
[[Category:Package Manager]]
[[category: LBU]]

Alpine Package Keeper

2021-12-02T19:01:49Z

Dfen: /* Listing installed packages */ get list of non-automatic packages

{{TOC right}}

Because Alpine Linux is designed to run from RAM, package management involves two phases:
* Installing / Upgrading / Deleting packages on a running system.
* Restoring a system to a previously configured state (e.g. after reboot), including all previously installed packages and locally modified configuration files. '''(RAM-Based Installs Only)'''
 
'''apk''' is the tool used to install, upgrade, or delete software on a running system. 
'''lbu''' is the tool used to capture the data necessary to restore a system to a previously configured state.

This page documents the [https://git.alpinelinux.org/apk-tools/ apk tool] - See the [[Alpine_local_backup|Alpine Local Backup page]] for the lbu tool.

= Overview =

The '''apk''' tool supports the following operations:

{|
| [[#Add a Package|add]]
| Add new packages or upgrade packages to the running system
|-
| [[#Remove a Package|del]]
| Delete packages from the running system
|-
| fix
| Attempt to repair or upgrade an installed package
|-
| [[#Update the Package list|update]]
| Update the index of available packages
|-
| [[#Information on Packages|info]]
| Prints information about installed or available packages
|-
| [[#Search for Packages|search]]
| Search for packages or descriptions with wildcard patterns
|-
| [[#Upgrade a Running System|upgrade]]
| Upgrade the currently installed packages
|-
| [[#Cache maintenance|cache]]
| Maintenance operations for locally cached package repository
|-
| version
| Compare version differences between installed and available packages
|-
| index
| create a repository index from a list of packages
|-
| fetch
| download (but not install) packages
|-
| audit
| List changes to the file system from pristine package install state
|-
| verify
| Verify a package signature
|-
| dot
| Create a [http://graphviz.org/ graphviz] graph description for a given package
|-
| [[#apk_policy|policy]]
| Display the repository that updates a given package, plus repositories that also offer the package
|-
| stats
| Display statistics, including number of packages installed and available, number of directories and files, etc.
|-
| manifest
| Display checksums for files contained in a given package
|}

= Packages and Repositories =

Software packages for Alpine Linux are digitally signed tar.gz archives containing programs, configuration files, and dependency metadata. They have the extension <code>.apk</code>, and are often called "a-packs".

The packages are stored in one or more ''repositories''. A repository is simply a directory with a collection of *.apk files. The directory must include a special index file, named {{Path|APKINDEX.tar.gz}} to be considered a repository.

The '''apk''' utility can install packages from multiple repositories. The list of repositories to check is stored in {{Path|/etc/apk/repositories}}, one repository per line. If you booted from a USB stick ({{Path|/media/sda1}}) or CD-ROM ({{Path|/media/cdrom}}), your repository file probably looks something like this:

{{Cat|/etc/apk/repositories|/media/sda1/apks/}}

In addition to local repositories, the '''apk''' utility uses '''busybox wget''' to fetch packages using ''http:'', ''https:'' or ''ftp:'' protocols. The following is a valid repository file:

{{Cat|/etc/apk/repositories|
/media/sda1/apks
http://dl-3.alpinelinux.org/alpine/v2.6/main
https://dl-3.alpinelinux.org/alpine/v2.6/main
ftp://dl-3.alpinelinux.org/alpine/v2.6/main
}}

{{Note| A list of public repositories is in [https://mirrors.alpinelinux.org/ mirrors.alpinelinux.org]. Accepted protocols vary.}}

== Repository pinning ==

You can specify additional "tagged" repositories in {{Path|/etc/apk/repositories}}:

{{Cat|/etc/apk/repositories|
http://nl.alpinelinux.org/alpine/v3.7/main
http://nl.alpinelinux.org/alpine/v3.7/community
@edge http://nl.alpinelinux.org/alpine/edge/main
@edgecommunity http://nl.alpinelinux.org/alpine/edge/community
@testing http://nl.alpinelinux.org/alpine/edge/testing
}}

After which you can "pin" dependencies to these tags using:

{{cmd|apk add stableapp newapp@edge bleedingapp@testing}}

Apk will now by default only use the untagged repositories, but adding a tag to specific package:

1. will prefer the repository with that tag for the named package, even if a later version of the package is available in another repository

2. ''allows'' pulling in dependencies for the tagged package from the tagged repository (though it ''prefers'' to use untagged repositories to satisfy dependencies if possible)

== Commandline repository options ==

By default, the '''apk''' utility will use the system repositories for all operations. This behavior can be overridden by the following options:

{|
| --repositories-file REPOFILE
| Override the system repositories by specifying a repositories file.
|-
| <nowiki>-X|--repository REPO</nowiki>
| Specify a supplemental repository that will be used in addition to the system repositories. This option can be provided multiple times.
|}

= Update the Package list =

Remote repositories change as packages are added and upgraded. To get the latest list of available packages, use the ''update'' command. The command downloads the {{Path|APKINDEX.tar.gz}} from each repository and stores it in the local cache, typically {{Path|/var/cache/apk/}}, {{Path|/var/lib/apk/}} or {{Path|/etc/apk/cache/}}.

{{Cmd|apk update}}



Adding the <code>--update-cache</code>, or for short <code>-U</code> switch to another apk command, as in <code>apk --update-cache upgrade</code> or <code>apk -U add ...</code>, the command has the same effect as first running <code>apk update</code> before the other apk command.

{{Tip|With remote repositories, it is a good idea to always do an '''update''' right '''before''' doing an '''upgrade or add''' command. That way the command will install the latest available packages.}}

= Add a Package =

Use '''add''' to install packages from a repository. Any necessary dependencies are also installed. If you have multiple repositories, the '''add''' command installs the newest package.

{{Cmd|apk add openssh
apk add openssh openntp vim}}

If you only have the main repository enabled in your configuration, apk will not include packages from the other repositories. To install a package from the edge/testing repository without changing your repository configuration file, use the command below. This will tell apk to use that particular repository.

{{cmd|apk add cherokee --update-cache --repository http://dl-3.alpinelinux.org/alpine/edge/testing/ --allow-untrusted}}

{{Note|Be careful when using third-party or the testing repository. Your system can go down.}}

= Add a local Package =

To install a locally available apk package, for example if this device has no internet access but you can upload apk packages directly to it, use the '''--allow-untrusted''' flag:

{{cmd|apk add --allow-untrusted /path/to/file.apk}}

Note that multiple packages can be given. When installing a local package, all dependencies should also be specified. For example:

{{cmd|apk add --allow-untrusted /var/tig-2.2-r0.apk /var/git-2.11.1-20.apk}}

= Remove a Package =
Use '''del''' to remove a package (and dependencies that are no longer needed.)

{{cmd|apk del openssh
apk del openssh openntp vim}}

= Upgrade a Running System =

=== Packages in general ===

To get the latest security upgrades and bugfixes available for the ''installed'' packages of a running system, first '''update''' the list of available packages and then '''upgrade''' the installed packages:

{{cmd|apk update
apk upgrade
}}

Or, combining the same into one single command:

{{cmd|apk -U upgrade
}}

Here is an example, showing the procedure on a system that has several additional [[#Repository_pinning|repositories pinned]]:

# apk update
fetch http://dl-3.alpinelinux.org/alpine/v3.6/main/x86_64/APKINDEX.tar.gz
fetch http://dl-3.alpinelinux.org/alpine/v3.6/community/x86_64/APKINDEX.tar.gz
fetch http://dl-3.alpinelinux.org/alpine/edge/main/x86_64/APKINDEX.tar.gz
fetch http://dl-3.alpinelinux.org/alpine/edge/community/x86_64/APKINDEX.tar.gz
fetch http://dl-3.alpinelinux.org/alpine/edge/testing/x86_64/APKINDEX.tar.gz
v3.6.2-191-gf98d79930f [http://dl-3.alpinelinux.org/alpine/v3.6/main]
v3.6.2-190-ga5d68c47df [http://dl-3.alpinelinux.org/alpine/v3.6/community]
v3.6.0-4618-g0bf77c9821 [http://dl-3.alpinelinux.org/alpine/edge/main]
v3.6.0-4605-g85ed51dd83 [http://dl-3.alpinelinux.org/alpine/edge/community]
v3.6.0-4624-g11f1b9c8ab [http://dl-3.alpinelinux.org/alpine/edge/testing]
OK: 20118 distinct packages available

# apk upgrade
(1/2) Upgrading extra-cmake-modules@testing (5.38.0-r0 -> 5.39.0-r0)
(2/2) Upgrading extra-cmake-modules-doc@testing (5.38.0-r0 -> 5.39.0-r0)
Executing mdocml-apropos-1.14.1-r0.trigger
OK: 2635 MiB in 803 packages

To upgrade only ''specific'' packages, use the ''-u'' or ''--upgrade'' option of the '''add''' command:

{{cmd|apk update
apk add --upgrade busybox
}}

To enable unattended, automatic upgrades of packages, see the {{pkg|apk-autoupdate}} package.

To upgrade to a newer release, refer to the corresponding release notes and [[Upgrading_Alpine]].

=== Upgrading "diskless" and "data" disk mode installs ===

If booting a "diskless" system from a read-only device, or iso image on writable media, it's not possible to update the boot files (kernel, modules, firmware, ...) that reside on that device.

It becomes possible to update the boot files, though, if using a boot device that is writable and has been prepared with <code>[[Alpine_setup_scripts#setup-bootable|setup-bootable]]</code>.

However, even then, the kernel, with its modules and firmware files, can still not be updated directly through regular packages updates. Instead, there is the <code>update-kernel</code> script that can generate initfs images and install them together with upgraded kernels.

Upgrading can be done as follows.
{{cmd|apk add mkinitfs
}}
This package is required for the generation of the initial filesystem used during boot.
* Additional initfs features that are missing in the default configuration, like the "btrfs" filesystem support (at the time of writing, to allow loading .apkovl configs and package cache during boot), may be enabled in <code>/etc/mkinitfs/mkinitfs.conf</code>.
* Available initfs features may be listed with <code>ls /etc/mkinitfs/features.d</code>
{{cmd|ls /etc/mkinitfs/features.d
apk add nano
nano /etc/mkinitfs/mkinitfs.conf
lbu commit
}}
Finally update the kernel and its boot environment.
{{cmd|update-kernel /media/sdXY/boot/
}}
* An <code>update-kernel</code> run needs at least 8 GB free ram memory to avoid a broken modloop-image.
* See <code>update-kernel --help</code> for options to manually add additional module or firmware packages.

= Search for Packages =
The '''search''' command searches the repository Index files for installable packages.

The return format is '''Package'''-'''Version'''. Omit '''Version''' for ''apk add '''Package'''''

Examples:
* To list all packages available, along with their descriptions: {{cmd|apk search -v}}
* To list all packages are part of the ACF system: {{cmd|apk search -v 'acf*' }}
* To list all packages that list NTP as part of their description, use the ''-d'' or ''--description'' option: {{cmd|apk search -v --description 'NTP' }}

= Information on Packages =

== apk info ==

The '''info''' command provides information on the contents of packages, their dependencies, and which files belong to a package.

For a given package, each element can be chosen (for example, ''-w'' to show just the webpage information), or all information displayed with the ''-a'' command.

Example: {{cmd|apk info -a zlib}}

'''zlib-1.2.5-r1 description:'''
A compression/decompression Library

'''zlib-1.2.5-r1 webpage:'''
<nowiki>http://zlib.net</nowiki>

'''zlib-1.2.5-r1 installed size:'''
94208

'''zlib-1.2.5-r1 depends on:'''
libc0.9.32

'''zlib-1.2.5-r1 is required by:'''
libcrypto1.0-1.0.0-r0
apk-tools-2.0.2-r4
openssh-client-5.4_p1-r2
openssh-5.4_p1-r2
libssl1.0-1.0.0-r0
freeswitch-1.0.6-r6
atop-1.25-r0

'''zlib-1.2.5-r1 contains:'''
lib/libz.so.1.2.5
lib/libz.so.1
lib/libz.so

'''zlib-1.2.5-r1 triggers:'''

As shown in the example you can determine
* The '''description''' of the package (''-d'' or ''--description'')
* The '''webpage''' where the application is hosted (''-w'' or ''--webpage'')
* The '''size''' the package will require once installed (in bytes) (''-s'' or ''--size'')
* What packages are required to use this one ('''depends''') (''-R'' or ''--depends'')
* What packages require this one to be installed ('''required by''') (''-r'' or ''--rdepends'')
* The '''contents''' of the package, that is, which files it installs (''-L'' or ''--contents'')
* Any '''triggers''' this package sets. (''-t'' or ''--triggers'') Listed here are directories that are watched; if a change happens to the directory, then the trigger script is run at the end of the apk add/delete. For example, doing a depmod once after installing all packages that add kernel modules.

{{Tip|The '''info''' command is also useful to determine which package a file belongs to. For example: {{cmd|apk info --who-owns /sbin/lbu}} will display

/sbin/lbu is owned by alpine-conf-x.x-rx
}}

=== Listing installed packages ===

To list all installed packages, use:

<pre>apk info</pre>

To list all installed packages in alphabetical order, with a description of each, do:

<pre>apk -vv info|sort</pre>

The apk tool does not have a subcommand to list manually-installed packages that do not have reverse dependencies. To get this information on a traditional system that is not using [[Alpine local backup|lbu]], try this script. Note that this approach will also list core packages like alpine-base that should not be removed.

<pre>#!/bin/sh
apk info | grep -ve '-doc$' | sort | while read pkg
do
rdep=`apk info -qr "$pkg"`
[ -z "$rdep" ] && echo $pkg
done</pre>

== apk policy ==

To display the repository a package was installed from and will be updated from, plus any [[#Repository_pinning|tagged]] or enabled repositories where it is also offered, if any, for this architecture - its '''policy''':

apk policy ''package''

For example:
<pre>
$ apk policy vlc
vlc policy:
2.2.6-r1:
lib/apk/db/installed
http://dl-3.alpinelinux.org/alpine/v3.7/community
3.0.0_rc2-r1:
@edgecommunity http://dl-3.alpinelinux.org/alpine/edge/community
</pre>

= Additional apk Commands =
In progress...

= Local Cache =

{{:Local_APK_cache}}

= Advanced APK Usage =

== Holding a specific package back ==

In certain cases, you may want to upgrade a system, but keep a specific package at a back level. It is possible to add "sticky" or versioned dependencies. For instance, to hold the ''asterisk'' package to the 1.6.2 level or lower:
{{cmd|1=apk add asterisk=1.6.0.21-r0}}
or
{{cmd|apk add 'asterisk<1.6.1'}}

after which a {{cmd|apk upgrade}}

will upgrade the entire system, keeping the asterisk package at the 1.6.0 or lower level

To later upgrade to the current version,

{{cmd|apk add 'asterisk>1.6.1'}}

will ensure that 1.6.1 is the minimum version used.

You can also use "fuzzy" version matching to pin the version to a major/minor release. For example:

{{cmd|1=apk add 'asterisk=~1.6'}}

will match any version of asterisk that starts with 1.6 (such as 1.6.0.21-r0 or 1.6.9.31-r9) <ref>[https://git.alpinelinux.org/apk-tools/commit/?id=693b4bcdb0f22904a521a7c8ac4f13e697dc4d71 Alpine source commit message]</ref>

If you desire deterministic, repeatable package installation (such as with containerized environments) via package pinning, it is important to understand your package repo's version retention rules. For example, most Alpine package repos contain an "edge" branch, which may drop package versions that are not deemed fit to make it into a stable branch. This means that pinning to a version on the edge branch may stop working after the package version is revoked from the repo. Always pin to a package version that is intended for your current Alpine Linux version.

= Troubleshooting =

== "apk-tools is old" ==

'''apk update''', '''apk upgrade''' or '''apk add''' may report the following:
WARNING: This apk-tools is OLD! Some packages might not function properly

This may happen if you are running Alpine Linux stable version with a certain edge/main, edge/community or testing package(s) also installed. One resolution is to consider upgrading {{pkg|apk-tools}}. If edge is already [https://wiki.alpinelinux.org/wiki/Alpine_Linux_package_management#Repository_pinning tagged] in your repositories, then try:

<pre>sudo apk add --upgrade apk-tools@edge</pre>

= =
* [https://www.cyberciti.biz/faq/10-alpine-linux-apk-command-examples/ 10 Alpine Linux apk Command Examples] Vivek Gite 2019

[[Category:Package Manager]]

Enable Serial Console on Boot

2021-12-02T17:11:21Z

Dfen: /* Example /boot/extlinux.conf */ correct metric prefix, cite source, add caveat about zero timeout

== How to Enable the Serial Console on Boot (1.10.x)==

When using syslinux to boot, you'll need to modify the syslinux.cfg file in the root directory of the boot device. If using a disk-based Alpine, modify the /boot/extlinux.cfg file.

Add the following:
* <tt>serial 0 9600</tt>
* add <tt>console=ttyS0,9600</tt> to the <tt>append</tt> parameter
* optionally, remove <tt>quiet</tt> from the <tt>append </tt> parameter

=== Example syslinux.cfg ===

<pre>
serial 0 9600
timeout 20
prompt 1
default grsec
label grsec
kernel /boot/grsec
append initrd=/boot/grsec.gz alpine_dev=sda1:vfat modules=sd-mod,usb-storage console=ttyS0,9600
</pre>

== extlinux.conf (3.0+)==

The /etc/update-extlinux.conf is read by the update-extlinux utility.

To do so, change the default entry:
<pre>default_kernel_opts="quiet"</pre>
to read like this:
<pre>default_kernel_opts="console=ttyS0,9600 quiet"</pre>

Set the serial port and baud rate to match the default_kernel_opts line above:
<pre>serial_port=0
serial_baud=9600</pre>

=== Xen ===

Notice, if you want to use this for a Xen VM,
you need to configure the speed at '''115200''' bps and enable the
<pre>serial="pty"</pre>
setting in the VM config file.

----

Xen can be configured to use and log to a serial console by editing /etc/update-extlinux.conf to include the following lines:
<pre>
default_kernel_opts="console=hvc0 earlyprintk=xen nomodeset"
xen_opts="dom0_mem=256M com1=115200,8n1 console=com1"
</pre>

See the [http://wiki.xen.org/wiki/Xen_Serial_Console Xen wiki] for more details.

=== Example /boot/extlinux.conf ===

This is a complete file, written by the update-extlinux command.

<pre>
DEFAULT menu.c32
PROMPT 0
MENU TITLE Alpine/Linux Boot Menu
MENU AUTOBOOT Alpine will be booted automatically in # seconds.
SERIAL 0 9600
TIMEOUT 100
LABEL grsec
MENU DEFAULT
MENU LABEL Linux 3.10.33-0-grsec
LINUX vmlinuz-3.10.33-0-grsec
INITRD initramfs-3.10.33-0-grsec
APPEND root=UUID=re-mov-ed-uu-id modules=sd-mod,usb-storage,ext4 console=ttyS0,9600

MENU SEPARATOR
</pre>

Please: adjust the tty speed to 115200 if needed (Xen!!).

The timeout is given in deciseconds, so this would be a 10 second timeout.[https://wiki.syslinux.org/wiki/index.php?title=Config#TIMEOUT] A timeout of 0 does not boot without delay, but rather waits indefinitely for the user.

If the file is read by pygrub, the same value is interpreted as seconds, resulting in a 100s bootup delay per VM.

== Enabling a login console ==

This is done in /etc/inittab. There is commented entry for ttyS0. Just enable it.
<pre>
# Put a getty on the serial port
ttyS0::respawn:/sbin/getty -L ttyS0 115200 vt100
</pre>

To start the getty, restart init:
<pre>
kill -HUP 1
</pre>

== Enabling two consoles during boot ==

It's possible to output to both the serial and vga console during the system boot.

<PRE>
append "quiet console=ttyS0,9600 console=tty0"
</PRE>

Not known how to do the same thing in the extlinux menu.
You might find a starting point in this thread: http://patchwork.openembedded.org/patch/45175/

== Add your serial console to the trusted local terminal list ==
If you face the problem that the login prompt always refuses your password when you use serial console, you missed this entry.

Add this to the <tt>/etc/securetty</tt> file:
<PRE>
ttyS0
</PRE>

[[Category:Booting]]
[[Category:Installation]]