Alpine Linux - User contributions [en]

Raspberry Pi

2023-05-18T22:58:24Z

Mtbu: /* Netboot */ Typo

{{warning | 11 Feb 2021 - There is currently a known bug upstream [https://github.com/raspberrypi/firmware/issues/1529 kernel/initramfs cannot be loaded from subdirectory with same name as volume label] }}

{{TOC right}}

This tutorial explains how to install Alpine Linux on a Raspberry Pi. Alpine Linux will be installed in [[Installation#Diskless_Mode|diskless mode]], hence, [[Alpine local backup|Alpine Local Backup (lbu)]] is required to save modifications between reboots.

For scenarios where there is not expected to be significant changes to disk after setup (like running a static HTTP server), this is likely preferable, as running the entire system from memory will improve performance (by avoiding the slow SD card) and improve the SD card life (by reducing the writes to the card, as all logging will happen in RAM). Diskless installations still allow you to install packages, save local files, and tune the system to your needs.

If any of the following apply, then installation in [[Classic install or sys mode on Raspberry Pi|sys-mode installation]] is likely more appropriate.

* There will be constant changes to the disk after initial setup (for example, if you expect people to login and save files to their home directories)
* Logs should persists across reboots
* Plan to install packages which consume more space than can be loaded into RAM
* Plan to install kernel modules (such as ZFS or Wireguard)

== Preparation ==

# [http://alpinelinux.org/downloads/ Download] the Alpine for Raspberry Pi tarball. You should be safe using the '''armhf''' build on all versions of Raspberry Pi (including Pi Zero and Compute Modules); but it may perform less optimally on recent versions of Raspberry Pi. The '''armv7''' build is compatible with Raspberry Pi 2 Model B. The '''aarch64''' build should be compatible with Raspberry Pi 2 Model v1.2, Raspberry Pi 3 and Compute Module 3, and Raspberry Pi 4 model B.
# [[Create_a_Bootable_Device#Manually_copying_Alpine_files|Create a bootable FAT32 partition on your SD card.]] The partitioning and formatting part of the instructions on the linked page could be done using a graphical partitioning tool such as [https://en.wikipedia.org/wiki/GNOME_Disks gnome-disks], just make sure the partition type is <code>W95 FAT32 (LBA)</code>. (The current type can be found in the "Type" column in the output of <code>fdisk -l</code>.)
# Extract the tarball to the root of the bootable FAT32 partition.

To setup a headless system, a bootstrapping configuration overlay file [https://github.com/macmpi/alpine-linux-headless-bootstrap headless.apkovl.tar.gz] may be added to enable basic networking, so that following configuration steps can be performed under <code>ssh</code>. Pi Zero may be configured with simple USB ethernet-gadget networking with another computer sharing its internet connection.

Optionally create a '''usercfg.txt''' file on the partition to configure low-level system settings. Specifications can be found [https://www.raspberrypi.org/documentation/configuration/config-txt here]. However, note some settings can only be set directly in '''config.txt''', which may be overwritten after updates. In particular, <code>gpu_mem</code> will have no effect when specified in '''usercfg.txt''' ([https://github.com/raspberrypi/firmware/issues/1332 source]). Some interesting values include:
* To enable the UART console: <code>enable_uart=1</code>
* To enable audio: <code>dtparam=audio=on</code>
* If you see black edges around your screen after booting the Pi, you can add <code>disable_overscan=1</code>
* If you plan to install on a Pi Compute Module 4 with I/O board, you may need to add: <code>otg_mode=1</code>

Recent versions include Broadcom firmware files. If you're using an older Alpine version, see [[#Wireless_support_with_older_Alpine_images|section below]].

== Installation ==

Follow these steps to install Alpine Linux in Diskless Mode:

# Insert the SD card into the Raspberry Pi and power it on
# Login into the Alpine system as root. Leave the password empty.
# Type <code>setup-alpine</code>
# Once the installation is complete, commit the changes by typing <code>lbu commit -d</code>

Type <code>reboot</code> to verify that the installation was indeed successful.

== Post Installation ==

=== Update the System ===

After installation, make sure your system is up-to-date:

{{cmd|apk update
apk upgrade}}

Don't forget to save the changes:

{{cmd|lbu commit -d}}

Note: this does not upgrade the kernel. In order to upgrade the kernel, a full upgrade of the Alpine Linux version must be performed as described in [[Upgrading Alpine#Upgrading Alpine Linux on other removable media (such as CF/USB)|upgrading Alpine Linux for removable media]].

=== Clock-related error messages ===

During the booting time, you might notice errors related to the hardware clock. The Raspberry Pi does not have
a hardware clock, thus you need to disable the hwclock daemon and enable swclock:

{{cmd|rc-update add swclock boot # enable the software clock
rc-update del hwclock boot # disable the hardware clock}}

Since the Raspberry Pi does not have a clock, Alpine Linux needs to know what the time is by using a
[https://en.wikipedia.org/wiki/Network_Time_Protocol Network Time Protocol (NTP)] daemon. Make sure you have a
NTP daemon installed and running. If you are not sure, you can install an NTP client by running the following
command:

{{cmd|setup-ntp}}

The Busybox NTP client might be the most lightweight solution. Save the changes and reboot, once the NTP software is
installed and running:

{{cmd|lbu commit -d
reboot}}

After reboot, make sure the <code>date</code> command outputs the correct date and time.

=== WiFi on boot ===
If you have already [[Connecting_to_a_wireless_access_point|configured WiFi]] during the setup, the connection will not return on reboot.
You will need to start up a service to automatically connect to the wireless access point.
# Run <code>rc-update add wpa_supplicant boot</code> to connect to the wireless access point during bootup.
# Run it manually with <code>/etc/init.d/wpa_supplicant start</code>.

=== Enable Graphics ===
Remount the boot partition writeable (i.e. <code>/media/mmcblk0p1</code>):

{{cmd|mount /media/mmcblk0p1 -o rw,remount}}

Add the following lines to <code>/media/mmcblk0p1/config.txt</code>:

dtoverlay=vc4-kms-v3d

If you are experiencing graphical issues, you can also try:

dtoverlay=vc4-fkms-v3d

And perhaps also raising the default <code>gpu_mem</code>:

gpu_mem=128

Note that raising the gpu memory is not likely to [https://www.raspberrypi.com/documentation/computers/config_txt.html#gpu_mem actually improve performance on the Pi4]

Install the Mesa drivers:

{{cmd|<nowiki>apk add mesa-dri-gallium</nowiki>}}

Then reboot:

{{cmd|lbu_commit -d; reboot}}

=== WiFi drivers ===
As of Alpine 3.14, the WiFi drivers for the Raspberry Pi were moved from <code>linux-firmware-brcm</code> to the <code>linux-firmware-cypress</code> package (source?). Since the images seem to be an outdated version of the former, Wi-Fi will work during installation, but after the first update it will break.
Use the ethernet interface to download the required packages:

{{cmd|apk add linux-firmware-cypress}}

And reboot.

== Persistent storage ==
=== Loopback image with overlayfs ===

When you install Alpine in diskless mode, the entire system is loaded into memory at boot. If you want additional storage (for example, if you need more space than offered by your RAM) we need to create loop-back storage onto the SD card mounted with overlayfs.

First, make the SD card writable again and change fstab to always do so:
{{cmd|mount /media/mmcblk0p1 -o rw,remount
sed -i 's/vfat\ ro,/vfat\ rw,/' /etc/fstab}}

Create the loop-back file, this example is 1 GB:

{{cmd|dd if=/dev/zero of=/media/mmcblk0p1/persist.img bs=1024 count=0 seek=1048576}}

Install the ext utilities:

{{cmd|apk add e2fsprogs}}

Format the loop-back file:

{{cmd|mkfs.ext4 /media/mmcblk0p1/persist.img}}

Mount the storage:

{{cmd|echo "/media/mmcblk0p1/persist.img /media/persist ext4 rw,relatime,errors=remount-ro 0 0" >> /etc/fstab
mkdir /media/persist
mount -a}}

Make the overlay folders, we are using the /usr directory here, but you can use /home or anything else.
{{Warning|Overlay workdir needs to be an empty directory on the same filesystem mount as the upper directory. So each overlay must use its own workdir.}}

{{cmd|mkdir /media/persist/usr
mkdir /media/persist/.work_usr
echo "overlay /usr overlay lowerdir=/usr,upperdir=/media/persist/usr,workdir=/media/persist/.work_usr 0 0" >> /etc/fstab
mount -a}}

Your /etc/fstab should look something like this:
{{Cmd|/dev/cdrom /media/cdrom iso9660 noauto,ro 0 0
/dev/usbdisk /media/usb vfat noauto,ro 0 0
/dev/mmcblk0p1 /media/mmcblk0p1 vfat rw,relatime,fmask=0022,dmask=0022,errors=remount-ro 0 0
/media/mmcblk0p1/persist.img /media/persist ext4 rw,relatime,errors=remount-ro 0 0
overlay /usr overlay lowerdir=/usr,upperdir=/media/persist/usr,workdir=/media/persist/.work_usr 0 0}}

Now commit the changes: (optionally remove the e2fsprogs, but it does contain repair tools)
{{cmd|lbu_commit -d}}

Remember, with this setup if you install things and you have done this overlay for /usr, you must not commit the 'apk add', otherwise, while it boots it will try and install it to memory, not to the persistent storage.

If you do want to install something small at boot, you can use `apk add` and `lbu commit -d`.

If it is something a bit bigger, then you can use `apk add` but then not commit it. It will be persistent (in /user), but be sure to check everything you need is in that directory and not in folders you have not made persistent.

=== Traditional disk-based (sys) installation ===
{{Merge|Classic install or sys mode on Raspberry Pi|There's an existing page for sys-installations on RasPi.}}

It is also possible to switch to a fully disk-based installation. This is not yet formally supported, but can be done somewhat manually. This frees all the memory otherwise needed for the root filesystem, allowing more installed packages.

Split your SD card into two partitions: the FAT32 boot partition described above (in this example it'll be <code>mmcblk0p1</code>) , and a second partition to hold the root filesystem (here it'll be <code>mmcblk0p2</code>). Boot and configure your diskless system as above, then create a root filesystem:

{{cmd|apk add e2fsprogs
mkfs.ext4 /dev/mmcblk0p2}}

Now do a disk install via a mountpoint. The <code>setup-disk</code> script will give some errors about syslinux/extlinux, but you can ignore them.
The Raspberry Pi doesn't need them to boot.

{{cmd|<nowiki>mkdir /stage
mount /dev/mmcblk0p2 /stage
setup-disk -o /media/mmcblk0p1/MYHOSTNAME.apkovl.tar.gz /stage
# (ignore errors about syslinux/extlinux)</nowiki>}}

Add a line to <code>/stage/etc/fstab</code> to mount the Pi's boot partition again:

{{cmd|/dev/mmcblk0p1 /media/mmcblk0p1 vfat defaults 0 0}}

Now add a <code>root=/dev/mmcblk0p2</code> parameter to the Pi's boot command line, either <code>cmdline-rpi2.txt</code> or <code>cmdline-rpi.txt</code> depending on model:

{{cmd|<nowiki>mount -o remount,rw /media/mmcblk0p1
sed -i '$ s/$/ root=\/dev\/mmcblk0p2/' /media/mmcblk0p1/cmdline-rpi2.txt</nowiki>}}

You might also consider <code>overlaytmpfs=yes</code> here, which will cause the underlying SD card root filesystem to be mounted read-only, with an overlayed tmpfs for modifications which will be discarded at shutdown.

N.B. the contents of /boot will be ignored when the Pi boots. It will use the kernel, initramfs, and modloop images from the FAT32 boot partition. To update the kernel, initfs or modules, you will need to manually (generate and) copy these to the boot partition or you could use bind mount, in which case,
copying the files to boot partition manually, is not needed.

{{cmd|<nowiki>echo /media/mmcblk0p1/boot /boot none defaults,bind 0 0 >> /etc/fstab</nowiki>}}

=== Persistent Installation on Raspberry Pi 3 ===
See [[Classic install or sys mode on Raspberry Pi]] and https://web.archive.org/web/20171125115835/https://forum.alpinelinux.org/comment/1084#comment-1084

=== Persistent Installation on Raspberry Pi 4 ===
As of 3.14, setup-alpine should ask you if you want to create a sys mode partition on your Raspberry Pi 4.

== Netboot ==

=== Netbooting Raspberry Pi 4 ===

The Raspberry Pi 4 bootloader can be configured to boot from the network [https://www.raspberrypi.com/documentation/computers/raspberry-pi.html#raspberry-pi-4-bootloader-configuration]. Configure the bootloader with at least

{{cmd|<nowiki>BOOT_ORDER=0xf142
TFTP_PREFIX=1</nowiki>}}

and optionally also {{cmd|<nowiki>TFTP_IP=x.x.x.x</nowiki>}} where <code>x.x.x.x</code> is the IP address of your TFTP server.

If not configuring <code>TFTP_IP</code> in the bootloader, you'll need to configure your DHCP server to advertise the TFTP server IP address. This varies depending on your DHCP server; use the following details if applicable:

# Vendor class: <code>PXEClient:Arch:00000:UNDI:002001</code>
# Filename: <code>/</code>

The minimal set of files that your TFTP server needs to host are:

# <code>bcm2711-rpi-4-b.dtb</code> (from [https://raw.githubusercontent.com/raspberrypi/firmware/master/boot/bcm2711-rpi-4-b.dtb raspberrypi/firmware/master/boot/bcm2711-rpi-4-b.dtb])
# <code>cmdline.txt</code> (see below)
# <code>config.txt</code> (see below)
# <code>fixup4.dat</code> (from [https://raw.githubusercontent.com/raspberrypi/firmware/master/boot/fixup4.dat raspberrypi/firmware/master/boot/fixup4.dat], alternatively <code>fixup4cd.dat</code> for the cut down version)
# <code>initramfs-rpi4</code> (from [http://dl-cdn.alpinelinux.org/alpine/edge/releases/aarch64/netboot/initramfs-rpi4 alpine/edge/releases/aarch64/netboot/initramfs-rpi4])
# <code>start4.elf</code> (from [https://raw.githubusercontent.com/raspberrypi/firmware/master/boot/start4.elf raspberrypi/firmware/master/boot/start4.elf], alternatively <code>start4cd.elf</code> for the cut down version)
# <code>vmlinuz-rpi4</code> (from [http://dl-cdn.alpinelinux.org/alpine/edge/releases/aarch64/netboot/vmlinuz-rpi4 alpine/edge/releases/aarch64/netboot/vmlinuz-rpi4])

<code>config.txt</code>:
{{cmd|<nowiki>[pi4]
kernel=vmlinuz-rpi4
initramfs initramfs-rpi4
arm_64bit=1
</nowiki>}}

<code>cmdline.txt</code>:
{{cmd|<nowiki>modules=loop,squashfs console=ttyAMA0,115200 ip=dhcp alpine_repo=http://dl-cdn.alpinelinux.org/alpine/edge/main modloop=http://dl-cdn.alpinelinux.org/alpine/edge/releases/aarch64/netboot/modloop-rpi4</nowiki>}}

Instead of using the http://dl-cdn.alpinelinux.org/alpine/edge/releases/aarch64/netboot/ base URL above, pinning to a specific point in time is preferred. Raspberry Pi 4 netboot files are available from https://dl-cdn.alpinelinux.org/alpine/edge/releases/aarch64/netboot-20230329/ onward.

With the above configured the Raspberry Pi 4 should be able to boot from the network without an SD card.

== Troubleshooting ==

=== Long boot time when running headless ===

If no peripherals are connected, the system might hang for an exceptionally long period of time while it attempts to accumulate entropy.

If this is the case, simply plugging in any USB device should work around this issue, since it increases the amount of entropy available to the kernel via interrupts.

=== apk indicating 'No space left on device' ===

Note some models of the Raspberry Pi such as the 3A+ only have 512M of RAM, which on fresh Alpine deployment will only leave around 200M for tmpfs root. It's important to keep this limitation in mind when using these boards.

=== Wireless support with older Alpine images ===

If you need Wi-Fi, you'll need to [https://github.com/RPi-Distro/firmware-nonfree/tree/master/brcm download] the latest Broadcom drivers to your SD card.
(Replace /mnt/sdcard with the correct mount point.)

git clone --depth 1 https://github.com/RPi-Distro/firmware-nonfree.git
cp firmware-nonfree/brcm/* /mnt/sdcard/firmware/brcm

== See Also ==

* [[Classic install or sys mode on Raspberry Pi]] - a variant.
* [[Raspberry Pi 3 - Setting Up Bluetooth]]
* [[Raspberry Pi 3 - Configuring it as wireless access point -AP Mode]]
* [[Raspberry Pi 3 - Browser Client]]
* [[Linux Router with VPN on a Raspberry Pi]]
* [[Create a bootable SDHC from a Mac]]
* Build custom Raspberry Pi images based on Alpine via [https://github.com/tolstoyevsky/pieman Pieman]
* [[Tutorials and Howtos#Raspberry Pi]]

[[Category:Installation]]
[[Category: Raspberry]]

Alpine Linux:FAQ

2021-07-30T21:25:06Z

Mtbu: /* My cron jobs don't run? */ typo in code example "daildy"

[[Image:filetypes.svg|64px|left|link=]]
This is a list of '''frequently asked questions''' about Alpine Linux. 
If your question is not answered on this page, use the search box above to find work in progress pages not linked here, or in case of no answer, edit this page and write down your question.
{{Tip| Prepare your question. Think it through. Make it simple and understandable.}}

=General=

Alpine Linux is used heavily in containers (e.g. docker images) on servers, so many of its main packages are focused on server services.

== Where to start? ==

The «[[Installation|Installation page]]» provides a basic orientation.

A broader overview may be found on the official «[http://alpinelinux.org/about About page]», and at the «[[Alpine Linux:Overview|Wiki Overview]]».

Please note that testing is safer on your own virtual machine or on a public «[https://distrotest.net/AlpineLinux/ DistroTest.net]».

== I have found a bug, where can I report it? ==

You can report it in the [https://gitlab.alpinelinux.org/groups/alpine/-/issues bugtracker], but search it first to see if the issue has already been reported.

== Are there any details about the releases available? ==
Yes, please check the [https://alpinelinux.org/releases/ releases] page.

== How can I contribute? ==
You can contribute by:
* Using the software and giving feedback.
* Documenting your [http://www.alpinelinux.org Alpine Linux] experiences on this [[Main_Page|wiki]].
* In many other ways.
Please visit [[Contribute|Contribute page]] to read more about this topic.

== Why don't I have man pages or where is the 'man' command? ==
The ''man'' command and ''man pages'' are not installed by default. Many packages have documentation companion packages suffixed ''-doc''. Keep in mind, not all packages have a corresponding documentation package and when there is one it may not include ''man pages''.

To install the ''man'' command, and related utilities, first add the {{pkg|man-db}} package:

<code>apk add man-db</code>

Once installed, add documentation for the package where you need it. For example, say you installed {{pkg|nftables}} and you now require its man pages:

<code>apk add nftables-doc</code>

Now we've installed ''nft(8)'' and [https://pkgs.alpinelinux.org/contents?branch=edge&name=nftables-doc&arch=x86_64&repo=main other documentation] to our system and you can issue the command:

<code>man nft</code>.

To always install the documentation companion package, when available, add the {{pkg|docs}} meta package.

<code>apk add docs</code>

== What is the difference between edge and stable releases? ==
Stable releases are just what they sound like: initially a point-in-time snapshot of the package archives, but then maintained with bug-fixes only in order to keep a stable environment.

[[Edge]] is more of a rolling-release, with the latest and greatest packages available in the online repositories. 
Occasionally, snapshot ISO images of the then-current state of [[edge]] are made and are available for download. 
Typically these are made when there are major kernel upgrades or package upgrades that require initramfs rebuilds.

== What architectures does Alpine support? ==
As Alpine uses the Linux kernel, it supports:
* '''aarch64''': The 64-bit only ARM execution state of the ARMv8 device machines.
* '''armhf''': The newer ARM hard-float for newer, more powerful 32-bit devices alongside 64-bit
* '''armv7''': The 32-bit only ARM execution state of the ARMv7 devices machines.
* '''mips64''':
* '''s390x''': For the Super powered IBM mainframes, especially IBM Z and IBM LinuxONE servers.
* '''ppc64le''': For 64-bit PowerPC devices with pure little-endian mode, mostly for POWER8 and POWER9
* '''x86''': (i386, PC 32bit) and x86_64 (i686, PC 64bit and amd64)
* '''x86_64''': The popular AMD64 compatible 64-bit x86 based machines, i386 is not recommended for newer/latest hardware.

'''Please check [https://alpinelinux.org/downloads Download] page for media availability on each one''' and check [[Alpine_Linux:Releases|Releases]] pages for latest.

== What kind of release of Alpine Linux are available? ==
Please check the [https://alpinelinux.org/releases/ Releases] page for more information.

=Setup=

== What is the difference between ''sys'', ''data'', and ''diskless'' when running <code>setup-alpine</code> or <code>setup-disk</code>? ==

'''sys:''' This mode is a traditional disk install. The following partitions will be created on the disk: ''/boot/'', ''/'' (filesystem root) and ''swap''.
This mode may be used for development boxes, desktops, virtual servers, etc.

'''data:''' This mode uses your disk(s) for data storage, not for the operating system. Runs from the media and only a ''/var/'' is created on disk. The system itself will run from a ''tmpfs'' (RAM). Use this mode if you only want to use the disk(s) for data, like ''mailspool'', ''databases'', ''logs'', etc.

'''diskless:''' No disks are to be used. [[Alpine local backup]] may still be used in this mode.

These modes are explained further [[Installation#Installation_Overview|on the '''Installation''' page]].

== How do I upgrade Alpine? ==

To upgrade to a new stable release or edge:
<code>apk upgrade --available</code>

==My cron jobs don't run?==

Start service ''crond'' and add it to runlevel:

: {{cmd|rc-service crond start && rc-update add crond}}

After that the cron daemon is started automatically on system boot and executes the scripts placed in the folders under ''/etc/periodic/'' - there're folders for ''15min'', ''hourly'', ''daily'', ''weekly'' and ''monthly'' scripts.

To check whether your scripts are likely to run, use the ''run-parts'' command, for example:

{{cmd|run-parts --test /etc/periodic/15min}}

This command will tell you what should run but will not actually execute the scripts.

If the results of the test are not as expected, check the following:

* Make sure the script is executable - if unsure, issue the command {{cmd|chmod a+x /etc/periodic/[path/scriptname]}}
* Make sure the first line of your script is <code>#!/bin/sh</code>
* Do not use periods on your script file names - this stops them from working; for example: <code>/etc/periodic/daily/myscript</code> will run, but <code>/etc/periodic/daily/myscript.sh</code> won't.

= Time and timezones =

== How do I set the local timezone? ==

If you wish to edit the ''timezone'' (TZ) after installation, run the [[Alpine_setup_scripts#setup-timezone|setup-timezone]] script.

= Packages =

== Can you build an apk package for ...? ==
Yes, we probably can. 
Please create an [https://gitlab.alpinelinux.org/alpine/aports/issues/new issue] in the [https://gitlab.alpinelinux.org bugtracker]. Prefix with "feat" in title and include a short description (one-line), an URL for the home page, and an URL for the source package.

== How can I build my own package? ==
Please see the [[Creating an Alpine package]] page.

== What does "required by: world[$pkgname]" mean? ==

It means that the package you try to install does not exist in the repositories you have configured.

Maybe you forgot to add community, testing or unmaintained to ''/etc/apk/repositories''?

Or is the package in a [[Alpine_Linux_package_management#Repository_pinning|pinned repository]] and you forgot to suffix the package with the repo tag? Example:

{{cmd|apk add experimental-package@testing}}

== How can I find out if a certain package exists in Alpine? ==

If you want to only search repositories you have configured in /etc/apk/repositories, then <code>apk search $pkgname</code> should get you sorted. If you want to search all repositories have a look at the [https://pkgs.alpinelinux.org/ online pkg oracle]

== WARNING: Ignoring APKINDEX.xxxx.tar.gz ==
If you get <code>WARNING: Ignoring APKINDEX.xxxx.tar.gz: No such file or directory</code> while running [[Alpine_Linux_package_management|package related tools]], check your ''/etc/apk/repositories'' file.

To check the content of the repositories file
{{Cmd|cat /etc/apk/repositories}}

or
{{Cmd|setup-apkrepos}}

= Dynamic DNS =
== How do I schedule a regular dynamic DNS update? ==
You'll want to install the {{pkg|ez-ipupdate}} package:
{{cmd|apk add ez-ipupdate}}

After that, create a new file at {{path|/etc/ez-ipupdate.conf}} with contents similar to:
service-type=dyndns
user=myusername:mypassword
interface=eth1
host=myhostname.dyndns.org

Make the new ip cache directory:
{{cmd|mkdir /var/cache/ez-ipupdate
lbu add /var/cache/ez-ipupdate}}

Then schedule a new cron job with this command:
{{cmd|echo >> /var/log/ez-ipupdate && \ /bin/date >> /var/log/ez-ipupdate && \ ez-ipupdate --config-file /etc/ez-ipupdate.conf -f -F /var/run/ez-ipupdate.pid \ --cache-file /var/cache/ez-ipupdate/ipcache --quiet >> /var/log/ez-ipupdate 2>&1}}

Don't forget to backup your settings!
{{cmd|lbu ci}}

= Terminal =

== How to enable/fix colors for git? ==

The problem is not in git itself or terminal, but in the <tt>less</tt> command.
Busybox’s <tt>less</tt> doesn’t support <tt>-r</tt> (<tt>--raw-control-chars</tt>) and <tt>-R</tt> (<tt>--RAW-CONTROL-CHARS</tt>) options.

The simplest (yet not ideal) solution is to install GNU less:

{{cmd|apk add less}}

= Old questions, no longer freqently asked =

== Alpine freezes during boot from Compact Flash, how can I fix? ==
Most Compact Flash card readers do not support proper DMA. 
You should append '''nodma''' to the ''append'' line in {{path|syslinux.cfg}}.

== How do I remove the CDROM? ==
Since the modloop loopback device is on CDROM you cannot just run <code>eject</code>. You need to unmount the modloop first. 
Unmounting both the modloop and the CDROM in one step can be done by executing:
{{Cmd|/etc/init.d/modloop stop}}

Then it's possible to eject the CDROM:
{{Cmd|eject}}

== How can I install a custom firmware in a diskless system? ==

The modules and firmware are both special images which are mounted as read-only. 
To fix this issue you can copy the firmware directory to your writeable media (cf/usb) and copy your custom firmware to it. 
After reboot Alpine should automatically use the directory on your local storage instead of the loopback device.

== How do I play my .ogg/.mp3 files? ==
First, the sound card should be recognized (you must have {{path|/dev/snd/*****}} files)

{{pkg|sox}}, {{pkg|mpg123}}, etc all use the oss sound driver, while Alpine uses ALSA drivers. 
So you need to load the snd-pcm-oss compatibility module. 
While you're at it, you might need {{pkg|aumix}} to turn up the sound volume
{{cmd|echo snd-pcm-oss >> /etc/modules
modprobe snd-pcm-oss
apk_add aumix sox
aumix (set volume settings)
play really_cool_song.mp3}}

== OpenNTPD reports an error with "adjtime" ==
Your log contains something like:
reply from 85.214.86.126: offset 865033148.784255 delay 0.055466, next query 32s
reply from 202.150.212.24: offset 865033148.779314 delay 0.400771, next query 3s
adjusting local clock by 865033148.779835s
adjtime failed: Invalid argument

{{pkg|openntpd}} is supposed to make small adjustments in the time without causing time jumps. 
If the adjustment is too big then something is clearly wrong and ntpd gives up. (its actually adjtime(3) that has a limit on how big adjustments are allowed)

You can make ntpd set the time at startup by adding ''-s'' option to ntpd. This is done by setting '''NTPD_OPTS="-s"''' in {{path|/etc/conf.d/ntpd}}.

== Using a cron job to keep the time in sync ==
Add the following to {{path|/etc/periodic/daily}} (or use another folder under the {{path|/etc/periodic}} heirarchy if you want to run the script more/less frequently)

Example: file called {{path|do-ntp}}
<pre>
#!/bin/sh
ntpd -d -q -n -p uk.pool.ntp.org</pre>

This queries the uk time server pool - you can modify this to suit your localisation, or just use ''pool.ntp.org''. More info here: [http://www.pool.ntp.org/zone/@ http://www.pool.ntp.org/zone/@]

== Windows clients reports an error when trying to sync ==
{{pkg|openntpd}} needs to run for a while before it is satisfied it is in sync.
Until then it will set a flag "clock not synchronized" and Windows will report an error while trying to sync with your {{pkg|openntpd}} server.

Only thing to do is wait, do something else for 15-20mins and then check.

[[Category:Newbie]]

Alpine Package Keeper

2021-07-24T15:24:58Z

Mtbu: /* Upgrading "diskless" and "data" disk mode installs */ Fix typo

{{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 [https://wiki.alpinelinux.org/wiki/Alpine_Linux_package_management#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>

== apk policy ==

To display the repository a package was installed from and will be updated from, plus any [https://wiki.alpinelinux.org/wiki/Alpine_Linux_package_management#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]]

Raspberry Pi

2021-07-23T08:07:36Z

Mtbu: /* See Also */ Link to Raspberry Pi Headless Installation page

{{warning | 11 Feb 2021 - There is currently a known bug upstream [https://github.com/raspberrypi/firmware/issues/1529 kernel/initramfs cannot be loaded from subdirectory with same name as volume label] }}

{{TOC right}}

This tutorial will help you install Alpine Linux on your Raspberry Pi.

== Preparation ==

# [http://alpinelinux.org/downloads/ Download] the Alpine for Raspberry Pi tarball. You should be safe using the '''armhf''' build on all versions of Raspberry Pi (including Pi Zero and Compute Modules); but it may perform less optimally on recent versions of Raspberry Pi. The '''armv7''' build is compatible with Raspberry Pi 2 Model B. The '''aarch64''' build should be compatible with Raspberry Pi 2 Model v1.2, Raspberry Pi 3 and Compute Module 3, and Raspberry Pi 4 model B.
# [[Create a Bootable USB#Format USB stick|Create a bootable FAT32 partition on your SD card.]] The partition type should be <code>W95 FAT32 (LBA)</code>. (The current type can be found in the "Type" column in the output of <code>fdisk -l</code>.) You can use a partitioning tool such as [https://en.wikipedia.org/wiki/GNOME_Disks gnome-disks] or [http://linux.die.net/man/8/fdisk fdisk].
# Create a filesystem on the partition with <code>mkdosfs -F 32 /dev/sdX1</code> (Replace sdX1 with the correct reference to the partition you just created.)
# Mount the partition and extract the tarball contents onto it.

Optionally create a '''usercfg.txt''' file on the partition to configure low-level system settings. Specifications can be found [https://www.raspberrypi.org/documentation/configuration/config-txt here]. However, note some settings can only be set directly in '''config.txt''', which may be overwritten after updates. In particular, <code>gpu_mem</code> will have no effect when specified in '''usercfg.txt''' ([https://github.com/raspberrypi/firmware/issues/1332 source]). Some interesting values include:
* To enable audio: <code>dtparam=audio=on</code>
* If you see black edges around your screen after booting the Pi, you can add <code>disable_overscan=1</code>

Recent versions include Broadcom firmware files. If you're using an older Alpine version, see [[#Wireless_support_with_older_Alpine_images|section below]].

== Installation ==

Alpine Linux will be installed in [[Installation#Installation_Handbook|diskless mode]], hence you need to use [[Alpine local backup|Alpine Local Backup (lbu)]] to save your modifications between reboots.

For users who will be using their Raspberry Pi in scenarios where there is not expected to be significant changes to disk after setup (like running a static HTTP server), this is likely preferable, as running the entire system from memory will improve performance (by avoiding the slow SD card) and improve the SD card life (by reducing the writes to the card, as all logging will happen in RAM). Diskless installations still allow you to install packages, save local files, and tune the system to your needs.

However, if you:
* Expect there will be constant changes to the disk after initial setup (for example, if you expect people to login and save files to their home directories)
* Need logs to persist after reboot
* Plan to install packages which consume more space than can be loaded into RAM
* Want to install kernel modules (such as ZFS or Wireguard)

Then you may be better served by a [[Classic install or sys mode on Raspberry Pi|sys-mode installation]].

Follow these steps to install Alpine Linux in Diskless Mode:

# Insert the SD card into the Raspberry Pi and power it on
# Login into the Alpine system as root. Leave the password empty.
# Type <code>setup-alpine</code>
# Once the installation is complete, commit the changes by typing <code>lbu commit -d</code>

Type <code>reboot</code> to verify that the installation was indeed successful.

== Post Installation ==

=== Update the System ===

After installation, make sure your system is up-to-date:

{{cmd|apk update
apk upgrade}}

Don't forget to save the changes:

{{cmd|lbu commit -d}}

Note: this does not upgrade the kernel. In order to upgrade the kernel, a full upgrade of the Alpine Linux version must be performed as described in [[Upgrading Alpine#Upgrading Alpine Linux on other removable media (such as CF/USB)|upgrading Alpine Linux for removable media]].

=== Clock-related error messages ===

During the booting time, you might notice errors related to the hardware clock. The Raspberry Pi does not have
a hardware clock, thus you need to disable the hwclock daemon and enable swclock:

{{cmd|rc-update add swclock boot # enable the software clock
rc-update del hwclock boot # disable the hardware clock}}

Since the Raspberry Pi does not have a clock, Alpine Linux needs to know what the time is by using a
[https://en.wikipedia.org/wiki/Network_Time_Protocol Network Time Protocol (NTP)] daemon. Make sure you have a
NTP daemon installed and running. If you are not sure, you can install an NTP client by running the following
command:

{{cmd|setup-ntp}}

The Busybox NTP client might be the most lightweight solution. Save the changes and reboot, once the NTP software is
installed and running:

{{cmd|lbu commit -d
reboot}}

After reboot, make sure the <code>date</code> command outputs the correct date and time.

=== WiFi on boot ===
If you have already [[Connecting_to_a_wireless_access_point|configured WiFi]] during the setup, the connection will not return on reboot.
You will need to start up a service to automatically connect to the wireless access point.
# Run <code>rc-update add wpa_supplicant boot</code> to connect to the wireless access point during bootup.
# Run it manually with <code>/etc/init.d/wpa_supplicant start</code>.

=== Enable OpenGL (Raspberry Pi 3/4) ===
Remount the boot partition writeable (i.e. <code>/media/mmcblk0p1</code>):

{{cmd|mount /media/mmcblk0p1 -o rw,remount}}

Add the following lines to <code>/media/mmcblk0p1/config.txt</code>:

gpu_mem=128
# Raspberry Pi 3:
dtoverlay=vc4-kms-v3d
# Raspberry Pi 4:
dtoverlay=vc4-fkms-v3d

256MB (and more on the Raspberry Pi 4) <code>gpu_mem</code> is also possible.

Install the Mesa drivers:

{{cmd|<nowiki># Raspberry Pi 3:
apk add mesa-dri-vc4
# Raspberry Pi 4:
apk add mesa-dri-gallium</nowiki>}}

Then reboot:

{{cmd|lbu_commit -d; reboot}}

=== WiFi drivers ===
As of Alpine 3.14, the WiFi drivers for the Raspberry Pi were moved from <code>linux-firmware-brcm</code> to the <code>linux-firmware-cypress</code> package (source?). Since the images seem to be an outdated version of the former, Wi-Fi will work during installation, but after the first update it will break.
Use the ethernet interface to download the required packages:

{{cmd|apk add linux-firmware-cypress}}

And reboot.

== Persistent storage ==
=== Loopback image with overlayfs ===

When you install Alpine in diskless mode, the entire system is loaded into memory at boot. If you want additional storage (for example, if you need more space than offered by your RAM) we need to create loop-back storage onto the SD card mounted with overlayfs.

First, make the SD card writable again and change fstab to always do so:
{{cmd|mount /media/mmcblk0p1 -o rw,remount
sed -i 's/vfat\ ro,/vfat\ rw,/' /etc/fstab}}

Create the loop-back file, this example is 1 GB:

{{cmd|dd if=/dev/zero of=/media/mmcblk0p1/persist.img bs=1024 count=0 seek=1048576}}

Install the ext utilities:

{{cmd|apk add e2fsprogs}}

Format the loop-back file:

{{cmd|mkfs.ext4 /media/mmcblk0p1/persist.img}}

Mount the storage:

{{cmd|echo "/media/mmcblk0p1/persist.img /media/persist ext4 rw,relatime,errors=remount-ro 0 0" >> /etc/fstab
mkdir /media/persist
mount -a}}

Make the overlay folders, we are using the /usr directory here, but you can use /home or anything else:

{{cmd|mkdir /media/persist/usr
mkdir /media/persist/.work
echo "overlay /usr overlay lowerdir=/usr,upperdir=/media/persist/usr,workdir=/media/persist/.work 0 0" >> /etc/fstab
mount -a}}

Your /etc/fstab should look something like this:
{{Cmd|/dev/cdrom /media/cdrom iso9660 noauto,ro 0 0
/dev/usbdisk /media/usb vfat noauto,ro 0 0
/dev/mmcblk0p1 /media/mmcblk0p1 vfat rw,relatime,fmask=0022,dmask=0022,errors=remount-ro 0 0
/media/mmcblk0p1/persist.img /media/persist ext4 rw,relatime,errors=remount-ro 0 0
overlay /usr overlay lowerdir=/usr,upperdir=/media/persist/usr,workdir=/media/persist/.work 0 0}}

Now commit the changes: (optionally remove the e2fsprogs, but it does contain repair tools)
{{cmd|lbu_commit -d}}

Remember, with this setup if you install things and you have done this overlay for /usr, you must not commit the 'apk add', otherwise, while it boots it will try and install it to memory, not to the persistent storage.

If you do want to install something small at boot, you can use `apk add` and `lbu commit -d`.

If it is something a bit bigger, then you can use `apk add` but then not commit it. It will be persistent (in /user), but be sure to check everything you need is in that directory and not in folders you have not made persistent.

=== Traditional disk-based (sys) installation ===
{{Merge|Classic install or sys mode on Raspberry Pi|There's an existing page for sys-installations on RasPi.}}

It is also possible to switch to a fully disk-based installation. This is not yet formally supported, but can be done somewhat manually. This frees all the memory otherwise needed for the root filesystem, allowing more installed packages.

Split your SD card into two partitions: the FAT32 boot partition described above (in this example it'll be <code>mmcblk0p1</code>) , and a second partition to hold the root filesystem (here it'll be <code>mmcblk0p2</code>). Boot and configure your diskless system as above, then create a root filesystem:

{{cmd|apk add e2fsprogs
mkfs.ext4 /dev/mmcblk0p2}}

Now do a disk install via a mountpoint. The <code>setup-disk</code> script will give some errors about syslinux/extlinux, but you can ignore them.
The Raspberry Pi doesn't need them to boot.

{{cmd|<nowiki>mkdir /stage
mount /dev/mmcblk0p2 /stage
setup-disk -o /media/mmcblk0p1/MYHOSTNAME.apkovl.tar.gz /stage
# (ignore errors about syslinux/extlinux)</nowiki>}}

Add a line to <code>/stage/etc/fstab</code> to mount the Pi's boot partition again:

{{cmd|/dev/mmcblk0p1 /media/mmcblk0p1 vfat defaults 0 0}}

Now add a <code>root=/dev/mmcblk0p2</code> parameter to the Pi's boot command line, either <code>cmdline-rpi2.txt</code> or <code>cmdline-rpi.txt</code> depending on model:

{{cmd|<nowiki>mount -o remount,rw /media/mmcblk0p1
sed -i '$ s/$/ root=\/dev\/mmcblk0p2/' /media/mmcblk0p1/cmdline-rpi2.txt</nowiki>}}

You might also consider <code>overlaytmpfs=yes</code> here, which will cause the underlying SD card root filesystem to be mounted read-only, with an overlayed tmpfs for modifications which will be discarded at shutdown.

N.B. the contents of /boot will be ignored when the Pi boots. It will use the kernel, initramfs, and modloop images from the FAT32 boot partition. To update the kernel, initfs or modules, you will need to manually (generate and) copy these to the boot partition or you could use bind mount, in which case,
copying the files to boot partition manually, is not needed.

{{cmd|<nowiki>echo /media/mmcblk0p1/boot /boot none defaults,bind 0 0 >> /etc/fstab</nowiki>}}

=== Persistent Installation on Raspberry Pi 3 ===
See [[Classic install or sys mode on Raspberry Pi]] and https://web.archive.org/web/20171125115835/https://forum.alpinelinux.org/comment/1084#comment-1084

=== Persistent Installation on Raspberry Pi 4 ===
As of 3.14, setup-alpine should ask you if you want to create a sys mode partition on your Raspberry Pi 4.

== Troubleshooting ==

=== Long boot time when running headless ===

If no peripherals are connected, the system might hang for an exceptionally long period of time while it attempts to accumulate entropy.

If this is the case, simply plugging in any USB device should work around this issue.

'''Alternatively''', installing haveged, the random numbers generator, would speed up the process:

apk update
apk add haveged
rc-update add haveged boot
lbu commit -d
service haveged start

(Tested on a raspberry pi zero W in headless mode, no USB connected, Alpine 3.10.3)

=== apk indicating 'No space left on device' ===

Note some models of the Raspberry Pi such as the 3A+ only have 512M of RAM, which on fresh Alpine deployment will only leave around 200M for tmpfs root. It's important to keep this limitation in mind when using these boards.

=== Wireless support with older Alpine images ===

If you need Wi-Fi, you'll need to [https://github.com/RPi-Distro/firmware-nonfree/tree/master/brcm download] the latest Broadcom drivers to your SD card.
(Replace /mnt/sdcard with the correct mount point.)

git clone --depth 1 https://github.com/RPi-Distro/firmware-nonfree.git
cp firmware-nonfree/brcm/* /mnt/sdcard/firmware/brcm

== See Also ==

* [[Classic install or sys mode on Raspberry Pi]] - a variant.
* [[Raspberry Pi - Headless Installation]]
* [[Raspberry Pi 3 - Setting Up Bluetooth]]
* [[Raspberry Pi 3 - Configuring it as wireless access point -AP Mode]]
* [[Raspberry Pi 3 - Browser Client]]
* [[Linux Router with VPN on a Raspberry Pi]]
* [[Create a bootable SDHC from a Mac]]
* Build custom Raspberry Pi images based on Alpine via [https://github.com/tolstoyevsky/pieman Pieman]
* [[Tutorials and Howtos#Raspberry Pi]]

[[Category:Installation]]
[[Category: Raspberry]]

Setup Hardware Clock (RTC) Module on a Raspberry Pi

2021-07-17T09:51:30Z

Mtbu: Add page to Raspberry category as it's focusing on a Raspberry Pi

= Install Hardware =

I used a [http://www.piface.org.uk/products/piface_clock PiFace Real Time Clock]. After installing the CR1220 battery and correctly mounting on the board, [http://www.piface.org.uk/assets/piface_clock/PiFaceClockguide.pdf see manual] for that.

= Install Software =
Add the modules from the kernel

== /etc/modules/ ==
Add these modules so they're loaded on boot. You can modprobe each one individually if you don't want to reboot.

<pre>i2c_dev
i2c_bcm2708
i2c:mcp7941x</pre>

== /media/mmcblk0p1/config.txt ==
You will need to mount this as read-write

{{cmd|mount -o remount,rw /media/mmcblk0p1}}

Add these two parameters to the bottom

<pre>dtparam=i2c1=on
dtparam=i2c_arm=on</pre>

{{cmd|mount -o remount,ro /media/mmcblk0p1}}

Then you will need to reboot.

== Binding the hardware clock device ==

You will want to make sure the device is created when hwclock starts, if it isn't already created. To the bottom of /etc/conf.d/hwclock add this:

<pre>start_pre() {
if [ -d "/sys/class/i2c-adapter/i2c-1/i2c-dev/i2c-1" ]; then
einfo "Creating RTC device";
echo mcp7941x 0x6f > /sys/class/i2c-adapter/i2c-1/new_device
fi
}</pre>

For the time being this is necessary but in the future when [https://github.com/raspberrypi/linux/issues/1032 issue 1032] you should be able to just add

<pre>dtparam=i2c-rtc,mcp7941x</pre>

to /media/mmcblk0p1/config.txt

[[Category:Hardware]]
[[Category:System Administration]]
[[Category:Raspberry]]

OpenRC

2021-07-17T09:45:17Z

Mtbu: /* Quick-Start Information */ Fix typo

== Quick-Start Information ==
Alpine Linux uses [https://wiki.gentoo.org/wiki/OpenRC OpenRC] for its init system.

The following commands are available to manage the init system:
* Basics:
{{Cmd|rc-update add <service> <runlevel>}}
{{Cmd|rc-update del <service> <runlevel>}}
{{Cmd|rc-service <service> <start stop restart> # ⇔ /etc/init.d/service <start stop restart>}}

* To check services and their set runlevels:
{{Cmd|rc-status}}

* To change to a different runlevel:
{{Cmd|rc <runlevel>}}

* Reboot/Halt/Poweroff: (And their equivalent from traditional GNU/Linux systems)
{{Cmd|reboot # ⇔ shutdown now -r}}
{{Cmd|halt # ⇔ shutdown now -H}}
{{Cmd|poweroff # ⇔ shutdown now -P}}

{{Tip|Prior to Alpine Linux 2.0.0, you might need to use the following commands instead: ''rc_add, rc_delete,'' and ''rc_status''.}}

== Available Runlevels ==
The available runlevels are:
* '''default''' - Used if no runlevel is specified. (This is generally the runlevel you want to add services to.)
* '''hotplugged'''
* '''manual'''

The special runlevels are:
* '''sysinit''' - Brings up any system specific stuff such as <code>/dev</code>, <code>/proc</code> and optionally <code>/sys</code> for Linux based systems. It also mounts <code>/lib/rc/init.d</code> as a ramdisk using tmpfs where available unless <code>/</code> is mounted rw at boot. <code>'''rc'''</code> uses <code>/lib/rc/init.d</code> to hold state information about the services it runs. sysinit always runs when the host first starts and should not be run again.
* '''boot''' - Generally the only services you should add to the boot runlevel are those which deal with the mounting of filesystems, set the initial state of attached peripherals and logging. Hotplugged services are added to the boot runlevel by the system. All services in the boot and sysinit runlevels are automatically included in all other runlevels except for those listed here.
* '''single''' - Stops all services except for those in the sysinit runlevel.
* '''reboot''' - Changes to the shutdown runlevel and then reboots the host.
* '''shutdown''' - Changes to the shutdown runlevel and then halts the host.

== rc-update usage ==
Usage: rc-update [options] add service <runlevel>
rc-update [options] del service <runlevel>
rc-update [options] show

Options: [suChqv]
-s, --stack Stack a runlevel instead of a service
-u, --update Force an update of the dependency tree
-h, --help Display this help output
-C, --nocolor Disable color output
-v, --verbose Run verbosely
-q, --quiet Run quietly

== rc-status usage ==
Usage: rc-status [options] [runlevel1] [runlevel2] ...

Options: [aclrsuChqv]
-a, --all Show services from all run levels
-c, --crashed Show crashed services
-l, --list Show list of run levels
-r, --runlevel Show the name of the current runlevel
-s, --servicelist Show service list
-u, --unused Show services not assigned to any runlevel
-h, --help Display this help output
-C, --nocolor Disable color output
-v, --verbose Run verbosely
-q, --quiet Run quietly

== rc-service usage ==
Usage: rc-service [options]

Options: [e:ilr:ChqVv]
-e, --exists <arg> tests if the service exists or not
-i, --ifexists if the service exists then run the command
-l, --list list all available services
-r, --resolve <arg> resolve the service name to an init script
-h, --help Display this help output
-C, --nocolor Disable color output
-V, --version Display software version
-v, --verbose Run verbosely
-q, --quiet Run quietly

== rc usage ==
Usage: rc [options]

Options: [a:o:s:SChqVv]
-a, --applet <arg> runs the applet specified by the next argument
-o, --override <arg> override the next runlevel to change into
when leaving single user or boot runlevels
-s, --service <arg> runs the service specified with the rest
of the arguments
-S, --sys output the RC system type, if any
-h, --help Display this help output
-C, --nocolor Disable color output
-V, --version Display software version
-v, --verbose Run verbosely
-q, --quiet Run quietly

[[Category:Booting]]

Raspberry Pi 3 - Browser Client

2021-07-16T19:00:19Z

Mtbu: Add page to Category:Raspberry

This is a guide for setting up a RAM based Alpine which is able to run X, and firefox. This tutorial will go through setting up auto login, and starting X on boot without user interaction. It is a type of kiosk or possibly digital signage.

'''Tested as of 05/2020''' - RPI 3

'''12/2020''' - x86

'''04/2021''' - RPI 4

==Overview==
This guide uses the following:
* aarch64 img (though this guide is also x86-compatible)
* RPI3
* community repo is used.

It is based off of this guide: [[Raspberry_Pi]]. Due to the dependencies required to run X and FF, there is very little RAM disk space for the user to operate in, after this tutorial is complete (about 30MB is v3.11). The 2GB RPI 4 has 1GB of ram, without adjusting /boot/config.txt. 1GB may be enough for most needs.

aarch64 is used, because firefox-esr is in the community repo. armhf (as of v3.11) does not have firefox prepackaged in the base or community repo.

See https://pkgs.alpinelinux.org/packages?name=*firefox*&branch=v3.11&arch=aarch64

Note that the aarch64 build is not compatible with all RPI. See [[Raspberry Pi]].

==Steps==
===Base Install===

These steps are duplicated from [[Raspberry_Pi]] page.

Use fdisk or gdisk to format the SD card. You must have the first partition
be a bootable, FAT filesystem.
e.g.:
<pre>
Command (m for help): p
Disk /dev/sdb: 59.5 GiB, 63864569856 bytes, 124735488 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x00000000

Device Boot Start End Sectors Size Id Type
/dev/sdb1 * 2048 62916607 62914560 30G b W95 FAT32
</pre>
mkdosfs -F 32 /dev/sdX1

untar onto mounted disk

mount /dev/sdX1 /mnt/folder
tar xvf archive.tar -C /mnt/folder/.

If you plan to enable increased RAM (e.g. for RPI4 with 2 or 4GB) or other
config settings, do so in a usercfg.txt now.

Again, duplicating the [[Raspberry Pi]] page

Insert the SD card into the Raspberry Pi and turn it on
Login into the Alpine system as root. Leave the password empty.
Type setup-alpine
Once the installation is complete, commit the changes by typing lbu commit -d

Things to keep in mind here:
* There is no need to make multiple partitions (e.g. on an sdcard). One partition that takes up the whole of the storage will suffice in diskless / sys mode.
* For the setup-alpine install, most of the choices will be at the defaults. Particularly when prompted with "No disks available, try boot media /mmcblk0p1". Here you will click the default [n]. If you make a mistake during the install, you can always reimage and start over.

Saving space: busybox instead of chronyd, dropbear instead of openssh

After setup, make sure dropbear is installed
apk add dropbear

Start it:
rc-service dropbear start

Add it to the default runlevel:
rc-update add dropbear

If you need an accurate clock, enable software/ntp here (optional, i don't need a clock for the website I view).
rc-update add swclock boot # enable the software clock
rc-update del hwclock boot # disable the hardware clock
setup-ntp

===Browser Client Install===

Enable community repo (/etc/apk/repositories) (uncomment community)
nano /etc/apk/repositories
apk update

install firefox and X dependencies:
apk add libx11-dev libxft-dev libxinerama-dev adwaita-gtk2-theme adwaita-icon-theme ttf-dejavu
Note that the fonts/icon theme are required for FF to display correctly. Without these, firefox will load, but text will not render on the browser menus.

the RAM tmp fs remaining can be viewed while installing, with watch df -h

install firefox
apk add firefox-esr
install X
setup-xorg-base
The RPI also requires for X:
apk add xf86-video-fbdev

note: this command can vary if you are using x86. For example, I installed no xf86-video... drivers, and had a libEGL.so missing library error on Xorg, and that was resolved via "apk search libEGL.so" which pointed to mesa-egl. Note that apk search is case sensitive.

At this point, we have about 421MB used up (if NTP was not setup).
<pre>
Filesystem Size Used Available Use% Mounted on
devtmpfs 10.0M 0 10.0M 0% /dev
shm 457.9M 0 457.9M 0% /dev/shm
/dev/mmcblk0p1 30.0G 259.4M 29.7G 1% /media/mmcblk0p1
tmpfs 457.9M 420.0M 37.9M 92% /
tmpfs 91.6M 188.0K 91.4M 0% /run
/dev/loop0 24.9M 24.9M 0 100% /.modloop
</pre>

lbu_commit -d

===AutoLogin, Startx automatically on Boot===

At this point, you should be able to login as root, and run startx manually. Now, we will add a number of configuration files that allow this to happen without user interaction.

/root/ doesn't save any files, so it's necessary to edit files in /etc/ and lbu_commit -d after all changes. First let's add a file that will call firefox.
lbu_commit is alpine local backup. If you want to save folders other than /etc see:https://wiki.alpinelinux.org/wiki/Alpine_local_backup#Include_special_files.2Ffolders_to_the_apkovl
also see: /etc/apk/protected_paths.d/lbu.list

create a file named /etc/startup.sh:
#!/bin/ash
firefox http://somewebsite.com

!!!NOTE: This is ash, not bash. By default, alpine ships with the ashbourne shell. Although bash is available in the repositories.

We have to edit xinitrc, and the profile configs. Normally, this would be done in the user's directory, but here we will use the globals for simplicity.
mv /etc/X11/xinit/xinitrc /etc/X11/xinit/xinitrc_BAK
nano /etc/X11/xinit/xinitrc
In this file put:
/etc/startup.sh
At the end of /etc/profile (leave the existing file) append
startx
And remember to: lbu_commit -d For autologin, alpine uses busybox, which has an alias to /sbin/getty as well as /bin/login. It's possible to navigate to /sbin/ or /bin/ and run /sbin/getty -h to see what settings are available. To have root auto login upon boot, review the existing inittab and edit as needed, according to the config below.
<pre>
# Set up a couple of getty's
#tty1::respawn:/sbin/getty 38400 tty1
tty2::respawn:/sbin/getty 38400 tty2
tty3::respawn:/sbin/getty 38400 tty3
tty4::respawn:/sbin/getty 38400 tty4
tty5::respawn:/sbin/getty 38400 tty5
tty6::respawn:/sbin/getty 38400 tty6

tty1::respawn:/bin/login -f root
</pre>

===Disable Screensaver, and refresh webpage (optional)===

As a kiosk, the RPI will need to have the screensaver ([https://wiki.archlinux.org/DPMS DPMS]) disabled. Also, my particular application (video streams) required a refresh occasionally. These were managed with xorg.conf, xdotool, and crontab respectively.

{{cat|/etc/X11/xorg.conf|
Section "Extensions"
Option "DPMS" "Disable"
EndSection}}

{{cmd|# apk add xdotool}}

<pre># crontab -u root -e
* * * * * DISPLAY=:0 /usr/bin/xdotool key F5</pre>

Note that xset is not an option here, as it's not included by default. It can be installed from repositories, if needed.
That's it. Now reboot, and watch the RPI boot into firefox without user intervention. At this point, you have a functioning minimal OS booting from RAM, with firefox, and ~30MB of available space for further configuration.

==Digital Signage==
It's common to use GNULinux and x86/RPIs for digital signage. A quick glance at https://elinux.org/RPi_Projects/Digital_Signage will show a number of options. Why would you use this guide for digital signage vs. those pre-built projects?
# Alpine runs from RAM, which increases the lifetime of the storage (flash / hdd).
# There is no requirement to use 'cloud' services, or depend upon an internet connection.
# You have full control over the build and design (all kiosk build steps are documented & have a small learning curve, compared to some of the more complex projects mentioned above).
# Free software. No recurring costs (outside of optional maintenance).
# No ties to external infrastructure / frameworks. Full freedom.

In this addition to the guide above, I will install Chromium, which seems to be the defacto standard. However, you could use any application that runs in X. Here we will also run a web server with PHP, which hosts the resources we want to display on the sign.
Make sure community apk is enabled in /etc/apk/repositories
apk add chromium
In /etc/startup.sh add the browser instead of firefox:
chromium-browser --home-page http://127.0.0.1/resource --no-sandbox --window-size=1920,1280 --start-fullscreen --test-type
Note that this is a potentially insecure setup, and users are advised to add a user, and remove the --no-sandbox tag. The tags used are the following: --home-page will start us on a given URL. --no-sandbox will allow root to run chromium. --window-size will give us the resolution we want, and start-fullscreen will ensure the browser takes up all of the screen.

If you deploy the device on a TV, and you are unsure what resolution it is, you can access the resolution from the terminal (not in X), by using
xrandr -d :0
For example, I built my device on a computer monitor that was 1920x1280, but when I deployed, the TV was 1920x1080. Since we run chromium straight on X, without any WM, it's necessary to query xrandr from the console. If desired, you could install DWM and hide the bar, obtaining access to a terminal accessible via keyboard shortcut configured in dwm's config.h, But a WM is not required.

Make sure to lbu_commit -d, in order to save any changes as needed in the apkvol on the SD or HDD storage.

===Install Apache/PHP===
See [[Apache]].

===Install xset to disable screensaver===
apk add xset
xset q
xset s off

===Hide Scrollbars of Browser===
This can be done in CSS.
body {
overflow: hidden; /* Hide scrollbars */
}

==Tips/Troubleshooting==
===Why was this setup used? Why not Awesome, or dwm?===
I ran through a few different setups of alpine on the rpi, and found that (dwm | awesome) & firefox required too many dependencies to run on an RPI3 with 512MB in /tmp (running in RAM), or other browsers which used less dependencies were unstable (the application was viewing video streams). Therefore, running firefox direct off X was just barely able to fit into the available space, and was stable. This is one of the reasons aarch64 was used, instead of armhf. The 2GB RPI4 by default has 1GB of ram in alpine available (for storage), and doesn't have this limitation. It should be possible to get more RAM via /boot/config.txt

If your application doesn't require media (i.e. a static webpage) you may be able to run other browsers, such as midori, falkon, or surf, without stability issues on the RPI.

It is possible that VLC or a GTK/QT app would also fit into the limited space on the RPI 3. This was not tested.

===Width & height of firefox doesn't fit the monitor===
Firefox can be called with -height and -width flags, e.g.
firefox -width 480 -height 640 somewebsite.com

===Periodic Firefox Crashes on RPI3 due to Low Memory===
With the RPI3, I found firefox crashing reliably after a couple days uptime of watching video. On the server I saw notices of memory running out. This may have been a memory leak, and with the small amount of RAM available, it would crash firefox, leaving the screen blank.

The solution was to setup a nightly reboot of the system via cron, and this has kept the system stable since. However, if I was to do this again, I would try an RPI4 with >1GB ram which may obviate the need for a nightly reboot.

==Related Links==
* [[dwm]]
* [[Raspberry Pi]]
* [[Apache]]

[[Category:Raspberry]]

Raspberry Pi 4 - Persistent system acting as a NAS and Time Machine

2021-07-16T18:59:49Z

Mtbu: Add page to Category:Raspberry

== Tinker, Tailor, Raspberry Pi ==

I went ahead and got myself a Raspberry Pi 4B with 4GB RAM, which I intend to use as a job scheduling server, only to find out that the suggested OS, Raspberry Pi OS, is 32-bit. Fortunately, the Linux distro Alpine, which I’ve grown very fond of lately, is available for Raspberry Pi as aarch64, meaning it’s both 64-bit kernel and userland. Unfortunately the distro is currently, as of version 3.12, not set up for persistent storage and is more of a live playground. Gathering bits and pieces from various guides online, that can be remedied with some tinkering. On this page you will find how to set up a persistent 64-bit OS on the Raspberry Pi, share a USB attached disk, as well as some interesting software.

Note: the Pi 4 has micro-HDMI ports. I thought they were mini, for which I already had cabling, but alas, another adapter had to be purchased. Also, when attaching a USB disk it is better if it is externally powered. The Pi can however power newer external SSD drives that have low power consumption. I tried with a USB powered magnetic disk drive, but it behaved somewhat strangely. With that said, let’s look at how to get yourself a shiny, tiny, new server.

=== Tinkering for Persistence ===

After downloading the Alpine v3.12 tarball, the next step is to set up the SDHC card for the Pi. I borrowed a MacBook Air, since it has a built-in card reader. The Pi boots off a FAT32 partition, but ultimately, we want the system to reside in an ext4 partition. We'll start by reserving a small portion of the card for the boot partition. This is done using Terminal in macOS with the following commands.

diskutil list
diskutil partitionDisk /dev/disk2 MBR "FAT32" ALP 256MB "Free Space" SYS R
sudo fdisk -e /dev/disk2
> f 1
> w
> exit

The tarball should have decompressed once it hit your download folder. If not, use the option “xvzf” for tar.

cd /Volumes/ALP
tar xvf ~/Downloads/alpine-rpi-3.12.0-aarch64.tar
nano usercfg.txt

The newly created file usercfg.txt should contain the following:

enable_uart=1
gpu_mem=32
disable_overscan=1

The smallest amount of memory for a headless install is 32MB. Removing overscan gives you more usable screen area. If you intend to use this as a desktop computer rather than a headless server, you probably want to allocate more memory to the GPU and enable sound. Full specifications for options can be found on the official Raspberry Pi homepage.

After that, you need to make sure the card is not busy. Change to a safe directory then eject the card (making sure that any pending writes are finalized).

cd
diskutil eject /dev/disk2

Put the SDHC card in the Pi and boot. Login with “root” as username and no password. This presumes that you have connected everything else, e.g. a keyboard and monitor.

setup-alpine

During setup, select your keymap, hostname, etc, as desired. However, when asked where to store configs, type “none”, and the same for the apk cache directory. If you want to follow this guide to the point, you should also select “chrony” as the NTP client. The most important part here though is to get your network up and running. A full description of the setup programs can be found on the Alpine homepage.

apk update
apk upgrade
apk add cfdisk
cfdisk /dev/mmcblk0

In cfdisk, select “Free space” and the "New" option. It will suggest using the entire available space, so just press enter, then select the option "primary" followed by "Write". Type "yes" to write the partition table to disk, then select "Quit".

apk add e2fsprogs
mkfs.ext4 /dev/mmcblk0p2
mount /dev/mmcblk0p2 /mnt
setup-disk -m sys /mnt
mount -o remount,rw /media/mmcblk0p1

Ignore the warnings about extlinux. This and the following trick was found in the Alpine Wiki, but in a confusing order.

rm -f /media/mmcblk0p1/boot/*
cd /mnt
rm boot/boot
mv boot/* /media/mmcblk0p1/boot/
rm -Rf boot
mkdir media/mmcblk0p1
ln -s media/mmcblk0p1/boot boot

Now the mountpoints need fixing, so run:

apk add nano
nano etc/fstab

If you prefer some other editor (since people tend to become religious about these things) feel free to use whatever you want. Add the following line:

/dev/mmcblk0p1 /media/mmcblk0p1 vfat defaults 0 0

Now the kernel needs to know where the root filesystem is.

nano /media/mmcblk0p1/cmdline.txt

Append the following at the end of the one and only line in the file:

root=/dev/mmcblk0p2

After exiting nano, reboot:

reboot

After rebooting, login using "root" as username, and the password you selected during setup-alpine earlier. Now you have a persistent system, as opposed to the way the original distro was configured.

=== Tailoring for Remote Access ===

OpenSSH should already be installed, but it will not allow remote root login. Initially, we'll relax this restriction. Last in this article is a section on hardening where we again disallow root login. If you intend to have this box accessible from the Internet, I strongly advise hardening the Pi.

nano /etc/ssh/sshd_config

Uncomment and change the line (about 30 lines down) with PermitRootLogin to:

PermitRootLogin yes

Then restart the service:

rc-service sshd restart

Now you should be able to ssh to your Pi. The following steps are easier when you can cut and paste things into a terminal window.

=== Keeping the Time ===

If you selected chrony as your NTP client, it may take a long time for it to correct the clock. Since the Pi does not have a hardware clock, it’s necessary to have the correct time at bootup. We'll change the configuration such that the clock gets set if it is more than 60 seconds off during the first 10 lookups.

nano /etc/chrony/chrony.conf

Add the following line at the bottom of the file.

makestep 60 10

Check the date, restart the service, and check the (now hopefully corrected) date again.

date
rc-service chronyd restart
date

Having the correct time is a good thing, particularly when building a job scheduling server.

=== Silencing the Fan ===

Together with the Pi, I also bought a fan, the Pimoroni Fan Shim. According to reviews it is one of the better ways to cool your Pi. Unless control software is installed, it runs at full speed. It’s not noisy, but still noticeable a meter from the Pi. Again, some tinkering will be needed since the control software needs some prerequisites installed. We lost nano between reboots, so we'll reinstall it.

apk update
apk upgrade
apk add nano

Other software we need is in the “community” repositories of Alpine. In order to activate that repository, we need to edit a file:

nano /etc/apk/repositories

Uncomment the second line (ending in v3.12/community), exit, then install the necessary packages.

apk update
apk add git bash python3 python3-dev py3-pip py3-wheel build-base

After those prerequisites are in place, install the fan shim software using:

git clone https://github.com/pimoroni/fanshim-python
cd fanshim-python
./install.sh
apk add py3-psutil
cd examples
./install-service.sh

The last script will fail with “systemctl: command not found”, since Alpine uses OpenRC as its init system, and not systemd which this script presumes.
We'll write our own startup script:

nano /etc/init.d/fanshim

The new file should have the following contents:

#!/sbin/openrc-run
name="fanshim"
command="/usr/bin/python3 /root/fanshim-python/examples/automatic.py"
command_args="--on-threshold 65 --off-threshold 55 --delay 2"
pidfile="/var/run/$SVCNAME.pid"
command_background="yes"

There are a lot of interesting options for fanshim you can explore, like tuning it’s RGB led. We want this to run at boot time, so add it the the default runlevel, then start it.

rc-update add fanshim default
rc-service fanshim start

Enjoy the silence!

=== Adding and Sharing a Disk ===

Some of files we'll be transferring are quite large. It would also be neat to be able to access files easily from the Finder in macOS, so I am adding a USB3 connected hard disk with 4TB storage. What follows will be very similar to setting up a NAS, and in fact, the way I fell in love with Alpine was by building my own NAS from scratch (with the minor differences being more disks and using zfs).

First we need to change the filesystem. The disk comes formatted as FAT32, which is very poorly suited for a network disk. Samba, which is what we will be using for sharing, more or less requires a filesystem that supports extended attributes. After plugging in the drive, we will repartition the drive and format it to ext4.

cfdisk /dev/sda

Using cfdisk, delete any existing partitions and create one new partition. It should become "Linux filesystem" by default. Don’t forget to "Write" before "Quit"ing. Next, format it:

mkfs.ext4 /dev/sda1

Now we need to add autofs to get automatic mounting. This package is in edge/testing though, so we need to enable that branch and repository, but still have main and community take preference. This can be done by labelling a repository.

nano /etc/apk/repositories

Change the line with the testing repository to the following. Note that yours will have some server.from.setup/path depending on what you selected in setup-alpine. You only uncomment and add the @testing label in other words.

@testing http://<server.from.setup/path>/edge/testing

Now autofs can be installed from the labelled repo.

apk add autofs@testing

Note that dependencies are still pulled from main/community to the extent it is possible. In order to configure autofs, first:

nano /etc/autofs/auto.master

Add the following line after the uncommented line starting with /misc. It will also disconnect the hard disk after 5 minutes to save energy:

/- /etc/autofs/auto.hdd --timeout=300

Then create this new config file:

nano /etc/autofs/auto.hdd

Add the the following line to the empty file.

/hdd -fstype=ext4 :/dev/sda1

Now, the user pi needs to be created.

adduser pi
smbpasswd -a pi

Select passwords for the pi user. The latter one will later be stored in the macOS keychain and therefore easy to forget, so make note of it somewhere.

Add autofs to startup and start it now. Change the ownership of /hdd to pi.

rc-update add autofs default
rc-service autofs start
chown -R pi.pi /hdd

With that in place (disk can be accessed through /hdd) it is time to set up the sharing. For this we will use samba and avahi for network discovery.

apk add samba avahi dbus
nano /etc/samba/smb.cfg

Now, this is what my entire smb.cfg file looks like, with all the tweaks to get stuff running well from macOS.

[global]
create mask = 0664
directory mask = 0775
veto files = /.DS_Store/lost+found/
delete veto files = true
nt acl support = no
inherit acls = yes
ea support = yes
security = user
passdb backend = tdbsam
map to guest = Bad User
vfs objects = catia fruit streams_xattr recycle
acl_xattr:ignore system acls = yes
recycle:repository = .recycle
recycle:keeptree = yes
recycle:versions = yes
fruit:aapl = yes
fruit:metadata = stream
fruit:model = MacSamba
fruit:veto_appledouble = yes
fruit:posix_rename = yes
fruit:zero_file_id = yes
fruit:wipe_intentionally_left_blank_rfork = yes
fruit:delete_empty_adfiles = yes
server max protocol = SMB3
server min protocol = SMB2
workgroup = WORKGROUP
server string = NAS
server role = standalone server
dns proxy = no
[Harddisk]
comment = Raspberry Pi Removable Harddisk
path = /hdd
browseable = yes
writable = yes
spotlight = yes
valid users = pi
fruit:resource = xattr
fruit:time machine = yes
fruit:advertise_fullsync = true

Those last two lines can be removed if you are not interested in using the disk as a Time Machine backup for your Apple devices. I will likely not use it, but since this is how I configured my NAS and it was a hassle to figure out how to get it working I thought I’d leave it here for reference. Doesn’t hurt to keep it there.

Let us also configure the avahi-daemon, by creating a config file for the samba service. Avahi will announce the server using Bonjour, making them easily recognizable from macOS (where they automagically show up in the Finder).

nano /etc/avahi/services/samba.service

This new file should have the following contents:

<?xml version="1.0" standalone='no'?>
<!DOCTYPE service-group SYSTEM "avahi-service.dtd">
<service-group>
<name replace-wildcards="yes">%h</name>
<service>
<type>_smb._tcp</type>
<port>445</port>
</service>
<service>
<type>_device-info._tcp</type>
<port>0</port>
<txt-record>model=RackMac</txt-record>
</service>
<service>
<type>_adisk._tcp</type>
<txt-record>sys=waMa=0,adVF=0x100</txt-record>
<txt-record>dk0=adVN=HDD,adVF=0x82</txt-record>
</service>
</service-group>

Not that the txt-record containing adVN=HDD can be removed if you are not interested in using the disk as a Time Machine backup. Still, leaving it won’t hurt.

Finally, it’s time to add samba and avahi to the startup, and start the services.

rc-update add samba default
rc-update add avahi-daemon default
rc-service samba start
rc-service avahi-daemon start

The disk should now be visible from macOS. Remember to click “Connect as…” and enter “pi” as the username and your selected smbpasswd from earlier. Check the box “Remember this password in my keychain” for quicker access next time. Sometimes, due to a bug in Catalina, you may get “The original item cannot be found” when accessing the remote disk. If that happens, force quit Finder, and you should be good to go again. If anyone knows of any other fix to this issue, let me know!

=== Automation ===

This server will be used as a job server. Some of the jobs running will need the psql command from PostgreSQL and some others will be R jobs. Let’s install both, or whatever you need to satisfy your desire. You can skip this step for now if you are undecided about what to run or just need basic services like the built-in shell scripting.

apk add R postgresql

In order to automate these jobs, we will be using Cronicle. It depends on node.js so we need to install the prerequisites. It’s run script is fetched using curl, so that will also need to be installed.

apk add nodejs npm curl

The installation is done as follows (it is a oneliner even if it looks broken here).

curl -s https://raw.githubusercontent.com/jhuckaby/Cronicle/master/bin/install.js | node

I want to use standard ports, so I had to change the config slightly.

nano /opt/cronicle/conf/config.json

Change base_app_url from port 3012 to 80. Much further down, change http_port from 3012 to 80, and https_port from 3013 to 443. If you want mail to be sent, change smtp_hostname at the beginning of the file to the mail relay you are using. After that, an initialization script needs to be run.

/opt/cronicle/bin/control.sh setup

We need to get it running at boot time. This is, however, a service that we do not want to “kill” using a PID, so we are going to enable local scripts that start and stop the service in a controlled manner instead.

rc-update add local default
nano /etc/local.d/cronicle.start

This new file should have the following line in it:

/opt/cronicle/bin/control.sh start

Now we need to create a stop file as well:

nano /etc/local.d/cronicle.stop

This file should have the contents:

/opt/cronicle/bin/control.sh stop

In order for the local script daemon to run these, they need to be executable.

chmod +x /etc/local.d/cronicle.*

With that, let’s secure things.

=== Hardening ===

Now that most configuring is done, it’s time to harden the Pi. First we will install a firewall with some basic login protection using the builtin 'limit' in iptables. Assuming you are in the 192.168.1.0/24 range, which was set during setup-alpine, the following should be run. Only clients on the local network are allowed access to shared folders.

apk add ufw@testing
rc-update add ufw default
ufw allow 22
ufw limit 22/tcp
ufw allow 80
ufw allow 443
ufw allow from 192.168.1.0/24 to any app CIFS
ufw allow Bonjour

With the rules in place, it’s time to disallow root login via ssh, and make sure only fresh protocols are used.

nano /etc/ssh/sshd_config

Change the line that previously said yes to no, and add the other lines at the bottom of the file (borrowed from this security site):

PermitRootLogin no
PrintMotd no
Protocol 2
HostKey /etc/ssh/ssh_host_ed25519_key
HostKey /etc/ssh/ssh_host_rsa_key
KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,umac-128@openssh.com

After that, enable ufw and restart sshd. Note: if something goes wrong here, you will need to plug in a monitor and keyboard again to login locally and fix things.

ufw enable
rc-service sshd restart

Now is a good time to reboot and reconnect to check that everything is working.

reboot

With root not being able to login, you will instead login as "pi". It is possible for this user to (temporarily, until exit) elevate privileges with the following command:

su

Another option is to use sudo, but I will leave it like this for now, and go ahead with setting up some jobs. That’s a story for another article though.

I hope this guide has been of help. It should be of use for anyone tinkering with Alpine on their Raspberries, and likely some parts for those running other Linux flavors on different hardware as well.

[[Category:Raspberry]]

Configure Wake-on-LAN

2021-07-16T16:28:55Z

Mtbu: Add page to Category:Networking

Configuring Wake-on-LAN is a simple process on Alpine Linux. First, check if your network card supports Wake-on-LAN (''WOL''):

<pre>
# apk add ethtool
# ethtool eth0 | grep -i wake
Supports Wake-on: pumbg
Wake-on: d
</pre>

''Supports Wake-on: pumbg'' means that WOL is supported, ''Wake-on: d'' means that it is currently disabled. To enable it, edit ''/etc/network/interfaces'' as follows:

<pre>
auto eth0
pre-up /usr/sbin/ethtool -s eth0 wol g
</pre>

Reboot, and you should now be able to wake your machine from LAN. You can check if it is really enabled like so:

<pre>
# ethtool eth0 | grep -i wake
Supports Wake-on: pumbg
Wake-on: g
</pre>

''Wake-on: g'' means that it is now enabled.

There are many tools that allow you to wake up the machine now that WOL is supported; https://github.com/sabhiram/go-wol is an excellent one.

[[Category:Networking]]

Setting up a new user

2021-07-16T16:02:11Z

Mtbu: /* User creation and defaults */ Fix some typos

The <code>root</code> account should be used only for local administrative purposes that require elevated access permissions.

This page shows how to create non-privileged user accounts. i.e. those used for daily work, including desktop usage and remote logins.

= Overview =

Creating user accounts provides users their own $HOME directory and allows you (the root user) to limit the access those user accounts have to the operating system configuration files.

Using them increases security, because they limit possible actions and thus possible damage (even from accidental errors).

= Creating a new user =

{{Warning|If using a '''"diskless" or "data" disk mode''' installation, it's important to make the <code>/home</code> directory persistent.
 
* Either the <code>/home</code> filesystem needs to be mounted from a writable partition, or
* the /home directories have to be added to the lbu backup, and a new local backup needs to be committed after creating the user:
{{Cmd| # lbu include /home
# lbu commit
}} (Not recommended, as reverting to an older .apkovl will also revert the files in /home).
}}

Regular user accounts can be created with:
{{Cmd|# adduser [-g "<Full Name>"] <username>}}

By default, adduser will:
* prompt you to set a password for the new user
* create a home directory in {{Path|/home/<username>}}
* set the shell to the one used by the <code>root</code> account (ash by default)
* assign user ID and group ID starting at 1000
* set the GECOS (full name) field to "Linux User,,,"

{{Tip|The optional <code>-g "<Full Name>"</code> above sets the GECOS field.
This can be very useful to specify. Setting this string - at least equal to the username - makes the user distinguishable, e.g. when they are listed at the login screen of a display manager.
}}

'''Only''' if <code>elogind</code> is not being used and running, then X users would need to be added to the video and input groups to be able to work with a graphical display.
adduser 'UserName' video
adduser 'UserName' input

'''If a user ''really must'' be allowed to have access to the root account''', the <username> can be added to the wheel group, <code>doas</code> ("do as") may be installed, and the group "wheel" can be allowed to become root:
adduser -g "<username>" <username>
adduser <username> wheel
apk add doas
apk add nano
nano /etc/doas.conf

{{Warning|It's recommended to '''not''' run complete applications, like editors, as root just to modify administrative files.
 
* Many desktop environments and file browsers support using <code>admin:///</code> in their address bars, to access files through a local gvfs-admin mount
* [https://github.com/AN3223/scripts/blob/master/doasedit <code>doasedit</code>] or <code>sudoedit</code> enables starting an editor with a temporary copy of a file, which overwrites the original file after the user modifies and saves it. For example, <code>sudoedit /etc/apk/lbu.conf</code>
}}
The <code>sudo</code> package is an alternative to using the BSD-like <code>doas</code>, but is a much larger package.
It may be used as follows: adding a custom user configuration file to avoid having to deal with manually changing configuration files later during package upgrades.
apk add sudo
NEWUSER='yourUserName'
adduser -d "${NEWUSER}" $NEWUSER
echo "$NEWUSER ALL=(ALL) ALL" > /etc/sudoers.d/$NEWUSER && chmod 0440 /etc/sudoers.d/$NEWUSER

The new user gets listed in

{{Cat|/etc/passwd|root:x:0:0:root:/root:/bin/ash
.
.
.
<username>:x:1000:1000:Linux User,,,:/home/<username>:/bin/ash}}

Now you should be able to issue the command <code>exit</code> and login to the new account.

= Options =

=== adduser ===

Usage (from "man busybox"):

<pre><nowiki>adduser [OPTIONS] USER [GROUP]

Create new user, or add USER to GROUP

-h --home DIR Home directory
-g --gecos GECOS GECOS field
-s --shell SHELL Login shell named SHELL by example /bin/bash
-G --ingroup GRP Group (by name)
-S --system Create a system user
-D --disabled-password Don't assign a password, so cannot login
-H --no-create-home Don't create home directory
-u --uid UID User id
-k SKEL Skeleton directory (/etc/skel)
</nowiki></pre>

{{Tip|Multi-user collaboration
If <nowiki>--ingroup</nowiki> isn't set, (default) the new user is assigned a new GID that matches the UID. If the GID corresponding to a provided UID already exists, adduser will fail.

This ensures new users default to having a "user's private group" (UPG) as primary group. These allow the system to use a permission umask (002), which creates new files automatically as group-writable, but only by the user's private group. In special set-group-id (collaboration) directories, new files can be automatically created writable by the directory's group.
}}

=== addgroup ===

Usage (from "man busybox"):

<pre><nowiki>addgroup [-g GID] [-S] [USER] GROUP

Create a group or add a user to a group

-g --gid GID Group id
-s --system Create a system group
</nowiki></pre>

= Legacy =

=== Common permission groups ===

(Taken from https://git.alpinelinux.org/alpine-baselayout/tree/group)

* '''disk''':x:6:root,adm needed only for use vith virtual machines and access to other partitions.
* '''lp''':x:7:lp needed for printing services and printers management.
* '''wheel''':x:10:root Administrator group, members can use <code>sudo</code> to run commands as root if enabled in the sudo configuration.
* '''floppy''':x:11:root Backward compatible group. Use only if access to special external devices is needed.
* '''audio''':x:18: Needed for audio listening and management of sound volume as normal user.
* '''cdrom''':x:19: For access to CD/DVD/BR writers and mounting DVD, BR or CD rom disk as normal user.
* '''dialout''':x:20:root Needed for dialing private connections and use of modems as normal user.
* '''tape''':x:26:root Needed if you're planning to use special devices for backup. Rare. Ususally used only on servers.
* '''video''':x:27:root For usage of cameras, more than one GPU special features, as normal user.
* '''netdev''':x:28: For network connections management as normal user.
* '''kvm''':x:34:kvm Only if a normal user will manage virtual machines via a GUI. Rare. Ususally used only on servers.
* '''games''':x:35: Needed if you want to play games. Especially if sharing scores between users.
* '''cdrw''':x:80: Needed to write RW-DVD, RW-BR or RW-CD disk on a disk writing device.
* '''apache''':x:81: Needed if you do development as normal user and want to publish locally on web server.
* '''usb''':x:85: Needed to access to special usb devices. Deprecated group.
* '''users''':x:100:games Needed if you plan to use common files for all users. Mandatory for desktop usage.

= Old newbie notes =

=== User creation and defaults ===

The following commands will set up root environment login, then assign a new password:

<pre><nowiki>
cat > /root/.cshrc << EOF
unsetenv DISPLAY || true
HISTCONTROL=ignoreboth
EOF

cp /root/.cshrc /root/.profile

echo "secret_new_root_password" | chpasswd
</nowiki></pre>

By default, remote management cannot be done directly with the root account. Because of SSH security we need to set up a remote connection account that will be used to switch to the root user via the su command, once connected.

Here's an example: create user named "remote" and a user named "general". We will set up a hardened, limited, user environment and create those two users:

<pre><nowiki>
mkdir -p /etc/skel/

cat > /etc/skel/.logout << EOF
history -c
/bin/rm -f /opt/remote/.mysql_history
/bin/rm -f /opt/remote/.history
/bin/rm -f /opt/remote/.bash_history
EOF

cat > /etc/skel/.cshrc << EOF
set autologout = 30
set prompt = "$ "
set history = 0
set ignoreeof
EOF

cp /etc/skel/.cshrc /etc/skel/.profile

adduser -D --home /opt/remote --shell /bin/ash remote

echo "secret_new_remote_user_password" | chpasswd

adduser -D --shell /bin/bash general

echo "secret_new_general_user_password" | chpasswd
</nowiki></pre>

{{Tip|"'''general'''" is the name of the user. That name MUST contain ONLY lowercase letters, NO spaces and NO symbols}}

Note that those users are created with minimal privilege settings.

== User management and system access ==

By default, a newly created user will not have enough privileges for most desktop purposes.

To add newly created users to groups that may come in handy for desktop useage, you run this command as root:

<pre><nowiki>
for u in $(ls /home); do for g in disk lp floppy audio cdrom dialout video netdev games users; do addgroup $u $g; done;done
</nowiki></pre>