ARM Installation Guide
This Installation Guide for ARM computers assumes some basic familiarity with GNU/Linux systems and utilities, especially the command line. Note that, dealing with ARM computers is more complicated than common x86 computers; because you will need to learn some some hardware specific knowledge.
- 1 Some hardware and booting background
- 2 ARM Hardware Support Status
- 3 Know your hardware
- 4 Bootloaders and their limitations
- 5 Setup your host system
- 6 Partition disks
- 7 Format the partitions
- 8 Mount the partitions
- 9 rootfs installation
- 10 Configure the system
- 10.1 Set host and hostname
- 10.2 Set timezone and locales
- 10.3 Generate initial RAM-disk
- 10.4 Configure speech support (for blind and visually impaired users)
- 10.5 Configure pacman
- 10.6 Service management
- 10.7 Setup users, groups, and passwords
- 10.8 Final steps
- 11 Installing the bootloader
- 12 Update the system
- 13 Un-mount and reboot
- 14 Conclusion
- 14.1 Adding support for an ARM computer in Parabola
- 14.2 See also
- 14.3 Troubleshooting
- 14.3.1 Mkinitcpio
- 14.3.2 Iceweasel
- 14.4 Acknowledgement
1 Some hardware and booting background
It's best to begin with some basic concepts and definitions, which are used throughout this installation guide.
1.1 System on a chip
In most of the ARM computers, the Central Processing Unit (CPU) and many peripherals are consolidated into a single Integrated Circuit "chip" (IC). Such a chip is conventionally called: 'System On A Chip' (SoC); because it provides all common functionality of a typical personal computer system. Besides the CPU, it often contains:
- A graphics processing unit (GPU)
- A display controller (eg: HDMI,VGA)
- One or more USB host controllers
- An USB OTG/Device controller
- An SD-card controller
- A serial port controller
- Other miscellaneous peripherals
1.2 Boot ROM and booting
Most Systems on a Chip have machine code instructions hard-wired as Read-Only Memory (ROM), which are the first instructions executed when the machine is powered-on. Conventionally, this hardware is known as: 'boot-rom' or 'BROM'; and the process is referred to as: the 'boot0' boot stage.
The BROM is responsible for initializing the SoC hardware, and locating and fetching the user-replaceable second-stage boot-loader ('boot1') from among a set of predefined storage devices (eg: internal flash, removable SD-card). Often it is also possible to load a boot-loader via a standard 'Universal Serial Bus On-the_Go' (USB-OTG) or RS232 (serial) port.
The boot-loader then does some more (device specific) hardware initialization, then loads the operating system, and cedes control to the kernel.
In order for the BROM to detect a boot-loader on some external storage device, the device must be supported by the BROM. For instance, the Allwinner SoC BROM supports booting from eMMC/SD/microSD cards and SPI/NAND flash chips, but not SATA hard disks and solid-state drives.
The set of storage devices and their order of precedence, can often be configured by hardware and/or software.
2 ARM Hardware Support Status
Given the bewildering variety of computers and devices in the "ARM Zoo", Parabola can not claim to support all hardware, as completely as the more common "garden variety" x86 hardware. In addition to basic software support, Parabola also maintains a list and detailed install guides for a small set of the Parabola Recommended ARM Computers, which are deemed to be highly desirable from a software/hardware freedom perspective, and are designated with high-priority support status. Each of these are in the possession of at least one active Parabola team member; which is an essential requisite for bug-triage, trouble-shooting and bug-squashing. Given that most of the available options are comparable in computing power and cost, this limited set of recommended hardware, also helps users to decide among such an assortment, differing mainly in minutia, obscured with technical jargon.
Some ARM devices have integrated non-free boot-loaders. While they could technically run Parabola, they are not supported or endorsed by Parabola. Parabola only supports ARM devices which can boot with 100% a free software boot-loader and firmware. This has several advantages for Parabola users:
- If an ARM device is supported by Parabola software, we can ensure that it can boot with free software; though not all components may function perfectly.
- Companies and bloggers can not claim that any device which requires any non-free software to boot, is supported by Parabola. Of course it may work; and it is quite understandable for someone who already has such a computer, to want to run a mostly free system on it. However, the Parabola team members would discourage people from purchasing any computer which requires non-free software. It could not run a pure Parabola system; and the people who explain or endorse that use-case, would be the ones responsible for maintenance and support.
- As the boot-loader/OS interface evolves, we can update every component (the installation guides, the software, and configurations) to work well together.
2.1 Freedom status
Single-board computers (SBC) typically run some variant of the GNU/Linux system, but that alone does not imply that you have total software freedom while using these boards. Boards which are "Respects Your Freedom" (RYF) or "Open-Source Hardware" (OSHW) certified, though there are currently few complete examples, are categorically better for Freedom.
- Many ARM computers (such as the popular "raspberries") do not work without running a non-free startup program.
- Most mass Storage devices (HDDs, SSDs, microSD, eMMC, USB sticks) have internal non-free firmware to function.
- At least Some keyboards have firmware, maybe some mice too.
- Some displays also have internal firmware while some other don't.
Besides the firmware mentioned above, which are often invisible and in the peripheral themselves, many ARM computers can be used with 100% free software. This however does not mean that every hardware component and special feature is fully supported by free software. For instance, just as with x86 desktops and laptops, graphics acceleration and WiFi are functional on some, but not others; so it is best to do some research and choose your hardware accordingly. See the Article on the single-board-computers at the FSF for more details on the topic. Beware that the article on the single-board-computers at the FSF also covers devices that do not have an ARM CPU, and that are not supported by Parabola because of that.
2.2 64bit ARM
While there are no aarch64 (ARM 64bit) version of Parabola yet, it's still possible to use Parabola on some devices that have 64bit ARM CPU. To do that you will need to use Parabola/armv7h with the special linux-libre-64 kernel. The standard armv7h ARM kernels will not work as-is, for various reasons:
- The device tree for 64bit devices are not present in the 32bit kernel packages
- Many drivers and hardware support for 64bit ARM hardware are probably be missing in the 32bit kernel configurations, so they are probably missing in the 32bit kernel packages as well.
To install linux-libre-64, first you need to enable the 'kernels' repository in /etc/pacman.conf:
[kernels] Include = /etc/pacman.d/mirrorlist
Then install linux-libre-64:
pacman -Sy linux-libre-64
However there are still some limitations:
- This can only work for devices with a CPU which supports 32bit mode. Some 64-bit ARM CPUs do not.
- Special boot-loaders must be packaged for aarch64 devices.
Currently, aarch64 support was tested on a single board computer, ehich had an integrated u-boot boot-loader. Once the kernel was installed, the following configuration file: /boot/extlinux/extlinux.conf was used to boot the hardware:
timeout 1 default linux-libre-64 label linux-libre-64 kernel /boot/vmlinuz-linux-libre-64 append loglevel=8 systemd.show_status=false rw root=/dev/mmcblk0p1 fdtdir /boot/dtbs/linux-libre-64 initrd /boot/initramfs-linux-libre-64.img
When choosing an ARM device, you should take into account, the state of software support in upstream projects. The project with the most important hardware support is Linux/Linux-libre kernel.
- Allwinner - The linux-sunxi wiki has some generic information regarding Allwinner support in Linux; and information regarding specific Allwinner-based boards.
Device vendors typically ship an old version of the Linux kernel, which they have modified to support their specific hardware. That is not ideal with respect to software freedom; because that makes it more difficult for users to replace their kernel; and it is not always clear where those custom changes are published (if at all). The Free and OpenSource software communities are actively working, to add support for more ARM devices, directly to the Linux kernel project.
If the device which you want to get, is not supported upstream (and that you don't intend to add such support yourself), you should rather consider other devices. If your device requires a kernel version that is much older than the one in your GNU/Linux distribution's repositories, it may be unusable; because some essential software (eg: systemd) is strongly coupled to kernel releases. Also, the kernel is not likely to be updated indefinitely by the device vendor; so even if the vendor kernel is working currently, it still may become unusable in the future, unless you also keep the same OS release indefinitely. If that OS is on a rolling release schedule (such as Parabola), that means never upgrading the system.
Bootloaders are less a concern, as you might be able to workaround the lack of support of modern filesystems and partitions. However finding why your device does not boot can be painful, so it's strongly advised to get devices which are support in upstream Free and Open source bootloader projects.
3 Know your hardware
ARM devices can be very different, and this has implications on the way you will install Parabola.
More specifically you will need to know:
- From which storage device(s) your device can boot. Most supported devices can boot from a microSD card. Knowing the order in which it tries to boot on the storage devices, can also be useful, as it helps you understand what is going on, if your device is not booting. Knowing the partitioning/filesystem boot requirements, can also be handy in that case, especially if they are not mentioned in this installation guide. If so, it would be nice if you could add them in this guide.
- Obtaining insight, as to why the system may not be booting:
- Not all devices can be connected to a display, and when they can, the display is not necessarily available early at boot.
- Some devices have an easily accessible serial port that can act as a display + keyboard replacement.
- The state of the software support for your device:
- What hardware components have kernel support, and which do not
- The limitations of the boot-loader (and it's version)
For boards which high-priority support by the Parabola team, refer to the Parabola Recommended ARM Computers article.
In addition, the Computers article also lists other ARM computers which need a bit more work in Parabola and/or this installation guide. Note that some of them they might already contains enough information to be installed by more experienced people, but lack information on the status and so on. Make sure to read the page for your device, if there is one, as those contains device-specific information, which may be important for a successful Parabola installation.
For other boards, here are some links to such information:
4 Bootloaders and their limitations
Parabola currently supports only the u-boot bootloader for ARM machines.
u-boot supports the EXT2, EXT3, and EXT4 filesystem,. However, at the time of writing, the versions used in Parabola do not support all 'extensions' of the ext4 filesystem. If you use unsupported EXT4 extensions on Parabola, you would usually be able to list the filesystem content with ext4ls or similar commands, but some files may be unreadable. This is not a problem for the root filesystem, if that is a separate partition from /boot; but for the /boot filesystem, u-boot will output some errors at boot; and booting will fail.
To avoid using unsupported extensions on the /boot partition, it is recommended that you format with this command:
mkfs.ext4 -F -O ^metadata_csum,^64bit /dev/<DEV_PART>
To see which extensions you have, you can use the following command:
tune2fs -l /dev/<DEV_PART>
TODO: Check the commands below to remove unnecessary fsck:
Existing EXT4 filesystems can also be converted, to remove metadata_csum:
fsck.ext4 -C 0 -f /dev/<DEV_PART> tune2fs -O ^metadata_csum /dev/<DEV_PART> fsck.ext4 -C 0 -f /dev/<DEV_PART>
And for removing 64bit:
fsck.ext4 -C 0 -f /dev/<DEV_PART> resize2fs -s /dev/<DEV_PART>> fsck.ext4 -C 0 -f /dev/<DEV_PART>
5 Setup your host system
The ARM install methods described in this guide, require the use of another working computer (we will refer to this as the "host system"), and some hardware or cables, which allow it to access the storage medium, from which the ARM computer will boot (eg: a micro-SD-card).
Install the arch-install-scripts package:
pacman -S --needed arch-install-scripts
6 Partition disks
The choice of partitioning tools and layouts is a matter of preference, and beyond the scope of this install guide. See the partitioning guide for details and suggestions.
Remember to create any stacked block devices like LVM, LUKS, or RAID, if you choose to use those advanced partitioning technologies. You will also need to generate an initramfs and configure your bootloader properly to use it. Be aware that these all add complexity to your system, and therefore the potential for problems. Per the KISS principle, most people should not bother with them; but rather prefer a simple schema (eg: a MBR partition table, a single partition per OS).
If your ARM computer will use a bootloader provided by Parabola (eg: uboot4extlinux), you will need to use an MBR and not GPT. With MBR, most partitioning tools like fdisk, sfdisk, and gparted reserves a 1MiB space un-partitioned (empty), before the first partition, by default. This is of critical importance; because, bootloaders typically are installed within this 1MiB gap.
7 Format the partitions
The choice of filesystems is a matter of preference, and beyond the scope of this install guide. See the filesystems guide for details and suggestions.
You will most likely need to use a filesystem supported by your bootloader. Do not use any unsupported filesystem features for the files in /boot. For uboot, EXT4 has worked well in our tests (use the command in the 'uboot' section above).
Some System on a chip may also require the bootloader to reside on a specific partition. (For that case, the 1MiB empty space would be unused).
8 Mount the partitions
Next, you must mount the target partitions. This guide uses /mnt as the mount-point of the root ('/') filesystem.
# mount /dev/<DEV_PART_2> /mnt # root ('/') filesystem (eg: /dev/mmcblk0p2)
You should also create directories as mount-points for, and mount onto them, any optional partitions which you created in the "Partition disks" and "Format the partitions" sections (eg: /mnt/boot, /mnt/home, ...). The /home and swap partitions are not essential in this step; but if you created them, and you want them to be auto-mounted when the new system boots, you should mount them now also. eg:
# mkdir /mnt/boot # mount /dev/<DEV_PART_1> /mnt/boot # boot ('/boot') filesystem (eg: /dev/mmcblk0p1) # mkdir /mnt/home # mount /dev/<DEV_PART_3> /mnt/home # boot ('/home') filesystem (eg: /dev/mmcblk0p3) # swapon /dev/<DEV_PART_4> # swap filesystem (eg: /dev/mmcblk0p4)
9 rootfs installation
You can either install the rootfs:
- from the released tarball (faster, and easier)
- bootstrapped with pacstrap (slower, but more versatile)
If your ARM computer normally boots from a removable storage (eg: micro-SD-card is very common). the simplest way to install Parabola is by downloading the pre-made release system from Parabola, onto your host system, then copying it onto the removable storage, from which the ARM computer will boot. Alternatively, you may also elect to install via the standard bootstrap method (eg: using pacstrap), for special use-cases. The two options accomplish essentially the same task. Whichever of the two options that you choose, skip one of sections below, whichever corresponds to the other option.
9.1 Using the release tarball
This is the simplest install method. For a customized install, skip ahead to the "Using pacstrap" section.
Download and verify the Parabola ARM Release tarball
- The release tarballs are signed and it is highly recommend to verify their signature before use. On Parabola GNU/Linux-libre, this can be done by using pacman-key -v <tarball-file>.sig. On other systems: gpg --verify <tarball-file>.sig. You may have to import the key from a keyserver with gpg --recv-keys <0x key ID>.
- Checksums are also provided in the accompanying SHA512SUMS and WHIRLPOOLSUMS files. They can be verified with: sha512sum -c SHA512SUMS and whirlpool-hash -c WHIRLPOOLSUMS.
After mounting the filesystem, which is to be your ARM computer's rootfs ('/' partition) onto the host system (eg: the /mnt directory), extract the Parabola rootfs onto it:
$ sudo tar xpf <tarball-file> -C /mnt/ --numeric-owner
Here --numeric-owner is used to avoid permissions problems during the install procedure, if for example, the user and group ids differ between the tarball system and the host system. This may be the case if the host system is some GNU/Linux distribution other than Parabola (eg: Trisquel).
Skip ahead now, to the "Configure the system" section
9.2 Using pacstrap
9.2.1 Prepare your host system
A bit more preparation is needed for the pactrap install method.
The host system will need to have the ArchLinuxARM keyring installed; because when possible, Parabola leverages libre packages published by the ArchLinuxARM team.
# pacman -S --needed archlinuxarm-keyring
Pacstrap will perform some of it's magic by "chrooting" into the the target filesystem. If your host system has a CPU other then ARM (eg: it it running Parabola x86_64 or i686), the qemu-arm-static binary will need to be accessible from within the target filesystem:
# pacman -S qemu-user-static-binfmt # mkdir -p /mnt/usr/bin # cp /usr/bin/qemu-arm-static /mnt/usr/bin
Next, instruct the kernel to leverage QEMU, whenever a foreign-arch binary is loaded. How this is done, depends on the target init-system:
- Parabola/SystemD host systems:
# systemctl start systemd-binfmt.service
- Parabola/OpenRC host systems:
Once this is done, programs such as pacstrap, arch-chroot, and chroot will be able to execute ARM code inside the chroot transparently, as if they were native binaries.
If you plan for the target system to use the same init-system as the host system, then you can skip this step. In order to install openrc as the init-system, the [nonsystemd] repo must be enabled on the host system before proceeding. In order to install openrc as the init-system, the [nonsystemd] repo must NOT be enabled.
[nonsystemd] enabled in /etc/pacman.conf:
[nonsystemd] Include = /etc/pacman.d/mirrorlist
[nonsystemd] disabled in /etc/pacman.conf:
#[nonsystemd] #Include = /etc/pacman.d/mirrorlist
9.2.3 Bootstrap Install
Now, you are ready to install the base system using pacstrap. Choose ONE of the following commands:
First, let's set an alias here, just to make the instructions more concise.
# alias pacstrap='pacstrap -C /usr/share/pacman/defaults/pacman.conf.armv7h'
# pacstrap /mnt/ base
# pacstrap /mnt/ base libelogind udev-init-scripts
You can install additional packages by passing the package names as extra arguments, or by running pacstrap again. For example, if you have a BTRFS root, you probably want to install btrfs-progs. eg:
# pacstrap /mnt/ btrfs-progs # BTRFS filesystem support # pacstrap /mnt/ pro-audio # pro-audio work-station # pacstrap /mnt/ lxde iceweasel octopi # graphical desktop
10 Configure the system
Generate an fstab with the following command (if you prefer to use UUIDs or labels, add the -U or -L option, respectively):
# genfstab -p /mnt >> /mnt/etc/fstab
Next we chroot into our newly installed system:
# arch-chroot /mnt
10.1 Set host and hostname
Add the following text to /etc/hosts, in the following form:
127.0.0.1 localhost ::1 localhost 127.0.1.1 MY_HOSTNAME.localdomain myhostname
If the system has a permanent IP address, the final ('MY_HOSTNAME') entry should refer to that, instead of 127.0.1.1.
Replace 'MY_HOSTNAME' with your preferred host name. Your computer's hostname can be anything that you like, consisting of letters a-z, digits 0-9, and hyphens '-' (eg: alices-laptop). The system hostname is mainly informational, making it easier to distinguish computers on your local network. This name will also appear in your shell prompt - eg:
On a systemd system, add the same chosen hostname to /etc/hostname, in the following form:
On an OpenRC system, add the same chosen hostname to /etc/conf.d/hostname, in the following form:
10.2 Set timezone and locales
- Symlink /etc/localtime to /usr/share/zoneinfo/Zone/SubZone. Replace Zone and Subzone to your liking. For example:
# ln -sf /usr/share/zoneinfo/Europe/Athens /etc/localtime
- Set locale preferences in /etc/locale.conf
- Add console keymap and font preferences in /etc/vconsole.conf when using systemd, or in /etc/conf.d/keymaps and /etc/conf.d/consolefont when using OpenRC.
- Uncomment the selected locale in /etc/locale.gen and generate it with locale-gen
10.3 Generate initial RAM-disk
- If you need special boot features, such as for disk encryption, configure /etc/mkinitcpio.conf accordingly (see mkinitcpio). In any case, re-generate the initial RAM-disk with:
# mkinitcpio -p KERNEL
... where: KERNEL is the one that you chose in the "Install a kernel" step (eg: linux-libre, linux-libre-lts). If you have installed multiple kernels, run the same command again for each kernel.
10.4 Configure speech support (for blind and visually impaired users)
If you are using TalkingParabola and need start speech support when you boot the system, you will need to do:
- Install espeakup and alsa-utils.
- Save the state of the sound card, so that it will be retrieved on reboot:
# alsactl store
- Enable the espeakup systemd service by executing:
# systemctl enable espeakup.service
- Enable the espeakup systemd service by executing:
# rc-update add espeakup default
10.5 Configure pacman
Edit /etc/pacman.conf and configure pacman's options, also enabling the repositories you need.
If you are running systemd rather than OpenRC, make sure that the nonsystemd repo is NOT enabled.
If you are running OpenRC rather than systemd, make sure that the nonsystemd repo is enabled.
Also consider using Pacman2pacman, a peer to peer package system, in order to reduce load on official Parabola servers.
10.6 Service management
Most casual desktop users would rarely need to interact with the service manager; but it is a good idea to learn the basics. The process is the same, now while in the chroot, and afterward during normal use.
Interaction with systemd is done through the systemctl command. Read a:systemd#Basic systemctl usage for more information.
Systemd services normally must be manually "started" and/or "enabled" for auto-start. Interaction with OpenrRC is done through the rc-update, rc-service, and rc-status commands.
Newly installed services will need to be added to specific runlevels. The 'default' runlevel is the only one that most users will need. Note, however, that essential services are enabled by default (e.g. dbus, elogind, opensysusers and opentmpfiles). You will need to "chroot" into the target system first, in order to accomplish this. That will normally not be necessary, once the system is installed and running.
To activate the 'NetworkManager' service, for example:
# rc-update add NetworkManager default
10.7 Setup users, groups, and passwords
Set a root password with passwd:
Create an unprivileged (normal/everyday) user login (replace '<YOUR_USER_NAME>'):
# useradd -m <YOUR_USER_NAME> # passwd <YOUR_USER_NAME>
Add your user to any special groups, if needed. eg:
# gpasswd -a <YOUR_USER_NAME> wheel
See User management for advanced examples of users and groups.
There are no special requirements for users and groups with a Parabola/systemd system.
A Parabola/OpenRC desktop system requires unprivileged users to be in some extra permission groups. See the OpenRC article for details.
10.8 Final steps
Additional networking configuration may be needed for graphical wifi managers and other network management tools. See a:Network configuration and Wireless Setup; or ask for help on IRC, on the web forum, or on the mailing list, if you would like suggestions.
There are some subtle caveats to be aware of regarding OpenRC, in some system configurations, which have not been mentioned in this guide. The OpenRC article has some trouble-shooting advice for the most common problems. If you have a problem initially, with using your new OpenRC system, please read that article, first before reporting bugs.
11 Installing the bootloader
11.1 Bootloader provided by parabola
Parabola provides bootloaders for many devices. If parabola has one for your ARM computer, you can simply chroot and install it:
# arch-chroot /mnt # pacman -S uboot4extlinux-a20-olinuxino-lime2 resolving dependencies... looking for conflicting packages... Packages (1) uboot4extlinux-a20-olinuxino-lime2-2017.01-1.1 Total Download Size: 0.20 MiB Total Installed Size: 0.53 MiB :: Proceed with installation? [Y/n] [...]
However merely installing the package isn't sufficient to make the device boot from that bootloader.
This is the same than with x86 computers: on x86 computers, after installing the GRUB package, you also need to install GRUB itself, so that the BIOS or UEFI could find GRUB and run it.
Here all the ARM computers supported by Parabola have an ARM system on a chip with a bootrom (the bootrom is is read-only ARM code inside the silicon). At power on, that bootrom will be executed and will try to fetch the bootloader from various locations on various storage device (microSD, eMMC, etc) and execute it. See the Bootrom and booting section for more details.
So like with x86 computers, we need to install the bootloader to specific locations on the storage device for it to be found and executed.
This is why at the end of the package installation, you will be asked if you want to do that. It will look like that:
A new U-Boot version needs to be flashed onto /dev/mmcblk0. Do you want to do this now? [y|N]
If you are installing on an x86 system, your sd card may be available at /dev/sdb. Find the exact location using command lsblk.
When that happens, double check that /dev/sdb corresponds to the storage device you're installing Parabola on and not your x86 laptop hard disk or SSD you are installing from.
This is where the 1MB space comes into play. Your bootloader will be stored in those 1MBs. Write the bin file using the dd command over your complete card.
dd if=/boot/u-boot/images/u-boot-sunxi-with-spl.bin of=/dev/sdb bs=1024 seek=8
The installation of u-boot bin file will give a prompt like the one shown below:
526+1 records in 526+1 records out 539287 bytes (539 kB, 527 KiB) copied, 0.165519 s, 3.3 MB/s ==> WARNING: Remember to set up your kernels in /boot/extlinux/extlinux.conf
Now, you need to edit /boot/extlinux/extlinux.conf to make it boot. For most cases, default extlinux.conf files works well if your kernel lies at 1st partition. If your root filesystem lies at different partition, edit the /dev/mmcblk0p1 with the corresponding partition (eg: the 'N' in /dev/sdbN partition as seen on the host system, will correspond to the same 'N' in mmcblk0pN on the target ARM board. eg. sdb2 -> mmcblk0p2, when the ARM system is running on the hardware).
Several bootloaders are available in Parabola.
All the u-boot4extlinux packages implement the distroboot protocol.
The distroboot protocol is meant to be able to boot multiple distributions with the exact same u-boot binary and also enable distributions to support a large number of ARM computer without having to make specific changes to boot each of them.
That standard also supports syslinux configuration files among other ways to boot.
This is really nice as that configuration file format is also used by Extlinux and Syslinux on x86 computers.
While Extlinux and Syslinux are well known and used than GRUB on x86 computers, they are still used as the bootloader in live CDs and many other applications, so there is pretty good information on their configuration file format.
They also allow for interactive multi-boot and multiple kernels.
To successfully boot the extlinux.conf needs to be in /extlinux/extlinux.conf or /boot/extlinux/extlinux.conf in the first partition or a partition that has the bootable flag set.
If needed, the bootable flag can be set with sfdisk. Below is an example to set the bootable flag to the second partition:
# sfdisk /dev/CARD -A 2
Here /dev/CARD needs to be replaced by the path of the SD-card, which could be /dev/mmcblk0 if you use a 'native' SD reader, or /dev/sdb for instance if you have an 'usb mass storage' SD reader.
In addition that partition needs to be readable by u-boot. So if u-boot doesn't support BTRFS for instance it would be better to create a /boot partition so that extlinux.conf could be installed in it.
For more details see the distro boot protocol documentation in u-boot source code.
Installing the appropriate U-Boot package will copy the bootloader to your storage device's boot sector. Manual intervention shouldn't be necessary.
Once installed, you will need to run the following command to configure it:
# cd /boot && ./mkscr
uboot4grub packages are under development yet for U-Boot with GRUB support. At the moment, we have some packages for testing and debugging from [libre-testing].
11.1.5 Which bootloader package to use for which device?
Here's a list of devices with their corresponding bootloaders packages:
|Computer(s) (vendor, product)||Bootloader(s) packages||Bootrom constraints|
There are many more devices supported, a quick search in Parabola's packages shows many more bootloaders
11.1.6 Bootloader configurations
Our kernel images use custom names (eg. /boot/vmlinuz-linux-libre-grsec) to allow for various kernels to coexist via a multi-boot bootloader like GRUB or Extlinux. You really need to verify that your bootloader is configured to look for the right kernel name.
For instance for extlinux, it can be done by adding an initrd line, which would meake an entry look like that:
label Parabola GNU/Linux-libre, linux-libre kernel kernel /boot/vmlinuz-linux-libre initrd /boot/initramfs-linux-libre.img append console=ttyS0,115200n8 quiet rw root=/dev/mapper/vg-rootfs fdtdir /boot/dtbs/linux-libre/
11.2 Bootloader not provided by parabola
- See Barebox
11.2.2 Already present on the device
12 Update the system
If you installed via the ARM Release Tarball or one of the "Complete" LiveISOs, you could upgrade the fresh system now. Otherwise, the fresh system is already up-to-date.
# pacman -Syu
13 Un-mount and reboot
Exit the chroot, then un-mount any partitions which you mounted in the "Mount the partitions" step. Then you can reboot and login to the new system normally.
# exit # swapoff /dev/<DEV_PART_4> # if you mounted a swap partition (eg: /dev/mmcblk0p4) # umount /mnt/boot # if you mounted a separate /boot partition # umount /mnt/home # if you mounted a separate /home partition # umount /mnt # you surely mounted a / partition # reboot
Your new system is now fully functional Parabola GNU/Linux-Libre environment. Welcome to Fosstopia.
14.1 Adding support for an ARM computer in Parabola
To add support for a new ARM computer in Parabola:
- That computer needs to be able to boot with free software
- The installation instructions need to explain how to install Parabola on it
- The bootloader should be packaged if it needs to be provided by Parabola
In addition if we want to continue supporting that device for a long time:
- It should work with upstream Linux without any additional patches
- For the bootloader if Parabola provides it it would also be a good idea for it to work without any patches
- Parabola developers and users need to be able to get that device too somehow, in order to be able to test any changes on it.
14.2 See also
22.214.171.124 WARNING: No modules were added to the image. This is probably not what you want.
If when creating the initramfs image with mkinitcpio, you get the message
==> WARNING: No modules were added to the image. This is probably not what you want.
Just ignore, you should be able to boot anyways.
126.96.36.199 ERROR: kernel version extraction from image not supported for `armv7' architecture
If when running mkinitcpio you get the message
ERROR: kernel version extraction from image not supported for `armv7' architecture
Or similar (like armv7h, armv7l, etc) edit /bin/mkinitcpio and where it says $arch leave it as
if [[ $arch != @(i?86|x86_64|armv7?) ]]; then error "kernel version extraction from image not supported for \`%s' architecture" "$arch"
188.8.131.52 ERROR: invalid kernel specified: '/boot/vmlinuz-linux-libre'
In this case edit /etc/mkinitcpio.d/linux-libre-xxx.preset and where it says ALL_kver="/boot/vmlinuz-linux-libre-xxx" change /boot/vmlinuz-linux-libre-xxx with the kernel release, which should be the output of uname -r, if you are using that kernel. You can see them with
$ ls /lib/modules
184.108.40.206 Error code: NS_ERROR_NET_INADEQUATE_SECURITY
If some websites give you this error on Iceweasel (an probably on Icecat) with a message like:
Your connection is not secure The website tried to negotiate an inadequate level of security. www.example.com uses security technology that is outdated and vulnerable to attack. An attacker could easily reveal information which you thought to be safe. The website administrator will need to fix the server first before you can visit the site. Error code: NS_ERROR_NET_INADEQUATE_SECURITY
Then open a new tab and write about:config, then search spd and disable network.http.spdy.enabled