This document captures the common-case workflow for building and deploying Fuchsia onto a device using fx
development commands. Most such commands have options for less common situations; see fx help <command>
for details.
The initial build and deploy workflow using fx
is as follows:
fx set core.x64
Configures the build to build the “core” product on a generic x64 board. See fx list-products
and fx list-boards
for lists of available products and boards, respectively.fx build
Builds Zircon, then the rest of Fuchsia.fx mkzedboot <usb_drive_device_path>
Builds the Zedboot media and installs to the USB drive target. See below for notes on obtaining the USB drive device path.fx pave
Starts the bootserver.Instructions for determining the correct path to your USB drive are as follows, depending on the host OS. In either case, you can run the command once with the USB drive disconnected, then run again with it connected, to see the difference.
sudo fdisk -l
Drives are usually of the form /dev/sd[x], e.g. ‘/dev/sdc’. Select the drive rather than a specific partition.diskutil list | grep external
Drives are usually of the form /dev/disk[n], e.g. ‘/dev/disk2’.hdiutil unmount /dev/disk[n]
. If this does not fix the error, try reformating the drive: diskutil eraseDisk JHFSX <name_of_the_usb_stick> /dev/disk[n]
.The workflow for re-building and re-deploying using fx
is slightly different:
jiri update
Fetches the latest code.fx build
Builds Zircon, then the rest of Fuchsia.fx setup-macos
Sets up firewall rules (Mac users ONLY)fx serve
Starts a development package server on the host.fx ota
Pushes updated packages to the device.NOTE: If desired, the device can be re-paved using Zedboot USB as per steps 4-5 in the previous section. This is slower, but may be necessary in some cases where the system handles the OTA less than gracefully.
fx build
to fail. The script will change the working directory such that it may create conflicts between the commands it uses (e.g. touch
) and the binaries in the working directory.