This part assumes that you have decided to install Chimera on a disk and that you have managed to successfully boot the media and log in to it.
When installing onto devices that use device images instead of live ISOs, an alternative to partitioning and installing the system manually is to get the image again and flash it to the target media the same way as you flashed it onto the SD card. To do that, follow the Preparing media page again. Do note that this comes with reduced flexibility regarding e.g. choosing your filesystems.
If you are installing manually, you will need to partition your target drive. This will differ depending on your architecture and system firmware, but some parts will always be the same.
If you wish to use Disk encryption, that will influence the way you partition your drive.
Let’s assume that the target disk drive is
/dev/sda. Let’s start
with wiping everything on it:
# wipefs -a /dev/sda
If there was LVM on the drive before, this might fail with an error
Device or resource busy. This is because the volume group
might have gotten set up on boot. In such cases, you will want to
bring it down, e.g. with:
# vgchange -an
wipefs -a should work. You might have to perform
similar things for
mdadm and so on.
In any case, once you have wiped the drive, the easiest way to
initialize a partition table and create partitions is with the
cfdisk TUI program:
# cfdisk /dev/sda
If you wish to have your root file system on ZFS, please read this page and then go to Root on ZFS.
Legacy BIOS x86 systems
- Root filesystem partition
Partition table: MBR (DOS)
Legacy BIOS setups only strictly need one partition. Do keep in mind that if you have an NVMe SSD, you will be unable to boot from it. Linux will see the SSD, but the BIOS will not. Use UEFI for NVMe. In fact, use UEFI unless you really can’t.
MBR is limited to 4 partitions and 2 terabytes. When using BIOS, you should nearly always use MBR.
dos option in
cfdisk. Mark the partition containing
with the bootable flag.
GPT with legacy BIOS
It is possible to use GPT if you create a special partition sized
1MB with the type
BIOS boot (
and no filesystem at the beginning, which will allow the bootloader
to install. This may or may not work.
- EFI System
- Root filesystem
Partition table: GPT
UEFI is the system of choice on most modern x86_64 systems, as well as a variety of systems of other architectures such as AArch64 and RISC-V.
Create a partition of type
EFI System that is at least 200 megabytes.
Smaller partitions will usually work, but some firmware may have issues.
Outside of that, the partition layout is up to you.
- Root filesystem
Partition table: any (usually GPT)
OpenPOWER systems have an onboard bootloader that is a part of the system firmware, and run Linux as their system firmware. Therefore, they can use many different partition tables.
You will usually want GPT though.
PowerVM and other OpenFirmware POWER
- PowerPC PReP Boot
- Root filesystem
Partition table: MBR or GPT
Non-OpenPOWER systems of the POWER archictecture are usually this. Virtual machines (qemu) are usually also this. These systems use variants of OpenFirmware (IEEE1275).
The first partition should be of
PowerPC PReP Boot type and it should
have around a megabyte. Virtual machines and newer physical systems
will happily use either MBR or GPT, but you might want to stick with
MBR for compatibility.
- Root filesystem
Partition table: APM (Apple Partition Map)
Power Macs have a special partition table called APM, which needs a special tool to manipulate. Depending on the image or system you have booted, you may already have it. If not, you can install it, on Chimera using the following:
# apk add mac-fdisk
In any case, the bootloader must be on APM, in a bootstrap partition. The root filesystem partition can be on any partition table GRUB can handle, but if you are installing on a Mac disk, it will typically be the same APM.
mac-fdisk tool is used to manipulate the partitions. A typical partition
table may look like this:
In an APM, there is always an implicit first partition representing the APM itself.
You can create that layout like this:
# mac-fdisk /dev/sdX i # initialize partition table, wipes all data b 2p # bootstrap partition c 3p 120G rootfs # root filesystem c 4p 4p swap # swap partition, all unused space w # write q # quit
b command is equivalent to
C <x> 800k bootstrap Apple_Bootstrap.
This will wipe everything on the disk. That means it is suitable for clean installations, but if you wish to dual boot, you have to do a bit more work.
In this case, you will not be reinitializing your partition layout. Depending on how your disk is partitioned you may or may not be able to do this.
You can use the
p command to print the existing layout. You will need to
have free space, which should be marked
Apple_Free. If you have some free
space, you can create the bootstrap partition inside of it. If you do not,
you will have to delete a partition or shrink one to get some free space.
On installations with OS X, it seems to be common that you have
around 128MB scattered around. These gaps are a good place to create your
bootstrap partition. OS X does not need anything but its own HFS+ partition,
which acts as its own bootstrap.
Generally the layout of the disk does not matter as long as you have your bootstrap partition somewhere and then another partition (or more) for the root filesystem or others.
To make an example, given a layout like this:
In this context,
sdX3 is OS X,
sdX5 is an empty HFS+ formatted partition
you want to install the system in. The
sdX4 are just gaps, as is
You could do something like this:
# mac-fdisk /dev/sdX b 2p # bootstrap partition in first gap d 5p # delete the 50G Apple_HFS c 4p 46G rootfs # create root filesystem partition c 5p 5p swap # create swap partition w q
4p here as deleting the
Apple_HFS will merge the resulting
three gaps together, forming a single 4th partition.
Other configurations may need adjustments.
- Root filesystem
Partition table: MBR/GPT
For Raspberry Pi 3 you will need a MBR partition table, as the built-in firmware cannot deal with GPT (protective MBR hacks aside).
For Raspberry Pi 4, you can use GPT, while MBR will also work.
In both cases, you will need to have a partition for
/boot as the
first partition. On MBR, this needs to be marked bootable. On GPT,
it needs to be of type
Microsoft basic data or
EFI System, or
it will not be found.
- Typically an SPL partition
- Typically a U-Boot partition
- Root filesystem
Partition table: typically GPT
The specifics of U-Boot partitioning vary wildly, but in a typical case
the arrangement will be two small partitions for SPL and U-Boot, followed
/boot partition and a root filesystem.
Technically SPL and U-Boot usually do not need dedicated partitions, but it is better to create them for clarity. The alternative is to have only two partitions, making sure the first one starts at a sufficient offset not to conflict with the firmware, and then manually write the firmware into the empty space before at the right offsets.
Some devices do require actual partitions for U-Boot and SPL though, and
some even need them to be special partition types. For devices where they
are not needed, a good partition type to use is
Linux reserved which has
8DA63339-0007-60C0-C436-083AC8230908. For the
you might want to use the type
Linux extended boot which has the GUID
In any case, the specifics of your device partitioning should come with your device’s documentation. For devices that Chimera supports, known partition layouts can be found here.
In general, the root partition should be labeled
root for the default
cmdlines on most devices to work. If you don’t label it, you will have
to remove the pre-defined
root= parameter from
update-u-boot auto-generate a correct
root= instead (the
defaults include a static
root= to ease generation of generic SD card
If your device is in the above list, then you can save yourself some time manually partitioning the disk, and do something like the following:
# fetch https://raw.githubusercontent.com/chimera-linux/chimera-live/master/sfdisk/pbp # sed -i '' 's/@BOOT_SIZE@/512MiB/' pbp # sfdisk /dev/mmcblk2 < pbp
Doing this will take care of the labeling if necessary.
Of course, you will need to substitute the filename for your platform, the
boot partition size for whatever you like, and the
mmcblk2 for your target
device. You can also further edit the file for other adjustments. The default
arrangement should however be usable for most scenarios; when encrypting,
create your LUKS where the root partition would have been, and then either
create an LVM or a filesystem on that.
This is not required, but you might want one, depending on your system
RAM and other requirements (e.g. hibernation). The partition type should
A good amount is at least 4 gigabytes. The old guidelines for swap size based on your physical RAM no longer apply these days.
Note that if you are planning to use disk encryption with LVM, you will most likely want to make swap a part of your LVM, as swap can expose secrets.
You can also have a separate
/boot partition if you like and not already
mandatory. On EFI systems it is also possible to combine your
the ESP. That allows for the following layouts:
/bootand ESP separate (3 partitions)
- Root, combined
/bootand ESP (2 partitions)
- Root with
/boot, separate ESP (2 partitions)
It mostly comes down to your preference and special circumstances such as Secure Boot systems and the bootloader of choice.
Sometimes, you may need a separate
/boot because of your bootloader,
if the bootloader does not support your root filesystem of choice.
It may be a good idea to make the
/boot partition of type
Linux extended boot,
bc13c2ff-59e6-4262-a352-b275fd6f7172, when using GPT. This is for better
compatibility with some UEFI bootloaders.
This configuration is not supported in Chimera, as it’s a fully usrmerged system. Please do not attempt this.
This is up to you and can be used with all layouts.