tweak fixin's, documentation

bdisk/bGPG.py

@@ -9,6 +9,7 @@ import psutil
 def genGPG(conf):
     # https://media.readthedocs.org/pdf/pygpgme/latest/pygpgme.pdf
     build = conf['build']
+    dlpath = build['dlpath']
     bdisk = conf['bdisk']
     gpghome = conf['gpg']['mygpghome']
     distkey = build['gpgkey']
@@ -101,6 +102,9 @@ def genGPG(conf):
             '--lsign-key',
             '0x{0}'.format(importkey)]
     subprocess.call(cmd, stdout = DEVNULL, stderr = subprocess.STDOUT)
+    # We need to expose this key to the chroots, too, so we need to export it.
+    with open('{0}/gpgkey.pub'.format(dlpath), 'wb') as f:
+        gpg.export(pkeys[0].subkeys[0].keyid, f)
     return(gpg)
 
 def killStaleAgent(conf):

bdisk/bdisk.py

@@ -25,7 +25,7 @@ if __name__ == '__main__':
     for a in arch:
         bchroot.chroot(conf['build']['chrootdir'] + '/root.' + a, 'bdisk.square-r00t.net')
         bchroot.chrootUnmount(conf['build']['chrootdir'] + '/root.' + a)
-    prep.postChroot(conf['build'])
+    prep.postChroot(conf)
     bchroot.chrootTrim(conf['build'])
     build.genImg(conf)
     build.genUEFI(conf['build'], conf['bdisk'])

bdisk/host.py

@@ -32,6 +32,7 @@ def getConfig(conf_file='/etc/bdisk/build.ini'):
                         '/usr/share/bdisk/build.ini',
                         '/usr/share/bdisk/extra/build.ini',
                         '/usr/share/docs/bdisk/build.ini',  # this is the preferred installation path for packagers
+                        '/usr/local/etc/bdisk/build.ini',
                         '/usr/local/share/docs/bdisk/build.ini',
                         '/opt/dev/bdisk/build.ini',
                         '/opt/dev/bdisk/extra/build.ini',

bdisk/prep.py

@@ -129,35 +129,37 @@ def buildChroot(conf, keep = False):
         for y in ['files', 'dirs']:
             prebuild_overlay[y] = []
             prebuild_arch_overlay[x][y] = []
-    for path, dirs, files in os.walk(extradir + '/pre-build.d/'):
-        prebuild_overlay['dirs'].append(path + '/')
+    for path, dirs, files in os.walk('{0}/pre-build.d/'.format(extradir)):
+        prebuild_overlay['dirs'].append('{0}/'.format(path))
         for file in files:
             prebuild_overlay['files'].append(os.path.join(path, file))
     for x in prebuild_overlay.keys():
-        prebuild_overlay[x][:] = [re.sub('^' + extradir + '/pre-build.d/', '', s) for s in prebuild_overlay[x]]
+        prebuild_overlay[x][:] = [re.sub('^{0}/pre-build.d/'.format(extradir), '', s) for s in prebuild_overlay[x]]
         prebuild_overlay[x] = list(filter(None, prebuild_overlay[x]))
         for y in prebuild_arch_overlay.keys():
             prebuild_arch_overlay[y][x][:] = [i for i in prebuild_overlay[x] if i.startswith(y)]
-            prebuild_arch_overlay[y][x][:] = [re.sub('^' + y + '/', '', s) for s in prebuild_arch_overlay[y][x]]
+            prebuild_arch_overlay[y][x][:] = [re.sub('^{0}/'.format(y), '', s) for s in prebuild_arch_overlay[y][x]]
             prebuild_arch_overlay[y][x] = list(filter(None, prebuild_arch_overlay[y][x]))
         prebuild_overlay[x][:] = [y for y in prebuild_overlay[x] if not y.startswith(('x86_64','i686'))]
     prebuild_overlay['dirs'].remove('/')
     # create the dir structure. these should almost definitely be owned by root.
     for a in arch:
         for dir in prebuild_overlay['dirs']:
-            os.makedirs(chrootdir + '/root.' + a + '/' + dir, exist_ok = True)
-            os.chown(chrootdir + '/root.' + a + '/' + dir, 0, 0)
+            os.makedirs('{0}/root.{1}/{2}'.format(chrootdir, a, dir), exist_ok = True)
+            os.chown('{0}/root.{1}/{2}'.format(chrootdir, a, dir), 0, 0)
         # and copy over the files. again, chown to root.
         for file in prebuild_overlay['files']:
-            shutil.copy2(extradir + '/pre-build.d/' + file, chrootdir + '/root.' + a + '/' + file, follow_symlinks = False)
-            os.chown(chrootdir + '/root.' + a + '/' + file, 0, 0, follow_symlinks = False)
+            shutil.copy2('{0}/pre-build.d/{1}'.format(extradir, file),
+                        '{0}/root.{1}/{2}'.format(chrootdir, a, file), follow_symlinks = False)
+            os.chown('{0}/root.{1}/{2}'.format(chrootdir, a, file), 0, 0, follow_symlinks = False)
         # do the same for arch-specific stuff.
         for dir in prebuild_arch_overlay[a]['dirs']:
-            os.makedirs(chrootdir + '/root.' + a + '/' + dir, exist_ok = True)
-            os.chown(chrootdir + '/root.' + a + '/' + dir, 0, 0)
+            os.makedirs('{0}/root.{1}/{2}'.format(chrootdir, a, dir), exist_ok = True)
+            os.chown('{0}/root.{1}/{2}'.format(chrootdir, a, dir), 0, 0)
         for file in prebuild_arch_overlay[a]['files']:
-            shutil.copy2(extradir + '/pre-build.d/' + a + '/' + file, chrootdir + '/root.' + a + '/' + file, follow_symlinks = False)
-            os.chown(chrootdir + '/root.' + a + '/' + file, 0, 0, follow_symlinks = False)
+            shutil.copy2('{0}/pre-build.d/{1}/{2}'.format(extradir, a, file),
+                        '{0}/root.{1}/{2}'.format(chrootdir, a, file), follow_symlinks = False)
+            os.chown('{0}/root.{1}/{2}'.format(chrootdir, a, file), 0, 0, follow_symlinks = False)
 
 def prepChroot(conf):
     build = conf['build']
@@ -187,22 +189,79 @@ def prepChroot(conf):
     tpl = env.get_template('VERSION_INFO.txt.j2')
     tpl_out = tpl.render(build = build, bdisk = bdisk, hostname = host.getHostname(), distro = host.getOS())
     for a in arch:
+        # Copy the GPG pubkey
+        shutil.copy2('{0}/gpgkey.pub'.format(dlpath), '{0}/root.{1}/root/pubkey.gpg'.format(chrootdir, a))
+        # Write the VERSION_INFO.txt from template
         with open('{0}/root.{1}/root/VERSION_INFO.txt'.format(chrootdir, a), 'w+') as f:
             f.write(tpl_out)
-        with open(prepdir + '/VERSION_INFO.txt', 'w+') as f:
+        with open('{0}/VERSION_INFO.txt'.format(prepdir), 'w+') as f:
             f.write(tpl_out)
-    tpl = env.get_template('VARS.txt.j2')
-    tpl_out = tpl.render(bdisk = bdisk, user = user)
+    # And perform the templating overlays
+    templates_overlay = {}
+    templates_arch_overlay = {}
+    for x in arch:
+        templates_arch_overlay[x] = {}
+        for y in ['files', 'dirs']:
+            templates_overlay[y] = []
+            templates_arch_overlay[x][y] = []
+    for path, dirs, files in os.walk('{0}/pre-build.d'.format(templates_dir)):
+        for dir in dirs:
+            templates_overlay['dirs'].append('{0}/'.format(dir))
+        for file in files:
+            templates_overlay['files'].append(os.path.join(path, file))
+    for x in templates_overlay.keys():
+        templates_overlay[x][:] = [re.sub('^{0}/pre-build.d/(.*)(\.j2)'.format(templates_dir), '\g<1>', s) for s in templates_overlay[x]]
+        templates_overlay[x] = list(filter(None, templates_overlay[x]))
+        for y in templates_arch_overlay.keys():
+            templates_arch_overlay[y][x][:] = [i for i in templates_overlay[x] if i.startswith(y)]
+            templates_arch_overlay[y][x][:] = [re.sub('^{0}/(.*)(\.j2)'.format(y), '\g<1>', s) for s in templates_arch_overlay[y][x]]
+            templates_arch_overlay[y][x][:] = [re.sub('^{0}/'.format(y), '', s) for s in templates_arch_overlay[y][x]]
+            templates_arch_overlay[y][x] = list(filter(None, templates_arch_overlay[y][x]))
+        templates_overlay[x][:] = [y for y in templates_overlay[x] if not y.startswith(('x86_64','i686'))]
+    if '/' in templates_overlay['dirs']:
+        templates_overlay['dirs'].remove('/')
+    # create the dir structure. these should almost definitely be owned by root.
+    if build['gpg']:
+        gpg = conf['gpgobj']
+        if conf['gpg']['mygpgkey']:
+            signkey = conf['gpg']['mygpgkey']
+        else:
+            signkey = str(gpg.signers[0].subkeys[0].fpr)
     for a in arch:
-        with open('{0}/root.{1}/root/VARS.txt'.format(chrootdir, a), 'w+') as f:
+        for dir in templates_overlay['dirs']:
+            os.makedirs('{0}/root.{1}/{2}'.format(chrootdir, a, dir), exist_ok = True)
+            os.chown('{0}/root.{1}/{2}'.format(chrootdir, a, dir), 0, 0)
+        # and write the files. again, chown to root.
+        for file in templates_overlay['files']:
+            tplname = 'pre-build.d/{0}.j2'.format(file)
+            tpl = env.get_template(tplname)
+            tpl_out = tpl.render(build = build, bdisk = bdisk, mygpgkey = signkey, user = user)
+            with open('{0}/root.{1}/{2}'.format(chrootdir, a, file), 'w') as f:
                 f.write(tpl_out)
+            os.chown('{0}/root.{1}/{2}'.format(chrootdir, a, file), 0, 0, follow_symlinks = False)
+        # do the same for arch-specific stuff.
+        for dir in templates_arch_overlay[a]['dirs']:
+            os.makedirs('{0}/root.{1}/{2}'.format(chrootdir, a, dir), exist_ok = True)
+            os.chown('{0}/root.{1}/{2}'.format(chrootdir, a, dir), 0, 0)
+        for file in templates_arch_overlay[a]['files']:
+            tplname = 'pre-build.d/{0}/{1}.j2'.format(a, file)
+            tpl = env.get_template('{0}'.format(tplname))
+            tpl_out = tpl.render(build = build, bdisk = bdisk, mygpgkey = signkey)
+            with open('{0}/root.{1}/{2}'.format(chrootdir, a, file), 'w') as f:
+                f.write(tpl_out)
+            os.chown('{0}/root.{1}/{2}'.format(chrootdir, a, file), 0, 0, follow_symlinks = False)
     return(build)
 
-def postChroot(build):
+def postChroot(conf):
+    build = conf['build']
+    bdisk = conf['bdisk']
     dlpath = build['dlpath']
     chrootdir = build['chrootdir']
     arch = build['arch']
     overdir = build['basedir'] + '/overlay/'
+    templates_dir = '{0}/extra/templates'.format(build['basedir'])
+    loader = jinja2.FileSystemLoader(templates_dir)
+    env = jinja2.Environment(loader = loader)
     postbuild_overlay = {}
     postbuild_arch_overlay = {}
     for x in arch:
@@ -212,7 +271,7 @@ def postChroot(build):
             postbuild_overlay[y] = []
             postbuild_arch_overlay[x][y] = []
     for path, dirs, files in os.walk(overdir):
-        postbuild_overlay['dirs'].append(path + '/')
+        postbuild_overlay['dirs'].append('{0}/'.format(path))
         for file in files:
             postbuild_overlay['files'].append(os.path.join(path, file))
     for x in postbuild_overlay.keys():
@@ -227,16 +286,72 @@ def postChroot(build):
     # create the dir structure. these should almost definitely be owned by root.
     for a in arch:
         for dir in postbuild_overlay['dirs']:
-            os.makedirs(chrootdir + '/root.' + a + '/' + dir, exist_ok = True)
-            os.chown(chrootdir + '/root.' + a + '/' + dir, 0, 0, follow_symlinks = False)
+            os.makedirs('{0}/root.{1}/{2}'.format(chrootdir, a, dir), exist_ok = True)
+            os.chown('{0}/root.{1}/{2}'.format(chrootdir, a, dir), 0, 0, follow_symlinks = False)
         # and copy over the files. again, chown to root.
         for file in postbuild_overlay['files']:
-            shutil.copy2(overdir + file, chrootdir + '/root.' + a + '/' + file, follow_symlinks = False)
-            os.chown(chrootdir + '/root.' + a + '/' + file, 0, 0, follow_symlinks = False)
+            shutil.copy2(overdir + file, '{0}/root.{1}/{2}'.format(chrootdir, a, file), follow_symlinks = False)
+            os.chown('{0}/root.{1}/{2}'.format(chrootdir, a, file), 0, 0, follow_symlinks = False)
         # do the same for arch-specific stuff.
         for dir in postbuild_arch_overlay[a]['dirs']:
-            os.makedirs(chrootdir + '/root.' + a + '/' + dir, exist_ok = True)
-            os.chown(chrootdir + '/root.' + a + '/' + dir, 0, 0, follow_symlinks = False)
+            os.makedirs('{0}/root.{1}/{2}'.format(chrootdir, a, dir), exist_ok = True)
+            os.chown('{0}/root.{1}/{2}'.format(chrootdir, a, dir), 0, 0, follow_symlinks = False)
         for file in postbuild_arch_overlay[a]['files']:
-            shutil.copy2(overdir + a + '/' + file, chrootdir + '/root.' + a + '/' + file, follow_symlinks = False)
-            os.chown(chrootdir + '/root.' + a + '/' + file, 0, 0, follow_symlinks = False)
+            shutil.copy2('{0}{1}/{2}'.format(overdir, a, file),
+                            '{0}/root.{1}/{2}'.format(chrootdir, a, file),
+                            follow_symlinks = False)
+            os.chown('{0}/root.{1}/{2}'.format(chrootdir, a, file), 0, 0, follow_symlinks = False)
+    # And perform the templating overlays
+    templates_overlay = {}
+    templates_arch_overlay = {}
+    for x in arch:
+        templates_arch_overlay[x] = {}
+        for y in ['files', 'dirs']:
+            templates_overlay[y] = []
+            templates_arch_overlay[x][y] = []
+    for path, dirs, files in os.walk('{0}/overlay'.format(templates_dir)):
+        for dir in dirs:
+            templates_overlay['dirs'].append('{0}/'.format(dir))
+        for file in files:
+            templates_overlay['files'].append(os.path.join(path, file))
+    for x in templates_overlay.keys():
+        templates_overlay[x][:] = [re.sub('^{0}/overlay/(.*)(\.j2)'.format(templates_dir), '\g<1>', s) for s in templates_overlay[x]]
+        templates_overlay[x] = list(filter(None, templates_overlay[x]))
+        for y in templates_arch_overlay.keys():
+            templates_arch_overlay[y][x][:] = [i for i in templates_overlay[x] if i.startswith(y)]
+            templates_arch_overlay[y][x][:] = [re.sub('^{0}/(.*)(\.j2)'.format(y), '\g<1>', s) for s in templates_arch_overlay[y][x]]
+            templates_arch_overlay[y][x][:] = [re.sub('^{0}/'.format(y), '', s) for s in templates_arch_overlay[y][x]]
+            templates_arch_overlay[y][x] = list(filter(None, templates_arch_overlay[y][x]))
+        templates_overlay[x][:] = [y for y in templates_overlay[x] if not y.startswith(('x86_64','i686'))]
+    if '/' in templates_overlay['dirs']:
+        templates_overlay['dirs'].remove('/')
+    # create the dir structure. these should almost definitely be owned by root.
+    if build['gpg']:
+        gpg = conf['gpgobj']
+        if conf['gpg']['mygpgkey']:
+            signkey = conf['gpg']['mygpgkey']
+        else:
+            signkey = str(gpg.signers[0].subkeys[0].fpr)
+    for a in arch:
+        for dir in templates_overlay['dirs']:
+            os.makedirs('{0}/root.{1}/{2}'.format(chrootdir, a, dir), exist_ok = True)
+            os.chown('{0}/root.{1}/{2}'.format(chrootdir, a, dir), 0, 0)
+        # and write the files. again, chown to root.
+        for file in templates_overlay['files']:
+            tplname = 'overlay/{0}.j2'.format(file)
+            tpl = env.get_template(tplname)
+            tpl_out = tpl.render(build = build, bdisk = bdisk, mygpgkey = signkey)
+            with open('{0}/root.{1}/{2}'.format(chrootdir, a, file), 'w') as f:
+                f.write(tpl_out)
+            os.chown('{0}/root.{1}/{2}'.format(chrootdir, a, file), 0, 0, follow_symlinks = False)
+        # do the same for arch-specific stuff.
+        for dir in templates_arch_overlay[a]['dirs']:
+            os.makedirs('{0}/root.{1}/{2}'.format(chrootdir, a, dir), exist_ok = True)
+            os.chown('{0}/root.{1}/{2}'.format(chrootdir, a, dir), 0, 0)
+        for file in templates_arch_overlay[a]['files']:
+            tplname = 'overlay/{0}/{1}.j2'.format(a, file)
+            tpl = env.get_template(tplname)
+            tpl_out = tpl.render(build = build, bdisk = bdisk, mygpgkey = signkey)
+            with open('{0}/root.{1}/{2}'.format(chrootdir, a, file), 'w') as f:
+                f.write(tpl_out)
+            os.chown('{0}/root.{1}/{2}'.format(chrootdir, a, file), 0, 0, follow_symlinks = False)

docs/TODO

@@ -6,7 +6,8 @@
 -sizes of build iso files
 -GPG sigs on built files
 -fix the branding, etc. on ipxe. :(
--convert docs to asciidoc, turn up instead of RTD (https://github.com/rtfd/readthedocs.org/issues/17#issuecomment-3752702)
+-fix links in docs. see the password generation section for bug :/ http://asciidoctor.org/docs/asciidoc-writers-guide/#cross-references
+--http://asciidoctor.org/docs/asciidoc-syntax-quick-reference/#links
 -add ipxe to full iso maybe?
 
 ## General ##

docs/manual/USER.adoc

@@ -8,7 +8,7 @@ BDisk was ultimately designed to make your life easier. "Why would I possibly ne
 Using BDisk, you can:
 
 * Install GNU/Linux (https://wiki.archlinux.org/index.php/installation_guide[Arch^], https://watchmysys.com/blog/2015/02/installing-centos-7-with-a-chroot/[CentOS^], https://www.debian.org/releases/stable/amd64/apds03.html.en[Debian^], https://wiki.gentoo.org/wiki/Handbook:AMD64#Installing_Gentoo[Gentoo^], https://help.ubuntu.com/lts/installation-guide/powerpc/apds04.html[Ubuntu^]...). BDisk may be Arch-based, but many if not most other distros offer ways to install from any GNU/Linux live distribution.
-* Perform disk maintenance (https://raid.wiki.kernel.org/index.php/RAID_setup[mdadm^], fdisk/http://www.rodsbooks.com/gdisk/[gdisk^], http://gparted.org/[gparted^], https://www.thomas-krenn.com/en/wiki/StorCLI[storcli^], etc.). Need to replace that disk in your RAID and you don't have hotswap? Not a problem!
+* Perform disk maintenance (https://raid.wiki.kernel.org/index.php/RAID_setup[mdadm^], fdisk / http://www.rodsbooks.com/gdisk/[gdisk^], http://gparted.org/[gparted^], https://www.thomas-krenn.com/en/wiki/StorCLI[storcli^], etc.). Need to replace that disk in your RAID and you don't have hotswap? Not a problem!
 * Rescue, recover, wipe (http://www.sleuthkit.org/sleuthkit/[scalpel^], http://www.andybev.com/index.php/Nwipe[nwipe^], http://foremost.sourceforge.net/[foremost^], etc.). Chances are this is why you booted a live distro in the first place, yes?
 * Boot over the Internet (or LAN). Burning a new image to CD/DVD/USB is a pain. BDisk has built-in support for http://ipxe.org/[iPXE^] (and traditional PXE setups). Update the filesystem image once, deploy it everywhere.
 * And much, much more.

docs/manual/faq/ALTERNATIVES.adoc

@@ -1,5 +1,5 @@
 == I don't like BDisk. Are there any other alternatives?
-First, I'm sorry to hear that BDisk doesn't suit your needs. If you want any features you think are missing or encounter any <<FURTHER.adoc#_bug_reports_feature_requests, bugs>>, please report them!
+First, I'm sorry to hear that BDisk doesn't suit your needs. If you want any features you think are missing or encounter any <<FURTHER.adoc#bug_reports_feature_requests, bugs>>, please report them!
 
 But yes; there are plenty of alternatives!
 

docs/manual/further/BUGS.adoc

@@ -14,5 +14,5 @@ If you have any suggestions on how to improve *this documentation* or feel it's
 === Patches
 I gladly welcome https://www.gnu.org/software/diffutils/manual/html_node/Unified-Format.html[patches^], but I deplore using GitHub (even though I https://github.com/johnnybubonic/BDisk[have a mirror there^]). For this reason, please follow the same https://www.kernel.org/doc/Documentation/SubmittingPatches[patch/pull request process] for the Linux kernel and email it to bts@square-r00t.net.
 
-Alternatively, you may attach a patch to a <<_bugs,bug report>>/<<_feature_requests,feature request>>.
+Alternatively, you may attach a patch to a <<bugs,bug report>>/<<feature_requests,feature request>>.
 

docs/manual/further/PASSWORDS.adoc

@@ -2,11 +2,11 @@
 NOTE: If you're specifying passwords, be sure to use a https://www.schneier.com/blog/archives/2014/03/choosing_secure_1.html[strong password^]!
 
 === `build.ini` Password Value Examples
-Passwords work a little interestingly in BDisk. These aspects all apply to both <<__code_root_password_code,the root password>> and <<__code_password_code,the user password>> (if you enable a regular user).
+Passwords work a little interestingly in BDisk. These aspects all apply to both <<code_root_password_code,the root password>> and <<code_password_code,the user password>> (if you enable a regular user).
 
 CAUTION: DO *NOT* USE A PLAINTEXT PASSWORD IN THE `build.ini`! This is _by design_; plaintext passwords are much more insecure. If you use a plaintext password, it *will not work*.
 
-WARNING: Remember to <<_escaping_the_salted_hash,escape your hash>> before placing it in your `build.ini`!
+WARNING: Remember to <<escaping_the_salted_hash,escape your hash>> before placing it in your `build.ini`!
 
 .Password Value Scheme
 [frame="topbot",options="header,footer"]

docs/manual/user/ADVANCED.adoc

@@ -1,2 +1,4 @@
 == Advanced Customization
-If the <<_the_code_build_ini_code_file,`build.ini` file>> doesn't provide enough customization to your liking, I don't blame you! It was designed only to provide the most basic control and is primarily only used to control the build process itself.
+If the <<the_code_build_ini_code_file,`build.ini`>> file doesn't provide enough customization to your liking, I don't blame you! It was designed only to provide the most basic control and is primarily only used to control the build process itself.
+
+Luckily, there are a lot of changes you can make. For all of these, you'll want to make a copy of the <<code_basedir_code,`basedir`>> directory somewhere and change the basedir configuration option in the <<the_code_build_ini_code_file,`build.ini`>> file to point to the parent directory.

docs/manual/user/BUILDINI.adoc

@@ -5,6 +5,18 @@ It's single-level, but divided into "sections". This is unfortunately a limitati
 
 Blank lines are ignored, as well as any lines beginning with `#` and `;`. There are some restrictions and recommendations for some values, so be sure to note them when they occur. Variables referencing other values in the `build.ini` are allowed in the format of `${value}` if it's in the same section; otherwise, `${section:value}` can be used.
 
+If you want to use your own `build.ini` file (and you should!), the following paths are searched in order. The first one found will be used.
+
+* `/etc/bdisk/build.ini`
+* `/usr/share/bdisk/build.ini`
+* `/usr/share/bdisk/extra/build.ini`
+* `/usr/share/docs/bdisk/build.ini`
+* `/usr/local/etc/bdisk/build.ini`
+* `/usr/local/share/docs/bdisk/build.ini`
+* `/opt/dev/bdisk/build.ini`
+* `/opt/dev/bdisk/extra/build.ini`
+* `/opt/dev/bdisk/extra/dist.build.ini`
+
 We'll go into more detail for each section below.
 
 === Example
@@ -87,7 +99,7 @@ This value is a "basic" name of your project. It's not really shown anywhere end
 . Will be converted to uppercase if it isn't already
 
 ==== `uxname`
-This value is used for filenames and the like. I highly recommend it be the same as `<<__code_name_code,name>>` (in lowercase) but it doesn't need to be. It also has some rules:
+This value is used for filenames and the like. I highly recommend it be the same as `<<code_name_code,name>>` (in lowercase) but it doesn't need to be. It also has some rules:
 
 . Alphanumeric only
 . No whitespace
@@ -102,12 +114,12 @@ This string is used for "pretty-printing" of the project name; it should be a mo
 . ASCII only
 
 ==== `ver`
-The version string. If this isn't specified, we'll try to guess based on the current git commit and tags in `<<__code_basedir_code,build:basedir>>`.
+The version string. If this isn't specified, we'll try to guess based on the current git commit and tags in `<<code_basedir_code,build:basedir>>`.
 
 . No whitespace
 
 ==== `dev`
-The name of the developer or publisher of the ISO, be it an individual or organization. For example, if you are using BDisk to build an install CD for your distro, this would be the name of your distro. The same rules as `<<__code_pname_code,pname>>` apply.
+The name of the developer or publisher of the ISO, be it an individual or organization. For example, if you are using BDisk to build an install CD for your distro, this would be the name of your distro. The same rules as `<<code_pname_code,pname>>` apply.
 
 . *Can* contain whitespace
 . *Can* be mixed-case, uppercase, or lowercase
@@ -132,7 +144,7 @@ What is this project's URI (website, etc.)? Alternatively, your personal site, y
 ==== `root_password`
 The escaped, salted, hashed string to use for the root user.
 
-Please see <<_passwords,the section on passwords>> for information on this value. In the <<_example,example above>>, the string `$$6$$t92Uvm1ETLocDb1D$$BvI0Sa6CSXxzIKBinIaJHb1gLJWheoXp7WzdideAJN46aChFu3hKg07QaIJNk4dfIJ2ry3tEfo3FRvstKWasg/` is created from the password `test`. I cannot stress this enough, do not use a plaintext password here nor just use a regular `/etc/shadow` file/`crypt(3)` hash here. Read the section. I promise it's short.
+Please see <<passwords,the section on passwords>> for information on this value. In the <<example,example above>>, the string `$$6$$t92Uvm1ETLocDb1D$$BvI0Sa6CSXxzIKBinIaJHb1gLJWheoXp7WzdideAJN46aChFu3hKg07QaIJNk4dfIJ2ry3tEfo3FRvstKWasg/` is created from the password `test`. I cannot stress this enough, do not use a plaintext password here nor just use a regular `/etc/shadow` file/`crypt(3)` hash here. Read the section. I promise it's short.
 
 ==== `user`
 *Default: no*
@@ -150,7 +162,7 @@ NOTE: If enabled, this user has full sudo access.
 |======================
 
 === `[user]`
-This section of `build.ini` controls aspects about `bdisk:user`. It is only used if <<__code_user_code,`bdisk:user`>> is enabled.
+This section of `build.ini` controls aspects about `bdisk:user`. It is only used if <<code_user_code,`bdisk:user`>> is enabled.
 
 ==== `username`
 What username should the user have? Standard *nix username rules apply:
@@ -170,33 +182,33 @@ What comment/description/real name should be used for the user? For more informa
 ==== `password`
 The escaped, salted, hashed string to use for the non-root user.
 
-Please see <<_passwords,the section on passwords>> for information on this value. In the <<_example,example above>>, the string `$$6$$t92Uvm1ETLocDb1D$$BvI0Sa6CSXxzIKBinIaJHb1gLJWheoXp7WzdideAJN46aChFu3hKg07QaIJNk4dfIJ2ry3tEfo3FRvstKWasg/` is created from the password `test`. I cannot stress this enough, do not use a plaintext password here nor just use a regular `/etc/shadow` file/`crypt(3)` hash here. Read the section. I promise it's short.
+Please see <<passwords,the section on passwords>> for information on this value. In the <<example,example above>>, the string `$$6$$t92Uvm1ETLocDb1D$$BvI0Sa6CSXxzIKBinIaJHb1gLJWheoXp7WzdideAJN46aChFu3hKg07QaIJNk4dfIJ2ry3tEfo3FRvstKWasg/` is created from the password `test`. I cannot stress this enough, do not use a plaintext password here nor just use a regular `/etc/shadow` file/`crypt(3)` hash here. Read the section. I promise it's short.
 
 === `[build]`
 This section controls some aspects about the host and things like filesystem paths, etc.
 
 ==== `mirror`
-A mirror that hosts the bootstrap tarball. It is *highly* recommended you use an Arch Linux https://wiki.archlinux.org/index.php/Install_from_existing_Linux#Method_A:_Using_the_bootstrap_image_.28recommended.29[bootstrap tarball^] as the build process is highly specialized to this (but <<_bug_reports_feature_requests,patches/feature requests>> are welcome for other built distros). You can find a list of mirrors at the bottom of Arch's https://www.archlinux.org/download/[download page^].
+A mirror that hosts the bootstrap tarball. It is *highly* recommended you use an Arch Linux https://wiki.archlinux.org/index.php/Install_from_existing_Linux#Method_A:_Using_the_bootstrap_image_.28recommended.29[bootstrap tarball^] as the build process is highly specialized to this (but <<bug_reports_feature_requests,patches/feature requests>> are welcome for other built distros). You can find a list of mirrors at the bottom of Arch's https://www.archlinux.org/download/[download page^].
 
 . No whitespace
 . Must be accessible remotely/via a WAN-recognized address
 . Must be a domain/FQDN only; no paths (those come later!)
 
 ==== `mirrorproto`
-What protocol should we use for <<_mirror,the mirror>>?
+What protocol should we use for the <<code_mirror_code,`mirror`>>?
 
 |======================
 ^s|Must be (case-insensitive) one of: ^.^m|http ^.^m|https ^.^m|ftp
 |======================
 
 ==== `mirrorpath`
-What is the path to the tarball directory on the <<__code_mirror_code,`mirror`>>?
+What is the path to the tarball directory on the <<code_mirror_code,`mirror`>>?
 
 . Must be a complete path (e.g. `/dir1/subdir1/subdir2`)
 . No whitespace
 
 ==== `mirrorfile`
-What is the filename for the tarball found in the path specified in <<__code_mirrorpath_code,`mirrorpath`>> ? If left blank, we will use the sha1 <<__code_mirrorchksum_code,checksum>> file to try to guess the most recent file.
+What is the filename for the tarball found in the path specified in <<code_mirrorpath_code,`mirrorpath`>> ? If left blank, we will use the sha1 <<code_mirrorchksum_code,checksum>> file to try to guess the most recent file.
 
 ==== `mirrorchksum`
 The path to a sha1 checksum file of the bootstrap tarball.
@@ -208,33 +220,33 @@ The path to a sha1 checksum file of the bootstrap tarball.
 ==== `mirrorgpgsig`
 *[optional]* +
 *default: (no GPG checking done)* +
-*requires: <<_optional,_gpg/gnupg_>>* +
-*requires: <<__code_gpgkey_code,`gpgkey`>>*
+*requires: <<optional,_gpg/gnupg_>>* +
+*requires: <<code_gpgkey_code,`gpgkey`>>*
 
 If the bootstrap tarball file has a GPG signature, we can use it for extra checking. If it's blank, GPG checking will be disabled.
 
-If you specify just `.sig` (or use the default and don't specify a <<__code_mirrorfile_code,`mirrorfile`>>), BDisk will try to guess based on the file from the sha1 <<__code_mirrorchksum_code,checksum>> file. Note that this must evaluate to a full URL. (e.g. `${mirrorproto}://${mirror}${mirrorpath}somefile.sig`)
+If you specify just `.sig` (or use the default and don't specify a <<code_mirrorfile_code,`mirrorfile`>>), BDisk will try to guess based on the file from the sha1 <<code_mirrorchksum_code,checksum>> file. Note that this must evaluate to a full URL. (e.g. `${mirrorproto}://${mirror}${mirrorpath}somefile.sig`)
 
 ==== `gpgkey`
-*requires: <<_optional,_gpg/gnupg_>>*
+*requires: <<optional,_gpg/gnupg_>>*
 
-What is a key ID that should be used to verify/validate the <<__code_mirrorgpgsig_code,`mirrorgpgsig`>>?
+What is a key ID that should be used to verify/validate the <<code_mirrorgpgsig_code,`mirrorgpgsig`>>?
 
-. Only used if <<__code_mirrorgpgsig_code,`mirrorgpgsig`>> is set
+. Only used if <<code_mirrorgpgsig_code,`mirrorgpgsig`>> is set
 . Can be in "short" form (e.g. _7F2D434B9741E8AC_) or "full" form (_4AA4767BBC9C4B1D18AE28B77F2D434B9741E8AC_), with or without the _0x_ prefix.
 
 ==== `gpgkeyserver`
 *default: blank (GNUPG-bundled keyservers)* +
-*requires: <<_optional,_gpg/gnupg_>>*
+*requires: <<optional,_gpg/gnupg_>>*
 
-What is a valid keyserver we should use to fetch <<__code_gpgkey_code,`gpgkey`>>?
+What is a valid keyserver we should use to fetch <<code_gpgkey_code,`gpgkey`>>?
 
-. Only used if <<__code_mirrorgpgsig_code,`mirrorgpgsig`>> is set
+. Only used if <<code_mirrorgpgsig_code,`mirrorgpgsig`>> is set
 . The default (blank) is probably fine. If you don't specify a personal GPG config, then you'll most likely want to leave this blank.
 . If set, make sure it is a valid keyserver URI (e.g. `hkp://keys.gnupg.net`)
 
 ==== `gpg`
-Should we sign our release files? See the gpg section.
+Should we sign our release files? See the <<code_gpg_code_2,`[gpg]`>> section.
 
 [options="header"]
 |======================
@@ -261,13 +273,13 @@ WARNING: If you manage your project in git, this should not be checked in as it
 . Will be created if it doesn't exist
 
 ==== `basedir`
-Where your <<_extra,`extra/`>> and <<_overlay,`overlay/`>> directories are located. If you checked out from git, this would be your git worktree directory.
+Where your <<extra,`extra/`>> and <<overlay,`overlay/`>> directories are located. If you checked out from git, this would be your git worktree directory.
 
 . No whitespace
 . Must exist and contain the above directories populated with necessary files
 
 ==== `isodir`
-This is the output directory of ISO files when they're created (as well as GPG signatures if you <<__code_gpg_code,enabled them>>).
+This is the output directory of ISO files when they're created (as well as GPG signatures if you <<code_gpg_code,enabled them>>).
 
 WARNING: If you manage your project in git, this should not be checked in as it has many large files that are automatically generated!
 
@@ -319,7 +331,7 @@ s|only build an x86_64-architecture ISO ^m|x86_64 ^m|64 ^m|no32
 
 Enable iPXE ("mini ISO") functionality.
 
-NOTE: This has no bearing on the <<__code_sync_code,`[sync]`>> section, so you can create an iPXE HTTP preparation for instance without needing to sync it anywhere (in case you're building on the webserver itself).
+NOTE: This has no bearing on the <<code_sync_code,`[sync]`>> section, so you can create an iPXE HTTP preparation for instance without needing to sync it anywhere (in case you're building on the webserver itself).
 
 [options="header"]
 |======================
@@ -343,7 +355,7 @@ This option should only be enabled if you are on a fairly powerful, multicore sy
 |======================
 
 === `[gpg]`
-This section controls settings for signing our release files. This is only used if <<__code_gpg_code,`build:gpg`>> is enabled.
+This section controls settings for signing our release files. This is only used if <<code_gpg_code,`build:gpg`>> is enabled.
 
 ==== `mygpgkey`
 A valid key ID that BDisk should use to _sign_ release files.
@@ -353,7 +365,7 @@ A valid key ID that BDisk should use to _sign_ release files.
 . We will generate one if this is blank and you have selected sign as yes.
 
 ==== `mygpghome`
-The directory should be used for the above GPG key if specified. Make sure it contains your private key. (e.g. `/home/username/.gnupg`)
+The directory should be used for the above GPG key if specified. Make sure it contains a keybox (`.kbx`) your private key. (e.g. `/home/username/.gnupg`)
 
 === `[sync]`
 This section controls what we should do with the resulting build and how to handle uploads, if we choose to use those features.
@@ -361,7 +373,7 @@ This section controls what we should do with the resulting build and how to hand
 ==== `http`
 *default: no*
 
-If enabled, BDisk will generate/prepare HTTP files. This is mostly only useful if you plan on using iPXE.
+If enabled, BDisk will generate/prepare HTTP files. This is mostly only useful if you plan on using iPXE. See the <<code_http_code_2,`[http]`>> section.
 
 [options="header"]
 |======================
@@ -385,6 +397,7 @@ If enabled, BDisk will generate/prepare TFTP files. This is mostly only useful i
 |======================
 
 ==== `git`
+*requires: <<optional,git>>* +
 *default: no*
 
 Enable automatic Git pushing for any changes done to the project itself. If you don't have upstream write/push access, you'll want to disable this.
@@ -398,6 +411,7 @@ Enable automatic Git pushing for any changes done to the project itself. If you
 |======================
 
 ==== `rsync`
+*requires: <<optional,rsync>>* +
 *default: no*
 
 Enable rsync pushing for the ISO (and other files, if you choose- useful for iPXE over HTTP(S)).
@@ -411,7 +425,7 @@ Enable rsync pushing for the ISO (and other files, if you choose- useful for iPX
 |======================
 
 === `[http]`
-This section controls details about HTTP file preparation/generation. Only used if <<__code_http_code,`sync:http`>> is enabled.
+This section controls details about HTTP file preparation/generation. Only used if <<code_http_code,`sync:http`>> is enabled.
 
 ==== `path`
 This directory is where to build an HTTP webroot.
@@ -444,7 +458,7 @@ What group the HTTP files should be owned as. This is most likely going to be ei
 |======================
 
 === `[tftp]`
-This section controls details about TFTP file preparation/generation. Only used if <<__code_tftp_code,`sync:tftp`>> is enabled.
+This section controls details about TFTP file preparation/generation. Only used if <<code_tftp_code,`sync:tftp`>> is enabled.
 
 ==== `path`
 The directory where we want to build a TFTP root.
@@ -476,11 +490,11 @@ What group the TFTP files should be owned as. This is most likely going to be ei
 |======================
 
 === `[ipxe]`
-This section controls aspects of iPXE building. Only used if <<__code_ipxe_code,`build:ipxe`>> is enabled.
+This section controls aspects of iPXE building. Only used if <<code_ipxe_code,`build:ipxe`>> is enabled.
 
 ==== `iso`
 *default: no* +
-*requires: <<_optional,_git_>>*
+*requires: <<optional,_git_>>*
 
 Build a "mini-ISO"; that is, an ISO file that can be used to bootstrap an iPXE environment (so you don't need to set up a traditional PXE environment on your LAN). We'll still build a full standalone ISO no matter what.
 
@@ -499,7 +513,7 @@ NOTE: If you require HTTP BASIC Authentication or HTTP Digest Authentication (un
 
 NOTE: This currently does not work for HTTPS with self-signed certificates.
 
-. *Required* if <<__code_iso_code,`iso`>> is enabled
+. *Required* if <<code_iso_code,`iso`>> is enabled
 
 ==== `ssldir`
 Directory to hold SSL results, if we are generating keys, certificates, etc.
@@ -514,7 +528,7 @@ NOTE: You can use your own CA to sign existing certs. This is handy if you run a
 
 . No whitespace
 . Must be in PEM/X509 format
-. *Required* if <<__code_iso_code,`iso`>> is enabled
+. *Required* if <<code_iso_code,`iso`>> is enabled
 . If it exists, a matching key (ssl_cakey) *must* be specified
 .. However, if left blank/doesn't exist, one will be automatically generated
 
@@ -523,9 +537,9 @@ Path to the (root) CA key file iPXE should use.
 
 . No whitespace
 . Must be in PEM/X509 format
-. *Required* if <<__code_iso_code,`iso`>> is enabled
-. If left blank or it doesn't exist (and <<__code_ssl_ca_code,`ssl_ca`>> is also blank), one will be automatically generated
-. *Must* match/pair to <<__code_ssl_ca_code,`ssl_ca`>> if specified/exists
+. *Required* if <<code_iso_code,`iso`>> is enabled
+. If left blank or it doesn't exist (and <<code_ssl_ca_code,`ssl_ca`>> is also blank), one will be automatically generated
+. *Must* match/pair to <<code_ssl_ca_code,`ssl_ca`>> if specified/exists
 . MUST NOT be passphrase-protected/DES-encrypted
 
 ==== `ssl_crt`
@@ -533,21 +547,21 @@ Path to the _client_ certificate iPXE should use.
 
 . No whitespace
 . Must be in PEM/X509 format
-. *Required* if <<__code_iso_code,`iso`>> is enabled
-. If specified/existent, a matching CA cert (<<__code_ssl_ca_code,`ssl_ca`>>) and key (<<__code_ssl_cakey_code,`ssl_cakey`>>) *must* be specified
+. *Required* if <<code_iso_code,`iso`>> is enabled
+. If specified/existent, a matching CA cert (<<code_ssl_ca_code,`ssl_ca`>>) and key (<<code_ssl_cakey_code,`ssl_cakey`>>) *must* be specified
 .. However, if left blank/doesn't exist, one will be automatically generated
-. *Must* be signed by <<__code_ssl_ca_code,`ssl_ca`>>/<<__code_ssl_cakey_code,`ssl_cakey`>> if specified and already exists
+. *Must* be signed by <<code_ssl_ca_code,`ssl_ca`>>/<<code_ssl_cakey_code,`ssl_cakey`>> if specified and already exists
 
 ==== `ssl_key`
 Path to the _client_ key iPXE should use.
 
 . No whitespace
 . Must be in PEM/X509 format
-. *Required* if <<__code_iso_code,`iso`>> is enabled
-. If left blank/nonexistent (and <<__code_ssl_ca_code,`ssl_ca`>> is also blank), one will be automatically generated
+. *Required* if <<code_iso_code,`iso`>> is enabled
+. If left blank/nonexistent (and <<code_ssl_ca_code,`ssl_ca`>> is also blank), one will be automatically generated
 
 === `[rsync]`
-This section controls aspects of rsync pushing. Only used if <<__code_rsync_code,`sync:rsync`>> is enabled.
+This section controls aspects of rsync pushing. Only used if <<code_rsync_code,`sync:rsync`>> is enabled.
 
 ==== `host`
 The rsync destination host.
@@ -566,11 +580,11 @@ This is the remote user we should use when performing the rsync push.
 This is the remote destination path we should use for pushing via rsync.
 
 
-NOTE: You'll probably want to set *`http:user`* and *`group`* to what it'll need to be on the destination.
+NOTE: You'll probably want to set <<code_user_code_3,`http:user`>> and <<code_group_code,`http:group`>> to what it'll need to be on the destination.
 
 . No whitespace
 . The path *must* exist on the remote host
-. The path MUST be writable by <<__code_user_code_5,`user`>>
+. The path MUST be writable by <<code_user_code_5,`user`>>
 
 ==== `iso`
 Should we rsync over the ISO files too, or just the boot files?

docs/manual/user/IMPORTANT_CONCEPTS.adoc

@@ -23,7 +23,7 @@ A *live distro*, *live CD*, *live DVD*, *live USB*, and the like are a way of bo
 === Why live media is necessary/Why you might want BDisk
 "But Brent," I hear you ask in a voice which most likely is nothing close to what you actually sound like and entirely in my head, "Why would I need a live CD/USB/etc.? And why BDisk?"
 
-Elementary, my dear imaginary reader! I touch on some reasons why one might want live media in the beginning of the <<USER.adoc#_user_manual,User Manual>>, but here's why you might want BDisk specifically as opposed to another live distro (or <<FAQ.adoc#_i_don_t_like_bdisk_are_there_any_other_alternatives,live distro creator>>).
+Elementary, my dear imaginary reader! I touch on some reasons why one might want live media in the beginning of the <<USER.adoc#user_manual,User Manual>>, but here's why you might want BDisk specifically as opposed to another live distro (or <<FAQ.adoc#i_don_t_like_bdisk_are_there_any_other_alternatives,live distro creator>>).
 
 * Fully customizable
 * Works with a multitude of GNU/Linux distros -- both for the host build system and as the guest. (Still under development!)

docs/manual/user/PROJECT_LAYOUT.adoc

@@ -58,6 +58,14 @@ The following is a tree of files and directories in a BDisk root directory. Note
  │       │   │   └── 02.banner.patch.j2
  │       │   └── ssl
  │       │       └── openssl.cnf
+ │       ├── overlay
+ │       │   ├── (...)
+ │       │   ├── i686
+ │       │   ├── x86_64
+ │       ├── pre-build.d
+ │       │   ├── (...)
+ │       │   ├── i686
+ │       │   ├── x86_64
  │       ├── VARS.txt.j2
  │       └── VERSION_INFO.txt.j2
  └── overlay

docs/manual/user/fslayout/EXTRA.adoc

@@ -2,19 +2,19 @@
 This directory contains multiple "support files" for BDisk building.
 
 ==== bdisk.png
-This file is used for bootloader graphics. If you change the name of the project, this can be named something different -- see <<_uxname,the section on uxname>>.
+This file is used for bootloader graphics. If you change the name of the project, this can be named something different -- see <<code_uxname_code,the section on uxname>>.
 
 ==== bin/
 This directory contains sample code or extra tools that don't have anything to do with BDisk normal operation but are useful in building a BDisk distribution.
 
 ==== dist.build.ini
-This is the "source-provided"/upstream example `build.ini`. It will be sourced for any missing configuration options or the like.
+This is the "source-provided"/upstream example <<the_code_build_ini_code_file,`build.ini`>>. It will be sourced for any missing configuration options or the like.
 
 ==== external/
 This directory contains external source code for use with extra features in BDisk that would otherwise be inconvenient to fetch and build dynamically.
 
 ==== pkg.build.ini
-This is the recommended default `build.ini` file for packagers of distro repositories to use when packaging BDisk for inclusion in a package manager.
+This is the recommended default <<the_code_build_ini_code_file,`build.ini`>> file for packagers of distro repositories to use when packaging BDisk for inclusion in a package manager.
 
 include::PREBUILD.adoc[]
 

docs/manual/user/fslayout/OVERLAY.adoc

@@ -1,5 +1,5 @@
 === overlay/
-This directory follows similar rules to the <<_pre_build_d,pre-build.d/>> directory, except it is applied *after* the chroots are prepared (as it is designed to be user-centric rather than core functionality). We'll go more into this later in-depth, as this is where most of your customizations will be done.
+This directory follows similar rules to the <<pre_build_d,pre-build.d/>> directory, except it is applied *after* the chroots are prepared (as it is designed to be user-centric rather than core functionality). We'll go more into this later in-depth, as this is where most of your customizations will be done.
 
 For files that should be included in both chroots, simply recreate the path with the desired file. For instance, if you want a file `/etc/foo/bar.conf` to exist in both i686 and x86_64 versions, it would exist as the path `overlay/etc/foo/bar.conf`.
 

docs/manual/user/fslayout/PREBUILD.adoc

@@ -1,5 +1,5 @@
 ==== pre-build.d/
-This file contains a "core" overlay. Generally these files shouldn't be modified unless you know what you're doing, but there are some interesting things you can do in here. Generally speaking, though, you'll want to place your modifications in the `overlay/` directory.
+This file contains a "core" overlay. Generally these files shouldn't be modified unless you know what you're doing, but there are some interesting things you can do in here. Generally speaking, though, you'll want to place your modifications in the <<overlay_2,`overlay/`>> directory.
 
 For files that should be included in both chroots, simply recreate the path with the desired file. For instance, if you want a file `/etc/foo/bar.conf` to exist in both i686 and x86_64 versions, it would exist as the path `pre-build.d/etc/foo/bar.conf`.
 

docs/manual/user/fslayout/TEMPLATES.adoc

@@ -29,16 +29,19 @@ This file contains default parameters for the https://www.gnupg.org/documentatio
 ===== iPXE/
 This directory holds templates for iPXE/mini builds.
 
-The `BIOS/` directory is similar to <<_bios, BIOS/>> mentioned above, but it only needs one configuration file and is a much more minimal design (since its entire purpose is to chainload to the iPXE loader).
+The `BIOS/` directory is similar to <<bios, BIOS/>> mentioned above, but it only needs one configuration file and is a much more minimal design (since its entire purpose is to chainload to the iPXE loader).
 
-The `EFI/` directory is similar to <<_efi, EFI/>> above also, but needs fewer configuration files (its only purpose is to bootstrap iPXE).
+The `EFI/` directory is similar to <<efi, EFI/>> above also, but needs fewer configuration files (its only purpose is to bootstrap iPXE).
 
 `EMBED.j2` is the iPXE http://ipxe.org/scripting[embedded script^] (http://ipxe.org/embed[more info^]). This is what chainloads the remote resources (kernel, intird, squashed filesystem images, and so forth).
 
 The `patches/` directory largely control branding of the mini ISO. They are in https://www.gnu.org/software/diffutils/manual/html_node/Unified-Format.html[unified diff^] (or "patch") format.
 
-===== VARS.txt.j2
-This template passes variables specified in the configuration and generated by BDisk to the chroot bash script.
+===== overlay/
+This directory contains *templated* overlays. These are intended to be templated by the user. See <<overlay, the overlay section>> for more information on how to use this. Remember to suffix your template files with the `.j2` extension.
+
+===== pre-build.d/
+This directory contains *templated* overlays. These are intended to not be managed by the user, as they handle configuration necessary for building an ISO. See <<pre_build_d, the pre-build.d section>> for more information on this.
 
 ===== VERSION.txt.j2
 This template specifies a VERSION.txt file placed in various locations throughout the builds to help identify which version, build, etc. the ISO is.

extra/pre-build.d/etc/initcpio/install/livecd

@@ -19,11 +19,19 @@ build()
 
         add_runscript
 
+	# Normally, archiso does this for us. But we don't want to use the build.sh they provide, so we perform it in a more minimal version here.
+	if [ -f /root/pubkey.gpg ];
+	then
+		add_binary "/usr/bin/gpg"
+		mkdir -p "${BUILDROOT}${dest}"/gpg
+		gpg --homedir "${BUILDROOT}${dest}"/gpg --import /root/pubkey.gpg
+	fi
+
 }
  
 help() 
 {
         cat <<HELPEOF
-Mount a squashed flat-file directory with OverlayFS on /, add SSL support
+Mount a squashed flat-file directory with OverlayFS on /, add SSL support, and add GPG support (if needed) for BDisk.
 HELPEOF
 }

extra/pre-build.d/root/pre-build.sh

@@ -20,6 +20,11 @@ exec 1>/var/log/chroot_install.log 2>&1
 
 # we need this fix before anything.
 dirmngr </dev/null
+gpg --batch --yes --import /root/pubkey.gpg 
+# This is unnecessary as we have no private key
+#gpg --batch --yes --lsign-key 0x${SIGKEY}
+
+exec 17<>/root/pubkey.gpg
 
 cleanPacorigs()
 {
@@ -78,7 +83,10 @@ chown aurbuild:aurbuild /var/empty/.gnupg
 chmod 700 /var/empty/.gnupg
 cleanPacorigs
 apacman -Syy
-apacman -S --noconfirm --noedit --skipinteg --needed -S apacman apacman-deps apacman-utils expac
+for p in apacman apacman-deps apacman-utils expac;
+do
+	apacman -S --noconfirm --noedit --skipinteg --needed -S "${p}"
+done
 apacman --gendb
 cleanPacorigs
 # Install multilib-devel if we're in an x86_64 chroot.
@@ -132,7 +140,7 @@ then
 	cleanPacorigs
 fi
 # Add the regular user
-useradd -m -s /bin/bash -c "Default user" ${REGUSR}
+useradd -m -s /bin/bash -c "${USERCOMMENT}" ${REGUSR}
 usermod -aG users,games,video,audio ${REGUSR}
 passwd -d ${REGUSR}
 # Add them to sudoers

extra/templates/VARS.txt.j2

@@ -1,9 +0,0 @@
-export DISTNAME='{{ bdisk['name']|upper }}'
-export UXNAME='{{ bdisk['name']|lower }}'
-export PNAME='{{ bdisk['name'] }}'
-export DISTPUB='{{ bdisk['dev'] }}'
-export DISTDESC='{{ bdisk['desc'] }}'
-export REGUSR='{{ bdisk['name']|lower }}'
-export REGUSR_PASS='{{ user['password'] }}'
-export ROOT_PASS='{{ bdisk['root_password'] }}'
-