docs: add --setopt "*.countme=false" to dnf examples

* Consistently use --releasever instead of --release in dnf examples
* Remove trailing whitespace
* Use --use-host-config --setopt "*.countme=false" when running dnf with
  an empty --installroot
* Use Fedora 42 instead of Fedora 30 in examples
* Block quote console examples in tutorials

Signed-off-by: Nalin Dahyabhai <nalin@redhat.com>

demos/buildah-scratch-demo.sh

@@ -19,14 +19,13 @@ function is_rootless() {
 ## as root. The `buildah unshare` command switches your user
 ## session to root within the user namespace.
 if is_rootless; then
-  buildah unshare $0
+  exec buildah unshare $0
-  exit
 fi
 
 demoimg=myshdemo
 quayuser=ipbabble
 myname=WilliamHenry
-distrorelease=30
+distrorelease=42
 pkgmgr=dnf   # switch to yum if using yum
 
 #Setting up some colors for helping read the demo output
@@ -55,9 +54,9 @@ ls $scratchmnt
 echo -e "${red}Note that the root of the scratch container is EMPTY!${reset}"
 read -p "${cyan}Time to install some basic bash capabilities: coreutils and bash packages${reset}"
 if [ "$pkgmgr" == "dnf" ]; then
-	$pkgmgr install --installroot $scratchmnt --release ${distrorelease} bash coreutils --setopt install_weak_deps=false -y
+	$pkgmgr install --installroot $scratchmnt --releasever ${distrorelease} bash coreutils --use-host-config --setopt "*.countme=false" --setopt install_weak_deps=false -y
 elif [ "$pkgmgr" == "yum" ]; then
-	$pkgmgr install --installroot $scratchmnt --releasever ${distrorelease} bash coreutils  -y
+	$pkgmgr install --installroot $scratchmnt --releasever ${distrorelease} bash coreutils ---use-host-config --setopt "*.countme=false" y
 else
 	echo -e "${red}[Error] Unknown package manager ${pkgmgr}${reset}"
 fi

docs/buildah-unshare.1.md

@@ -40,23 +40,26 @@ buildah unshare rm -fr $HOME/.local/share/containers/storage /run/user/\`id -u\`
 
 buildah unshare --mount containerID sh -c 'cat ${containerID}/etc/os-release'
 
-If you want to use buildah with a mount command then you can create a script that looks something like:
+buildah unshare --mount root=containerID sh -c 'cat ${root}/etc/os-release'
 
-```
+If you want to use buildah with a 'mount' command then you can create a script that looks something like:
-cat buildah-script.sh << _EOF
+
-#!/bin/sh
+```console
+cat > buildah-script.sh << _EOF
+#!/bin/bash
 ctr=$(buildah from scratch)
 mnt=$(buildah mount $ctr)
-dnf -y install --installroot=$mnt PACKAGES
+dnf -y install --installroot=$mnt --use-host-config --setopt "*.countme=false" PACKAGES
 dnf -y clean all --installroot=$mnt
 buildah config --entrypoint="/bin/PACKAGE" --env "FOO=BAR" $ctr
 buildah commit $ctr imagename
 buildah unmount $ctr
 _EOF
+chmod +x buildah-script.sh
 ```
 Then execute it with:
-```
+```console
-buildah unshare buildah-script.sh
+buildah unshare ./buildah-script.sh
 ```
 
 ## SEE ALSO

docs/tutorials/01-intro.md

@@ -18,11 +18,15 @@ Note that installation instructions below assume you are running a Linux distro
 
 First step is to install Buildah. Run as root because you will need to be root for installing the Buildah package:
 
+```console
     $ sudo -s
+```
 
 Then install buildah by running:
 
+```console
     # dnf -y install buildah
+```
 
 ## Rootless User Configuration
 
@@ -32,37 +36,53 @@ If you plan to run Buildah as a user without root privileges, i.e. a "rootless u
 
 After installing Buildah we can see there are no images installed. The `buildah images` command will list all the images:
 
+```console
     # buildah images
+```
 
 We can also see that there are also no working containers by running:
 
+```console
     # buildah containers
+```
 
 When you build a working container from an existing image, Buildah defaults to appending '-working-container' to the image's name to construct a name for the container. The Buildah CLI conveniently returns the name of the new container. You can take advantage of this by assigning the returned value to a shell variable using standard shell assignment:
 
+```console
     # container=$(buildah from fedora)
+```
 
 It is not required to assign the container's name to a shell variable. Running `buildah from fedora` is sufficient. It just helps simplify commands later. To see the name of the container that we stored in the shell variable:
 
+```console
     # echo $container
+```
 
 What can we do with this new container? Let's try running bash:
 
+```console
     # buildah run $container bash
+```
 
 Notice we get a new shell prompt because we are running a bash shell inside of the container. It should be noted that `buildah run` is primarily intended for debugging and running commands as part of the build process. A more full-featured engine like Podman or a container runtime interface service like [CRI-O](https://github.com/kubernetes-sigs/cri-o) is more suited for starting containers in production.
 
 Be sure to `exit` out of the container and let's try running something else:
 
+```console
     # buildah run $container java
+```
 
 Oops. Java is not installed. A message containing something like the following was returned.
 
+```
     runc create failed: unable to start start container process: exec: "java": executable file not found in $PATH
+```
 
 Let's try installing it inside the container using:
 
+```console
     # buildah run $container -- dnf -y install java
+```
 
 The `--` syntax basically tells Buildah: there are no more `buildah run` command options after this point. The options after this point are for the command that's started inside the container. It is required if the command we specify includes command line options which are not meant for Buildah.
 
@@ -74,81 +94,108 @@ One of the advantages of using `buildah` to build OCI compliant container images
 
 Let's build a container and image from scratch. The special "image" name "scratch" tells Buildah to create an empty container.  The container has a small amount of metadata about the container but no real Linux content.
 
+```console
     # newcontainer=$(buildah from scratch)
+```
 
 You can see this new empty container by running:
 
+```console
     # buildah containers
+```
 
 You should see output similar to the following:
 
+```
     CONTAINER ID  BUILDER  IMAGE ID     IMAGE NAME                       CONTAINER NAME
     82af3b9a9488     *     3d85fcda5754 docker.io/library/fedora:latest  fedora-working-container
     ac8fa6be0f0a     *                  scratch                          working-container
+```
 
 Its container name is working-container by default and it's stored in the `$newcontainer` variable. Notice the image name (IMAGE NAME) is "scratch". This is a special value that indicates that the working container wasn't based on an image. When we run:
 
+```console
     # buildah images
+```
 
 We don't see the "scratch" image listed. There is no corresponding scratch image. A container based on "scratch" starts from nothing.
 
 So does this container actually do anything? Let's see.
 
+```console
     # buildah run $newcontainer bash
+```
 
 Nope. This really is empty. The package installer `dnf` is not even inside this container. It's essentially an empty layer on top of the kernel. So what can be done with that? Thankfully there is a `buildah mount` command.
 
+```console
     # scratchmnt=$(buildah mount $newcontainer)
+```
 
 Note: If attempting to mount in rootless mode, the command fails. Mounting a container can only be done in a mount namespace that you own. Create and enter a user namespace and mount namespace by executing the `buildah unshare` command. See buildah-mount(1) man page for more information.
 
+```console
     $ export newcontainer
     $ buildah unshare
     # scratchmnt=$(buildah mount $newcontainer)
+```
 
 By echoing `$scratchmnt` we can see the path for the [overlay mount point](https://wiki.archlinux.org/index.php/Overlay_filesystem), which is used as the root file system for the container.
 
+```console
     # echo $scratchmnt
     /var/lib/containers/storage/overlay/b78d0e11957d15b5d1fe776293bd40a36c28825fb6cf76f407b4d0a95b2a200d/merged
+```
 
 Notice that the overlay mount point is somewhere under `/var/lib/containers/storage` if you started out as root, and under your home directory's `.local/share/containers/storage` directory if you're in rootless mode. (See above on `containers/storage` or for more information see [containers/storage](https://github.com/containers/storage).)
 
 Now that we have a new empty container we can install or remove software packages or simply copy content into that container. So let's install `bash` and `coreutils` so that we can run bash scripts. This could easily be `nginx` or other packages needed for your container.
 
-**NOTE:** the version in the example below (40) relates to a Fedora version which is the Linux platform this example was run on.  If you are running dnf on the host to populate the container, the version you specify must be valid for the host or dnf will throw an error.  I.e. If you were to run this on a RHEL platform, you'd need to specify `--releasever 8.1` or similar instead of `--releasever 40`.  If you want the container to be a particular Linux platform, change `scratch` in the first line of the example to the platform you want, i.e. `# newcontainer=$(buildah from fedora)`, and then you can specify an appropriate version number for that Linux platform.
+**NOTE:** the version in the example below (42) relates to a Fedora version which is the Linux platform this example was run on.  If you are running dnf on the host to populate the container, the version you specify must be valid for the host or dnf will throw an error.  I.e. If you were to run this on a RHEL platform, you'd need to specify `--releasever 8.1` or similar instead of `--releasever 42`.  If you want the container to be a particular Linux platform, change `scratch` in the first line of the example to the platform you want, i.e. `# newcontainer=$(buildah from fedora)`, and then you can specify an appropriate version number for that Linux platform.
 
-    # dnf install --installroot $scratchmnt --releasever 40 bash coreutils --setopt install_weak_deps=false -y
+```console
+    # dnf install --installroot $scratchmnt --releasever 42 bash coreutils --use-host-config --setopt "*.countme=false" --setopt install_weak_deps=false -y
+```
 
 Let's try it out (showing the prompt in this example to demonstrate the difference):
 
+```console
     # buildah run $newcontainer sh
     sh-5.1# cd /usr/bin
     sh-5.1# ls
     sh-5.1# exit
+```
 
 Notice we now have a `/usr/bin` directory in the newcontainer's root file system. Let's first copy a simple file from our host into the container. Create a file called runecho.sh which contains the following:
 
+```console
     #!/usr/bin/env bash
     for i in `seq 0 9`;
     do
     	echo "This is a new container from ipbabble [" $i "]"
     done
+```
 
 Change the permissions on the file so that it can be run:
 
+```console
     # chmod +x runecho.sh
+```
 
 With `buildah` files can be copied into the new container.  We can then use `buildah run` to run that command within the container by specifying the command.  We can also configure the image we'll create from this container to run the command directly when we run it using [Podman](https://github.com/containers/podman) and its `podman run` command. In short the `buildah run` command is equivalent to the "RUN" command in a Dockerfile (it always needs to be told what to run), whereas `podman run` is equivalent to the `docker run` command (it can look at the image's configuration to see what to run).  Now let's copy this new command into the container's `/usr/bin` directory, configure the command to be run when the image is run by `podman`, and create an image from the container's root file system and configuration settings:
 
+```console
     # To test with Podman, first install via:
     # dnf -y install podman
     # buildah copy $newcontainer ./runecho.sh /usr/bin/
     # buildah config --cmd /usr/bin/runecho.sh $newcontainer
     # buildah commit $newcontainer newimage
+```
 
 We've got a new image named "newimage". The container is still there because we didn't remove it.
 Now run the command in the container with Buildah specifying the command to run in the container:
 
+```console
     # buildah run $newcontainer /usr/bin/runecho.sh
     This is a new container from ipbabble [ 0 ]
     This is a new container from ipbabble [ 1 ]
@@ -160,9 +207,11 @@ Now run the command in the container with Buildah specifying the command to run
     This is a new container from ipbabble [ 7 ]
     This is a new container from ipbabble [ 8 ]
     This is a new container from ipbabble [ 9 ]
+```
 
 Now use Podman to run the command in a new container based on our new image (no command required):
 
+```console
     # podman run --rm newimage
     This is a new container from ipbabble [ 0 ]
     This is a new container from ipbabble [ 1 ]
@@ -174,51 +223,69 @@ Now use Podman to run the command in a new container based on our new image (no
     This is a new container from ipbabble [ 7 ]
     This is a new container from ipbabble [ 8 ]
     This is a new container from ipbabble [ 9 ]
+```
 
 It works! Congratulations, you have built a new OCI container image from scratch that uses bash scripting.
 
 Back to Buildah, let's add some more configuration information.
 
+```console
     # buildah config --created-by "ipbabble"  $newcontainer
-    # buildah config --author "wgh at redhat.com @ipbabble" --label name=fedora40-bashecho $newcontainer
+    # buildah config --author "wgh at redhat.com @ipbabble" --label name=fedora42-bashecho $newcontainer
+```
 
 We can inspect the working container's metadata using the `inspect` command:
 
+```console
     # buildah inspect $newcontainer
+```
 
 We should probably unmount the working container's rootfs.  We will need to commit the container again to create an image that includes the two configuration changes we just made:
 
+```console
      # buildah unmount $newcontainer
      # buildah commit $newcontainer fedora-bashecho
      # buildah images
+```
 
 And you can see there is a new image called `localhost/fedora-bashecho:latest`. You can inspect the new image using:
 
+```console
     # buildah inspect --type=image fedora-bashecho
+```
 
 Later when you want to create a new container or containers from this image, you simply need to do `buildah from fedora-bashecho`. This will create a new container based on this image for you.
 
 Now that you have the new image you can remove the scratch container called working-container:
 
+```console
     # buildah rm $newcontainer
+```
 
 or
 
+```console
     # buildah rm working-container
+```
 
 ## OCI images built using Buildah are portable
 
 Let's test if this new OCI image is really portable to another container engine like Docker. First you should install Docker and start it. Notice that Docker requires a running daemon process in order to run any client commands. Buildah and Podman have no daemon requirement.
 
+```console
     # dnf -y install docker
     # systemctl start docker
+```
 
 Let's copy that image from where containers/storage stores it to where the Docker daemon stores its images, so that we can run it using Docker. We can achieve this using `buildah push`. This copies the image to Docker's storage area which is located under `/var/lib/docker`. Docker's storage is managed by the Docker daemon. This needs to be explicitly stated by telling Buildah to push the image to the Docker daemon using `docker-daemon:`.
 
+```console
     # buildah push fedora-bashecho docker-daemon:fedora-bashecho:latest
+```
 
 Under the covers, the containers/image library calls into the containers/storage library to read the image's contents from where buildah keeps them, and sends them to the local Docker daemon, which writes them to where it keeps them. This can take a little while. And usually you won't need to do this. If you're using `buildah` you are probably not using Docker. This is just for demo purposes. Let's try it:
 
+```console
     # docker run --rm fedora-bashecho
     This is a new container from ipbabble [ 0 ]
     This is a new container from ipbabble [ 1 ]
@@ -230,10 +297,13 @@ Under the covers, the containers/image library calls into the containers/storage
     This is a new container from ipbabble [ 7 ]
     This is a new container from ipbabble [ 8 ]
     This is a new container from ipbabble [ 9 ]
+```
 
 OCI container images built with `buildah` are completely standard as expected. So now it might be time to run:
 
+```console
     # dnf -y remove docker
+```
 
 ## Using Containerfiles/Dockerfiles with Buildah
 
@@ -241,6 +311,7 @@ What if you have been using Docker for a while and have some existing Dockerfile
 
 Find one of your Dockerfiles or create a file called Dockerfile. Use the following example or some variation if you'd like:
 
+```Dockerfile
     # Base on the most recently released Fedora
     FROM fedora:latest
     MAINTAINER ipbabble email buildahboy@redhat.com # not a real email
@@ -254,22 +325,31 @@ Find one of your Dockerfiles or create a file called Dockerfile. Use the followi
 
     # Run the httpd
     CMD ["/usr/sbin/httpd", "-DFOREGROUND"]
+```
 
 Now run `buildah build` with the name of the Dockerfile and the name to be given to the created image (e.g. fedora-httpd):
 
+```console
     # buildah build -f Dockerfile -t fedora-httpd .
+```
 
 or, because `buildah build` defaults to `Dockerfile` and using the current directory as the build context:
 
+```console
     # buildah build -t fedora-httpd
+```
 
 You will see all the steps of the Dockerfile executing. Afterwards `buildah images` will show you the new image. Now we can create a container from the image and test it with `podman run`:
 
+```console
     # podman run --rm -p 8123:80 fedora-httpd
+```
 
 While that container is running, in another shell run:
 
+```console
     # curl localhost:8123
+```
 
 You will see the standard Apache webpage.
 

docs/tutorials/02-registries-repositories.md

@@ -9,19 +9,27 @@ In the [first tutorial](https://github.com/containers/buildah/blob/main/docs/tut
 
 First we must pull down a registry. As a shortcut we will save the container name that is returned from the `buildah from` command, into a bash variable called `registry`. This is just like we did in Tutorial 1:
 
+```console
     # registryctr=$(buildah from registry)
+```
 
 It is worth pointing out that the `from` command can also use other protocols beyond the default (and implicitly assumed) order that first looks in local containers-storage (containers-storage:) and then looks in a container registry (by default, Docker Hub) (docker:). For example, if you already had a registry container image downloaded by a local Docker daemon then you could use the following:
 
+```console
     # registryctr=$(buildah from docker-daemon:registry:latest)
+```
 
 Then we need to start the registry. You should start the registry in a separate shell and leave it running there:
 
+```console
     # buildah run --net=host $registryctr /entrypoint.sh /etc/docker/registry/config.yml
+```
 
 If you would like to see more details as to what is going on inside the registry, especially if you are having problems with the registry, you can run the registry container in debug mode as follows:
 
+```console
     # buildah --log-level=debug run --net=host $registryctr /entrypoint.sh /etc/docker/registry/config.yml
+```
 
 You can use `--log-level=debug` on any Buildah command.
 
@@ -29,10 +37,13 @@ The registry is running and is waiting for requests to process. Notice that this
 
 Let's push our image to the private registry. By default, Buildah is set up to only make secure connections to a registry. Therefore we will need to turn the TLS verification off using the `--tls-verify` flag. We also need to tell Buildah that the registry is on this local host (i.e. localhost) and listening on port 5000. Similar to  what you'd expect to do on multi-tenant Docker Hub, we will explicitly specify that the registry is to store the image under the `ipbabble` repository - so as not to clash with other users' similarly named images.
 
+```console
     # buildah push --tls-verify=false fedora-bashecho docker://localhost:5000/ipbabble/fedora-bashecho:latest
+```
 
 [Skopeo](https://github.com/containers/skopeo) is a containers tool that was created to inspect images in registries without having to pull the image from the registry. It has grown to have many other uses. We will verify that the image has been stored by using Skopeo to inspect the image in the registry:
 
+```console
     # skopeo inspect --tls-verify=false docker://localhost:5000/ipbabble/fedora-bashecho:latest
     {
         "Name": "localhost:5000/ipbabble/fedora-bashecho",
@@ -51,9 +62,11 @@ Let's push our image to the private registry. By default, Buildah is set up to o
             "sha256:0cb7556c714767b8da6e0299cbeab765abaddede84769475c023785ae66d10ca"
         ]
     }
+```
 
 We can verify that it is still portable to Docker by starting Docker again, as we did in the first tutorial. Then we can pull down the image and start the container using Docker:
 
+```console
     # systemctl start docker
     # docker pull localhost:5000/ipbabble/fedora-bashecho
     Using default tag: latest
@@ -75,13 +88,17 @@ We can verify that it is still portable to Docker by starting Docker again, as w
     This is a new container named ipbabble [ 8 ]
     This is a new container named ipbabble [ 9 ]
     # systemctl stop docker
+```
 
 Pushing to Docker Hub is just as easy. Of course you must have an account with credentials. In this example I'm using a Docker Hub API key, which has the form "username:password" (example password has been edited for privacy), that I created with my Docker Hub account. I use the `--creds` flag to use my API key. I also specify my local image name `fedora-bashecho` as my image source and I use the `docker` protocol with no registry name or port so that it will look at the default port on the default Docker Hub registry:
 
+```console
     #  buildah push --creds=ipbabble:5bbb9990-6eeb-1234-af1a-aaa80066887c fedora-bashecho docker://ipbabble/fedora-bashecho:latest
+```
 
 And let's inspect that with Skopeo:
 
+```console
     # skopeo inspect --creds ipbabble:5bbb9990-6eeb-1234-af1a-aaa80066887c docker://ipbabble/fedora-bashecho:latest
     {
         "Name": "docker.io/ipbabble/fedora-bashecho",
@@ -100,9 +117,11 @@ And let's inspect that with Skopeo:
             "sha256:0cb7556c714767b8da6e0299cbeab765abaddede84769475c023785ae66d10ca"
         ]
     }
+```
 
 We can use Buildah to pull down the image using the `buildah from` command. But before we do let's clean up our local containers-storage so that we don't already have a copy of the fedora-bashecho image - otherwise Buildah will know it already exists and not bother pulling it down.
 
+```console
     #  buildah images
     IMAGE ID             IMAGE NAME                                               CREATED AT             SIZE
     d4cd7d73ee42         docker.io/library/registry:latest                        Dec 1, 2017 22:15      31.74 MB
@@ -113,19 +132,24 @@ We can use Buildah to pull down the image using the `buildah from` command. But
     #  buildah images
     IMAGE ID             IMAGE NAME                                               CREATED AT             SIZE
     d4cd7d73ee42         docker.io/library/registry:latest                        Dec 1, 2017 22:15      31.74 MB
+```
 
 Okay, so we don't have a fedora-bashecho image anymore. Let's pull the image from Docker Hub:
 
+```console
     # buildah from ipbabble/fedora-bashecho
+```
 
 If you don't want to bother doing the remove image step (`rmi`) you can use the flag `--pull-always` to force the image to be pulled again and overwrite any corresponding local image.
 
 Now check that image is in the local containers-storage:
 
+```console
     # buildah images
     IMAGE ID             IMAGE NAME                                               CREATED AT             SIZE
     d4cd7d73ee42         docker.io/library/registry:latest                        Dec 1, 2017 22:15      31.74 MB
     864871ac1c45         docker.io/ipbabble/fedora-bashecho:latest                Dec 5, 2017 21:38      315.4 MB
+```
 
 Success!
 

docs/tutorials/03-on-build.md

@@ -15,19 +15,27 @@ The following assumes installation on Fedora.
 
 Run as root because you will need to be root for installing the Buildah package:
 
+```console
     $ sudo -s
+```
 
 Then install Buildah by running:
 
+```console
     # dnf -y install buildah
+```
 
 After installing Buildah check to see that there are no images installed. The `buildah images` command will list all the images:
 
+```console
     # buildah images
+```
 
 We can also see that there are also no containers by running:
 
+```console
     # buildah containers
+```
 
 ## Examples
 
@@ -41,7 +49,7 @@ The first example was provided by Chris Collins (GitHub @clcollins), the idea is
 
 First create two Dockerfiles:
 
-```
+```Dockerfile
 $ cat << EOF > Dockerfile
 FROM registry.fedoraproject.org/fedora:latest
 RUN touch /foo
@@ -56,7 +64,7 @@ EOF
 
 Now to create the first container image and verify that ONBUILD has been set:
 
-```
+```console
 # buildah build --format=docker -f Dockerfile -t onbuild-image .
 # buildah inspect --format '{{.Docker.Config.OnBuild}}' onbuild-image
 [RUN touch /bar]
@@ -64,7 +72,7 @@ Now to create the first container image and verify that ONBUILD has been set:
 
 The second container image is now created and the `/bar` file will be created within it:
 
-```
+```console
 # buildah build --format=docker -f Dockerfile-2 -t result-image .
 STEP 1: FROM onbuild-image
 STEP 2: RUN touch /bar    # Note /bar is created here based on the ONBUILD in the base image
@@ -82,7 +90,7 @@ Instead of using a Dockerfile to create the onbuild-image, Buildah allows you to
 
 First a Fedora container will be created with `buildah from`, then the `/foo` file will be added with `buildah run`.  The `buildah config` command will configure ONBUILD to add `/bar` when a container image is created from the primary image, and finally the image will be saved with `buildah commit`.
 
-```
+```console
 # buildah from --format=docker --name onbuild-container registry.fedoraproject.org/fedora:latest
 # buildah run onbuild-container touch /foo
 # buildah config --onbuild="RUN touch /bar" onbuild-container
@@ -93,7 +101,7 @@ First a Fedora container will be created with `buildah from`, then the `/foo` fi
 ```
 The onbuild-image has been created, so now create a container from it using the same commands as the first example using the second Dockerfile:
 
-```
+```console
 # buildah build --format=docker -f Dockerfile-2 -t result-image .
 STEP 1: FROM onbuild-image
 STEP 2: RUN touch /bar    #  Note /bar is created here based on the ONBUILD in the base image
@@ -106,7 +114,7 @@ $ container=$(buildah from result-image)
 ```
 Or for bonus points, piece the secondary container image together with Buildah commands directly:
 
-```
+```console
 # buildah from --format=docker --name result-container onbuild-image
 result-container
 # buildah run result-container touch /baz
@@ -118,7 +126,7 @@ result-container
 
 For this example the ONBUILD instructions in the primary container image will be used to copy a shell script and then run it in the secondary container image.  For the script, we'll make use of the shell script from the [Introduction Tutorial](01-intro.md).  First create a file in the local directory called `runecho.sh` containing the following:
 
-```
+```console
 #!/usr/bin/env bash
 
 for i in `seq 0 9`;
@@ -128,13 +136,13 @@ done
 ```
 Change the permissions on the file so that it can be run:
 
-```
+```console
 $ chmod +x runecho.sh
 ```
 
 Now create a second primary container image.  This image has multiple ONBUILD instructions, the first ONBUILD instruction copies the file into the image and a second ONBUILD instruction to then run it.  We're going to do this example using only Buildah commands.  A Dockerfile could be translated easily and used from these commands, or these commands could be saved to a script directly.
 
-```
+```console
 # buildah from --format=docker --name onbuild-container-2 fedora:latest
 onbuild-container-2
 # buildah config --onbuild="COPY ./runecho.sh /usr/bin/runecho.sh" onbuild-container-2
@@ -147,7 +155,7 @@ onbuild-container-2
 
 Now the secondary container can be created from the second primary container image onbuild-image-2.  The runecho.sh script will be copied to the container's /usr/bin directory and then run from there when the secondary container is created.
 
-```
+```console
 # buildah from --format=docker --name result-container-2 onbuild-image-2
 STEP 1: COPY ./runecho.sh /usr/bin/runecho.sh
 STEP 2: RUN /usr/bin/runecho.sh
@@ -164,7 +172,7 @@ result-container-2
 ```
 As result-container-2 has a copy of the script stored in its /usr/bin it can be run at anytime.
 
-```
+```console
 # buildah run result-container-2 /usr/bin/runecho.sh
 This is a new container pull ipbabble [ 1 ]
 This is a new container pull ipbabble [ 2 ]

docs/tutorials/05-openshift-rootless-build.md

@@ -18,13 +18,13 @@ Make the registry URL available to the following steps.
 
 *Note that you need to change this so it matches your OpenShift installation.*
 
-````console
+```console
 $ export REGISTRY_URL=default-route-openshift-image-registry.apps.whatever.com
-````
+```
 
 Login to OpenShift and its registry:
 
-````console
+```console
 $ oc login -n image-build
 Username: ...
 Password: ...
@@ -36,7 +36,7 @@ Using project "image-build".
 
 $ oc whoami -t | buildah login --tls-verify=false -u $(id -u -n) --password-stdin $REGISTRY_URL
 Login Succeeded!
-````
+```
 
 
 ### Make builder image
@@ -47,7 +47,7 @@ The image starts a python web server. This allows us to interact with the contai
 
 First create an ImageStream to hold the image:
 
-````console
+```console
 $ oc create -f - <<EOF
 apiVersion: image.openshift.io/v1
 kind: ImageStream
@@ -56,14 +56,14 @@ metadata:
 EOF
 
 imagestream.image.openshift.io/buildah created
-````
+```
 
 Then create the image.
 
 Note that no packages are updated - this should ensure that this tutorial is actually working.
 If you are making anything for use in the real world, make sure to update it frequently for security fixes!
 
-````console
+```console
 $ cat > Containerfile-buildah <<EOF
 FROM quay.io/buildah/stable:v1.36.0
 
@@ -106,14 +106,14 @@ $ buildah push --tls-verify=false $REGISTRY_URL/image-build/buildah
 Getting image source signatures
 ...
 Storing signatures
-````
+```
 
 
 ### Create Service Account for building images
 
 Create a service account which is solely used for image building.
 
-````console
+```console
 $ oc create -f - <<EOF
 apiVersion: v1
 kind: ServiceAccount
@@ -122,14 +122,14 @@ metadata:
 EOF
 
 serviceaccount/buildah-sa created
-````
+```
 
 You need to assign it the ability to run as the standard `anyuid` [SCC](https://docs.openshift.com/container-platform/4.3/authentication/managing-security-context-constraints.html).
 
-````console
+```console
 $ oc adm policy add-scc-to-user anyuid -z buildah-sa
 clusterrole.rbac.authorization.k8s.io/system:openshift:scc:anyuid added: "buildah-sa"
-````
+```
 
 This will give the container *cap_kill*, *cap_setgid*, and *cap_setuid* capabilities which are extras compared to the `restricted` SCC.
 Note that *cap_kill* is dropped by the DeploymentConfig, but the two others are required to execute commands with different user ids as an image is built.
@@ -137,13 +137,13 @@ Note that *cap_kill* is dropped by the DeploymentConfig, but the two others are
 
 With this in place, when you get the Pod running (in a little while!), its YAML state will contain:
 
-````
+```
 kind: Pod
 metadata:
   ...
   openshift.io/scc: anyuid
 ...
-````
+```
 
 Which tells you that the Pod has been launched with the correct permissions.
 
@@ -154,7 +154,7 @@ This is a simple RC just to get the container running.
 
 Note that it drops CAP_KILL which is not required.
 
-````console
+```console
 $ oc create -f - <<EOF
 apiVersion: v1
 kind: ReplicationController
@@ -187,7 +187,7 @@ spec:
 EOF
 
 replicationcontroller/buildah created
-````
+```
 
 #### The Buildah container
 
@@ -195,7 +195,7 @@ In the OpenShift console you can now open the Pod's terminal (or run `oc rsh rc/
 
 This is what the user/platform should look like:
 
-````console
+```console
 sh-5.0$ id
 uid=1000(build) gid=1000(build) groups=1000(build)
 
@@ -216,11 +216,11 @@ uid=1000(build) euid=1000(build)
 gid=1000(build)
 groups=1000(build)
 Guessed mode: HYBRID (4)
-````
+```
 
 This is what the Buildah data should look like:
 
-````console
+```console
 sh-5.0$ buildah version
 Version:         1.36.0
 Go Version:      go1.22.3
@@ -277,7 +277,7 @@ sh-5.0$ buildah info
         "RunRoot": "/var/tmp/storage-run-1000/containers"
     }
 }
-````
+```
 
 #### Building an image
 
@@ -285,7 +285,7 @@ Now create some files for testing.
 
 This container test file exercises at least some of the critical parts of building an image (package update/installation, execution of commands, and use of volumes).
 
-````console
+```console
 sh-5.0$ cat > test-script.sh <<EOF
 #/bin/bash
 echo "Args \$*"
@@ -303,11 +303,11 @@ RUN dnf install -y gcc
 EOF
 
 sh-5.0$ mkdir output
-````
+```
 
 And finally build the image, testing that everything works as expected:
 
-````console
+```console
 sh-5.0$ buildah build --layers -v /home/build/output:/output:rw -v /home/build/test-script.sh:/test-script.sh:ro -t myimage -f Containerfile.test
 FROM fedora:40
 RUN ls -l /test-script.sh
@@ -477,4 +477,4 @@ registry.fedoraproject.org/fedora   40       b8638217aa4e   13 hours ago     233
 sh-5.0$ ls -l output/
 total 4
 -rw-r--r--. 1 build build 288 Aug  5 18:35 update-output.txt
-````
+```

docs/tutorials/README.md

@@ -23,4 +23,3 @@ Learn how to include Buildah as a library in your build tool.
 **[Rootless OpenShift container](05-openshift-rootless-build.md)**
 
 Learn how to build an image from a rootless OpenShift container.
-

tests/test_buildah_baseline.sh

@@ -1,36 +1,35 @@
 #!/usr/bin/env bash
-# test_buildah_baseline.sh 
+# test_buildah_baseline.sh
 # A script to be run at the command line with Buildah installed.
 # This should be run against a new kit to provide base level testing
-# on a freshly installed machine with no images or containers in 
+# on a freshly installed machine with no images or containers in
 # play.  This currently needs to be run as root.
 #
 # Commands based on the tutorial provided by William Henry.
 #
 # To run this command:
 #
-# /bin/bash -v test_buildah_baseline.sh 
+# /bin/bash -v test_buildah_baseline.sh
 
 ########
-# Next two commands should return blanks 
+# Next two commands should return blanks
 ########
 buildah images
 buildah containers
 
 ########
-# Run ls in redis container, this should work 
+# Run ls in redis container, this should work
 ########
-ctrid=$(buildah from registry.access.redhat.com/rhscl/redis-32-rhel7)
+ctrid=$(buildah from registry.redhat.io/rhscl/redis-6-rhel7)
 buildah run $ctrid ls /
 
-
 ########
 # Validate touch works after installing httpd, solved selinux
 # issue that should now work.
 ########
 ctr=$(buildah from scratch)
 mnt=$(buildah mount $ctr)
-dnf -y install --installroot=$mnt --releasever=30 httpd
+dnf -y install --installroot=$mnt --releasever=42 --use-host-config --setopt "*.countme=false" httpd
 buildah run $ctr touch /test
 
 ########
@@ -40,7 +39,7 @@ container=$(buildah from fedora)
 echo $container
 
 ########
-# Run container and display contents in /etc 
+# Run container and display contents in /etc
 ########
 buildah run $container -- ls -alF /etc
 
@@ -60,7 +59,7 @@ buildah run $container -- dnf -y install java
 buildah run $container java
 
 ########
-# Create a scratch container 
+# Create a scratch container
 ########
 newcontainer=$(buildah from scratch)
 
@@ -92,7 +91,7 @@ echo $scratchmnt
 ########
 # Install Fedora 30 bash and coreutils
 ########
-dnf install --installroot $scratchmnt --release 30 bash coreutils --setopt install_weak_deps=false -y
+dnf install --installroot $scratchmnt --releasever 42 bash coreutils --use-host-config --setopt "*.countme=false" --setopt install_weak_deps=false -y
 
 ########
 # Check /usr/bin on the new container
@@ -113,17 +112,17 @@ EOM
 chmod +x $FILE
 
 ########
-# Copy and run file on scratch container 
+# Copy and run file on scratch container
 ########
 buildah copy $newcontainer $FILE /usr/bin
 buildah config --cmd /usr/bin/runecho.sh $newcontainer
-buildah run $newcontainer /usr/bin/runecho.sh 
+buildah run $newcontainer /usr/bin/runecho.sh
 
 ########
 # Add configuration information
 ########
 buildah config --created-by "ipbabble"  $newcontainer
-buildah config --author "wgh at redhat.com @ipbabble" --label name=fedora30-bashecho $newcontainer
+buildah config --author "wgh at redhat.com @ipbabble" --label name=fedora42-bashecho $newcontainer
 
 ########
 # Inspect the container, verifying above was put into it
@@ -162,7 +161,7 @@ dnf -y install docker
 systemctl start docker
 
 ########
-# Push fedora-bashecho to the Docker daemon 
+# Push fedora-bashecho to the Docker daemon
 ########
 buildah push fedora-bashecho docker-daemon:fedora-bashecho:latest
 
@@ -196,18 +195,18 @@ EOM
 chmod +x $FILE
 
 ########
-# Build with Dockerfiles 
+# Build with Dockerfiles
 ########
 buildah bud -f ./Dockerfile --format=docker -t onbuild-image .
 buildah bud -f ./Dockerfile-2 --format=docker -t result-image .
 
 ########
-# Build a container to see if the /bar file has been created. 
+# Build a container to see if the /bar file has been created.
 ########
 ctr=$(buildah from result-image)
 
 ########
-# Validate that the /bar file has been created in the container. 
+# Validate that the /bar file has been created in the container.
 ########
 buildah run $ctr ls -alF /bar /foo /baz
 
@@ -216,7 +215,7 @@ buildah run $ctr ls -alF /bar /foo /baz
 ########
 FILE=./Dockerfile
 /bin/cat <<EOM >$FILE
-FROM docker/whalesay:latest
+FROM docker.io/docker/whalesay:latest
 RUN apt-get -y update && apt-get install -y fortunes
 CMD /usr/games/fortune -a | cowsay
 EOM
@@ -225,10 +224,10 @@ chmod +x $FILE
 ########
 # Build with the Dockerfile
 ########
-buildah bud -f Dockerfile -t whale-says . 
+buildah bud -f Dockerfile -t whale-says .
 
 ########
-# Create a whalesays container 
+# Create a whalesays container
 ########
 whalesays=$(buildah from whale-says)