nyuuzyou/wikis huggingface dataset:
Bootstrapping Alpine on Soekris net4xxx

Category:Installation
This is a step-by-step guide on bootstrapping the latest (developement) Alpine Linux on a CF card for Soekris net4xxx routers
We assume our CF reader is at /dev/sdb, with a 512+ MB CF formatted card loaded and will be mounted on /mnt/flash. We also assume root priviledges.
 export FLASHDEVICE=/dev/sdb1
 export MNT=/mnt/flash
First, we download the latest usbdrive tarball
 wget http://dev.alpinelinux.org/alpine/v1.7/usbdrive/alpine-1.7.5-i386.tar.gz
and unpack it on our CF card
 mount $FLASHDEVICE $MNT
 tar xzf ../alpine-1.7.5-i386.tar.gz -C $MNT
Next step is to build a custom initrd (for the serial console to work)
 mkdir /tmp/alpine
 cd /tmp/alpine
 zcat $MNT/kernel/generic/hd-ext3.gz > soekris
 tar xjf $MNT/base.tar.bz2 ./etc/inittab
 sed -i -e 's/^::respawn.*//' -e 's/^tty.*//' -e 's/^#\(ttyS0.*\) 115200 \(.*\)/\1 19200 \2/' etc/inittab
 echo etc/inittab | cpio -o -H newc -A -O soekris
 gzip -c -9 soekris > $MNT/kernel/generic/soekris.gz
and a custom syslinux.cfg
 cat > $MNT/syslinux.cfg <<EOF
 serial 0 19200
 timeout 0
 default generic-soekris
 
 label generic-soekris
 kernel /kernel/generic/bzImage
 append initrd=/kernel/generic/soekris.gz rw alpine_dev=hda1:vfat root_dev=none:tmpfs alpine_base=base.tar.bz2 pkg_dev=hda1:vfat pkg_subdir=/apks cfg_dev=hda1:vfat modloop=/kernel/generic/modloop.cmg console=ttyS0,19200
 EOF
Finally, we make the CF bootable
 syslinux $FLASHDEVICE
 umount alpine
Bridge wlan0 to eth0

== Introduction ==
This wiki describes methods to bridge a wired and wireless interface to enable network communication between hosts reachable via either interface. This allows one or more wired hosts to share the wireless interface on the bridge host.
In my use case, I have a desk with a wired switch with multiple hosts connected. All wired devices on this switch can access my home wifi network via the bridge host's wireless interface.
I am only going to document the proxy ARP method as that's what I'm currently using. Please feel free to add additional methods and remove this section of the introduction.
== Method 1: Proxy ARP ==
These steps result in a working solution where hosts on the wired side and hosts on the wireless side are all in the same ip network. There are no frills added, such as dhcp or automatic route entries for the wired hosts. Each wired host needs to have a manually configured IP address and an entry manually added to the bridge host's routing table.
Note: For your wired hosts, use IP addresses in the same IP range as the rest of your network but outside of the scope used by a local DHCP server, if applicable. You may need to reduce your DHCP scope to free up IP addresses for this purpose.
Configure the network interfaces on your bridge host:
Notice that the wireless interface (wlan0) uses dhcp from the home network as usual and that an IP address is not used at all on the wired interface (eth0).
Enable and create a local start-up script to add route entries at boot:
Add route statements for each host on the wired side of the bridge:
Enable proxy arp:
Category:Networking
Btrfs

Documentation how to use Btrfs on Alpine Linux.
== Install ==
Installing Btrfs is relatively straight forward. Install the package and tell Alpine to load the module on startup:
To load the module immediately, you can use the following command:
If using btrfs as your root filesystem, you should ensure that the initramfs is generated with the btrfs module, otherwise your system may fail to boot. To do so edit (as root) and ensure that "btrfs" is in the list of features; then (again as root) run the command.
== Mounting a volume ==
To mount a volume on boot, add a new entry to your fstab:
If you use more specific mounting options like for example:
do not forget to install additional dependencies. If you enabled on the fly compression you need to install zstd:
More information about mounting can be found in the official Btrfs wiki
== Troubleshooting ==
=== Mount failed ===
If you try mounting a Btrfs volume via your and it doesn't show up, it could be because Btrfs does not know about the drives during boot.
To work around this, you can enable the OpenRC service from the btrfs-progs package:
The volume should mount correctly after a reboot.
== See also ==
* BTRFS on Alpine Linux
* Using BTRFS on Alpine Linux
* Can't mount BTRFS volume using fstab
* ArchWiki
* Gentoo Wiki
* Install Alpine on a btrfs filesystem with refind as boot manager
Category:Filesystems
Build with abuild rootbld in Docker container

Category:Development
= Container privileges =
abuild-rootbld creates with bwrap an unprivileged sandbox.
To be allowed to use bwrap in the Alpine system running in the Docker container, the container needs additional privileges.
== The most unsafe solution ==
Simply start the container with --privileged argument or use it in compose file.
This is only possible when Docker (or Podman) is running as root.
== Safe solution using a modified seccomp profile ==
Take the default seccomp profile from github.com/moby/moby.
And add to the existing syscalls-JSON-Array this new object:
 
{
	"syscalls": [
		{
			"names": [
				"clone",
				"mount",
				"pivot_root",
				"setdomainname",
				"sethostname",
				"umount2"
			],
			"action": "SCMP_ACT_ALLOW"
		}
	]
}
Safe the extended profile to a file like seccomp-bwrap.json.
There is no predefined matching capability providing the pivot_root syscall.
The newly created file can be used in one of the following ways:
* Run the container with argument --security-opt seccomp=./seccomp-bwrap.json See reference and security seccomp.
* Specify in compose file to use this profile:
 
 security_opt:
 - seccomp=./seccomp-bwrap.json
= Run abuild =
== Start container ==
Connect to container with ssh or docker exec.
== net option ==
By default the rootbld sandbox does not have network connection.
If the build process needs network connection to download additional files during the build commands you have to specify the net option in APKBUILD file.
== abuild rootbld ==
Run in your git repository path
Buildlab

buildlab 2.13.0
 
Common options:
 
 -q	Quiet operation
 -p	Path to buildroot
 
Creating build roots (buildlab -C):
 
 -m	APK repository mirror
 -v	APK distribution version
 -a	APK repository architecture
 -k	Enable APK caching
 
Updating build roots (buildlab -u):
 
 No special options.
 
Building packages (buildlab -b):
 
 -b	APKBUILD file
 
Examples:
 
sudo ./buildlab -C -p /home/nenolod/buildroot -m dl-3.alpinelinux.org -v edge -a x86_64
sudo ./buildlab -b /home/nenolod/aports/main/gnome-panel/APKBUILD -p /home/nenolod/buildroot
sudo ./buildlab -u -p /home/nenolod/buildroot
Category:Development
Burning ISOs

== Burning an image to a CD or DVD ==
Many systems provide the cdrecord command (on Alpine it is provided by the package) to write an image to a disc. For example:
If there's only one CD drive on the system, it should be auto-detected. If not, find the device name using lsblk and specify the dev option. For example:
== See also ==
* Arch Wiki on CD/DVD Burning
* Gentoo page on converting image files
category: ISO
category: Installation
BusyBox

Alpine Linux is built around musl libc and busybox. To minimize footprint, Alpine Linux comes with BusyBox by default. BusyBox provides replacements for most of the utilities usually found in GNU coreutils, util-linux, etc. Built-in utility programs called as applets share code for many common operations. Invoking BusyBox with no argument lists the applets that have been compiled into BusyBox binary. Refer BusyBox Manual for options supported by BusyBox.
== Ash shell ==
Alpine Linux uses Busybox Ash for its default shell. To change the default shell to other shells like , , etc..refer change default shell.
When using Ash shell, one can’t set aliases in the , but environment variables can be set in it. In order to use aliases with Busybox Ash, you must set the ENV environment variable to refer the aliases file. 
First create the file as follows:
Next create the file as follows:
Now aliases can be added in the file :
== vi ==
Busybox uses tiny vi, a small 'vi' clone. Refer Busybox vi tutorial for an excellent introduction. 
== Replacing BusyBox utilities==
BusyBox is set up as an endpoint for numerous symlinks that substitute various utilities.The utilities in BusyBox generally have fewer options than their full-featured GNU counterparts. If you find certain utilities in busybox lacking in features or options, it is easy to replace respective endpoints by their equivalent full-featured utilities.
== See also ==
* Official website
* Official BusyBox Manual
* Busybox vi tutorial
Category:System Administration
Busybox acpid

Busybox acpid allows custom mapping and handling of ACPI events via options -M FILE (Map file) and -a FILE (Action file).
== Map file ==
A Map file maps ACPI events to descriptions (the last column). For example:
The built-in map file contains only PWRB/PWRF (power button) and LID (lid close).
== Action file ==
An Action file maps the event descriptions specified in the Map file to action scripts relative to the Config directory ( by default). It performs a substring match, so typically only the second part of the description is specified in the Action file. If the target path is not a file, but directory, it executes all scripts in the directory via run-parts. For example:
When the power button is pressed, acpid runs script .
== Resources ==
* https://oldforum.puppylinux.com/viewtopic.php?p=778500#p778500
Category:Power Management
CPU Microcode

CPU microcode is a form of firmware that controls the processor's internals. 
In modern processors, the microcode handles execution of complex and highly specialized instructions. Parts of the microcode also act as firmware for the processor's embedded controllers, and it is even used to fix or to mitigate processor design/implementation errata/bugs. Given the complexity of modern processors, a CPU may have over a hundred such errata.
Recently, microcode updates have become mandatory for security due to side-channel attacks against CPUs.
== Obtaining microcode updates on Alpine ==
On Alpine Linux, CPU microcode is loaded early via initrd images, premade images are available from packages:
To obtain the microcode update package for AMD processors:
To obtain the microcode update package for Intel processors:
If you are using syslinux or grub in a typical setup, the packages will automatically append your or file and merely a reboot will be required to run the new microcode. Users using UEFI's built-in boot manager will have to use efibootmgr to add a second initrd line. Likewise if you are using the limine bootoader will need to add a 2nd MODULE_PATH directive in pointing to the ucode file.
== Verifying that the microcode image has loaded ==
Run the command:
If the microcode initrd image was loaded, the microcode update driver will print a signature and revision
Example for Intel:
[ 2.198775 ] microcode: sig=0x6fd, pf=0x80, revision=0xa4
Example for AMD:
[ 11.442146] microcode: Current revision: 0x0a0011d5
[ 11.447027] microcode: Updated early from: 0x0a0011d3
== Check if CPU mitigation is working ==
This command not only shows if microcode is working, but other CPU vulnerabilities affected:
Category:Security
CPU frequency scaling

CPU frequency scaling is a feature of many modern processors whereby the CPU frequency can be changed at runtime. In this way, the system can be optimized for either powersaving (minimal frequency), performance (maximal frequency), or a combination (automatic switching). The latter would e.g. be optimal for a server that is idle for most of its uptime, but must sustain high CPU throughput when it does receive requests.
== Electing a governor ==
The CPU frequency scaling is handled by a so-called CPU governor, which decides which frequencies to use and when to switch between them. The most common governors are the following:
Governor 	Frequency	Switching
performance 	Maximum 	None
powersave 	Minimum 	None
ondemand 	Automatic	Immediate
conservative	Automatic	Gradual
userspace 	Custom 	Custom
In order to check which governors are available for your processors:
cat /sys/devices/system/cpu/cpufreq/policy*/scaling_available_governors
To e.g. change the governor of processor 0 to ondemand:
echo ondemand > /sys/devices/system/cpu/cpufreq/policy0/scaling_governor
To see that the governor you chose works as expected, you may compare scaling_cur_freq to scaling_min_freq and scaling_max_freq for different system loads. All of these files are located in the same folder /sys/devices/system/cpu/cpufreq/policy0 as the governor settings above.
== Manipulating the governor ==
Some governors can be configured further; these settings can be found in the folders /sys/devices/system/cpu/cpufreq/*. For instance, the ondemand governor defaults to switching to a higher frequency when the CPU usage increases beyond 95%. If we wish to lower this threshold to e.g. 80%, we could run:
echo 80 > /sys/devices/system/cpu/cpufreq/ondemand/up_threshold
== Automatic configuration ==
Once we have found a governor that we are satisfied with, we might want to keep it when the system is rebooted. This can be done by creating a local service in /etc/local.d. First, create a new local service /etc/local.d/cpufreq.start with the relevant CPU frequency scaling commands discussed above:
#!/bin/sh
# Set the governor to ondemand for all processors
for cpu in /sys/devices/system/cpu/cpufreq/policy*; do
 echo ondemand > ${cpu}/scaling_governor 
done
# Reduce the boost threshold to 80%
echo 80 > /sys/devices/system/cpu/cpufreq/ondemand/up_threshold
Make the boot script executable, make sure local services are started at boot, and sync your changes:
chmod +x /etc/local.d/cpufreq.start
rc-update add local default
lbu commit
Reboot your computer, and CPU frequency scaling should be enabled automatically.
Category:Power Management
Caddy

Caddy is a fast and extensible multi-platform HTTP/1, HTTP/2, and HTTP/3 web server with automatic TLS by default, providing HTTPS on every site.
== Intallation ==
Caddy package is available in the Alpine Linux repositories. To install it run:
=== System scripts ===
If you are running OpenRC, then you can install those with:
If you are running runit, s6, or dinit, (or other), then there are no scripts packaged for your init systems yet. Please feel free to contribute a package with them.
== Configuration ==
Caddy's default config file when using the Artix package is /etc/caddy/Caddyfile. 
Upstream provides Caddyfile configuration documentation.
Here is a simple Caddyfile hosting the site at localhost:2020:
== Controlling Caddy ==
=== Start Caddy ===
After the installation Caddy is not running. To start Caddy, use start.
Navigate a browser to the machine's address and a page should appear if you have configured /etc/caddy/Caddyfile correctly.
Enable Caddy on startup (if needed):
Edit the configuration in and run 
to enable your changes
== See Also ==
* Caddy Homepage
Category:Web Server
Cgit

cgit is a fast web-interface (CGI) for git written in the C programming language. It makes it possible for potential contributors to track and view project source code from the web instead of through a git client.
== Installation ==
Install the package that contains cgit and git.
Open up /etc/cgitrc with your favorite editor, in this case is vim.
If you want to show an specific repository your configuration should look something like this:
If you want to scan and show all the repositories you have, your configuration should look something like this:
=== Run cgit using spawn-fcgi and fcgiwrap ===
Install spawn-fcgi and fcgiwrap
Create a new service by doing a symbolic link.
Create a configuration file called spawn-fcgi.cgit in /etc/conf.d/ ; the service will run fcgiwrap automatically everytime is called. It should look exactly like this:
Start the newly created service.
== Run cgit with a web service ==
=== Configure Lighttpd to work with cgit ===
Install the package that contains lighttpd if you haven't already.
Create a cgit.conf file into the lighttpd directory with the following content:
Finally, add the following line to the lighttpd.conf file:
Restart the lighttpd service.
=== Configure NGINX to work with cgit pointing to a subdomain ===
Install the package that contains NGINX if you haven't already.
Create a custom configuration in the NGINX's conf.d directory.
The file should look something like this:
Restart the NGINX service.
Category:Server
Category:Git
Change default shell

Alpine Linux uses the BusyBox variant of the ash shell. This page explains various ways to change the default shell in Alpine Linux to other popular shells like , , etc.. You can revert back to ash shell at anytime with the same steps.
== By hand ==
Edit manually. An example line for a user named user is:
Change to point to the path of a shell from . Take care to not delete/mangle the line, as it would make you unable to log in again. The user should be the user you are changing the default login shell for.
== Using shadow ==
Download the required package:
And use chsh:
Now enter the path for the shell you want to use (e.g )
and press to confirm this change. The shell should exist in .
Category:Shell
Category:System Administration
Changing passwords for ACF

__NOTOC__
This provides documentation for beginner Alpine Linux users on how to change passwords for the console login as well as the ACF. It is pretty simple.
== Changing ACF password using command line ==
Setting ACF password is done in various ways depending on how old your system is.
=== Set ACF-password on Alpine Linux 1.9 and newer ===
Set the ACF-password for a specific user (where '<TT>username</TT>' could be a system user, such as '<TT>root</TT>'):
You will be prompted to enter a new password for this user.
=== Set ACF-password on Alpine Linux 1.8 and older ===
The logins and passwords for the ACF users are stored in a separate location: '<TT>/etc/acf/passwd</TT>'.
The syntax for the '<TT>/etc/acf/passwd</TT>' file is as follows:
 username:md5sumpassword::ROLE
For example, change the ACF user '<TT>Alpine</TT>' as follows:
# Generate a md5sum hash of the password '<TT>testing123</TT>', and send it to the passwd file: 
# Edit the passwd file to put the hash in the correct place as shown below, deleting the existing hash:
::Alpine:92707c3c2766ce04133e0f85681add8b::ADMIN
== To change passwords from the ACF Interface ==
Log on as a user with the Admin role, which has rights to change user passwords other than it's own.
Browse to System >> User Management
Under the Existing Account section, click [Edit this account] under the user whose password you want to change.
Enter the new password in the '<TT>Password</TT>' and '<TT>Password (Confirm)</TT>' fields.
Click [Save] to save the changes.
== Save changes ==
Remember to commit all changes (if you are running from 'tmpfs'): 
Category:ACF
Category:Security
Check hardware compatibility

There is an easy and quick method to check all hardware devices on the motherboard for Linux-compatibility with the help of recently added package in Edge/Testing. The tool checks operability of hardware devices by analysis of logs and tries to find missed drivers with the help of LKDDb.
== Install ==
The package can be installed from edge/testing repository by the following command:
== Check hardware ==
Use this command:
Sample output:
 Probe for hardware ... Ok
 Reading logs ... Ok
 Uploaded to DB, Thank you!
 Probe URL: https://linux-hardware.org/?probe=43a8c9674e
Now follow the link to check if everything is fine according to the hardware knowledge base.
Category:Installation
Category:Hardware
Chrony and GPSD

Sources such as:
* https://www.rjsystems.nl/en/2100-ntpd-garmin-gps-18-lvc-gpsd.php
* https://lists.ntp.org/pipermail/questions/2005-November/007878.html
Describe how to wire a Garmin gps 18 lvc to a serial port to grab the PPS (pulse-per-second) signal to create a Stratum 1 timesource. Other sources show using ntpd, and the gpsd man page provides config snippets.
Alpine Linux gpsd package 3.9-r1 and higher has the necessary pps code to interface with chrony. This page lists all of the files for a complete, working example:
* /etc/modules needs to list the pps_ldisc module - you'll need to manually load it if not doing a reboot
* If the GPS 18 LVC is on /dev/ttyS1, then:
* This shows all four methods of getting time from gpsd:
== Chronyc ==
If everything is working correctly, a chronyc 'sources' command should look like this:
 chronyc> sources
 210 Number of sources = 6
 MS Name/IP address Stratum Poll Reach LastRx Last sample
 ===============================================================================
 #x NMEA 0 4 377 14 +684ms[ +684ms] +/- 252ms
 #+ PPS 0 4 377 13 +2040ns[+2060ns] +/- 50ms
 #* SOCK 0 4 377 7 +225ns[ +245ns] +/- 2217ns
 ^? tick.tock.com 2 10 377 318 -5144us[-5144us] +/- 72ms
 ^? time.keeper.net 3 10 377 720 -4571us[-4567us] +/- 139ms
 ^? dead.time.server.org 0 10 0 10y +0ns[ +0ns] +/- 0ns
* NMEA (SHM0) is "x" - its really unstable
* PPS (SHM1) is good, but the delay of 0.1 makes it the not-preferred master
* SOCK is the preferred master
* The other NTP servers are only used if the local server goes down.
== Notes ==
* In /etc/chrony/chrony.conf, there are four possible time sources:
** SHM 0 (NMEA serial data)
** SHM 1 (NMEA with PPS)
** SOCK (PPS 'proprietary' gpsd/chrony interface)
** PPS (PPS only from the serial interface pulse)
* You only need 1 of them, although 3 are shown above
* In the example above, SHM1 is specified with a delay of 0.1 to prevent it from competing with the SOCK protocol
** If you prefer to use the SHM1 source instead of SOCK, then either:
*** comment out the SOCK protocol line
*** or reverse the delay values.
* Note that the SHM0 source (NMEA only, no PPS) is set to a higher delay - don't use it if you have PPS available.
** An example of where you would want to use SHM0 is a USB based gps receiver - they don't have the PPS line
* Chrony creates the SOCK interface; chrony should be started before gpsd. If you restart chronyd for some reason, make sure you restart gpsd after.
* The SHM0 interface can be used with USB based gps devices. In this case, use /dev/ttyUSBX in the /etc/conf.d/gpsd file, and leave the stty and setserial lines commented out.
Category:Server
Category:Networking