__          __             __
\ \_________\ \____________\ \___
 \  _ \  _\ _  \  _\ __ \ __\   /
  \___/\__/\__/ \_\ \___/\__/\_\_\

Bedrock Linux 1.0alpha2 Momo

Installation Instructions for Bedrock Linux 1.0alpha2 "Momo"

Note that there is no proper installer for this release of Bedrock Linux (1.0alpha2 "Momo"). Installation is done by manually collecting and compiling the components, laying out the filesystem, adding the users, etc. Experienced Linux users - those who are comfortable compiling their own software, know the sigificance of the various parts of the filesystem directory layout, etc - should not have overly much trouble, but those new to Linux or those who don't want to get their hands dirty may wish to seek another Linux distribution for their needs.

  1. Installation Host Environment
  2. Partitioning
  3. Creating the directory structure
  4. Mounting client distribution
    1. Optional directories
  5. Download core Bedrock Linux component sources
    1. Linux Kernel
    2. Busybox
    3. Syslinux
    4. Capchroot
    5. Fsck
    6. Bedrock Linux Scripts
  6. Compile core Bedrock Linux components
    1. Linux Kernel
    2. Busybox
    3. Syslinux
    4. Capchroot
    5. Fsck
    6. Bedrock Linux Scripts
  7. Configuration files
    1. Add users
    2. Hostname
    3. mdev.conf
    4. Hosts
    5. Groups
  8. Configure
  9. Setup First Client
  10. Reboot and Enjoy

Installation Host Environment

First, boot a Linux distribution from a device/partition other than the one on which you wish to install Bedrock. This will be called the "installer host." The installer host can be a LiveCD or LiveUSB Linux distribution (such as Knoppix or an Ubuntu installer), or simply a normal Linux distribution on another device or another partition on the same device.

Be sure the installer host uses the same instruction set as you wish Bedrock Linux to use. Specifically, watch out for (32-bit) x86 live Linux distribution if you wish to make Bedrock Linux (64-bit) x86-64. While it is possible have the installer host use a different instruction set from the targeted Bedrock, it is a bit more work and not covered in these instructions.

If the computer on which you wish to install Bedrock Linux is slow, you may find it preferable to use another computer to do the CPU-intensive compiling. However, this will make some things - such as choosing which modules to compile into the kernel - more difficult. These instructions do not cover compiling on a separate machine from the one on which you wish to install.

Partitioning

Using partitioning software such as gparted or fdisk, partition the device on which you wish to install Bedrock. Be very careful to only format bits and bytes which you no longer need - a mistake here could blow away another operating system with which you intended to dual-boot with Bedrock.

For the most part you are free to partition the system however you please. If you are unsure of how to partition it, it is reasonable to use only two partitions: (1) your main partition for mounting the root directory (ie, /) and (2) a swap partition. Recommendations for swap sizes usually vary between equal to your RAM size to two-and-a-half times your RAM size.

If you are comfortable with typical partitioning schemes for Linux - such as making /boot, /home, etc their own partitions - you are free to do so. However, you may first want to skip down to "Creating the directory structure" before doing so to note some unusual aspects of Bedrock's layout. Specifically, note that /usr is not heavily used. Rather, most of the software usually in /usr will be accessed from client Linux distributions. You may want to consider making /var/chroot its own partition and giving it a lot of space, as this is the recommended location for storing the client Linux distributions.

Note which devices files correspond to which partitions of the Bedrock Linux filesystem. These are normally located in /dev, and called sdXN, where X is a letter a-z and N is a digit 0-9. This information will be used later to mount these partitions.

Momo has only been tested with the ext2 and ext3 filesystems, but any Linux-supported filesystem should work fine. If you choose to use something other than ext2/3/4, be sure you know where to find (and how to set up) corresponding fsck software and a bootloader which can work with that filesystem, as these instructions will only cover ext2/3/4.

If you are dual-booting with another Linux distribution, wish to use that distribution's bootloader, and know how to add Bedrock Linux to that distribution's bootloader, be sure to keep the boot flag on the other distribution's boot partition. If you would like to use Bedrock's bootloader, be sure to set the boot flag on the proper partition (ie, either the Bedrock's main/root partition or, if you made a special /boot partition, then the /boot partition you made).

Mounting client distribution

Make a directory in which to mount Bedrock's fresh to partition(s). These instructions assumes you are using /mnt/bedrock for this. If you would like to use something else, be sure to change /mnt/bedrock accordingly whenever it comes up in these instructions. Note that this will become Bedrock's root directory when we are done. As root: 

mkdir -p /mnt/bedrock

Mount the newly-created main/root partition. Replace sdXN with the corresponding device file to the main/root partition. As root: 

mount /dev/sdXN /mnt/bedrock

If you created more than one partition (other than swap) for Bedrock, make the corresponding directories and mount them.

Creating the directory structure

Create the required directory structure for Bedrock. As root:

Most of these directories should be recognizable to any experienced Linux user. The one most likely to be new to people, /var/lib/urandom, will store the pseudo-random number generator seed between reboots so Bedrock doesn't have to wait for entropy when seeding it at every boot. /opt/bedrock/ will contain Bedrock-specific items which need to be shared with client Linux distributions.

Note that many directories other Linux distributions use - such as most of the contents of /usr - are missing. These aren't strictly necessary for the core of Bedrock; rather, the necessary aspects will be accessed through client Linux distributions. If you'd like, you're free to make them; they just won't be utilized.

The default permissions on most of these should be fine. However, /tmp needs to be writable by no-root users: 

chmod a+rwxt tmp

Optional directories

There are a number of other directories which aren't strictly required but which you may want to consider.

If you have hardware which requires firmware, you may want to create a directory in which to put the firmware. For example, some wireless cards require firmware. You could also build the firmware into the kernel if you choose. If you want (external to the kernel) firmware, create the required directory. As root: 

mkdir -p lib/firmware

Now would be a good time to put the firmware in there, before you forget.

Client Linux distributions can be placed just about anywhere. However, it is convenient to place them all in the same directory. The recommended location is /var/chroot/. As root: 

mkdir -p var/chroot

Download core Bedrock Linux component sources

Download the source code to the various core components of Bedrock Linux to /mnt/bedrock/usr/src.

Linux Kernel

The Linux kernel can be downloaded from: https://www.kernel.org/. If you don't know which version to grab, either the latest stable or a long-term supported kernel is a would be a good idea. Bedrock Linux uses (capchroot which uses) Linux capabilities, which puts a lower-bound on the oldest Linux kernel it can use. Linux 2.6.26 might be the cutoff. Momo was tested with Linux 3.2 - either that or anything newer than it should work.

Busybox

Busybox can be downloaded from: http://www.busybox.net/. Momo was tested successfully with busybox 1.19.4, but newer versions should work.

Syslinux

If you want Bedrock Linux to have its own bootloader (as opposed to dual-booting from another Linux distribution and using its bootloader), and you are using a ext2, ext3, ext4 or btrfs, download syslinux from: http://www.syslinux.org. Momo was tested successfully with syslinux 3.86, but newer versions should work.

Note: that syslinux is a project containing multiple bootloaders (one of which is syslinux). The specific bootloader you probably want is "extlinux" (which supports ext2 and ext3 filesystems, and ext4 and btrfs as of version 4) as the actual "syslinux" bootloader is for FAT filesystems. Extlinux should come packaged with syslinux.

Note: syslinux/extlinux is a BIOS-based bootloader, and will not work with (U)EFI. Many (U)EFI motherboards have a legacy BIOS-emulation mode which might work. Otherwise, you'll have to find another bootloader which supports (U)EFI and figure out how to set it up yourself.

Capchroot

Capchroot can be downloaded from: https://dev.archlinux.org/~thomas/capchroot/ and a patch which you will need to compile it statically can be found here. Despite the fact that a pre-compiled version is provided as a .tar.gz, you should still grab the source, as minor changes need to be made to the source before compiling to ensure it can be compiled statically.

Momo was tested with capchroot 0.1. Newer versions of capchroot may not necessarily work with these instructions.

Fsck

You can download fsck for ext2, ext3 and ext4 at: http://e2fsprogs.sourceforge.net/ If you would like to use another filesystem, it should not be difficult to find the fsck for it and install it instead, but these instructions do not cover it.

Momo was tested with e2fsprogs 1.42.4, but newer versions should work fine.

Bedrock Linux Scripts

Download the Momo userland from here.

These scripts are the ones written specifically for this release of Bedrock Linux (1.0alpha2 "Momo"). If you would like to use newer or older scripts, it would be best to find the corresponding instructions for that version of Bedrock.

Compile core Bedrock Linux components

If you are using a LiveCD/LiveUSB, don't forget to update the repository index. If you are on a Debian-based system (such as Knoppix or an Ubuntu installer), as root: 

apt-get update

If you do not already have it, install the usual compiling packages for the distribution on which you are compiling Bedrock's core components. For example, on Debian-based systems this would be done via (as root): 

apt-get install build-essential

You will also be needing the ncurses development libraries. Again, for Debian-based systems, as root: 

apt-get install libncurses5-dev

Or, if you foresee the need for wide characters: 

apt-get install libncursesw5-dev

The '5' in the package name may change in the future; change accordingly.

The Linux kernel is usually compressed. You will have a choice later for which compression system to use. You may have to install the corresponding libraries for that compression system. The options are usually:

Install the requirements for the kernel to be compressed with the compression software you want. For example, if you want to use LZO (the fastest option), and you are on a Debian-based system: 

apt-get install lzop

If you would like Bedrock Linux to use its own bootloader, and you are not using (32-bit) x86, you will also need nasm to compile syslinux. Again, for Debian-based systems as root: 

apt-get install nasm

To compile capchroot, you also need Linux capabilities development libraries and setcap executable. For a Debian-based system, as root: 

apt-get install libcap-dev libcap2-bin

Linux Kernel

These instructions are not intended to be complete or sufficient for everyone. It may be advisable to supplement this with other guides for compiling the Linux kernel.

Change to the directory in which you placed the source code packages. 

cd /mnt/bedrock/usr/src

Unpackage the kernel source and change directories into it.

First, it is usually a good idea to clean everything up just in case whoever packaged it forgot to do so before packaging. 

make mrproper

The Linux kernel's compilation configuration is usually stored in a file called .config located in the root of the source's directory. If you have never compiled the Linux kernel before, it may be a good idea to grab the .config used by another Linux distribution. These are usually stored in /boot with the name config-VERSION or gunzipped in /proc/config.gz at runtime. If you want to use the one in /boot: 

cp /boot/config-VERSION .config

Or, if you would like to use the runtime copy in /proc:

If you are experienced at compiling the Linux kernel, you probably have your own .config to reference. Feel free to use that. Just be wary that Bedrock Linux does not typically use an initrd.

Instead of using a generic kernel which includes support for hardware you will not need, you can customize the kernel to your specific hardware. The command lsmod will show modules the installer host has currently loaded. As of Linux 2.6.32, you can have the make command automatically change .config to include the modules which are open (and only those modules) with the following command: 

make localmodconfig

Alternatively, if you would rather these modules be built into the kernel rather than loaded on-the-fly, you use the following command: 

make localyesconfig

If the kernel you are about to compile contains features the reference .config doesn't mention, you may be prompted for what to do with the new options after make localmodconfig/localyesconfig. If you do not want to think about each item, the defaults are usually safe - you can just hold down the ENTER/RETURN key here until the prompts stop. You will have the chance to change these later with make menuconfig.

Note that these two commands often leave in some things as modules which aren't loaded, such as some webcam, videocard and soundcard modules. If you know with a high degree of confidence which drivers your kernel uses and which it does not, you may still want to go through menuconfig below and remove some items these two commands leave behind.

Note that these commands will leave out most modules which is not currently loaded. For example, if you do not have any USB mass storage devices plugged in when running the commands, support for USB mass storage may be removed from the .config. It can be re-added manually with make menuconfig below.

Note that not only can modules be loaded on-the-fly, they can also be removed on-the-fly, unlike anything compiled in. If, for example, you wish to switch between nouveau and the proprietary nVidia drivers, you will want to ensure nouveau is a module and not built-in.

Note that compile time can be improved drastically be only compiling the parts of the kernel your hardware will actually use. However, if you later add new hardware, you will have to recompile the kernel.

If you would like, you can compile the firmware directly into the kernel. If so, place the firmware in the firmware directory in the root of the unpackaged Linux kernel source.

To further customize the kernel, run the following command: 

make menuconfig

This will compile a very small program which acts as a menu to help you configure the Linux kernel.

Controls:

Recommended changes:

If you want to use a initramfs/initrd, you will have to find other instructions on how to do so. These instructions assume no initrd/initramfs. With that in mind, set the following to excluded: 

General Setup --->
	Initial RAM filesystem and RAM disk support

If you chose to use a .config from another Linux distribution, and you did not use make localyesconfig above, there is a chance that the kernel does not have everything you need to boot built-in. It might have been intended to load some things from within an initial ramdisk. Use lsmod to see loaded modules, and find any that looks necessary to (1) boot and (2) read the external modules from the filesystem - such code for ext2/3/4/ filesystems or SCSI/IDE/SATA drivers - and ensure they are built-in, unless you plan to make your own initramfs/initrd (by finding instructions elsewhere).

The Linux kernel has minimal support for in-kernal maintaining of /dev through a feature called "devtmpfs". Bedrock Linux uses busybox's mdev for this purpose, making devtmpfs unnecessary. Set the following to excluded: 

Device Drivers ->
	Generic Driver Options --->
		Maintain a devtmpfs filesystem to mount at /dev

If you want to compile multiple kernels of the same kernel version (such as trial-and-error on getting something to work), creating a local version is helpful. 

General Setup --->
	Local version - append to kernel release
General Setup --->
	Automatically append version information to the version string

If you have firmware you wish to install into directly into the kernel, and you placed it into the "firmware" directory as explained earlier, specify the filename of the firmware at 

Device Drivers ->
Generic Driver Options --->
External firmware blobs to build into the kernel binary

As of Linux 3.4, Linux now has a security module called "Yama" which can be used to lock down ptrace. If you want to use Bedrock's chroot system to attempt to do sandboxing, be sure to enable Yama support to protect against possible attacks from the sandboxed command via ptrace. This is probably a good idea even if you don't intend to do any special sandboxing. Build-in the following: 

Security options --->
	Yama Support

If you want to ensure it is enabled by default, set it as the Default security module: 

Security options --->
	Default security module

Once you have finished selecting the options you want in menuconfig, save and exit it.

To compile, run: 

make

Depending on the options you have selected and your machines performance, this can take quite a while.

Next, you need to install the kernel into Bedrock. Two environmental variables can be set to tell make where to install the modules and kernel itself. If you are not using /mnt/bedrock as the mount point for Bedrock, change the relevant part of the lines below:

Install the external modules: 

INSTALL_MOD_PATH=/mnt/bedrock make modules_install

Install the kernel itself: 

INSTALL_PATH=/mnt/bedrock/boot make install

If you see errors about grub after this command, you are free to disregard them. Just ensure that /mnt/bedrock/boot has, at least, two files: vmlinuz-KERNEL-VERSION and System.map-KERNEL-VERSION. You may also have config-KERNEL-VERSION, which you can later use as a new .config to create a new kernel.

Installing the modules created two symlinks which will break when Bedrock's root filesystem is mounted as / rather than /mnt/bedrock. To fix this, delete and manually re-create the pointing to the correct location.

Be careful to use the proper KERNEL-VERSION in the above commands. The terms starting with /mnt/bedrock should be tab-completable depending on your shell, but the /usr/src/linux-KERNEL-VERSION will need the name of the directory which contains the Linux kernel's source code without the /mnt/bedrock prefix.

Busybox

Change to the directory in which you placed the source code packages. 

cd /mnt/bedrock/usr/src

Unpackage the busybox source and change directories into it:

Configuring busybox is very similar to configuring the Linux kernel. To get the configuration menu, run: 

make menuconfig

The navigating and otherwise using the menu is the same the Linux kernel configuration.

Recommended configurations:

Bedrock Linux uses busybox for nearly the entirety of its userland. While most of the functionality will be acquired through client Linux distributions, it may still be beneficial to treat Bedrock Linux as a full-blown desktop when it is not much additional work extra work. Enable: 

Busybox Settings --->
	General Configuration --->
		Enable options for full-blown desktop systems

You will use the --install flag to install busybox's applets. Ensure this flag is available by enabling: 

Busybox Settings --->
	General Configuration --->
		Support --install [-s] to install applet links at runtime

There is minimal benefit to using /usr with Bedrock, only additional complexity. Enable: 

Busybox Settings --->
	General Configuration --->
		Don't use /usr

Making busybox a static binary makes both installation and updating by compiling in a client Linux distribution much easier. Enable: 

Busybox Settings --->
	Build Options --->
		Build BusyBox as a static binary (no shared libs)

Recommended applets:

The following list constitutes the minimum required commands - find the applets that supply these and ensure they are enabled: 

[ ar awk basename cat chmod chroot chvt clear cmp cp cut dd df
dirname echo ed env expand expr false find free fsck getty grep
head hostname hwclock id init install kill last length ln ls
mdev mkdir more mount mt od passwd printf ps readlink reset rm
route sed seq sh sleep sort split stat swapon sync tail time
top touch true tty umount uname vi wc wget which xargs yes

To compile, run: 

make

Note that a number of testers have reported substancial trouble compiling busybox statically on various Linux distributions with the instructions provided above. You may very well receive warnings along the lines of "statically linked applications requires at the runtime the shared libraries from the glibc verion used for linking". If this happens to you, you have several options available:

A high-priority goal for the upcoming release of Bedrock Linux will be to include a more consistent, installer host distro-agnostic solution for statically compiling buysbox.

To confirm that it was compiled statically, run 

ldd busybox

and check that the output is "not a dynamic executable". To install it, copy the binary to its new home: 

cp busybox /mnt/bedrock/bin/

Note that some commands which busybox will provide for us (such as su and ping) need to be setuid. The only way to achieve this is to setuid busybox itself. Busybox will drop permissions if it is called as an applet that does not need setuid. If you are worried about this, go back and create two busybox executables - one for things that need setuid and one for things that do not. To setuid busybox, as root: 

chmod +s /mnt/bedrock/bin/busybox

Busybox is a single executable that, when called with a different name, can act like other Linux userland utilities. To make it act like those other command transparently, we need to make other files which point to busybox. Busybox can create these itself with the --install flag. We must ensure busybox installs with the assumption that /mnt/bedrock is the root filesystem via chroot. As root: 

chroot /mnt/bedrock /bin/busybox --install

If you made a separate busybox for setuid-only things, be sure to --install it as well.

Note that, depending on the libraries used when compiling busybox, it may not be completely statically linked. For example, it may be lacking the ability to resolve DNS information. Before testing this, copy /etc/resolv.conf from your host into /mnt/bedrock/etc/, as this file is required to resolve DNS. Once that is done, you can try to see you can successfully use busybox to ping: 

chroot /mnt/bedrock /bin/busybox ping google.com

If this fails, try see if it succeeds from outside of the chroot: 

/mnt/bedrock/bin/busybox ping google.com

If it works outside of the chroot, but not inside, you have the option of copying the libraries from the installer host into the bedrock chroot, or simply live without the ability to resolve DNS in the core Bedrock Linux (this is a relatively minor issue since you can use a client for just about anything you would need). If you would like to copy the libraries from the installer host, use strace against both above commands (ie, inside and outside of the chroot) and determine which libraries busybox from outside can see and use but it can't from inside and copy them over.

Syslinux

Again, as a reminder, "syslinux" is the name of a project which contains several bootloaders, one of which is also called "syslinux." If you want Bedrock Linux to have its own bootloader, the specific bootloader from the syslinux project you most likely want to use is called "extlinux" and can be used with ext2 or ext3 (and as of version 4, ext4 and the btrfs filesystem).

If you want to dual-boot with another operating system and you know how to add Bedrock Linux to that other operating system, feel free to skip the this section of the instructions and simply add Bedrock Linux to your other operating system's bootloader. Be careful when installing syslinux, as if it is done improperly (either by not following these directions correctly, or by a fault in these directions), it could leave your system broken and unbootable. Practicing/testing in a VM is not a bad idea if you are worried.

It may be a good idea to read other guides on installing syslinux/extlinux to supplement this guide, just in case, and to skim the entirety of this section before starting to follow any of it.

From this point onward, avoid shutting down the installer host part-way through these instructions unless you are using a LiveUSB/LiveCD system. Otherwise you may have difficulty booting.

Change to the directory in which you placed the source code packages. 

cd /mnt/bedrock/usr/src

Unpackage syslinux and change directories into the extlinux subdirectory in it:

If you are using (32-bit) x86, you may use the compiled binary the package which comes with the package. Otherwise, you will have to compile extlinux it yourself. If you are not using (32-bit) x86 (or you would like to compile syslinux for another reason), run the following: 

make clean; make

This will compile a number of things you do not need. If you receive an error, there is a good chance that it was not with regards to extlinux. Check to see if extlinux compiled successfully: 

ls extlinux/extlinux

Install syslinux/extlinux. As root: 

extlinux/extlinux --install /mnt/bedrock/boot/extlinux

Note that, unlike with busybox, we do not want to use chroot to make /mnt/bedrock appear as the root directory.

Although syslinux is installed on the partition, it still needs to be properly set up on the harddrive itself. Find the corresponding device file for device you made bootable when you partitioned/formatted earlier. Note that here we aren't looking for the partition device file - /dev/sdXN - but rather the device's file - /dev/sdX. There should be no 0-9 digit in the filename. As root: 

cat mbr/mbr.bin > /dev/sdX # change X accordingly

You may now want to copy several files to /mnt/bedrock/boot/extlinux which syslinux needs for some of its features.

To use a simple menu when booting (as opposed to a commandline), copy menu.c32 

cp com32/menu/menu.c32 /mnt/bedrock/boot/extlinux

Or, if you'd prefer a fancy graphical menu, copy vesamenu.c32 

cp com32/menu/vesamenu.c32 /mnt/bedrock/boot/extlinux

To be able to poweroff from the boot menu (or commandline), copy poweroff.com: 

cp modules/poweroff.com /mnt/bedrock/boot/extlinux

Note that on poweroff.com does not seem to work across all computers.

To have "reboot" as a menu option, copy reboot.c32 

cp com32/modules/reboot.c32 /mnt/bedrock/boot/extlinux

Note that you can reboot with ctrl-alt-delete without reboot.c32.

To chain-load another operating system's bootloader (such as Microsoft Windows), you will need chain.c32. 

cp com32/modules/chain.c32 /mnt/bedrock/boot/extlinux

Now you should create the configuration file for syslinux. Unlike GRUB, syslinux must be configured by hand. Assuming you want a graphical menu, run the following to get a basic menu in syslinux: 

cat > /mnt/bedrock/boot/extlinux/extlinux.conf << EOF
UI menu.c32
MENU TITLE Syslinux Bootloader
DEFAULT Bedrock
PROMPT 0
TIMEOUT 50
LABEL Bedrock
MENU LABEL Bedrock Linux 1.0alpha2 Momo
LINUX ../vmlinuz-KERNEL-VERSION
APPEND root=/dev/sdXN quiet ro
EOF

Be sure to change KERNEL-VERSION to the version of the Linux kernel you compiled earlier so that ../vmlinuz-KERNEL-VERSION after the change will point the vmlinuz file you created when installing the Linux kernel. Also be sure to change sdXN to the partition you set to boot - either Bedrock's main/root partition or it's /boot partition if you made one. You may also change menu.c32 to vesamenu.c32 if you prefer.

If you would like to dual-boot with Windows, append the following: 

cat >> /mnt/bedrock/boot/extlinux/extlinux.conf << EOF
LABEL Windows
MENU LABEL Windows
COM32 chain.c32
APPEND hdN N
EOF

Be sure to change the N's in hdN N to the harddrive number (zero-indexed) and partition number (also zero-indexed) of the Windows bootloader. Note that Windows 7 (and probably Vista before it) usually comes with a roughly 100MB "System Reserved" partition, and so the actual partition you would like to boot for Windows is usually not the first partition. For example, Windows 7 is the only OS on the first harddrive, you probably want to use hd0 1. If you get it wrong, you can change it and try again (either from within Bedrock, or from a LiveCD/LiveUSB).

If you would like, feel free to add entries for other operating systems or customize the colors or other options of syslinux. For example, to customize the menu provided by menu.c32, see here.

Capchroot

Change to the directory in which you placed the source code packages. 

cd /mnt/bedrock/usr/src

Unpackage the capchroot source and change directories into it:

patch capchroot: 

patch -p1 < ../capchroot-0.1-static.patch

This patch allows capchroot to be compiled statically-linked, and moves the config file for capchroot to /opt/bedrock/etc/, making it easier to share with client Linux distributions.

Compile capchroot: 

LDFLAGS=-static make

To confirm that it was compiled statically, run 

ldd capchroot

and check that the output is "not a dynamic executable".

To install it, simply copy it to what will be Bedrock's /opt/bedrock/bin (as root): 

cp capchroot /mnt/bedrock/opt/bedrock/bin

Lastly, you will need to set the Linux capabilities permissions on capchroot so that it can allow non-root users to chroot. 

setcap cap_sys_chroot=ep /mnt/bedrock/opt/bedrock/bin/capchroot

Fsck

Change to the directory in which you placed the source code packages. 

cd /mnt/bedrock/usr/src

Unpackage the fsck source and change directory into it:

Create a build directory and change directory into it:

Compile fsck:

To confirm that it was compiled statically, run 

ldd e2fsck/e2fsck

and check that the output is "not a dynamic executable".

To install it, simply copy it to what will be Bedrock's /sbin with the names of the filesystems it supports (as root):

Bedrock Linux Scripts

First, ensure that root owns the tarball, as there have been some permission issues reported on some systems otherwise. 

chown root:root /mnt/bedrock/usr/src/bedrock-userland-1.0alpha2.tar.gz

Unpackage the Bedrock Linux scripts over the soon-to-be Bedrock Linux root.

This will install the following:

Configuration files

All of configuration files will be created from within Bedrock Linux via a chroot, as root.

Chroot into Bedrock Linux (as root): 

chroot /mnt/bedrock /bin/sh

Add users

Create the global user-management files (as root):

Create the root user (as root): 

adduser root -u 0 -h /root -s /opt/bedrock/bin/brsh -D

Set the password: 

passwd -a sha512

You can configure brsh to use either a shell from a client distribution or Bedrock's /bin/sh. If you would typically prefer to log into a client distribution's shell, but occasionally would like to log into Bedrock's /bin/sh, it may be easier to create another login which uses a different shell so you are not forced to log in, change brsh's configuration, then log out, then log back in. Moreover, this is a good backup option in case brsh fails to recognize that a client's shell is not working properly. To ensure root remains available quickly and easily in these situations, create another user (brroot) with the same UID which uses bedrock's busybox's /bin/sh.

If you would like to add other users, run the following for each user:

If you would like to ensure the users have two logins - one normal one and one for directly logging into Bedrock's /bin/sh without having to reconfigure brsh, run the following, changing USERNAME to the user's name.

Shells

Create the /etc/shells file

Hostname

Create the hostname. 

echo "HOSTNAME" > /etc/hostname

mdev.conf

The device files in /dev are maintained by busybox's mdev. This requires a configuration file, mdev.conf. The one used by the good folks at Linux From Scratch is adequate for Bedrock.

Run the instructions for creating mdev.conf in Cross Linux From Scratch as provided here.

Note that, since we do did not create a $CLFS variable and we are in the chroot, it should create it in the proper place. Just in case, ensure that, from within the chroot, the file is located at /etc/mdev.conf and that, from outside of the chroot, the file is located at /mnt/bedrock/etc/mdev.conf.

The as of the time of writing, the mdev.conf used by CLFS expects several scripts to be present in /lib/mdev. No work has yet been made to ensure this works with Bedrock. Instead, simply comment out any part which mentions /lib/mdev - but only that term and those following it, not the terms before it.

For example, change 

sd[a-z].* root:disk 0660 */lib/mdev/usbdisk_link

to 

sd[a-z].* root:disk 0660 #*/lib/mdev/usbdisk_link

Hosts

Create the hosts file:

Groups

Mdev expects certain users and groups to be present when it populates /dev in order to give these the proper ownership. You can create the groups to satisfy mdev, or - if you don't care to have mdev use special rules when creating the devices - you can remove the lines which expect non-existant groups from /etc/mdev.conf. To create the groups it expects, as root:

If your mdev.conf also includes other groups not mentioned here, feel free to include those as well. Moreover, if you later choose to use udev instead of mdev, it too may have certain expections about available groups. It may be wise to reference the group numbers other distributions use.

You may exit the chroot. At this point, the core of Bedrock Linux is finished installing, and the system should be bootable. The rest of these instructions can be done from within or without of the chroot, from the installer host or from Bedrock itself. However, remember that there may be some difficulties getting network access from the core of Bedrock without a client yet installed. Moreover, be careful about the paths described in the following instructions, as the exact paths will change depending on whether or not you are in the installer host, within the chroot, from the core of Bedrock, or from a client.

Configure

Configure Bedrock Linux as per the instructions made available here.

Setup First Client

Bedrock Linux does not do very much by itself without any client Linux distributions. Before booting into Bedrock, it may be wise to use the installer host to get your first client.

See the clients page on details for setting up a specific Linux distribution.

Reboot and Enjoy

If you wish to use another bootloader, be sure to set up Bedrock Linux in that bootloader.

Finally, reboot into Bedrock Linux and enjoy!