Once you have prepared your media, you can boot from it. The boot will vary depending on the image type you have used. Live images use the GRUB bootloader. Device-specific images may use their own bootloaders, but typically it is U-Boot.
ISO images
UEFI systems
This may vary with hardware, but in general a properly created USB stick or CD/DVD disc should appear in the list of boot entries.
On the x86_64 architecture, you will typically get a selection
between UEFI and BIOS mode, assuming CSM is not disabled. Pick
whichever you prefer, but keep in mind that this affects things
such as bootloader setup when installing.
OpenPOWER systems
OpenPOWER systems use Petitboot. Simply boot your computer with the removable media inserted and the respective boot entries should appear.
Power Mac systems
Power Macs use their flavor of OpenFirmware. You can boot either from optical media or from USB.
For optical media, you can use the standard chooser which you can bring up by holding the Option (Alt) key, and ignore the rest of this section. USB media are somewhat more complicated.
To boot from USB, insert the USB stick in your Mac, power it on and as soon as the chime sounds, hold the Command + Option + O + F combo (Win + Alt + O + F on standard PC keyboards). Keep holding the keys until the OpenFirmware console appears:
Release keys to continue!
After you release the keys, a prompt should appear:
ok
0 >
IF you are lucky, the ud alias should be present already. You can list
the aliases with the devalias command. If the alias is already in place,
you can boot like this:
0 > boot ud:,\\:tbxi
If this does not work, you can try booting the GRUB image directly, like so:
0 > boot ud:,\boot\grub\powerpc.elf
The GRUB screen should come up, where you can choose the boot option.
Note that booting from USB or optical media may take a while, both to show the bootloader screen and to load the kernel.
Defining a device alias for USB boot
If the devalias command did not print a ud, you will have to define one
before you can boot.
List the device tree:
0 > dev / ls
The listing may be long and you may have to press Space to scroll further. A portion of the listing may look like this:
ffXXXXXX: ...
ffXXXXXX: ...
ffXXXXXX: /pci@f2000000
ffXXXXXX: /...
ffXXXXXX: /...
ffXXXXXX: /...
ffXXXXXX: /usb@1a
ffXXXXXX: /device@1
ffXXXXXX: /keyboard@0
ffXXXXXX: /mouse@1
ffXXXXXX: /device@2
ffXXXXXX: /keyboard@0
ffXXXXXX: /mouse@1
ffXXXXXX: /interface@2
ffXXXXXX: /usb@1b
ffXXXXXX: /disk@1
ffXXXXXX: /...
ffXXXXXX: /...
The part you are looking for is the /disk@1 under /usb@1b. On your machine
this may look different, but in any case it should be a disk under USB.
Once you have located the right part, add the alias. With the above example listing it would look like this:
0 > devalias ud /pci@f2000000/usb@1b/disk@1
Once you have made the alias, you can boot from ud as described above.
Qemu virtual machines
When using virtual machines, you can pass the image like this:
-cdrom /path/to/chimera.iso -boot d
Serial console
If you wish to use a serial terminal, you might have to do some additional setup, depending on the configuration.
In a lot of cases, the kernel will output to serial console
automatically, without doing anything. This is especially the
case if you don’t have a graphical output. However, if you do
not get kernel output on your serial terminal (i.e. if the
bootloader does appear but the kernel messages do not) you
will have to enable it manually, with the console= parameter.
On most x86_64 setups, this will be console=ttyS0.
On most POWER setups, console=hvc0 is what you want. On some
other POWER systems this might be console=hvsi0.
AArch64 and RISC-V systems vary. Refer to the documentation for your
system. Examples include ttyAMA0, ttyS2, ttymxc0, ttySIF0
and others.
The Chimera live images are set up to automatically enable a
login prompt (getty) for all consoles the kernel outputs to.
Picking the boot option
Console images come with two boot options, regular boot and RAM boot. The latter results in the whole system being copied to system RAM, while the former will create a writable overlay over a read-only mount.
The RAM option requires a large amount of memory. Unless you are sure, you should be using the regular option. The benefit of the RAM option is that the system will run faster, and especially for optical media, will not result in accesses to the media.
Desktop images come with additional boot options to force console
boot (the default is to boot into GNOME desktop with Wayland). It
is also possible to force X11 by editing the graphical boot option
and adding the nowayland kernel command line parameter, but keep
in mind that GNOME currently has issues under X11 with most accelerated
drivers (software rendering works fine, so you may use it on systems
with unaccelerated 2D framebuffers) which may result in it freezing
on the first frame. Therefore, it is highly recommended to always
use Wayland for GNOME (X11 works for other window managers/desktops).
Logging in
Once this is set up properly, you will be presented with a login prompt on console images. Graphical boots bring you directly to desktop without having to log in.
You will want to use anon or root as the user name (depending
on if you want a superuser) with the password chimera. If you
log in with anon, use the doas utility to gain superuser
privileges.
Device images
Device images are pre-made so that they boot out of box on whichever device they made for.
There is no regular user. Log in with root, password chimera. If
your device supports serial console, it should be set up and working
by default, so there is nothing to configure.
Device images never come with a graphical desktop environment, but you can install one if you need one.
If the media you have flashed the image to is your final boot media and you will not be installing anywhere else, you can skip directly to Configuration as there is nothing else to do.