The following process should theoretically be applicable to other U-Boot devices and GNU+Linux distributions, but the focus here is specifically on ArchGNU+LinuxARM.
Sources used for this guide include the [following guide to install ArchGNU+LinuxARM on a RockPro64,](https://jforberg.se/blog/posts/2023-02-19-rockpro64/rockpro64.html)
The purpose of this guide is to instruct users on how to install an ArchGNU+LinuxARM on an external disk that will boot on a gru_bob chromebook, and optionally on the internal eMMC. Many concepts covered in this guide may be familiar to prospective and veteran nonGeNUine Boot users, with the scope being comprehensive.
1) EFI - common, modern boot method for amd64 architecture machines. This is not distribution-specific, so if you intend to make a portable drive that is compatible across multiple systems, you may have a use case.
This is an unlikely use-case, so it's a bit odd to use an EFI partition when not using a UEFI system.
2) boot.scr - a boot script provided by a distribution. Since it is u-boot specific, you will only be able to boot your device from u-boot.
Despite still being distributed by some distros, boot.scr is a legacy boot method according to the u-boot docs:
"Typically we expect extlinux.conf to be used, but execution of boot.scr is maintained for backwards-compatibility."
For more information about what actually goes into a boot.scr script, check [this page in the u-boot documentation](https://u-boot.readthedocs.io/en/latest/usage/cmd/source.html?highlight=boot.scr#fit-image)
3) extlinux.conf - a flat, bootloader-spec text file that lives in /boot/extlinux/extlinux.conf. That's all. Not a binary blob in sight!
Since extlinux.conf is supported by multiple bootloaders, making your system more portable, is natively supported by u-boot, and requires no binary blobs or extra software, it seems to be the best choice for a chromebook.
Creating extlinux.conf
======================
Here is an example template of extlinux.conf, [similar examples are found in the u-boot docs](https://u-boot.readthedocs.io/en/latest/develop/distro.html):
The nonGeNUine Boot configuration will boot the microSD card above the onboard eMMC if both are present and bootable. This is useful because it means no knowledge or use of the u-boot console is required.
Since the eMMC is 16GB of storage space, it's advisable to choose an external storage disk of less than 16GB if you intend to install onto the onboard storage, or to create a root partition of less than 15.8GB.
Find your device with my favourite command, `lsblk` and open it with `fdisk`
```
fdisk /dev/sdX
```
For users creating a bootable SD card, your device may show up as `/dev/mmcblkX` - if this is the case, make sure to change the commands in this guide to
contain that path instead of `/dev/sdX`.
In the fdisk tui, create two partitions on a Master Boot Record:
- create a new MBR label
- create boot partition of approx. 200MB or greater
- set bootable flag on this partition
- set type to fat32 (ext2 is also supported by extlinux I believe, but I used fat32)
in the template provided above, replace `$PARTUUID` with your own. It's possible to specify root in other ways - check the u-boot docs for more examples.
Boot-Disk Creation
==================
Now that we've got an extlinux.conf file, copy it to your /tmp directory, and we'll begin.
If you create an extlinux.conf file with paths to both images - like in the template above - you can select either by number at boot.
Going Live - Necessary Tweaks
=============================
Once you're at the login prompt, the fun isn't over! Login & password for root are both `root` by default.
Most Arch users will likely try to update their system now - don't update just yet.
Run `lsblk` and you'll see that the boot partition is not mounted by default.
Updating with `pacman -Syu` at this stage will cause driver problems if you update without your boot partition mounted, likely meaning you cannot connect to the internet with a USB peripheral.
To prevent this becoming a problem:
```
mkdir /boot
mount /dev/sdX1 /boot
```
With that out of the way, yes, you may now update.
It's worth creating a basic filesystem table to automate mounting at boot - it's blank by default so here's another template:
If you did not update before `dd`-ing your drive, remember that you may still have to use the fallback initramfs to boot properly until you update the kernel.
This should be everything you need to do for the time being - enjoy configuring your system!