Void linux install package

Installation

This section includes general information about the process of installing Void. For specific guides, see the «Advanced Installation» section.

Base system requirements

Void can be installed on very minimalist hardware, though we recommend the following minimums for most installations:

Architecture	CPU	RAM	Storage
x86_64-glibc	x86_64	96MB	700MB
x86_64-musl	x86_64	96MB	600MB
i686-glibc	Pentium 4 (SSE2)	96MB	700MB

Note that xfce image installations require more resources.

Void is not available for the i386, i486, or i586 architectures.

Before installing musl Void, please read the «musl» section of this Handbook, so that you are aware of software incompatibilities.

It is highly recommended to have a network connection available during install to download updates, but this is not required. ISO images contain installation data on-disk and can be installed without network connectivity.

Downloading installation media

The most recent live images and rootfs tarballs can be downloaded from https://repo-default.voidlinux.org/live/current/. They can also be downloaded from other mirrors. Previous releases can be found under https://repo-default.voidlinux.org/live/, organized by date.

Verifying images

Each image release’s directory contains two files used to verify the image(s) you download. First, there is a sha256sum.txt file containing image checksums to verify the integrity of the downloaded images. Second is the sha256sum.sig file, used to verify the authenticity of the checksums.

It is necessary to verify both the image’s integrity and authenticity. It is, therefore, recommended that you download both files.

Verifying image integrity

You can verify the integrity of a downloaded file using sha256sum(1) with the sha256sum.txt file downloaded above. The following command will check the integrity of only the image(s) you have downloaded:

$ sha256sum -c --ignore-missing sha256sum.txt void-live-x86_64-musl-20170220.iso: OK 

This verifies that the image is not corrupt.

Verifying digital signature

Prior to using any image you’re strongly encouraged to validate the signatures on the image to ensure they haven’t been tampered with.

Current images are signed using a minisign key that is specific to the release. If you’re on Void already, you can obtain the keys from the void-release-keys package, which will be downloaded using your existing XBPS trust relationship with your mirror and package signatures. You will also need a copy of minisign(1); on Void, this is provided by the minisign package.

The minisign executable is usually provided by a package of the same name, and can also be installed on Windows, even without WSL or MinGW.

If you are not currently using Void Linux, it will also be necessary to obtain the appropriate signing key from our Git repository here.

Once you’ve obtained the key, you can verify your image with the sha256sum.sig and sha256sum.txt files. First, you need to verify the authenticity of the sha256sum.txt file.

The following example demonstrates the verification of the sha256sum.txt file for the 20230628 images with minisign :

$ minisign -V -p /usr/share/void-release-keys/void-release-20230628.pub -x sha256sum.sig -m sha256sum.txt Signature and comment signature verified Trusted comment: This key is only valid for images with date 20230628. 

Finally, you need to verify that the checksum for your image matches the one in the sha256sum.txt file. This can be done with the sha256(1) utility from the outils package, as demonstrated below for the 20230628 x86_64 base image:

$ sha256 -C sha256sum.txt void-live-x86_64-20230628-base.iso (SHA256) void-live-x86_64-20230628-base.iso: OK 

Alternatively, if the sha256 utility isn’t available to you, you can use sha256sum(1):

$ sha256sum -c sha256sum.txt --ignore-missing void-live-x86_64-20230628-base.iso: OK 

If neither program is available to you, you can compute the SHA256 hash of the file and compare it to the value contained in sha256sum.txt .

If the verification process does not produce the expected «OK» status, do not use it! Please alert the Void Linux team of where you got the image and how you verified it, and we will follow up on it.

Источник

External Applications

The Void repositories have a number of Python and Lua packages. If possible, install packages from the Void repositories or consider packaging the library or application you need. Packaging your application allows for easier system maintenance and can benefit other Void Linux users, so consider making a pull request for it. The contribution instructions can be found here.

To keep packages smaller, Void has separate devel packages for header files and development tools. If you install a library or application via a language’s package manager (e.g. pip , gem ), or compile one from source, you may need to install the programming language’s -devel package. This is specially relevant for musl libc users, due to pre-built binaries usually targeting glibc instead.

Language	Package Manager	Void Package
Python3	pip, anaconda, virtualenv, etc	python3-devel
Python2	pip, anaconda, virtualenv, etc	python2-devel
Ruby	gem	ruby-devel
lua	luarocks	lua-devel

Restricted Packages

Some packages have legal restrictions on their distribution (e.g. Discord), may be too large, or have another condition that makes it difficult for Void to distribute. These packages have build templates, but the packages themselves are not built or distributed. As such, they must be built locally. For more information see the page on restricted packages.

Non-x86_64 Arch

The Void build system runs on x86_64 servers, both for compiling and cross compiling packages. However, some packages (e.g. libreoffice ) do not support cross-compilation. These packages have to be built locally on a computer running the same architecture and libc as the system on which the package is to be used. To learn how to build packages, refer to the README for the void-packages repository.

Flatpak

Flatpak is another method for installing external proprietary applications on Linux. For information on using Flatpak with Void Linux, see the official Flatpak documentation.

If sound is not working for programs installed using Flatpak, PulseAudio auto-activation might not be working correctly. Make sure PulseAudio is running before launching the program.

Note that Flatpak’s sandboxing will not necessarily protect you from any security and/or privacy-violating features of proprietary software.

Troubleshooting

Some apps may not function properly (e.g. not being able to access the host system’s files). Some of these issues can be fixed by installing one or more of the xdg-desktop-portal , xdg-desktop-portal-gtk , xdg-user-dirs , xdg-user-dirs-gtk or xdg-utils packages.

Some Flatpaks require D-Bus and/or Pulseaudio.

AppImages

An AppImage is a file that bundles an application with everything needed to run it. An AppImage can be used by making it executable and running it; installation is not required. AppImages can be run in a sandbox, such as firejail.

Some of the applications for which an AppImage is available can be found on AppImageHub.

AppImages do not yet work on musl installations.

Octave Packages

Some Octave packages require external dependencies to compile and run. For example, to build the control package, you must install the openblas-devel , libgomp-devel , libgfortran-devel , gcc-fortran , and gcc packages.

MATLAB

To use MATLAB’s help browser, live scripts, add-on installer, and simulink, install the libselinux package.

Steam

Steam can be installed either via a native package, which requires enabling the «nonfree» repository, or via Flatpak. The list of dependencies for different platforms and troubleshooting information for the native package can be found in its Void-specific documentation, while this section deals with potential issues faced by Flatpak users.

If you are using a different drive to store your game library, the —filesystem option from flatpak-override(1) can prove useful.

Источник

XBPS Package Manager

The X Binary Package System (XBPS) is a fast package manager that has been designed and implemented from scratch. XBPS is managed by the Void Linux team and developed at https://github.com/void-linux/xbps.

Most general package management is done with the following commands:

• xbps-query(1) searches for and displays information about packages installed locally, or, if used with the -R flag, packages contained in repositories.
• xbps-install(1) installs and updates packages, and syncs repository indexes.
• xbps-remove(1) removes installed packages, and can also remove orphaned packages and cached package files.
• xbps-reconfigure(1) runs the configuration steps for installed packages, and can be used to reconfigure certain packages after changes in their configuration files. The latter usually requires the —force flag.
• xbps-alternatives(1) lists or sets the alternatives provided by installed packages. Alternatives is a system which allows multiple packages to provide common functionality through otherwise conflicting files, by creating symlinks from the common paths to package-specific versions that are selected by the user.
• xbps-pkgdb(1) can report and fix issues in the package database, as well as modify it.
• xbps-rindex(1) manages local binary package repositories.

Most questions can be answered by consulting the man pages for these tools, together with the xbps.d(5) man page.

To learn how to build packages from source, refer to the README for the void-packages repository.

Updating

Like any other system, it is important to keep Void up-to-date. Use xbps-install(1) to update:

XBPS must use a separate transaction to update itself. If your update includes the xbps package, you will need to run the above command a second time to apply the rest of the updates.

Restarting Services

XBPS does not restart services when they are updated. This task is left to the administrator, so they can orchestrate maintenance windows, ensure reasonable backup capacity, and generally be present for service upgrades.

To find processes running different versions than are present on disk, use the xcheckrestart tool provided by the xtools package:

$ xcheckrestart 11339 /opt/google/chrome/chrome (deleted) (google-chrome) 

xcheckrestart will print out the PID, path to the executable, status of the path that was launched (almost always deleted ) and the process name.

xcheckrestart can and should be run as an unprivileged user.

Kernel Panic After Update

If you get a kernel panic after an update, it is likely your system ran out of space in /boot . Refer to «Removing old kernels» for further information.

Finding Files and Packages

To search available repositories for packages, use xbps-query(1):

The -R flag specifies that repositories should be searched. Without it, -s searches for locally-installed packages.

If you can’t find a file or program you expected to find after installing a package, you can use xbps-query(1) to list the files provided by that package:

The xtools package contains the xlocate(1) utility. xlocate works like locate(1), but for files in the Void package repositories:

$ xlocate -S Fetching objects: 11688, done. From https://repo-default.voidlinux.org/xlocate/xlocate + e122c3634. a2659176f master -> master (forced update) $ xlocate xlocate xtools-0.59_1 /usr/bin/xlocate xtools-0.59_1 /usr/share/man/man1/xlocate.1 -> /usr/share/man/man1/xtools.1 

It is also possible to use xbps-query(1) to find files, though this is strongly discouraged:

$ xbps-query -Ro /usr/bin/xlocate xtools-0.46_1: /usr/bin/xlocate (regular file) 

This requires xbps-query to download parts of every package to find the file. xlocate , however, queries a locally cached index of all files, so no network access is required.

To get a list of all installed packages, without their version:

$ xbps-query -l | awk '< print $2 >' | xargs -n1 xbps-uhelper getpkgname 

Источник