From d5eae632f526a4515a1a6c8c1ae98f555ad995d1 Mon Sep 17 00:00:00 2001
From: Your Name <you@example.com>
Date: Fri, 21 Mar 2025 12:52:26 +0000
Subject: [PATCH 01/19] initial technical walkthrough

---
 .../building-custom-glibc/_index.md           |  45 +++
 .../building-custom-glibc/_next-steps.md      |   8 +
 .../building-custom-glibc/fvp.md              | 174 +++++++++++
 .../building-custom-glibc/glibc.md            | 205 ++++++++++++
 .../building-custom-glibc/kernel.md           |  66 ++++
 .../naming-conventions.md                     |  44 +++
 .../building-custom-glibc/rootfs.md           |  50 +++
 .../building-custom-glibc/setup.md            | 292 ++++++++++++++++++
 8 files changed, 884 insertions(+)
 create mode 100644 content/learning-paths/servers-and-cloud-computing/building-custom-glibc/_index.md
 create mode 100644 content/learning-paths/servers-and-cloud-computing/building-custom-glibc/_next-steps.md
 create mode 100644 content/learning-paths/servers-and-cloud-computing/building-custom-glibc/fvp.md
 create mode 100644 content/learning-paths/servers-and-cloud-computing/building-custom-glibc/glibc.md
 create mode 100644 content/learning-paths/servers-and-cloud-computing/building-custom-glibc/kernel.md
 create mode 100644 content/learning-paths/servers-and-cloud-computing/building-custom-glibc/naming-conventions.md
 create mode 100644 content/learning-paths/servers-and-cloud-computing/building-custom-glibc/rootfs.md
 create mode 100644 content/learning-paths/servers-and-cloud-computing/building-custom-glibc/setup.md

diff --git a/content/learning-paths/servers-and-cloud-computing/building-custom-glibc/_index.md b/content/learning-paths/servers-and-cloud-computing/building-custom-glibc/_index.md
new file mode 100644
index 0000000000..998dc3a3e3
--- /dev/null
+++ b/content/learning-paths/servers-and-cloud-computing/building-custom-glibc/_index.md
@@ -0,0 +1,45 @@
+---
+title: Building and Running a custom glibc on an FVP
+
+minutes_to_complete: 60
+
+who_is_this_for: >
+  Developers who wish to run a Linux system (optionally using a custom kernel and a C library) on an Arm Fixed Virtual Platform (FVP) model. For example, this
+  guide might be useful if you want to test patches related to new architectural features for the Linux kernel or Glibc.
+
+learning_objectives: 
+  - Build the Linux kernel.
+  - Install the Shrinkwrap tool, build firmware for the FVP and run it.
+  - Configure and boot a Linux system on the FVP.
+  - Configure guest OS to make running Glibc tests easier.
+  - Build Glibc and run tests on the system running on the FVP.
+
+prerequisites:
+  - An AArch64 or x86 host running a Linux system.
+  - GCC cross toolchain for the `aarch64-none-linux-gnu` target.
+  - Docker.
+  - Git to checkout sources.
+  - Make to build the tools.
+  - Bash for your shell.
+  - Python 3.x and `pip` to create a Python virtual environment.
+  - Common tools like `wget`, `unxz`, `truncate`.
+
+author: Yury Khrustalev
+
+### Tags
+skilllevels: Advanced
+subjects: Architecture and Performance
+armips:
+    - AArch64
+tools_software_languages:
+    - Glibc
+    - Shrinkwrap
+    - Fast Models
+operatingsystems:
+    - Linux
+### FIXED, DO NOT MODIFY
+# ================================================================================
+weight: 1                       # _index.md always has weight of 1 to order correctly
+layout: "learningpathall"       # All files under learning paths have this same wrapper
+learning_path_main_page: "yes"  # This should be surfaced when looking for related content. Only set for _index.md of learning path content.
+---
\ No newline at end of file
diff --git a/content/learning-paths/servers-and-cloud-computing/building-custom-glibc/_next-steps.md b/content/learning-paths/servers-and-cloud-computing/building-custom-glibc/_next-steps.md
new file mode 100644
index 0000000000..c3db0de5a2
--- /dev/null
+++ b/content/learning-paths/servers-and-cloud-computing/building-custom-glibc/_next-steps.md
@@ -0,0 +1,8 @@
+---
+# ================================================================================
+#       FIXED, DO NOT MODIFY THIS FILE
+# ================================================================================
+weight: 21                  # Set to always be larger than the content in this path to be at the end of the navigation.
+title: "Next Steps"         # Always the same, html page title.
+layout: "learningpathall"   # All files under learning paths have this same wrapper for Hugo processing.
+---
diff --git a/content/learning-paths/servers-and-cloud-computing/building-custom-glibc/fvp.md b/content/learning-paths/servers-and-cloud-computing/building-custom-glibc/fvp.md
new file mode 100644
index 0000000000..fe52f77ef7
--- /dev/null
+++ b/content/learning-paths/servers-and-cloud-computing/building-custom-glibc/fvp.md
@@ -0,0 +1,174 @@
+---
+title: Boot Linux on the FVP
+weight: 5
+
+### FIXED, DO NOT MODIFY
+layout: learningpathall
+---
+
+## Introduction
+
+During this step, you will set up everything for the FVP to run and then boot the Linux system using the kernel and the root file system that you prepared earlier in the earlier sections.
+
+Arm [Fixed Virtual Platform (FVP)](https://developer.arm.com/downloads/-/arm-ecosystem-fvps) is a model that allows you to access functionality
+of Armv8.x or v9.x hardware. You will use the Armv-A Base Rev C Architecture Envelope Model (AEM).
+
+In addition to the model itself, you also need the device tree and the firmware. To simplify
+building these components, you will use a tool called [Shrinkwrap](https://gitlab.arm.com/tooling/shrinkwrap).
+
+This tool comes with a detailed [user guide](https://shrinkwrap.docs.arm.com/en/latest/) that covers all of its features and
+configuration options. You will also leverage this tool to run and boot the images you prepared on the FVP.
+
+Shrinkwrap can be used in a few different ways. One of the ways is to use a Docker container to facilitate the building of the firmware and
+running the FVP. This helps avoid installing all the dependencies on your host system.
+
+## Install Shrinkwrap
+
+First, install prerequisites in a Python virtual environment using Python 3.x:
+
+```bash
+cd $HOME
+python -m venv ./workspace/venv
+source ./workspace/venv/bin/activate
+pip install -U pip setuptools wheel
+pip install pyyaml termcolor tuxmake
+```
+
+Shrinkwrap can be used directly from the source, which can be checked out from its Git
+repository. Run this command in the workspace directory:
+
+```bash
+git clone https://git.gitlab.arm.com/tooling/shrinkwrap.git
+export PATH=${PATH}:${HOME}/workspace/shrinkwrap/shrinkwrap
+```
+
+Putting Shrinkwrap's main executable on your `PATH` is all you need to install the tool.
+To check that it works, ensure that the Python virtual environment we created earlier
+is activated, then run this command:
+
+```bash
+shrinkwrap --version
+```
+
+You should see a version printed.
+
+```output
+shrinkwrap v1.0.0
+```
+
+## Build firmware for the FVP
+
+Now, you can use the Shrinkwrap tool to build the firmware, the third essential ingredient in our
+setup. The following step needs to be done once although you will need to repeat it if you
+want to rebuild the firmware:
+
+```bash
+shrinkwrap build --overlay=arch/v9.4.yaml ns-edk2.yaml
+```
+
+This command uses the `arch/v9.4.yaml` config that enables Armv9.4 hardware features.
+This config is included with the Shrinkwrap installation. We also use the `ns-edk2.yaml`
+config. This configuration file is also a part of the Shrinkwrap tool. It defines the
+settings for building and running the firmware using EDK2 on Arm FVPs. The build
+process takes some time. During this step, Shrinkwrap downloads the required Docker
+image and starts a container to clone all the required firmware repositories and build
+the components including the device tree for the FVP.
+
+## Overlay config
+
+At this point, we have everything required to boot our system. Shrinkwrap uses so called overlay
+configuration files. The following file instructs Shrinkwrap to connect all the pieces together
+and locate the kernel image, and rootfs. It can also be used to tweak any of the FVP
+parameters. Create a file in $HOME/workspace directory called `aarch64.yaml` using a text editor of your choice. Copy the contents shown below into the file:
+
+```yaml
+run:
+  rtvars:
+    ROOTFS:
+      value: ~/workspace/rootfs.img
+    CMDLINE:
+      value: ip=dhcp kpti=off root=/dev/vda2 console=ttyAMA0
+    KERNEL:
+      value: ~/workspace/linux-build/arch/arm64/boot/Image
+  params:
+    -C bp.hostbridge.userNetworking: 1
+    -C bp.hostbridge.userNetPorts: 8022=22,8123=8123
+    -C bp.smsc_91c111.enabled: 1
+    -C bp.virtio_net.enabled: 0
+    -C cluster0.NUM_CORES: 1
+    -C cluster1.NUM_CORES: 0
+    -C pctl.CPU-affinities: 0.0.0.0
+```
+
+The most important parts in this configuration file are:
+
+ * Paths to the rootfs image and the kernel image.
+ * The kernel command line, which contains `root=/dev/vda2`, specifying where to locate
+   the filesystem to be mounted at `/`.
+ * The port mapping `8022=22`, which is used for SSH access into the guest system.
+   You can add more ports as needed.
+
+The FVP has many parameters that can be tweaked in this config by adding a `-C param: value`
+line to the `params` section. Refer to the [Fast Models Fixed Virtual Platforms Reference Guide](https://developer.arm.com/documentation/100966/latest/Getting-Started-with-Fixed-Virtual-Platforms/Configuring-the-model).
+for more details.
+
+## Run FVP with Shrinkwrap
+
+To run the FVP using Docker, execute the following command:
+
+```bash
+shrinkwrap run ns-edk2.yaml --overlay $HOME/workspace/aarch64.yaml
+```
+
+At first, Shrinkwrap starts a Docker container and runs the FVP in it. At the beginning
+of the output, you may see a line containing the IP address that you need to use for SSH
+access into the guest system:
+
+```
+Press '^]' to quit shrinkwrap.
+All other keys are passed through.
+Environment ip address: 172.17.0.2.
+```
+
+It also tells you how to stop the FVP execution: press `Ctrl+]` (more on this later).
+
+Booting the Linux on the FVP takes some time. Look out for the system log messages about
+growing the root partition to utilize the empty disk space we created earlier.
+
+```
+=> Growing root partition
+CHANGED: partition=2 ... old: size=1316864 ... new: size=5511135
+```
+
+After a couple of minutes, you should be able to SSH in a different terminal into the
+guest OS running on the FVP using the IP address reported by the Shrinkwrap tool and the
+port number specified earlier in our overlay config:
+
+```bash
+ssh root@172.17.0.2 -p 8022
+```
+
+The default password is `voidlinux`.
+
+When you have logged in, check the properties of your guest system, for example:
+
+```bash
+uname -a
+cat /proc/cpuinfo
+```
+
+## Powering down
+
+You can always press `Ctrl+]` to stop Shrinkwrap in the terminal where Shrinkwrap is
+running. However, this abruptly aborts execution of the FVP. This may leave the filesystem
+in your rootfs image, used by the guest system, in a broken state, resulting in errors
+during the next boot. To avoid this, it is advisable to shut down the guest system gracefully
+from the root console of your guest system, for example:
+
+```bash
+ssh root@172.17.0.2 -p 8022 poweroff
+```
+
+Continue to the next section for additional setup. The remaining steps are optional but it
+helps prepare our guest system for running Glibc tests and doing other complex tasks.
+
diff --git a/content/learning-paths/servers-and-cloud-computing/building-custom-glibc/glibc.md b/content/learning-paths/servers-and-cloud-computing/building-custom-glibc/glibc.md
new file mode 100644
index 0000000000..5491039adf
--- /dev/null
+++ b/content/learning-paths/servers-and-cloud-computing/building-custom-glibc/glibc.md
@@ -0,0 +1,205 @@
+---
+title: Glibc tests on the FVP
+weight: 7
+
+### FIXED, DO NOT MODIFY
+layout: learningpathall
+---
+
+## Prepare kernel headers
+
+For this step you need the GCC cross-toolchain for the `aarch64-linux-gnu` target.
+You can use the same toolchain as we used for building the kernel.
+
+Since we are going to use our Glibc on a system running a specific version of the kernel,
+we should build the Glibc using the kernel headers of the same version. The Glibc build
+scripts automatically pick up your host system's kernel headers unless configured to use
+headers from a specific directory. To ensure that we use correct headers for the kernel,
+we need to install them from source.
+
+We presume that the kernel source is in the `linux` subfolder, and we will install the
+headers in the `linux-headers` subfolder. First, you have to set a few environment variables.
+To do this, run the following commands:
+
+```bash
+cd $HOME/workspace
+export ARCH=arm64
+make -C linux headers_install INSTALL_HDR_PATH=$(pwd)/linux-headers
+```
+
+{{% notice %}}
+If you are running an x86_64 Linux host, the `CROSS_COMPILE` flag needs to be set. Example: export CROSS_COMPILE=aarch64-none-linux-gnu-
+{{% /notice %}}
+
+You should see kernel headers in the `$HOME/workspace/linux-headers/include` folder now.
+We will use this path during the next step.
+
+## Get Glibc sources and build for AArch64 target
+
+Clone the Glibc Git repository:
+
+```bash
+cd $HOME/workspace
+git clone git://sourceware.org/git/glibc.git
+```
+
+To make the following command simpler, let's introduce the `CROSS` variable (notice the hyphen
+at the end):
+
+```bash
+export CROSS=/usr/bin/aarch64-linux-gnu-
+```
+
+Now configure the cross-build for the `aarch64-linux-gnu` target:
+
+```bash
+mkdir glibc-build
+cd glibc-build
+
+LC_ALL=C BUILD_CC=gcc \
+CC=${CROSS}gcc CXX=${CROSS}g++ \
+NM=${CROSS}nm READELF=${CROSS}readelf \
+AR=${CROSS}ar GPROF=${CROSS}gprof \
+OBJDUMP=${CROSS}objdump OBJCOPY=${CROSS}objcopy \
+RANLIB=${CROSS}ranlib \
+../glibc/configure --prefix=/usr \
+  --host=aarch64-linux-gnu \
+  --enable-hardcoded-path-in-tests \
+  --with-headers=$HOME/workspace/linux-headers/include
+```
+
+Notice the path to the kernel headers in the last parameter in the `configure` command and
+also the `include` at the end of it.
+
+Finally, run the build:
+
+```bash
+make -j$(nproc)
+```
+
+## Run tests on FVP
+
+As you are using an AArch64 host, you can run Glibc tests both on your host and on the FVP
+from the same build tree. Before we run some tests, we need to make sure that we have two
+important prerequisites in place.
+
+First, we need to copy the target libraries from your toolchain's sysroot to ensure that
+the tests are using them rather than your OS's libraries. Run the following commands in the
+`glibc-build` folder:
+
+```bash
+cp $(${CROSS}gcc -print-file-name=libstdc++.so.6) .
+cp $(${CROSS}gcc -print-file-name=libgcc_s.so.1) .
+```
+
+Next, we will build the testroot. A Glibc testroot is a collection of files that resembles
+an installation of the Glibc that we have just built. It allows us to create the correct
+environment for the tests without actually installing the Glibc. Tun the following command
+int the Glibc build folder:
+
+```bash
+make $(pwd)/testroot.pristine/install.stamp
+```
+
+Now we can run the tests. Let's start with a single test to understand the structure of the
+command. Ensure the following:
+
+ * The FVP is running
+ * The guest system accepts SSH connections
+ * The Glibc source and build folders are available in the guest system via the NFS share
+ * The paths to these folders on the host and the guest systems are the same
+
+We should set the `TIMEOUTFACTOR` environment variable to extend the timeout for some of the
+tests that may fail just because execution takes longer than usual. This is expected on an
+emulated platform such as an FVP:
+
+```bash
+export TIMEOUTFACTOR=10
+```
+
+If you see any timeouts when running tests on the FVP, increase this value.
+
+To tell the Glibc test system to execute the tests on a remote system (in our case this
+means on the guest system running on the FVP), we will use the test wrapper script that
+is part of the Glibc sources: `scripts/cross-test-ssh.sh`. By default it uses `ssh` as a
+command to start an SSH connection, but it is possible to override it via the `--ssh` option.
+However, this option only accepts single word values. To avoid complexities related to
+using `sh` instead of `bash` and Bash aliases not being expanded in non-interactive shells,
+the easiest way to proceed is as follows:
+
+ * Create a simple shell script and save it using file name `ussh`:
+
+```bash
+#!/usr/bin/env bash
+dbclient -p 8022 "$@"
+```
+
+ Make it executable using the `chmod u+x` command, and save this script in one of the directories in your `PATH`, for example `/usr/bin`:
+
+```bash
+chmod u+x ussh && sudo mv ussh /usr/bin/ussh
+```
+
+To run a single test, use this command:
+
+```bash
+make test t=misc/tst-aarch64-pkey \
+  test-wrapper="/home/user/glibc/scripts/cross-test-ssh.sh --ssh ussh fvp"
+```
+
+Let's see what we have here. The `test` target will build (or rebuild) one test and all
+its dependencies and then run this test. This target requires one parameter, `t`, with the
+name of the test that we need to run. The Glibc tests are grouped into folders, and a test name
+would normally look like `misc/tst-aarch64-pkey` where `misc` is the name of the group and
+`tst-aarch64-pkey` is the name of the test in this group.
+
+When we use SSH test wrapper to run a test on the FVP we need to supply its absolute path along
+with any of the script's arguments as a value of the `test-wrapper` make parameter. Here,
+we use the `--ssh` option of the wrapper script to tell it to use the `ussh` command instead
+of `ssh` and we use `fvp` as the hostname of the remote system. All the setup that we have
+done in the previous steps makes using this wrapper script easier.
+
+To run the same test on your AArch64 host rather than on the FVP, just omit the `test-wrapper=...`
+parameter.
+
+With this particular test, you may see that on your AArch64 host, it reports that it is not
+supported:
+
+```
+UNSUPPORTED: misc/tst-aarch64-pkey
+original exit status 77
+```
+
+And on your FVP with the Linux kernel 6.13 or newer, you should get:
+
+```
+PASS: misc/tst-aarch64-pkey
+original exit status 0
+```
+
+To run a group of tests, use the following command with the `check` target:
+
+```bash
+make check -C $HOME/workspace/glibc/argp \
+  objdir=`pwd` \
+  test-wrapper="$HOME/workspace/glibc/scripts/cross-test-ssh.sh --ssh ussh fvp"
+```
+
+In this instance, we are building and running tests from the `argp` folder. We use the `-C`
+option of `make` to point it to the right directory, and we also supply a path to the
+build folder via the `objdir` parameter (which should be the current directory since we are
+running this command from within the build folder). The `test-wrapper` part remains the same.
+
+To run all the tests, simply do:
+
+```bash
+make check \
+  test-wrapper="$HOME/workspace/glibc/scripts/cross-test-ssh.sh --ssh ussh fvp"
+```
+
+Note that this will take a considerable amount of time. Also, notice that we are not using
+a parallel `make` command for running tests on the FVP. The reason is that the Fast Models
+simulation code runs primarily on a single thread, and running tests in parallel would not
+speed up the execution.
+
+By reaching the end of this learning path, you have completed setting up a Linux system on the FVP, and used it to run Glibc tests.
diff --git a/content/learning-paths/servers-and-cloud-computing/building-custom-glibc/kernel.md b/content/learning-paths/servers-and-cloud-computing/building-custom-glibc/kernel.md
new file mode 100644
index 0000000000..66a13fbd37
--- /dev/null
+++ b/content/learning-paths/servers-and-cloud-computing/building-custom-glibc/kernel.md
@@ -0,0 +1,66 @@
+---
+title: Build Linux kernel
+weight: 3
+
+### FIXED, DO NOT MODIFY
+layout: learningpathall
+---
+
+## Obtain kernel source
+
+The Linux kernel image is the first essential components that you need to build. You are going to build it from source.
+
+There are various ways to obtain the sources for a particular version of the Linux kernel that you want to use. Here, as an example, we obtain a stable
+version from the mainline repository.
+
+```bash
+git clone  https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
+pushd linux
+git checkout v6.13 -b release/6.13
+popd
+```
+
+Note that at the time when you are reading this, there might be a newer version
+available.
+
+Using a stable kernel version is a good starting point. When everything is up
+and running, you can switch to the version of the kernel that you are actually
+interested in running.
+
+## Configure and build kernel
+
+Before moving on, export some environment variables, pointing out some key directories and options.
+All the build output, including the binary that you intend to use later, will be put in
+the `linux-build` subfolder. Run the following commands in the workspace directory:
+
+
+```bash
+export KBUILD_OUTPUT="$(pwd)/linux-build"
+export ARCH=arm64
+````
+
+{{% notice %}}
+If you are running an x86_64 host, you will need to set the `CROSS_COMPILE` environment variable to point to your GCC cross compile toolchain. For example: export CROSS_COMPILE=aarch64-none-linux-gnu-
+{{% /notice %}}
+
+Next, build the kernel image:
+```bash
+make -C linux mrproper
+make -C linux defconfig
+make -C linux Image -j $(nproc)
+```
+
+The `mrproper` target is used to clean the build folder. It will also create
+this folder if it doesn't exist. The `defconfig` target generates the default
+configuration for the selected architecture, `arm64`. At this point, you may
+change this configuration if necessary, for example, if the feature that you
+are interested in is not enabled by default. To do this, you would usually run
+`make menuconfig` in the `linux-build` folder. Finally, building the `Image`
+target will produce the binary that we need.
+
+When the build completes, check that the kernel image binary is present:
+
+```bash
+ls linux-build/arch/arm64/boot/Image
+```
+
diff --git a/content/learning-paths/servers-and-cloud-computing/building-custom-glibc/naming-conventions.md b/content/learning-paths/servers-and-cloud-computing/building-custom-glibc/naming-conventions.md
new file mode 100644
index 0000000000..1305a8e9de
--- /dev/null
+++ b/content/learning-paths/servers-and-cloud-computing/building-custom-glibc/naming-conventions.md
@@ -0,0 +1,44 @@
+---
+title: Naming Conventions
+weight: 2
+
+### FIXED, DO NOT MODIFY
+layout: learningpathall
+---
+
+You may need root access on your host system to do minimal setup and install packages that are described in the following sections.
+
+## Naming conventions
+
+In the following sections we use host system to checkout sources and build various
+tools and we also make configuration changes to the guest system that will run on
+the Arm [Fixed Virtual Platform (FVP)][1] model.
+
+{{%notice  Note %}}
+The explicit path of where tools should be installed is listed below. It is important to follow this structure.
+{{%/notice%}}
+
+Table 1. Directory layout
+
+| Path                                 | Description                                |
+|--------------------------------------|--------------------------------------------|
+| `/path/to/cross/gcc`                 | GCC cross toolchain installation directory |
+| `/home/user`                         | Home directory of your host non-root user  |
+| `/home/user/shrinkwrap`              | Directory of shrinkwrap installation       |
+| `/home/user/workspace`               | Workspace directory                        |
+| `/home/user/workspace/linux`         | Folder with the Linux kernel sources       |
+| `/home/user/workspace/linux-headers` | Directory for installing kernel headers    |
+| `/home/user/workspace/linux-build`   | Folder for the Linux kernel build output   |
+| `/home/user/workspace/glibc`         | Folder for the Glibc sources               |
+| `/home/user/workspace/glibc-build`   | Directory for the Glibc build output       |
+
+
+
+We presume that the GCC cross toolchain installation directory contains everything a
+cross toolchain would need, for example, the path to the `gcc` tool would be
+`/path/to/cross/gcc/bin/aarch64-none-linux-gnu-gcc`.
+
+In the next steps we create a Python virtual environment. It doesn't matter where
+it is located, but to avoid ambiguity let's presume it is in `~/workspace/venv`.
+
+[1]: https://developer.arm.com/downloads/-/arm-ecosystem-fvps
\ No newline at end of file
diff --git a/content/learning-paths/servers-and-cloud-computing/building-custom-glibc/rootfs.md b/content/learning-paths/servers-and-cloud-computing/building-custom-glibc/rootfs.md
new file mode 100644
index 0000000000..cf13a1a021
--- /dev/null
+++ b/content/learning-paths/servers-and-cloud-computing/building-custom-glibc/rootfs.md
@@ -0,0 +1,50 @@
+---
+title: Build the Root file system
+weight: 4
+
+### FIXED, DO NOT MODIFY
+layout: learningpathall
+---
+
+## Download and unpack root file system
+
+The root file system (or rootfs for short) is the second essential component
+that you will need. The root file system is a collection of files that are essential
+for a Linux system to function. Usually, it also includes various tools that
+make using your system more convenient.
+
+Since you are providing your own kernel, there isn't much that is required from a
+rootfs. All you need is for it to be built for the AArch64 target and contain
+the tools that you require.
+
+To speed things up for this learning path, you will use a readily available rootfs
+for the [Void Linux](https://voidlinux.org/) distro. There are other options for obtaining a working
+root file system, but the rest of this learning path assumes that you are using
+the Void Linux distribution.
+
+Download the image:
+
+```bash
+cd $HOME/workspace
+wget https://repo-default.voidlinux.org/live/20250202/void-rpi-aarch64-20250202.img.xz
+```
+
+Note that at the time when you are reading this, there might be a newer version available.
+
+Let's unpack and resize the image. The added size determines how much free disk space
+you will have in your guest system:
+
+```bash
+unxz --keep void-rpi-aarch64-20250202.img.xz
+mv void-rpi-aarch64-20250202.img rootfs.img
+truncate -s +2G rootfs.img
+```
+
+Here you added 2 GiB of free space. Of course, the file system in this image is not actually
+resized at this point. Void Linux will be able to do it automatically during the first
+boot.
+
+Note that when we run our system, the rootfs image file will be modified. If something
+goes wrong, the image might be corrupted, and you might not be able to boot from it again.
+That's why it's recommended to create a backup copy after the initial setup.
+
diff --git a/content/learning-paths/servers-and-cloud-computing/building-custom-glibc/setup.md b/content/learning-paths/servers-and-cloud-computing/building-custom-glibc/setup.md
new file mode 100644
index 0000000000..9fa2ca3c3d
--- /dev/null
+++ b/content/learning-paths/servers-and-cloud-computing/building-custom-glibc/setup.md
@@ -0,0 +1,292 @@
+---
+title: Guest and host setup
+weight: 6
+
+### FIXED, DO NOT MODIFY
+layout: learningpathall
+---
+
+In this section, you will configure the guest system to make it easier running more complex tasks.
+
+## Void Linux basics
+
+For a detailed guide on Void Linux, refer to the [documentation](https://docs.voidlinux.org/).
+
+Commands in this section are executed on the guest system.
+
+It is recommended to use Bash as your default shell on the guest system. To change
+the default shell for a user, run this command:
+
+```bash
+chsh -s /bin/bash root
+```
+
+You install packages using `xbps-install`. The `-S` option updates the repository cache. You need to run this once before installing additional packages. For example, install `vim` with the following commands:
+
+```bash
+xbps-install -y -S
+xbps-install -y vim
+```
+
+You can add a bit of automation to speed up configuring your system from scratch:
+
+```bash
+required=(nfs-utils sv-netmount rpcbind)
+optional=(vim binutils make strace python3)
+for p in "${required[@]}" "${optional[@]}"; do
+  xbps-query -l | grep -w ${p} > /dev/null || {
+    xbps-install -y ${p}
+  }
+done
+```
+
+Installing the required packages is important for the following steps. Choose
+optional packages according to your use case. You can always install or remove
+packages later.
+
+The rootfs image that we are using is limited in size, and it might be useful
+to free up some space. Since we use our own kernel and firmware, we can safely
+delete the following packages:
+
+```bash
+unused=(rpi-firmware rpi-kernel)
+for p in "${unused[@]}"; do
+  test -f "/etc/xbps.d/disable-${p}.conf" || {
+    echo "ignorepkg=${p}" > "/etc/xbps.d/disable-${p}.conf"
+    xbps-remove -y ${p}
+  }
+done
+```
+
+Here, you also mask these packages to prevent them from being installed automatically
+during system updates, saving time in the process.
+
+The last two code snippets are written so that you can re-run them multiple times.
+If a change has already been applied, it will be skipped.
+
+Optionally, to update your guest OS, run:
+
+```bash
+xbps-install -y -Su
+```
+
+## Lightweight SSH server
+
+Commands in this section are executed on the guest system.
+
+Our main interaction with the guest system will be via SSH. Running software on an
+FVP is slower than on real hardware, so we want to reduce the overhead. One way to
+do this is by replacing the preinstalled OpenSSH server with a more lightweight
+alternative, such as [Dropbear](https://matt.ucc.asn.au/dropbear/dropbear.html).
+
+First, install Dropbear and enable corresponding service:
+
+```bash
+xbps-query -l | grep -w dropbear > /dev/null || {
+  xbps-install -y dropbear
+}
+
+test -h /var/service/dropbear || {
+  ln -s /etc/sv/dropbear /var/service/
+}
+```
+
+Now, disable the OpenSSH server:
+
+```bash
+test -h /var/service/sshd && {
+  sv stop sshd
+  rm -vf /var/service/sshd
+}
+```
+
+Finally, create a simple service that prints a message to the system log when the guest
+system is ready for incoming SSH connections:
+
+```bash
+test -h /var/service/hello || {
+  mkdir -p /etc/sv/hello
+  cat <<EOF > /etc/sv/hello/run
+#!/bin/bash
+sv status dropbear || exit 1
+. /etc/runit/functions
+msg "SSH service is ready"
+sv stop hello
+EOF
+  chmod a+x /etc/sv/hello/run
+  ln -s /etc/sv/hello /var/service/
+}
+```
+
+During the next boot, you should see this message in the system log. You might also
+experience an improvement in SSH connection speed:
+
+```
+=> Initialization complete, running stage 2...
+...
+=> SSH service is ready
+
+```
+
+## Configure SSH on host
+
+Commands in this section should be run on the host system.
+
+Using a password for SSH can be inconvenient when automating tasks. The solution is
+to set up authentication via SSH keys. Since we are using the Dropbear server, we need
+to use the Dropbear client and configure SSH keys for it.
+
+First, install the Dropbear client:
+
+```bash
+sudo apt -y install dropbear-bin
+```
+
+To avoid typing the guest system's IP address every time, add it to `/etc/hosts`:
+
+```
+172.17.0.2 fvp
+```
+
+Now, create an SSH key and upload its public part to the guest system:
+
+```bash
+test -f ~/.ssh/id_dropbear || dropbearkey -t rsa -f ~/.ssh/id_dropbear
+dbclient -l root -p 8022 fvp mkdir -p .ssh
+dropbearkey -y -f ~/.ssh/id_dropbear | grep "^ssh-rsa " | \
+dbclient -l root -p 8022 -T fvp "cat >> .ssh/authorized_keys"
+```
+
+Check that you can SSH into the guest system using the Dropbear SSH client without
+entering a password:
+
+```bash
+dbclient -l root -p 8022 fvp
+```
+
+## Set up a non-root user
+
+Commands in this section are executed on the guest system.
+
+Creating a non-root user in the guest system can be practical. Additionally, we will
+copy the same SSH key used for the root user to avoid setting up different key pair
+and having to alternate between them. For a non-root user in the guest system we
+will use the username `user`.
+
+SSH as root into the guest system running on FVP and execute these commands:
+
+```bash
+id -u user 2> /dev/null || useradd -m -s /bin/bash user
+
+test -d /home/user/.ssh || {
+  mkdir -p /home/user/.ssh
+  chown user:user /home/user/.ssh
+  chmod 0700 /home/user/.ssh
+}
+
+test -f /root/.ssh/authorized_keys && {
+  cp /root/.ssh/authorized_keys /home/user/.ssh/authorized_keys
+  chown user:user /home/user/.ssh/authorized_keys
+  chmod 0600 /home/user/.ssh/authorized_keys
+}
+```
+
+Now, you should be able to SSH into the guest system running on the FVP as a non-root user
+without having to enter a password:
+
+```bash
+dbclient -p 8022 fvp
+```
+
+## Configure a shared workspace
+
+Commands in this section are executed first on the host system and then on the guest.
+
+It is useful to share a folder between the host and guest systems to facilitate file exchange.
+This is especially useful for running Glibc tests, as we will see in the following steps.
+
+To enable file sharing, we leverage the local network set up by Docker and configure an NFS
+share. The FVP offers a Plan 9 filesystem protocol server as an alternative to using NFS,
+but it does not currently support some file system operations such as `flock` which is used,
+for example, by the Glibc tests, so it is not suitable for our use case.
+
+On your host, install the NFS server (this example is for Debian or Ubuntu):
+
+```bash
+sudo apt -y install nfs-kernel-server
+sudo systemctl disable nfs-kernel-server
+```
+
+Add this line to the `/etc/exports` file (we presume that host user ID is `1000` and group ID
+is `1000`, amend according to your actual setup):
+
+```
+/home/user/workspace 172.17.0.0/24(rw,sync,no_subtree_check,all_squash,anonuid=1000,anongid=1000,insecure)
+```
+
+We allow access only from clients within the Docker network (`172.17.0.0/24`) and use the `insecure`
+option to avoid complexities of requiring privileged ports on the guest system. To ensure that
+the file permissions are aligned between the guest and the host systems, we also specify `anonuid`
+and `anongid` options.
+
+Restart the NFS server for the changes to take effect:
+
+```bash
+sudo systemctl restart nfs-kernel-server
+```
+
+Now, SSH into the guest system as root and continue the setup on the guest side:
+
+```bash
+mkdir -p /home/user/workspace
+chown user:user /home/user/workspace
+```
+
+Edit the guest system's `/etc/fstab` to mount the NFS share automatically when the system running
+on the FVP boots:
+
+```bash
+grep "FVP NFS shared folder" /etc/fstab > /dev/null || {
+  echo "# FVP NFS shared folder" >> /etc/fstab
+  echo "172.17.0.1:/home/user/workspace /home/user/workspace nfs4 defaults,_netdev 0 0" >> /etc/fstab
+}
+```
+
+Finally, enable the necessary services for the NFS mounting:
+
+```bash
+services=(netmount rpcbind statd)
+for s in "${services[@]}"; do
+  test -h /var/service/${s} || {
+    ln -s /etc/sv/${s} /var/service/
+  }
+done
+```
+
+At the next boot, you should be able to SSH into the guest system as a non-root user and
+access files in the workspace directory, which should be synchronized between the guest
+and the host systems.
+
+## More configuration
+
+Disabling Address Space Layout Randomization (ASLR) in the guest system helps reducing host memory usage by the FVP:
+
+```bash
+mkdir -p /etc/sysctl.d
+test -f /etc/sysctl.d/01-disable-aslr.conf || {
+  echo "kernel.randomize_va_space = 0" > /etc/sysctl.d/01-disable-aslr.conf
+}
+```
+
+These changes help prevent the OOM (Out of Memory) killer from unnecessarily terminating
+processes on the guest system when they consume too much memory:
+
+```bash
+mkdir -p /etc/sysctl.d
+test -f /etc/sysctl.d/02-disable-vm-overcommit.conf || {
+  echo "vm.overcommit_memory = 2" > /etc/sysctl.d/02-disable-vm-overcommit.conf
+}
+```
+
+You are now ready to do put your Void Linux system to the test. Let'sbuild the Glibc from source and run its tests on the FVP.
+

From d4c4d02a4d6025f09bba096894fd29f945b4ec17 Mon Sep 17 00:00:00 2001
From: Your Name <you@example.com>
Date: Mon, 24 Mar 2025 10:32:35 +0000
Subject: [PATCH 02/19] check fvp + rootfs

---
 .../building-custom-glibc/fvp.md              | 25 +++++++++++--------
 .../building-custom-glibc/rootfs.md           | 17 +++----------
 2 files changed, 18 insertions(+), 24 deletions(-)

diff --git a/content/learning-paths/servers-and-cloud-computing/building-custom-glibc/fvp.md b/content/learning-paths/servers-and-cloud-computing/building-custom-glibc/fvp.md
index fe52f77ef7..579b22f7a2 100644
--- a/content/learning-paths/servers-and-cloud-computing/building-custom-glibc/fvp.md
+++ b/content/learning-paths/servers-and-cloud-computing/building-custom-glibc/fvp.md
@@ -39,26 +39,23 @@ repository. Run this command in the workspace directory:
 
 ```bash
 git clone https://git.gitlab.arm.com/tooling/shrinkwrap.git
-export PATH=${PATH}:${HOME}/workspace/shrinkwrap/shrinkwrap
+export PATH=${PATH}:$(pwd)/shrinkwrap/shrinkwrap
 ```
 
 Putting Shrinkwrap's main executable on your `PATH` is all you need to install the tool.
 To check that it works, ensure that the Python virtual environment we created earlier
-is activated, then run this command:
+is activated, then run this command to confirm shrinkwrap has been correctly installed.
 
 ```bash
 shrinkwrap --version
 ```
 
-You should see a version printed.
 
-```output
-shrinkwrap v1.0.0
-```
 
 ## Build firmware for the FVP
 
-Now, you can use the Shrinkwrap tool to build the firmware, the third essential ingredient in our
+Before proceeding, ensure that Docker is installed and usable. Follow the installation
+instructions for your distro. Now, you can use the Shrinkwrap tool to build the firmware, the third essential ingredient in our
 setup. The following step needs to be done once although you will need to repeat it if you
 want to rebuild the firmware:
 
@@ -79,17 +76,17 @@ the components including the device tree for the FVP.
 At this point, we have everything required to boot our system. Shrinkwrap uses so called overlay
 configuration files. The following file instructs Shrinkwrap to connect all the pieces together
 and locate the kernel image, and rootfs. It can also be used to tweak any of the FVP
-parameters. Create a file in $HOME/workspace directory called `aarch64.yaml` using a text editor of your choice. Copy the contents shown below into the file:
+parameters. Create a file in $HOME/workspace directory called `aarch64.yaml` using a text editor of your choice. Copy the contents shown below into the file. Under the ROOTFS and KERNEL values, replace `user` with the the appropriate value (e.g., ubuntu).
 
 ```yaml
 run:
   rtvars:
     ROOTFS:
-      value: ~/workspace/rootfs.img
+      value: /home/user/workspace/rootfs.img
     CMDLINE:
       value: ip=dhcp kpti=off root=/dev/vda2 console=ttyAMA0
     KERNEL:
-      value: ~/workspace/linux-build/arch/arm64/boot/Image
+      value: /home/user/workspace/linux-build/arch/arm64/boot/Image
   params:
     -C bp.hostbridge.userNetworking: 1
     -C bp.hostbridge.userNetPorts: 8022=22,8123=8123
@@ -117,7 +114,7 @@ for more details.
 To run the FVP using Docker, execute the following command:
 
 ```bash
-shrinkwrap run ns-edk2.yaml --overlay $HOME/workspace/aarch64.yaml
+shrinkwrap run ns-edk2.yaml --overlay ~/workspace/aarch64.yaml
 ```
 
 At first, Shrinkwrap starts a Docker container and runs the FVP in it. At the beginning
@@ -157,6 +154,12 @@ uname -a
 cat /proc/cpuinfo
 ```
 
+For example, the following terminal output is observed.
+
+```output
+cat /proc/cpuinfoLinux void-live 6.13.0 #1 SMP PREEMPT Fri Mar 21 10:16:33 UTC 2025 aarch64 GNU/Linux
+```
+
 ## Powering down
 
 You can always press `Ctrl+]` to stop Shrinkwrap in the terminal where Shrinkwrap is
diff --git a/content/learning-paths/servers-and-cloud-computing/building-custom-glibc/rootfs.md b/content/learning-paths/servers-and-cloud-computing/building-custom-glibc/rootfs.md
index cf13a1a021..5230f139de 100644
--- a/content/learning-paths/servers-and-cloud-computing/building-custom-glibc/rootfs.md
+++ b/content/learning-paths/servers-and-cloud-computing/building-custom-glibc/rootfs.md
@@ -8,24 +8,15 @@ layout: learningpathall
 
 ## Download and unpack root file system
 
-The root file system (or rootfs for short) is the second essential component
-that you will need. The root file system is a collection of files that are essential
-for a Linux system to function. Usually, it also includes various tools that
-make using your system more convenient.
+The root file system (or rootfs for short) is the second essential component that you will need. The root file system is a collection of files that are essential for a Linux system to function. Usually, it also includes various tools that make using your system more convenient.
 
-Since you are providing your own kernel, there isn't much that is required from a
-rootfs. All you need is for it to be built for the AArch64 target and contain
-the tools that you require.
+Since you are providing your own kernel, there isn't much that is required from a rootfs. All you need is for it to be built for the AArch64 target and contain the tools that you require.
 
-To speed things up for this learning path, you will use a readily available rootfs
-for the [Void Linux](https://voidlinux.org/) distro. There are other options for obtaining a working
-root file system, but the rest of this learning path assumes that you are using
-the Void Linux distribution.
+To speed things up for this learning path, you will use a readily available rootfs for the [Void Linux](https://voidlinux.org/) distro. There are other options for obtaining a working root file system, but the rest of this learning path assumes that you are using the Void Linux distribution.
 
-Download the image:
+Download the image (make sure you download into the directory detailed in the 'Naming Conventions' section)
 
 ```bash
-cd $HOME/workspace
 wget https://repo-default.voidlinux.org/live/20250202/void-rpi-aarch64-20250202.img.xz
 ```
 

From 8fd154c13eb4ce9df36b78a6acc8ba1b8435dea9 Mon Sep 17 00:00:00 2001
From: Your Name <you@example.com>
Date: Mon, 24 Mar 2025 11:58:36 +0000
Subject: [PATCH 03/19] add

---
 .../building-custom-glibc/setup.md                            | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/content/learning-paths/servers-and-cloud-computing/building-custom-glibc/setup.md b/content/learning-paths/servers-and-cloud-computing/building-custom-glibc/setup.md
index 9fa2ca3c3d..e9d8e25f04 100644
--- a/content/learning-paths/servers-and-cloud-computing/building-custom-glibc/setup.md
+++ b/content/learning-paths/servers-and-cloud-computing/building-custom-glibc/setup.md
@@ -25,10 +25,12 @@ You install packages using `xbps-install`. The `-S` option updates the repositor
 
 ```bash
 xbps-install -y -S
+```
+```bash
 xbps-install -y vim
 ```
 
-You can add a bit of automation to speed up configuring your system from scratch:
+You can add a bit of automation to speed up configuring your system from scratch. Paste the bash script below into a file and run. 
 
 ```bash
 required=(nfs-utils sv-netmount rpcbind)

From 3eaa56f6e263f3dc1c3e44759e925ba9c0e530cb Mon Sep 17 00:00:00 2001
From: Your Name <you@example.com>
Date: Tue, 25 Mar 2025 17:22:02 +0000
Subject: [PATCH 04/19] review setup

---
 .../building-custom-glibc/setup.md            | 29 ++++++++++---------
 1 file changed, 15 insertions(+), 14 deletions(-)

diff --git a/content/learning-paths/servers-and-cloud-computing/building-custom-glibc/setup.md b/content/learning-paths/servers-and-cloud-computing/building-custom-glibc/setup.md
index e9d8e25f04..0a2f0202de 100644
--- a/content/learning-paths/servers-and-cloud-computing/building-custom-glibc/setup.md
+++ b/content/learning-paths/servers-and-cloud-computing/building-custom-glibc/setup.md
@@ -133,7 +133,7 @@ experience an improvement in SSH connection speed:
 ## Configure SSH on host
 
 Commands in this section should be run on the host system.
-
+nano
 Using a password for SSH can be inconvenient when automating tasks. The solution is
 to set up authentication via SSH keys. Since we are using the Dropbear server, we need
 to use the Dropbear client and configure SSH keys for it.
@@ -178,18 +178,19 @@ will use the username `user`.
 SSH as root into the guest system running on FVP and execute these commands:
 
 ```bash
-id -u user 2> /dev/null || useradd -m -s /bin/bash user
-
-test -d /home/user/.ssh || {
-  mkdir -p /home/user/.ssh
-  chown user:user /home/user/.ssh
-  chmod 0700 /home/user/.ssh
-}
-
-test -f /root/.ssh/authorized_keys && {
-  cp /root/.ssh/authorized_keys /home/user/.ssh/authorized_keys
-  chown user:user /home/user/.ssh/authorized_keys
-  chmod 0600 /home/user/.ssh/authorized_keys
+# Create user
+id -u user 2> /dev/null || {
+  useradd -m -s /bin/bash user
+  test -d /home/user/.ssh || {
+    mkdir -p /home/user/.ssh
+    chown user:user /home/user/.ssh
+    chmod 0700 /home/user/.ssh
+  }
+  test -f /root/.ssh/authorized_keys && {
+    cp /root/.ssh/authorized_keys /home/user/.ssh/authorized_keys
+    chown user:user /home/user/.ssh/authorized_keys
+    chmod 0600 /home/user/.ssh/authorized_keys
+  }
 }
 ```
 
@@ -197,7 +198,7 @@ Now, you should be able to SSH into the guest system running on the FVP as a non
 without having to enter a password:
 
 ```bash
-dbclient -p 8022 fvp
+dbclient -l user -p 8022 fvp
 ```
 
 ## Configure a shared workspace

From 2600580c473c3358ce12cc877238b88c6fb5f1c2 Mon Sep 17 00:00:00 2001
From: Your Name <you@example.com>
Date: Wed, 26 Mar 2025 10:09:11 +0000
Subject: [PATCH 05/19] minor clarification to adjust user

---
 .../building-custom-glibc/setup.md                   | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/content/learning-paths/servers-and-cloud-computing/building-custom-glibc/setup.md b/content/learning-paths/servers-and-cloud-computing/building-custom-glibc/setup.md
index 0a2f0202de..b5a416cfc1 100644
--- a/content/learning-paths/servers-and-cloud-computing/building-custom-glibc/setup.md
+++ b/content/learning-paths/servers-and-cloud-computing/building-custom-glibc/setup.md
@@ -220,11 +220,11 @@ sudo apt -y install nfs-kernel-server
 sudo systemctl disable nfs-kernel-server
 ```
 
-Add this line to the `/etc/exports` file (we presume that host user ID is `1000` and group ID
-is `1000`, amend according to your actual setup):
+Add this line to the `/etc/exports` file (we presume that host user ID is `1000`, group ID
+is `1000` and user is called user, amend according to your actual setup). 
 
 ```
-/home/user/workspace 172.17.0.0/24(rw,sync,no_subtree_check,all_squash,anonuid=1000,anongid=1000,insecure)
+/home/<user>/workspace 172.17.0.0/24(rw,sync,no_subtree_check,all_squash,anonuid=1000,anongid=1000,insecure)
 ```
 
 We allow access only from clients within the Docker network (`172.17.0.0/24`) and use the `insecure`
@@ -246,12 +246,12 @@ chown user:user /home/user/workspace
 ```
 
 Edit the guest system's `/etc/fstab` to mount the NFS share automatically when the system running
-on the FVP boots:
+on the FVP boots. Make sure to correctly replace use the name of the user on the host if it is different (e.g., ubuntu):
 
 ```bash
 grep "FVP NFS shared folder" /etc/fstab > /dev/null || {
   echo "# FVP NFS shared folder" >> /etc/fstab
-  echo "172.17.0.1:/home/user/workspace /home/user/workspace nfs4 defaults,_netdev 0 0" >> /etc/fstab
+  echo "172.17.0.1:/home/<user>/workspace /home/user/workspace nfs4 defaults,_netdev 0 0" >> /etc/fstab
 }
 ```
 
@@ -267,7 +267,7 @@ done
 ```
 
 At the next boot, you should be able to SSH into the guest system as a non-root user and
-access files in the workspace directory, which should be synchronized between the guest
+access files in the `/home/user/workspace` directory, which should be synchronized between the guest
 and the host systems.
 
 ## More configuration

From b0a43ee4674edfa4bfc80e522fffcf767a6cf734 Mon Sep 17 00:00:00 2001
From: Your Name <you@example.com>
Date: Mon, 31 Mar 2025 16:43:14 +0100
Subject: [PATCH 06/19] review FVP

---
 .../servers-and-cloud-computing/building-custom-glibc/fvp.md    | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/content/learning-paths/servers-and-cloud-computing/building-custom-glibc/fvp.md b/content/learning-paths/servers-and-cloud-computing/building-custom-glibc/fvp.md
index 579b22f7a2..dbe22ed04a 100644
--- a/content/learning-paths/servers-and-cloud-computing/building-custom-glibc/fvp.md
+++ b/content/learning-paths/servers-and-cloud-computing/building-custom-glibc/fvp.md
@@ -76,7 +76,7 @@ the components including the device tree for the FVP.
 At this point, we have everything required to boot our system. Shrinkwrap uses so called overlay
 configuration files. The following file instructs Shrinkwrap to connect all the pieces together
 and locate the kernel image, and rootfs. It can also be used to tweak any of the FVP
-parameters. Create a file in $HOME/workspace directory called `aarch64.yaml` using a text editor of your choice. Copy the contents shown below into the file. Under the ROOTFS and KERNEL values, replace `user` with the the appropriate value (e.g., ubuntu).
+parameters. Create a file in $HOME/workspace directory called `aarch64.yaml` using a text editor of your choice. Copy the contents shown below into the file. Under the ROOTFS and KERNEL values. If needed, replace `user` with the the appropriate name for your system (e.g., ubuntu).
 
 ```yaml
 run:

From 7061bce6f1bda02a4c69d19bc288aa1b2fea3cfa Mon Sep 17 00:00:00 2001
From: Your Name <you@example.com>
Date: Mon, 31 Mar 2025 17:28:01 +0100
Subject: [PATCH 07/19] final check

---
 .../building-custom-glibc/_index.md           |  2 +-
 .../building-custom-glibc/glibc.md            | 22 ++++++++++---------
 .../building-custom-glibc/kernel.md           |  6 ++---
 .../naming-conventions.md                     | 10 ++++-----
 4 files changed, 20 insertions(+), 20 deletions(-)

diff --git a/content/learning-paths/servers-and-cloud-computing/building-custom-glibc/_index.md b/content/learning-paths/servers-and-cloud-computing/building-custom-glibc/_index.md
index 998dc3a3e3..5b7130b469 100644
--- a/content/learning-paths/servers-and-cloud-computing/building-custom-glibc/_index.md
+++ b/content/learning-paths/servers-and-cloud-computing/building-custom-glibc/_index.md
@@ -5,7 +5,7 @@ minutes_to_complete: 60
 
 who_is_this_for: >
   Developers who wish to run a Linux system (optionally using a custom kernel and a C library) on an Arm Fixed Virtual Platform (FVP) model. For example, this
-  guide might be useful if you want to test patches related to new architectural features for the Linux kernel or Glibc.
+  guide might be useful if you want to test patches related to new architectural features for the Linux kernel or Glibc. 
 
 learning_objectives: 
   - Build the Linux kernel.
diff --git a/content/learning-paths/servers-and-cloud-computing/building-custom-glibc/glibc.md b/content/learning-paths/servers-and-cloud-computing/building-custom-glibc/glibc.md
index 5491039adf..736b8efdef 100644
--- a/content/learning-paths/servers-and-cloud-computing/building-custom-glibc/glibc.md
+++ b/content/learning-paths/servers-and-cloud-computing/building-custom-glibc/glibc.md
@@ -8,7 +8,7 @@ layout: learningpathall
 
 ## Prepare kernel headers
 
-For this step you need the GCC cross-toolchain for the `aarch64-linux-gnu` target.
+For this step you need the GCC cross-toolchain for the `aarch64-none-linux-gnu` target.
 You can use the same toolchain as we used for building the kernel.
 
 Since we are going to use our Glibc on a system running a specific version of the kernel,
@@ -22,15 +22,16 @@ headers in the `linux-headers` subfolder. First, you have to set a few environme
 To do this, run the following commands:
 
 ```bash
-cd $HOME/workspace
+# Make sure that cross GCC is on the PATH
+export PATH=/path/to/cross/gcc/bin:${PATH}
+# Specify target architecture
 export ARCH=arm64
+# Specify cross compiler
+export CROSS_COMPILE=aarch64-none-linux-gnu-
+# Install headers
 make -C linux headers_install INSTALL_HDR_PATH=$(pwd)/linux-headers
 ```
 
-{{% notice %}}
-If you are running an x86_64 Linux host, the `CROSS_COMPILE` flag needs to be set. Example: export CROSS_COMPILE=aarch64-none-linux-gnu-
-{{% /notice %}}
-
 You should see kernel headers in the `$HOME/workspace/linux-headers/include` folder now.
 We will use this path during the next step.
 
@@ -47,15 +48,16 @@ To make the following command simpler, let's introduce the `CROSS` variable (not
 at the end):
 
 ```bash
-export CROSS=/usr/bin/aarch64-linux-gnu-
+CROSS=/path/to/cross/gcc/bin/aarch64-none-linux-gnu-
 ```
 
-Now configure the cross-build for the `aarch64-linux-gnu` target:
+Now configure the cross-build for the `aarch64-none-linux-gnu` target:
 
 ```bash
 mkdir glibc-build
 cd glibc-build
 
+# Configure Glibc:
 LC_ALL=C BUILD_CC=gcc \
 CC=${CROSS}gcc CXX=${CROSS}g++ \
 NM=${CROSS}nm READELF=${CROSS}readelf \
@@ -63,9 +65,9 @@ AR=${CROSS}ar GPROF=${CROSS}gprof \
 OBJDUMP=${CROSS}objdump OBJCOPY=${CROSS}objcopy \
 RANLIB=${CROSS}ranlib \
 ../glibc/configure --prefix=/usr \
-  --host=aarch64-linux-gnu \
+  --host=aarch64-none-linux-gnu \
   --enable-hardcoded-path-in-tests \
-  --with-headers=$HOME/workspace/linux-headers/include
+  --with-headers=/home/user/workspace/linux-headers/include
 ```
 
 Notice the path to the kernel headers in the last parameter in the `configure` command and
diff --git a/content/learning-paths/servers-and-cloud-computing/building-custom-glibc/kernel.md b/content/learning-paths/servers-and-cloud-computing/building-custom-glibc/kernel.md
index 66a13fbd37..b4b4ad48e4 100644
--- a/content/learning-paths/servers-and-cloud-computing/building-custom-glibc/kernel.md
+++ b/content/learning-paths/servers-and-cloud-computing/building-custom-glibc/kernel.md
@@ -37,12 +37,10 @@ the `linux-build` subfolder. Run the following commands in the workspace directo
 ```bash
 export KBUILD_OUTPUT="$(pwd)/linux-build"
 export ARCH=arm64
+# Specify cross compiler
+export CROSS_COMPILE=aarch64-none-linux-gnu-
 ````
 
-{{% notice %}}
-If you are running an x86_64 host, you will need to set the `CROSS_COMPILE` environment variable to point to your GCC cross compile toolchain. For example: export CROSS_COMPILE=aarch64-none-linux-gnu-
-{{% /notice %}}
-
 Next, build the kernel image:
 ```bash
 make -C linux mrproper
diff --git a/content/learning-paths/servers-and-cloud-computing/building-custom-glibc/naming-conventions.md b/content/learning-paths/servers-and-cloud-computing/building-custom-glibc/naming-conventions.md
index 1305a8e9de..72f00dea79 100644
--- a/content/learning-paths/servers-and-cloud-computing/building-custom-glibc/naming-conventions.md
+++ b/content/learning-paths/servers-and-cloud-computing/building-custom-glibc/naming-conventions.md
@@ -15,8 +15,10 @@ tools and we also make configuration changes to the guest system that will run o
 the Arm [Fixed Virtual Platform (FVP)][1] model.
 
 {{%notice  Note %}}
-The explicit path of where tools should be installed is listed below. It is important to follow this structure.
-{{%/notice%}}
+Tools must be installed in the specified paths for clarity and best practices. The GCC cross toolchain directory should include all necessary tools. For example, the `gcc` tool path would be `/path/to/cross/gcc/bin/aarch64-none-linux-gnu-gcc`. Note: This may differ from the cross compiler provided by your distribution's package manager.
+{{%/notice%}}. 
+
+[This resource](https://wiki.osdev.org/GCC_Cross-Compiler#Using_the_new_Compiler) may be useful for creating a GCC cross compiler. 
 
 Table 1. Directory layout
 
@@ -34,9 +36,7 @@ Table 1. Directory layout
 
 
 
-We presume that the GCC cross toolchain installation directory contains everything a
-cross toolchain would need, for example, the path to the `gcc` tool would be
-`/path/to/cross/gcc/bin/aarch64-none-linux-gnu-gcc`.
+
 
 In the next steps we create a Python virtual environment. It doesn't matter where
 it is located, but to avoid ambiguity let's presume it is in `~/workspace/venv`.

From 230f4af1a3c96eb85ae8efc16b1fa3f874427d6c Mon Sep 17 00:00:00 2001
From: Your Name <you@example.com>
Date: Mon, 31 Mar 2025 17:43:18 +0100
Subject: [PATCH 08/19] renamed LP for clarity

---
 .../servers-and-cloud-computing/building-custom-glibc/_index.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/content/learning-paths/servers-and-cloud-computing/building-custom-glibc/_index.md b/content/learning-paths/servers-and-cloud-computing/building-custom-glibc/_index.md
index 5b7130b469..b10be8b5da 100644
--- a/content/learning-paths/servers-and-cloud-computing/building-custom-glibc/_index.md
+++ b/content/learning-paths/servers-and-cloud-computing/building-custom-glibc/_index.md
@@ -1,5 +1,5 @@
 ---
-title: Building and Running a custom glibc on an FVP
+title: Building and Running a custom Linux System on FVP for Architecture Exploration
 
 minutes_to_complete: 60
 

From ad77384eb468f2bba16cfb6f08220ba720cdbd4e Mon Sep 17 00:00:00 2001
From: Your Name <you@example.com>
Date: Mon, 31 Mar 2025 17:44:45 +0100
Subject: [PATCH 09/19] renamed LP for clarity

---
 .../servers-and-cloud-computing/building-custom-glibc/_index.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/content/learning-paths/servers-and-cloud-computing/building-custom-glibc/_index.md b/content/learning-paths/servers-and-cloud-computing/building-custom-glibc/_index.md
index b10be8b5da..92c131fa6a 100644
--- a/content/learning-paths/servers-and-cloud-computing/building-custom-glibc/_index.md
+++ b/content/learning-paths/servers-and-cloud-computing/building-custom-glibc/_index.md
@@ -1,5 +1,5 @@
 ---
-title: Building and Running a custom Linux System on FVP for Architecture Exploration
+title: Build and Run a custom Linux System on a FVP for Architecture Exploration
 
 minutes_to_complete: 60
 

From ca47767af14dbc693e73a76d7edb52ef648fc74b Mon Sep 17 00:00:00 2001
From: Your Name <you@example.com>
Date: Mon, 31 Mar 2025 17:59:06 +0100
Subject: [PATCH 10/19] added notice on suitability of system compiler for user
 clarity

---
 .../building-custom-glibc/naming-conventions.md       | 11 +++++++----
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/content/learning-paths/servers-and-cloud-computing/building-custom-glibc/naming-conventions.md b/content/learning-paths/servers-and-cloud-computing/building-custom-glibc/naming-conventions.md
index 72f00dea79..cdb6f14323 100644
--- a/content/learning-paths/servers-and-cloud-computing/building-custom-glibc/naming-conventions.md
+++ b/content/learning-paths/servers-and-cloud-computing/building-custom-glibc/naming-conventions.md
@@ -14,11 +14,14 @@ In the following sections we use host system to checkout sources and build vario
 tools and we also make configuration changes to the guest system that will run on
 the Arm [Fixed Virtual Platform (FVP)][1] model.
 
-{{%notice  Note %}}
-Tools must be installed in the specified paths for clarity and best practices. The GCC cross toolchain directory should include all necessary tools. For example, the `gcc` tool path would be `/path/to/cross/gcc/bin/aarch64-none-linux-gnu-gcc`. Note: This may differ from the cross compiler provided by your distribution's package manager.
-{{%/notice%}}. 
 
-[This resource](https://wiki.osdev.org/GCC_Cross-Compiler#Using_the_new_Compiler) may be useful for creating a GCC cross compiler. 
+The GCC cross toolchain directory should include all necessary tools. For example, the `gcc` tool path would be `/path/to/cross/gcc/bin/aarch64-none-linux-gnu-gcc`. 
+
+**Please Note**: The cross compiler available from your distribution through a package manager is not suitable to explore architectural features and user needs to build your own custom GNU cross compiler. Please read [this resource ](https://wiki.osdev.org/GCC_Cross-Compiler#Using_the_new_Compiler) for further explanation. 
+
+
+Tools must be installed in the specified paths for clarity and best practices. 
+
 
 Table 1. Directory layout
 

From ac896b0f1058f2132343273ab19ccb1ed66992f2 Mon Sep 17 00:00:00 2001
From: Your Name <you@example.com>
Date: Wed, 2 Apr 2025 18:33:02 +0100
Subject: [PATCH 11/19] renamed LP and modified intended audience for clarity
 based on Yury's comments

---
 .../building-custom-glibc/_index.md                          | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/content/learning-paths/servers-and-cloud-computing/building-custom-glibc/_index.md b/content/learning-paths/servers-and-cloud-computing/building-custom-glibc/_index.md
index 92c131fa6a..016ade01c3 100644
--- a/content/learning-paths/servers-and-cloud-computing/building-custom-glibc/_index.md
+++ b/content/learning-paths/servers-and-cloud-computing/building-custom-glibc/_index.md
@@ -1,11 +1,10 @@
 ---
-title: Build and Run a custom Linux System on a FVP for Architecture Exploration
+title: Build a custom Linux System including custom glibc, and run on a FVP
 
 minutes_to_complete: 60
 
 who_is_this_for: >
-  Developers who wish to run a Linux system (optionally using a custom kernel and a C library) on an Arm Fixed Virtual Platform (FVP) model. For example, this
-  guide might be useful if you want to test patches related to new architectural features for the Linux kernel or Glibc. 
+  Developers who wish to run a Linux system (optionally using a custom kernel and a C library) on an Arm Fixed Virtual Platform (FVP) model. For example, this guide is useful if you want to test patches related to new architectural features for the Linux kernel or Glibc. 
 
 learning_objectives: 
   - Build the Linux kernel.

From 6204f254181de3ad907830a15558627e9cb5b27d Mon Sep 17 00:00:00 2001
From: Your Name <you@example.com>
Date: Wed, 2 Apr 2025 18:34:41 +0100
Subject: [PATCH 12/19] renamed to conventions for consistency

---
 .../building-custom-glibc/conventions.md      | 47 +++++++++++++++++++
 1 file changed, 47 insertions(+)
 create mode 100644 content/learning-paths/servers-and-cloud-computing/building-custom-glibc/conventions.md

diff --git a/content/learning-paths/servers-and-cloud-computing/building-custom-glibc/conventions.md b/content/learning-paths/servers-and-cloud-computing/building-custom-glibc/conventions.md
new file mode 100644
index 0000000000..cdb6f14323
--- /dev/null
+++ b/content/learning-paths/servers-and-cloud-computing/building-custom-glibc/conventions.md
@@ -0,0 +1,47 @@
+---
+title: Naming Conventions
+weight: 2
+
+### FIXED, DO NOT MODIFY
+layout: learningpathall
+---
+
+You may need root access on your host system to do minimal setup and install packages that are described in the following sections.
+
+## Naming conventions
+
+In the following sections we use host system to checkout sources and build various
+tools and we also make configuration changes to the guest system that will run on
+the Arm [Fixed Virtual Platform (FVP)][1] model.
+
+
+The GCC cross toolchain directory should include all necessary tools. For example, the `gcc` tool path would be `/path/to/cross/gcc/bin/aarch64-none-linux-gnu-gcc`. 
+
+**Please Note**: The cross compiler available from your distribution through a package manager is not suitable to explore architectural features and user needs to build your own custom GNU cross compiler. Please read [this resource ](https://wiki.osdev.org/GCC_Cross-Compiler#Using_the_new_Compiler) for further explanation. 
+
+
+Tools must be installed in the specified paths for clarity and best practices. 
+
+
+Table 1. Directory layout
+
+| Path                                 | Description                                |
+|--------------------------------------|--------------------------------------------|
+| `/path/to/cross/gcc`                 | GCC cross toolchain installation directory |
+| `/home/user`                         | Home directory of your host non-root user  |
+| `/home/user/shrinkwrap`              | Directory of shrinkwrap installation       |
+| `/home/user/workspace`               | Workspace directory                        |
+| `/home/user/workspace/linux`         | Folder with the Linux kernel sources       |
+| `/home/user/workspace/linux-headers` | Directory for installing kernel headers    |
+| `/home/user/workspace/linux-build`   | Folder for the Linux kernel build output   |
+| `/home/user/workspace/glibc`         | Folder for the Glibc sources               |
+| `/home/user/workspace/glibc-build`   | Directory for the Glibc build output       |
+
+
+
+
+
+In the next steps we create a Python virtual environment. It doesn't matter where
+it is located, but to avoid ambiguity let's presume it is in `~/workspace/venv`.
+
+[1]: https://developer.arm.com/downloads/-/arm-ecosystem-fvps
\ No newline at end of file

From a1f6baa759af2002e5dd1368650c73c40d0c62fd Mon Sep 17 00:00:00 2001
From: Your Name <you@example.com>
Date: Wed, 2 Apr 2025 18:35:20 +0100
Subject: [PATCH 13/19] removed old name (renamed)

---
 .../naming-conventions.md                     | 47 -------------------
 1 file changed, 47 deletions(-)
 delete mode 100644 content/learning-paths/servers-and-cloud-computing/building-custom-glibc/naming-conventions.md

diff --git a/content/learning-paths/servers-and-cloud-computing/building-custom-glibc/naming-conventions.md b/content/learning-paths/servers-and-cloud-computing/building-custom-glibc/naming-conventions.md
deleted file mode 100644
index cdb6f14323..0000000000
--- a/content/learning-paths/servers-and-cloud-computing/building-custom-glibc/naming-conventions.md
+++ /dev/null
@@ -1,47 +0,0 @@
----
-title: Naming Conventions
-weight: 2
-
-### FIXED, DO NOT MODIFY
-layout: learningpathall
----
-
-You may need root access on your host system to do minimal setup and install packages that are described in the following sections.
-
-## Naming conventions
-
-In the following sections we use host system to checkout sources and build various
-tools and we also make configuration changes to the guest system that will run on
-the Arm [Fixed Virtual Platform (FVP)][1] model.
-
-
-The GCC cross toolchain directory should include all necessary tools. For example, the `gcc` tool path would be `/path/to/cross/gcc/bin/aarch64-none-linux-gnu-gcc`. 
-
-**Please Note**: The cross compiler available from your distribution through a package manager is not suitable to explore architectural features and user needs to build your own custom GNU cross compiler. Please read [this resource ](https://wiki.osdev.org/GCC_Cross-Compiler#Using_the_new_Compiler) for further explanation. 
-
-
-Tools must be installed in the specified paths for clarity and best practices. 
-
-
-Table 1. Directory layout
-
-| Path                                 | Description                                |
-|--------------------------------------|--------------------------------------------|
-| `/path/to/cross/gcc`                 | GCC cross toolchain installation directory |
-| `/home/user`                         | Home directory of your host non-root user  |
-| `/home/user/shrinkwrap`              | Directory of shrinkwrap installation       |
-| `/home/user/workspace`               | Workspace directory                        |
-| `/home/user/workspace/linux`         | Folder with the Linux kernel sources       |
-| `/home/user/workspace/linux-headers` | Directory for installing kernel headers    |
-| `/home/user/workspace/linux-build`   | Folder for the Linux kernel build output   |
-| `/home/user/workspace/glibc`         | Folder for the Glibc sources               |
-| `/home/user/workspace/glibc-build`   | Directory for the Glibc build output       |
-
-
-
-
-
-In the next steps we create a Python virtual environment. It doesn't matter where
-it is located, but to avoid ambiguity let's presume it is in `~/workspace/venv`.
-
-[1]: https://developer.arm.com/downloads/-/arm-ecosystem-fvps
\ No newline at end of file

From 09d541405dbfd0f2013d4ae86d3d83f3711f4007 Mon Sep 17 00:00:00 2001
From: Your Name <you@example.com>
Date: Wed, 2 Apr 2025 18:37:37 +0100
Subject: [PATCH 14/19] adjusted wording on directory structure for clarity

---
 .../building-custom-glibc/conventions.md                 | 9 ++-------
 1 file changed, 2 insertions(+), 7 deletions(-)

diff --git a/content/learning-paths/servers-and-cloud-computing/building-custom-glibc/conventions.md b/content/learning-paths/servers-and-cloud-computing/building-custom-glibc/conventions.md
index cdb6f14323..c1b754e80c 100644
--- a/content/learning-paths/servers-and-cloud-computing/building-custom-glibc/conventions.md
+++ b/content/learning-paths/servers-and-cloud-computing/building-custom-glibc/conventions.md
@@ -10,9 +10,7 @@ You may need root access on your host system to do minimal setup and install pac
 
 ## Naming conventions
 
-In the following sections we use host system to checkout sources and build various
-tools and we also make configuration changes to the guest system that will run on
-the Arm [Fixed Virtual Platform (FVP)][1] model.
+In the following sections you use host system to checkout sources and build various tools and make configuration changes to the guest system that will run on the Arm [Fixed Virtual Platform (FVP)][https://developer.arm.com/downloads/-/arm-ecosystem-fvps] model.
 
 
 The GCC cross toolchain directory should include all necessary tools. For example, the `gcc` tool path would be `/path/to/cross/gcc/bin/aarch64-none-linux-gnu-gcc`. 
@@ -20,8 +18,7 @@ The GCC cross toolchain directory should include all necessary tools. For exampl
 **Please Note**: The cross compiler available from your distribution through a package manager is not suitable to explore architectural features and user needs to build your own custom GNU cross compiler. Please read [this resource ](https://wiki.osdev.org/GCC_Cross-Compiler#Using_the_new_Compiler) for further explanation. 
 
 
-Tools must be installed in the specified paths for clarity and best practices. 
-
+This Learning Path assumes the following directory structure. If your structure differs then you will need to substitute the correct paths accordingly.
 
 Table 1. Directory layout
 
@@ -43,5 +40,3 @@ Table 1. Directory layout
 
 In the next steps we create a Python virtual environment. It doesn't matter where
 it is located, but to avoid ambiguity let's presume it is in `~/workspace/venv`.
-
-[1]: https://developer.arm.com/downloads/-/arm-ecosystem-fvps
\ No newline at end of file

From 1b4241e5cd0dd98638a458fead62535093047cad Mon Sep 17 00:00:00 2001
From: Your Name <you@example.com>
Date: Wed, 2 Apr 2025 18:38:40 +0100
Subject: [PATCH 15/19] added docker installation guide link

---
 .../servers-and-cloud-computing/building-custom-glibc/fvp.md | 5 +----
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/content/learning-paths/servers-and-cloud-computing/building-custom-glibc/fvp.md b/content/learning-paths/servers-and-cloud-computing/building-custom-glibc/fvp.md
index dbe22ed04a..dd58f865a3 100644
--- a/content/learning-paths/servers-and-cloud-computing/building-custom-glibc/fvp.md
+++ b/content/learning-paths/servers-and-cloud-computing/building-custom-glibc/fvp.md
@@ -50,12 +50,9 @@ is activated, then run this command to confirm shrinkwrap has been correctly ins
 shrinkwrap --version
 ```
 
-
-
 ## Build firmware for the FVP
 
-Before proceeding, ensure that Docker is installed and usable. Follow the installation
-instructions for your distro. Now, you can use the Shrinkwrap tool to build the firmware, the third essential ingredient in our
+Before proceeding, ensure that Docker is installed and usable. Follow the installation instructions for your distribution [here](https://docs.docker.com/engine/install/). Now, you can use the Shrinkwrap tool to build the firmware, the third essential ingredient in our
 setup. The following step needs to be done once although you will need to repeat it if you
 want to rebuild the firmware:
 

From b713291ba7694bbac65747e23a2e803481cc7fab Mon Sep 17 00:00:00 2001
From: Your Name <you@example.com>
Date: Wed, 2 Apr 2025 18:42:10 +0100
Subject: [PATCH 16/19] added back export of PATH environment variable

---
 .../building-custom-glibc/kernel.md                         | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/content/learning-paths/servers-and-cloud-computing/building-custom-glibc/kernel.md b/content/learning-paths/servers-and-cloud-computing/building-custom-glibc/kernel.md
index b4b4ad48e4..ebda51d2c6 100644
--- a/content/learning-paths/servers-and-cloud-computing/building-custom-glibc/kernel.md
+++ b/content/learning-paths/servers-and-cloud-computing/building-custom-glibc/kernel.md
@@ -8,7 +8,7 @@ layout: learningpathall
 
 ## Obtain kernel source
 
-The Linux kernel image is the first essential components that you need to build. You are going to build it from source.
+The Linux kernel image is the first essential component that you need to build. You are going to build it from source.
 
 There are various ways to obtain the sources for a particular version of the Linux kernel that you want to use. Here, as an example, we obtain a stable
 version from the mainline repository.
@@ -31,10 +31,11 @@ interested in running.
 
 Before moving on, export some environment variables, pointing out some key directories and options.
 All the build output, including the binary that you intend to use later, will be put in
-the `linux-build` subfolder. Run the following commands in the workspace directory:
+the `linux-build` subfolder. Substitute the correct path for the commands below and run in the workspace directory.
 
 
 ```bash
+export PATH=/path/to/cross/gcc/bin:${PATH}
 export KBUILD_OUTPUT="$(pwd)/linux-build"
 export ARCH=arm64
 # Specify cross compiler
@@ -42,6 +43,7 @@ export CROSS_COMPILE=aarch64-none-linux-gnu-
 ````
 
 Next, build the kernel image:
+
 ```bash
 make -C linux mrproper
 make -C linux defconfig

From 0080edffa8db4672a736510d74fd8c609a22174f Mon Sep 17 00:00:00 2001
From: Your Name <you@example.com>
Date: Wed, 2 Apr 2025 18:44:18 +0100
Subject: [PATCH 17/19] removed typos

---
 .../building-custom-glibc/setup.md                            | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/content/learning-paths/servers-and-cloud-computing/building-custom-glibc/setup.md b/content/learning-paths/servers-and-cloud-computing/building-custom-glibc/setup.md
index b5a416cfc1..faf6e18676 100644
--- a/content/learning-paths/servers-and-cloud-computing/building-custom-glibc/setup.md
+++ b/content/learning-paths/servers-and-cloud-computing/building-custom-glibc/setup.md
@@ -133,7 +133,7 @@ experience an improvement in SSH connection speed:
 ## Configure SSH on host
 
 Commands in this section should be run on the host system.
-nano
+
 Using a password for SSH can be inconvenient when automating tasks. The solution is
 to set up authentication via SSH keys. Since we are using the Dropbear server, we need
 to use the Dropbear client and configure SSH keys for it.
@@ -291,5 +291,5 @@ test -f /etc/sysctl.d/02-disable-vm-overcommit.conf || {
 }
 ```
 
-You are now ready to do put your Void Linux system to the test. Let'sbuild the Glibc from source and run its tests on the FVP.
+You are now ready to do put your Void Linux system to the test. Let's build the Glibc from source and run its tests on the FVP.
 

From 69ccaa335205305f1a6c686d9f28f2c3ebb24280 Mon Sep 17 00:00:00 2001
From: Your Name <you@example.com>
Date: Wed, 2 Apr 2025 18:49:04 +0100
Subject: [PATCH 18/19] fixed typos

---
 .../building-custom-glibc/glibc.md            | 52 +++++++++----------
 1 file changed, 25 insertions(+), 27 deletions(-)

diff --git a/content/learning-paths/servers-and-cloud-computing/building-custom-glibc/glibc.md b/content/learning-paths/servers-and-cloud-computing/building-custom-glibc/glibc.md
index 736b8efdef..e356b63cc5 100644
--- a/content/learning-paths/servers-and-cloud-computing/building-custom-glibc/glibc.md
+++ b/content/learning-paths/servers-and-cloud-computing/building-custom-glibc/glibc.md
@@ -9,15 +9,15 @@ layout: learningpathall
 ## Prepare kernel headers
 
 For this step you need the GCC cross-toolchain for the `aarch64-none-linux-gnu` target.
-You can use the same toolchain as we used for building the kernel.
+You can use the same toolchain as you used for building the kernel.
 
-Since we are going to use our Glibc on a system running a specific version of the kernel,
-we should build the Glibc using the kernel headers of the same version. The Glibc build
+Since you are going to use our Glibc on a system running a specific version of the kernel,
+you should build the Glibc using the kernel headers of the same version. The Glibc build
 scripts automatically pick up your host system's kernel headers unless configured to use
-headers from a specific directory. To ensure that we use correct headers for the kernel,
-we need to install them from source.
+headers from a specific directory. To ensure that you use correct headers for the kernel,
+you need to install them from source.
 
-We presume that the kernel source is in the `linux` subfolder, and we will install the
+We presume that the kernel source is in the `linux` subfolder, and you will install the
 headers in the `linux-headers` subfolder. First, you have to set a few environment variables.
 To do this, run the following commands:
 
@@ -32,8 +32,7 @@ export CROSS_COMPILE=aarch64-none-linux-gnu-
 make -C linux headers_install INSTALL_HDR_PATH=$(pwd)/linux-headers
 ```
 
-You should see kernel headers in the `$HOME/workspace/linux-headers/include` folder now.
-We will use this path during the next step.
+You should see kernel headers in the `$HOME/workspace/linux-headers/include` folder now.You will use this path during the next step.
 
 ## Get Glibc sources and build for AArch64 target
 
@@ -82,10 +81,10 @@ make -j$(nproc)
 ## Run tests on FVP
 
 As you are using an AArch64 host, you can run Glibc tests both on your host and on the FVP
-from the same build tree. Before we run some tests, we need to make sure that we have two
+from the same build tree. Before you run some tests, you need to make sure that you have two
 important prerequisites in place.
 
-First, we need to copy the target libraries from your toolchain's sysroot to ensure that
+First, you need to copy the target libraries from your toolchain's sysroot to ensure that
 the tests are using them rather than your OS's libraries. Run the following commands in the
 `glibc-build` folder:
 
@@ -94,16 +93,16 @@ cp $(${CROSS}gcc -print-file-name=libstdc++.so.6) .
 cp $(${CROSS}gcc -print-file-name=libgcc_s.so.1) .
 ```
 
-Next, we will build the testroot. A Glibc testroot is a collection of files that resembles
-an installation of the Glibc that we have just built. It allows us to create the correct
-environment for the tests without actually installing the Glibc. Tun the following command
-int the Glibc build folder:
+Next, you will build the testroot. A Glibc testroot is a collection of files that resembles
+an installation of the Glibc that you have just built. It allows us to create the correct
+environment for the tests without actually installing the Glibc. Run the following command
+in the Glibc build folder:
 
 ```bash
 make $(pwd)/testroot.pristine/install.stamp
 ```
 
-Now we can run the tests. Let's start with a single test to understand the structure of the
+Now you can run the tests. Let's start with a single test to understand the structure of the
 command. Ensure the following:
 
  * The FVP is running
@@ -111,7 +110,7 @@ command. Ensure the following:
  * The Glibc source and build folders are available in the guest system via the NFS share
  * The paths to these folders on the host and the guest systems are the same
 
-We should set the `TIMEOUTFACTOR` environment variable to extend the timeout for some of the
+You should set the `TIMEOUTFACTOR` environment variable to extend the timeout for some of the
 tests that may fail just because execution takes longer than usual. This is expected on an
 emulated platform such as an FVP:
 
@@ -122,7 +121,7 @@ export TIMEOUTFACTOR=10
 If you see any timeouts when running tests on the FVP, increase this value.
 
 To tell the Glibc test system to execute the tests on a remote system (in our case this
-means on the guest system running on the FVP), we will use the test wrapper script that
+means on the guest system running on the FVP), you will use the test wrapper script that
 is part of the Glibc sources: `scripts/cross-test-ssh.sh`. By default it uses `ssh` as a
 command to start an SSH connection, but it is possible to override it via the `--ssh` option.
 However, this option only accepts single word values. To avoid complexities related to
@@ -149,16 +148,15 @@ make test t=misc/tst-aarch64-pkey \
   test-wrapper="/home/user/glibc/scripts/cross-test-ssh.sh --ssh ussh fvp"
 ```
 
-Let's see what we have here. The `test` target will build (or rebuild) one test and all
+The `test` target will build (or rebuild) one test and all
 its dependencies and then run this test. This target requires one parameter, `t`, with the
-name of the test that we need to run. The Glibc tests are grouped into folders, and a test name
+name of the test that you need to run. The Glibc tests are grouped into folders, and a test name
 would normally look like `misc/tst-aarch64-pkey` where `misc` is the name of the group and
 `tst-aarch64-pkey` is the name of the test in this group.
 
-When we use SSH test wrapper to run a test on the FVP we need to supply its absolute path along
-with any of the script's arguments as a value of the `test-wrapper` make parameter. Here,
-we use the `--ssh` option of the wrapper script to tell it to use the `ussh` command instead
-of `ssh` and we use `fvp` as the hostname of the remote system. All the setup that we have
+When you use SSH test wrapper to run a test on the FVP you need to supply its absolute path along
+with any of the script's arguments as a value of the `test-wrapper` make parameter. Here, you use the `--ssh` option of the wrapper script to tell it to use the `ussh` command instead
+of `ssh` and you use `fvp` as the hostname of the remote system. All the setup that you have
 done in the previous steps makes using this wrapper script easier.
 
 To run the same test on your AArch64 host rather than on the FVP, just omit the `test-wrapper=...`
@@ -187,9 +185,9 @@ make check -C $HOME/workspace/glibc/argp \
   test-wrapper="$HOME/workspace/glibc/scripts/cross-test-ssh.sh --ssh ussh fvp"
 ```
 
-In this instance, we are building and running tests from the `argp` folder. We use the `-C`
-option of `make` to point it to the right directory, and we also supply a path to the
-build folder via the `objdir` parameter (which should be the current directory since we are
+In this instance, you will build and run tests from the `argp` folder. You use the `-C`
+option of `make` to point it to the right directory, and you must also supply a path to the
+build folder via the `objdir` parameter (which should be the current directory since you are
 running this command from within the build folder). The `test-wrapper` part remains the same.
 
 To run all the tests, simply do:
@@ -199,7 +197,7 @@ make check \
   test-wrapper="$HOME/workspace/glibc/scripts/cross-test-ssh.sh --ssh ussh fvp"
 ```
 
-Note that this will take a considerable amount of time. Also, notice that we are not using
+Note that this will take a considerable amount of time. Also, notice that you are not using
 a parallel `make` command for running tests on the FVP. The reason is that the Fast Models
 simulation code runs primarily on a single thread, and running tests in parallel would not
 speed up the execution.

From 187d89e9801707f50b03022c8725eb37577ef939 Mon Sep 17 00:00:00 2001
From: Your Name <you@example.com>
Date: Thu, 3 Apr 2025 08:14:22 +0100
Subject: [PATCH 19/19] renamed title to assumptions

---
 .../building-custom-glibc/conventions.md                        | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/content/learning-paths/servers-and-cloud-computing/building-custom-glibc/conventions.md b/content/learning-paths/servers-and-cloud-computing/building-custom-glibc/conventions.md
index c1b754e80c..fb0e5f3173 100644
--- a/content/learning-paths/servers-and-cloud-computing/building-custom-glibc/conventions.md
+++ b/content/learning-paths/servers-and-cloud-computing/building-custom-glibc/conventions.md
@@ -1,5 +1,5 @@
 ---
-title: Naming Conventions
+title: Assumptions
 weight: 2
 
 ### FIXED, DO NOT MODIFY