增强现实AR>> u-root>> 返回
项目作者： u-root

项目描述 ：
A fully Go userland with Linux bootloaders! u-root can create a one-binary root file system (initramfs) containing a busybox-like set of tools written in Go.
高级语言： Go
项目地址: git://github.com/u-root/u-root.git
创建时间： 2015-11-19T02:28:59Z
项目社区：https://github.com/u-root/u-root
开源协议：BSD 3-Clause "New" or "Revised" License
下载


u-root

Build Status
codecov
Go Report Card
CodeQL
GoDoc
Slack
License
OpenSSF Best Practices

Description

u-root embodies four different projects.

  • Go versions of many standard Linux tools, such as ls,
    cp, or shutdown. See
    cmds/core for most of these.

  • A way to compile many Go programs into a single binary with
    busybox mode.

  • A way to create initramfs (an archive of files) to use with Linux kernels,
    embeddable into firmware.

  • Go bootloaders that use kexec to boot Linux or multiboot
    kernels such as ESXi, Xen, or tboot. They are meant to be used with
    LinuxBoot.

Usage

Make sure your Go version is >= 1.21.

Download and install u-root either via git:

  1. git clone https://github.com/u-root/u-root
  2. cd u-root
  3. go install

Or install directly with go:

  1. go install github.com/u-root/u-root@latest

[!NOTE]
The u-root command will end up in $GOPATH/bin/u-root, so you may
need to add $GOPATH/bin to your $PATH.

Examples

Here are some examples of using the u-root command to build an initramfs.

  1. git clone https://github.com/u-root/u-root
  2. cd u-root
  4. # Build an initramfs of all the Go cmds in ./cmds/core/... (default)
  5. u-root
  7. # Generate an archive with bootloaders
  8. #
  9. # core and boot are templates that expand to sets of commands
  10. u-root core boot
  12. # Generate an archive with only these given commands
  13. u-root ./cmds/core/{init,ls,ip,dhclient,wget,cat,gosh}
  15. # Generate an archive with all of the core tools with some exceptions
  16. u-root core -cmds/core/{ls,losetup}

[!IMPORTANT]

u-root works exactly when go build and go list work as well.

See also the section below discussing the
AMD64 architecture level.

[!NOTE]

The u-root tool is the same as the
mkuimage tool with some defaults
applied.

In the near future, uimage will replace u-root.

[!TIP]

To just build Go busybox binaries, try out
gobusybox‘s makebb tool.

Multi-module workspace builds

There are several ways to build multi-module command images using standard Go
tooling.

  1. $ mkdir workspace
  2. $ cd workspace
  3. $ git clone https://github.com/u-root/u-root
  4. $ git clone https://github.com/u-root/cpu
  6. $ go work init ./u-root
  7. $ go work use ./cpu
  9. $ u-root ./u-root/cmds/core/{init,gosh} ./cpu/cmds/cpud
  11. $ cpio -ivt < /tmp/initramfs.linux_amd64.cpio
  12. ...
  13. -rwxr-x---   0 root     root      6365184 Jan  1  1970 bbin/bb
  14. lrwxrwxrwx   0 root     root            2 Jan  1  1970 bbin/cpud -> bb
  15. lrwxrwxrwx   0 root     root            2 Jan  1  1970 bbin/gosh -> bb
  16. lrwxrwxrwx   0 root     root            2 Jan  1  1970 bbin/init -> bb
  17. ...
  19. # Works for offline vendored builds as well.
  20. $ go work vendor # Go 1.22 feature.
  22. $ u-root ./u-root/cmds/core/{init,gosh} ./cpu/cmds/cpud

When creating a new Go workspace is too much work, the goanywhere tool can
create one on the fly. This works only with local file system paths:

  1. $ go install github.com/u-root/gobusybox/src/cmd/goanywhere@latest
  3. $ goanywhere ./u-root/cmds/core/{init,gosh} ./cpu/cmds/cpud -- u-root

goanywhere creates a workspace in a temporary directory with the given
modules, and then execs u-root in the workspace passing along the command
names.

[!TIP]

While workspaces are good for local compilation, they are not meant to be
checked in to version control systems.

For a non-workspace way of building multi-module initramfs images, read more
in the mkuimage README. (The u-root
tool is mkuimage with more defaults applied.)

Extra Files

You may also include additional files in the initramfs using the -files flag.

If you add binaries with -files are listed, their ldd dependencies will be
included as well.

  1. $ u-root -files /bin/bash
  3. $ cpio -ivt < /tmp/initramfs.linux_amd64.cpio
  4. ...
  5. -rwxr-xr-x   0 root     root      1277936 Jan  1  1970 bin/bash
  6. ...
  7. drwxr-xr-x   0 root     root            0 Jan  1  1970 lib/x86_64-linux-gnu
  8. -rwxr-xr-x   0 root     root       210792 Jan  1  1970 lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
  9. -rwxr-xr-x   0 root     root      1926256 Jan  1  1970 lib/x86_64-linux-gnu/libc.so.6
  10. lrwxrwxrwx   0 root     root           15 Jan  1  1970 lib/x86_64-linux-gnu/libtinfo.so.6 -> libtinfo.so.6.4
  11. -rw-r--r--   0 root     root       216368 Jan  1  1970 lib/x86_64-linux-gnu/libtinfo.so.6.4
  12. drwxr-xr-x   0 root     root            0 Jan  1  1970 lib64
  13. lrwxrwxrwx   0 root     root           42 Jan  1  1970 lib64/ld-linux-x86-64.so.2 -> /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
  14. ...

You can determine placement with colons:

  1. $ u-root -files "/bin/bash:sbin/sh"
  3. $ cpio -ivt < /tmp/initramfs.linux_amd64.cpio
  4. ...
  5. -rwxr-xr-x   0 root     root      1277936 Jan  1  1970 sbin/sh
  6. ...

For example on Debian, if you want to add two kernel modules for testing,
executing your currently booted kernel:

  1. $ u-root -files "$HOME/hello.ko:etc/hello.ko" -files "$HOME/hello2.ko:etc/hello2.ko"
  2. $ qemu-system-x86_64 -kernel /boot/vmlinuz-$(uname -r) -initrd /tmp/initramfs.linux_amd64.cpio

Init and Uinit

u-root has a very simple (exchangable) init system controlled by the -initcmd
and -uinitcmd command-line flags.

  • -initcmd determines what /init is symlinked to. -initcmd may be a
    u-root command name or a symlink target.

  • -uinitcmd is run by the default u-root init after some
    basic file system setup. There is no default, users should optionally supply
    their own. -uinitcmd may be a u-root command name with arguments or a
    symlink target with arguments.

  • After running a uinit (if there is one), init will start a
    shell determined by the -defaultsh argument.

We expect most users to keep their -initcmd as init, but to
supply their own uinit for additional initialization or to immediately load
another operating system.

All three command-line args accept both a u-root command name or a target
symlink path. Only -uinitcmd accepts command-line arguments, however. For
example,

  1. u-root -uinitcmd="echo Go Gopher" ./cmds/core/{init,echo,gosh}
  3. cpio -ivt < /tmp/initramfs.linux_amd64.cpio
  4. # ...
  5. # lrwxrwxrwx   0 root     root           12 Dec 31  1969 bin/uinit -> ../bbin/echo
  6. # lrwxrwxrwx   0 root     root            9 Dec 31  1969 init -> bbin/init
  8. qemu-system-x86_64 -kernel $KERNEL -initrd /tmp/initramfs.linux_amd64.cpio -nographic -append "console=ttyS0"
  9. # ...
  10. # [    0.848021] Freeing unused kernel memory: 896K
  11. # 2020/05/01 04:04:39 Welcome to u-root!
  12. #                              _
  13. #   _   _      _ __ ___   ___ | |_
  14. #  | | | |____| '__/ _ \ / _ \| __|
  15. #  | |_| |____| | | (_) | (_) | |_
  16. #   \__,_|    |_|  \___/ \___/ \__|
  17. #
  18. # Go Gopher
  19. # ~/>

Passing command line arguments like above is equivalent to passing the arguments
to uinit via a flags file in /etc/uinit.flags, see Extra Files.

Additionally, you can pass arguments to uinit via the uroot.uinitargs kernel
parameters, for example:

  1. u-root -uinitcmd="echo Gopher" ./cmds/core/{init,echo,gosh}
  3. cpio -ivt < /tmp/initramfs.linux_amd64.cpio
  4. # ...
  5. # lrwxrwxrwx   0 root     root           12 Dec 31  1969 bin/uinit -> ../bbin/echo
  6. # lrwxrwxrwx   0 root     root            9 Dec 31  1969 init -> bbin/init
  8. qemu-system-x86_64 -kernel $KERNEL -initrd /tmp/initramfs.linux_amd64.cpio -nographic -append "console=ttyS0 uroot.uinitargs=Go"
  9. # ...
  10. # [    0.848021] Freeing unused kernel memory: 896K
  11. # 2020/05/01 04:04:39 Welcome to u-root!
  12. #                              _
  13. #   _   _      _ __ ___   ___ | |_
  14. #  | | | |____| '__/ _ \ / _ \| __|
  15. #  | |_| |____| | | (_) | (_) | |_
  16. #   \__,_|    |_|  \___/ \___/ \__|
  17. #
  18. # Go Gopher
  19. # ~/>

Note the order of the passed arguments in the above example.

The command you name must be present in the command set. The following will not
work:

  1. u-root -uinitcmd="echo Go Gopher" ./cmds/core/{init,gosh}
  2. # 21:05:57 could not create symlink from "bin/uinit" to "echo": command or path "echo" not included in u-root build: specify -uinitcmd="" to ignore this error and build without a uinit

You can also refer to non-u-root-commands; they will be added as symlinks. We
don’t presume to know whether your symlink target is correct or not.

This will build, but not work unless you add a /bin/foobar to the initramfs.

  1. u-root -uinitcmd="/bin/foobar Go Gopher" ./cmds/core/{init,gosh}

This will boot the same as the above.

  1. u-root -uinitcmd="/bin/foobar Go Gopher" -files /bin/echo:bin/foobar -files your-hosts-file:/etc/hosts ./cmds/core/{init,gosh}

The effect of the above command:

  • Sets up the uinit command to be /bin/foobar, with 2 arguments: Go Gopher
  • Adds /bin/echo as bin/foobar
  • Adds your-hosts-file as etc/hosts
  • builds in the cmds/core/init, and cmds/core/gosh commands.

This will bypass the regular u-root init and just launch a shell:

  1. u-root -initcmd=gosh ./cmds/core/{gosh,ls}
  3. cpio -ivt < /tmp/initramfs.linux_amd64.cpio
  4. # ...
  5. # lrwxrwxrwx   0 root     root            9 Dec 31  1969 init -> bbin/gosh
  7. qemu-system-x86_64 -kernel $KERNEL -initrd /tmp/initramfs.linux_amd64.cpio -nographic -append "console=ttyS0"
  8. # ...
  9. # [    0.848021] Freeing unused kernel memory: 896K
  10. # failed to put myself in foreground: ioctl: inappropriate ioctl for device
  11. # ~/>

(It fails to do that because some initialization is missing when the shell is
started without a proper init.)

AMD64 Architecture Level

Before building an initramfs for AMD64 with u-root, verify that the command

  1. go env GOAMD64

prints v1. A GOAMD64 setting
of any higher version may produce such binaries that don’t execute on old AMD64
processors (including the default CPU model of QEMU).

GOAMD64 can be reset to v1 with one of the following methods:

  • through the GOAMD64 environment variable:

    1. export GOAMD64=v1

  • through go env (only takes effect if the GOAMD64 environment variable
    is not set):

    1. go env -w GOAMD64=v1

Cross Compilation (targeting different architectures and OSes)

Cross-OS and -architecture compilation comes for free with Go. In fact, every PR
to the u-root repo is built against the following architectures: amd64, x86
(i.e. 32bit), mipsle, armv7, arm64, and ppc64le.

Further, we run integration tests on linux/amd64, and linux/arm64, using several
CI systems. If you need to add another CI system, processor or OS, please let us
know.

To cross compile for an ARM, on Linux:

  1. GOARCH=arm u-root

If you are on OSX, and wish to build for Linux on AMD64:

  1. GOOS=linux GOARCH=amd64 u-root

Testing in QEMU

A good way to test the initramfs generated by u-root is with qemu:

  1. qemu-system-x86_64 -nographic -kernel path/to/kernel -initrd /tmp/initramfs.linux_amd64.cpio

Note that you do not have to build a special kernel on your own, it is
sufficient to use an existing one. Usually you can find one in /boot.

If you don’t have a kernel handy, you can also get the one we use for VM testing:

  1. go install github.com/hugelgupf/vmtest/tools/runvmtest@latest
  3. runvmtest -- bash -c "cp \$VMTEST_KERNEL ./kernel"

It may not have all features you require, however.

Framebuffer

For framebuffer support, append a VESA mode via the vga kernel parameter:

  1. qemu-system-x86_64 \
  2.   -kernel path/to/kernel \
  3.   -initrd /tmp/initramfs.linux_amd64.cpio \
  4.   -append "vga=786"

For a list of modes, refer to the
Linux kernel documentation.

Entropy / Random Number Generator

Some utilities, e.g., dhclient, require entropy to be present. For a speedy
virtualized random number generator, the kernel should have the following:

  1. CONFIG_VIRTIO_PCI=y
  2. CONFIG_HW_RANDOM_VIRTIO=y
  3. CONFIG_CRYPTO_DEV_VIRTIO=y

Then you can run your kernel in QEMU with a virtio-rng-pci device:

  1. qemu-system-x86_64 \
  2.     -device virtio-rng-pci \
  3.     -kernel vmlinuz \
  4.     -initrd /tmp/initramfs.linux_amd64.cpio

In addition, you can pass your host’s RNG:

  1. qemu-system-x86_64 \
  2.     -object rng-random,filename=/dev/urandom,id=rng0 \
  3.     -device virtio-rng-pci,rng=rng0 \
  4.     -kernel vmlinuz \
  5.     -initrd /tmp/initramfs.linux_amd64.cpio

SystemBoot

SystemBoot is a set of bootloaders written in Go. It is meant to be a
distribution for LinuxBoot to create a system firmware + bootloader. All of
these use kexec to boot. The commands are in cmds/boot.
Parsers are available for GRUB, syslinux,
and other config files to make the transition to LinuxBoot easier.

  • pxeboot: a network boot client that uses DHCP and HTTP or TFTP to get a
    boot configuration which can be parsed as PXELinux or iPXE configuration
    files to get a boot program.

  • boot: finds all bootable kernels on local disk, shows a menu, and boots
    them. Supports (basic) GRUB, (basic) syslinux, (non-EFI) BootLoaderSpec, and
    ESXi configurations.

More detailed information about the build process for a full LinuxBoot firmware
image using u-root/systemboot and coreboot can be found in the
LinuxBoot book chapter about
LinuxBoot using coreboot, u-root and systemboot.

This project started as a loose collection of programs in u-root by various
LinuxBoot contributors, as well as a personal experiment by
Andrea Barberio that has since been merged
in. It is now an effort of a broader community and graduated to a real project
for system firmwares.

Compression

You can compress the initramfs. However, for xz compression, the kernel has some
restrictions on the compression options and it is suggested to align the file to
512 byte boundaries:

  1. xz --check=crc32 -9 --lzma2=dict=1MiB \
  2.    --stdout /tmp/initramfs.linux_amd64.cpio \
  3.    | dd conv=sync bs=512 \
  4.    of=/tmp/initramfs.linux_amd64.cpio.xz

Getting Packages of TinyCore

Using the tcz command included in u-root, you can install tinycore linux
packages for things you want.

You can use QEMU NAT to allow you to fetch packages. Let’s suppose, for example,
you want bash. Once u-root is running, you can do this:

  1. % tcz bash

The tcz command computes and fetches all dependencies. If you can’t get to
tinycorelinux.net, or you want package fetching to be faster, you can run your
own server for tinycore packages.

You can do this to get a local server using the u-root srvfiles command:

  1. % srvfiles -p 80 -d path-to-local-tinycore-packages

Of course you have to fetch all those packages first somehow :-)

Build an Embeddable u-root

You can build the cpio image created by u-root into a Linux kernel via the
CONFIG_INITRAMFS_SOURCE config variable or coreboot config variable, and
further embed the kernel image into firmware as a coreboot payload.

In the kernel and coreboot case, you may need to configure ethernet. We have a
dhclient command that works for both ipv4 and ipv6. Since v6 does not yet work
that well for most people, a typical invocation looks like this:

  1. % dhclient -ipv4 -ipv6=false

Or, on newer linux kernels (> 4.x) boot with ip=dhcp in the command line,
assuming your kernel is configured to work that way.

Build Modes

u-root can create an initramfs in two different modes, specified by -build:

  • gbb mode: One busybox-like binary comprising all the Go tools you ask to
    include.
    See the gobusybox README for how it works.
    In this mode, u-root copies and rewrites the source of the tools you asked
    to include to be able to compile everything into one busybox-like binary.

  • binary mode: each specified binary is compiled separately and all binaries
    are added to the initramfs.

Updating Dependencies

  1. go get -u
  2. go mod tidy
  3. go mod vendor

Building without network access

The u-root command supports building with workspace vendoring and module
vendoring. In both of those cases, if all dependencies are found in the vendored
directories, the build happens completely offline.

Read more in the mkuimage README.

u-root also still supports GO111MODULE=off builds.

Hardware

If you want to see u-root on real hardware, this
board is a good start.

Using with Plan 9

U-root works with Plan 9. The best distro to use for it is 9front, as the
9front cpiofs works with newc-format cpio (the format of Linux initramfs, which
u-root generates).

Here is a script for Plan 9. Once this script runs, all the u-root commands
appear in /bin. You will need to have go1.22 installed on Plan 9; or
create the u-root initramfs on some other system and copy it to Plan 9.

  1. #!/bin/rc
  2. u-root '-defaultsh=' '-initcmd=' '-shellbang=true'
  3. fs/cpiofs /tmp/initram*cpio
  4. bind -a /n/tapefs /
  5. bind -a /bbin /bin

Contributions

For information about contributing, including how we sign off commits, please
see CONTRIBUTING.md.

Improving existing commands (e.g., additional currently unsupported flags) is
very welcome. In this case it is not even required to build an initramfs, just
enter the cmds/ directory and start coding. A list of commands that are on the
roadmap can be found here.

Website

The sources of u-root.org are inside the docs/ directory and
are deployed to the gh-pages branch. The CNAME file is currently not part of the CI
which deploys to the branch which shall be evaluated if this makes futures deployments easier.