more work

CH9Config/01-NetworkConfig.sh

@@ -0,0 +1,51 @@
+#!/bin/bash
+
+function myfail {
+  echo "$1"
+  exit 1
+}
+
+if [ "`whoami`" != "root" ]; then
+  myfail "Must run this script as r00t"
+fi
+
+cat > /etc/hosts << "EOF"
+# Begin /etc/hosts
+
+127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4
+::1       localhost localhost.localdomain localhost6 localhost6.localdomain6
+
+# End /etc/hosts
+EOF
+
+# do not use systemd-resolved for now
+systemctl disable systemd-resolved
+cat > /etc/resolv.conf << "EOF"
+nameserver 8.8.8.8
+nameserver 8.8.4.4
+EOF
+
+if [ ! -f /USBFlash ]; then
+  # final system config
+  echo "localhost" > /etc/hostname
+  cat > /etc/systemd/network/10-lan0.link << "EOF"
+[Match]
+MACAddress=0c:c4:7a:c8:a5:4c
+
+[Link]
+NAME=lan0
+EOF
+  cat > /etc/systemd/network/10-lan0.network << "EOF"
+[Match]
+Name=lan0
+
+[Network]
+DHCP=ipv4
+EOF
+  # auto-update certificate bundle
+  systemctl enable update-pki.timer
+else
+  # bootable USB thumb drive
+  echo "lfsusb" > /etc/hostname
+  systemctl disable systemd-networkd-wait-online
+fi

PRENINE.sh

@@ -12,11 +12,9 @@ fi
 LFS="/mnt/newlfs"
 
 # So USB thumb drive install does not need a network connection
-if [ ! -d ${LFS}/home/lfs ]; then
-  if [ ! -f /home/lfs/lfs-buildscripts/USBFlash ]; then
+if [ ! -f ${LFS}/USBFlash ]; then
   mkdir -p ${LFS}/home/lfs
   cp /home/lfs/lfs-sources.tar ${LFS}/home/lfs/
   cp -ar /home/lfs/lfs-buildscripts ${LFS}/home/lfs/
-    touch ${LFS}/home/lfs/lfs-buildscripts/USBFlash
-  fi
+  touch ${LFS}/USBFlash
 fi

README.md

@@ -5,6 +5,10 @@ Shell scripts for building LFS SystemD
 Based upon https://www.linuxfromscratch.org/lfs/view/stable-systemd/
 version 12.2
 
+This set of scripts does not use `fdisk` or `mke2fs`, those need to be run and
+formatted for the appropriate partitions before starting. With caution of
+course.
+
 Do not yet use
 
 This git repository contains shell scripts needed to build LFS 12.2-systemd and
@@ -12,15 +16,27 @@ is being worked on in an `x86_64` LFS 11.3 (modified) system.
 
 There are some deviations from LFS 12.2, namely:
 
-* LibreSSL is used instead of OpenSSL
-* LTS Kernel series 6.6 is being used in place of 6.10.x kernel series
+* LibreSSL is used instead of OpenSSL *except* with Python3
+* LTS Kernel series 6.6.x is being used in place of 6.10.x kernel series
 * Some versions are updated from what is in the LFS book.
 
 The host I am building from is an LFS 11.3 system with similar modifications.
 
-As of present, these scripts are not complete and probably broken.
+When LFS 12.2 is built on the USB Thumb Drive, it should then be possible to
+boot from the USB Thumb Drive and run the scripts again to build LFS 12.2 from
+LFS 12.2 on a hard disk partition where I can then proceed with the other steps
+in `THE_PLAN.md` towards creating a RPM distro from scratch.
 
-These instructions are incomplete notes.
+As of present, these scripts are not complete and some are probably broken.
+
+These instructions are not complete notes.
+
+If you run the script `version-check.sh` (copy-pasta straight from the LFS
+book) and everything on your build system passes, there is a *good chance*
+these scripts can build LFS 12.2 on your build system. If anything on your
+build system does __not__ pass the tests in that scripts, there is a good
+chance your build system is not suitable. Sometimes you can upgrade some
+components, but it is smoother to start with a system already capable.
 
 
 Chapter 03 ‘Get Sources’ Script
@@ -161,6 +177,32 @@ and some of them are missing the running of the tests. Also, I need to add a
 way to disable the running of the tests.
 
 
+Chapter Nine Configuration
+--------------------------
+
+These configuration scripts have things very specific to my hardware, such as
+the MAC Address of my NIC and the UUID identifiers for my disk partitions.
+
+For the network configuration, I am trying to use `systemd-networkd` to
+configure the network interface card, I think I understand the documentation
+for that and the general impression I get is that it works quite well.
+
+For DNS resolution however, I found the documentation for `systemd-resolved` to
+be quite confusing and I also found many complaints from Ubuntu and Fedora
+users seeming to indicate it is still quite buggy.
+
+So the script for setting up networking disables `systemd-resolved` and instead
+creates a classic `/etc/resolv.conf` file. Once I have the system running, I
+will likely play with `systemd-resolved` but even if I do play with it and get
+it working well, I generally like to run `unbound` (in DNSSEC enforcing mode)
+on the localhost anyway.
+
+Network configuration for the USB flash drive is to not use it, it does not need
+a network connection for anything.
+
+
+
+
 The Madness
 -----------
 

THE-PLAN.md

@@ -1,8 +1,9 @@
 The Plan
 ========
 
-This is an attempt to create a new GNU/Linux distribution. The why I will
-document elsewhere.
+This is an attempt to create a new GNU/Linux distribution. The why is in the
+file `THE_WHY.md` but TLDR, because I can. Well, because I think I can. Maybe,
+and even if not, I will still learn a lot...
 
 The new distribution will be called ‘Yellow-Jacket GNU/Linux’ (abbreviated as
 ‘YJL’) and will be heavily based upon ‘Linux From Scratch’ (LFS) but will have
@@ -11,7 +12,8 @@ package manager.
 
 I first started this in early 2023 however my efforts were cut short by a busted
 water pipe in the ceiling over my bedroom, which also is my office. Extensive
-water damage resulted.
+water damage resulted and due to both poverty and a desire for things to be done
+right, it took a long time for the bedroom to be rebuilt.
 
 After that, there were some medical issues with family members that took a lot
 of my time and *still* take a lot of my time, but I am back on track.
@@ -26,12 +28,10 @@ Phase One: LFS Bootstrap
 
 This phase is what this git repository is about. Create the needed shell scripts
 to build the current SystemD LFS (12.2 as I type) on a USB thumb drive that can
-then boot an 'x86_64' system and rebuild itself to the hard drive of that
-system. It does not need to be able to make a network connection, the needed
-source tarballs and patches and scripts will be preserved in '/home/lfs' on the
-bootable USB thumb drive.
-
-I am hoping a 128 GB thumb drive will be enough.
+then boot an `x86_64` system and rebuild itself to the hard drive of that
+system. Long term goal is a generic image that can be copied onto any thumb
+drive via `dd`, boot a generic `x86_64` system, and build LFS on it. Short term
+goal is specific to my system.
 
 My build host is the LFS 11.3 system I build in 2023 (fortunately my PC did
 survive the water damage). As of today (2024-11-07) I have LFS 12.2 properly
@@ -39,7 +39,7 @@ building through Chapter 8 with my minor modifications (e.g. LibreSSL) but
 the build scripts do need some work still and stripping binaries etc. still
 needs to be scripted.
 
-I am using '/mnt/newlfs' as the install path rather than '/mnt/lfs' because I
+I am using `/mnt/newlfs` as the install path rather than `/mnt/lfs` because I
 do not want someone playing with these scripts to accidentally nuke their own
 LFS system.
 
@@ -61,13 +61,13 @@ rebuild GCC for full compiler support.
 To compile GCC with Ada and D support, a working Ada and D compiler is needed.
 
 My LFS 11.3 system has those. What I did back then, on CentOS 7.9 (my build host
-for LFS 11.3) I built GCC 7.5.0 with Ada ('gnat') and D ('gdc') support, with an
-install prefix of '/opt/gcc750'. GCC 7.5.0 was the newest GCC I could get to
+for LFS 11.3) I built GCC 7.5.0 with Ada (`gnat`) and D (`gdc`) support, with an
+install prefix of `/opt/gcc750`. GCC 7.5.0 was the newest GCC I could get to
 build in CentOS 7.9 with Ada and D support.
 
 I had to copy a few shared libraries from the CentOS 7 system into
-'/opt/gcc750/lib' but once I did that, I was able to use that GCC in LFS 11.3 to
-then build an Ada and D capable GCC 10.4.0 within '/opt/gcc1040', GCC 7.5.0
+`/opt/gcc750/lib` but once I did that, I was able to use that GCC in LFS 11.3 to
+then build an Ada and D capable GCC 10.4.0 within `/opt/gcc1040`, GCC 7.5.0
 would not succesfully build an Ada and D capable GCC 12.2.0.
 
 However I was then able to use GCC 10.4.0 to build the Ada and D capable GCC
@@ -75,7 +75,7 @@ However I was then able to use GCC 10.4.0 to build the Ada and D capable GCC
 
 For the LFS 12.2 GCC bootstrap, I *suspect* I can use the Ada and D capable GCC
 GCC 12.2.0 in LFS 11.3 to build an Ada and D capable GCC 14.2.0 installed in
-'/opt/gcc1420' that I can then use in LFS 12.2 to bootstrap the system GCC, of
+`/opt/gcc1420` that I can then use in LFS 12.2 to bootstrap the system GCC, of
 course running the full test suite before installing.
 
 I tried adding Ada and D support to the GCC building of LFS 12.2 Chapter 5 and
@@ -97,7 +97,18 @@ that work has already been done from my LFS 11.3 system but the spec files need
 to be updated and some still needed to be written when the water pipe broke.
 
 
-Phase Four: XFCE
+Phase Four: Mock Build Environment
+----------------------------------
+
+After the system is RPM bootstrapped, I have to build and configure a Mock build
+environment for packages, see https://rpm-software-management.github.io/mock/
+
+A Mock build build environment is essential for clean, untainted packages. I
+have used Mock build environments in the past but creating one from scratch for
+a new distribution is something I have not done.
+
+
+Phase Five: XFCE
 ----------------
 
 Once the system is RPM bootstrapped, I can start building the software needed
@@ -107,10 +118,10 @@ My *personal* preferred desktop environment is actually MATE but XFCE is what I
 am building as the default desktop environment for YJL.
 
 
-Phase Five: Installer
----------------------
+Phase Six: Installer
+--------------------
 
-With XFCE running, an bootable USB thumb drive that can install the system from
+With XFCE running, a bootable USB thumb drive that can install the system from
 RPM packages will have the be created. That will be when YJL becomes a reality
 and not just a concept I am working towards.
 
@@ -121,7 +132,7 @@ Beyond YJL
 I really dislike the current GNU/Linux ecosystems where a distribution tries to
 package everything under the sun.
 
-I much preferred the older days, pre Fedora, when 'yum' was new and you could
+I much preferred the older days, pre Fedora, when `yum` was new and you could
 install Red Hat Linux and then use add-on package repositories that met your
 specific needs.
 
@@ -153,7 +164,7 @@ and maybe they were only imagined back then.
 I am not a kernel hacker and even if the YJL project takes off, hiring a kernel
 hacker does not seem like a wise use of resources. By running a LTS kernel in
 YJL, security issues can be fixed by updating to the latest in the LTS series
-from 'kernel.org' without needing to backport patches. Using an LTS kernel means
+from `kernel.org` without needing to backport patches. Using an LTS kernel means
 that YJL does not have to hire a kernel hacker to remain secure without needing
 to break some systems with a kernel update when a particular kernel series is
 no longer maintained, the LTS kernels are maintained for a very long time.
@@ -167,7 +178,7 @@ wired network jack. I went and bought a PCI WiFi card with a Tux logo on it that
 claimed Linux compatibility. Well, that was only partially true.
 
 The card required a closed source driver that worked just fine with older
-kernels. In fact for CentOS, 'elrepo' had a package for it, but I could not get
+kernels. In fact for CentOS, `elrepo` had a package for it, but I could not get
 the card to work in Fedora because the kernel was too new. I also had a similar
 issue with an nVidia GPU.
 
@@ -176,7 +187,7 @@ the hardware does work with the kernel, it it likely to continue working with
 updates to the same LTS kernel series.
 
 Users and add-on package repositories are of course free to package kernels from
-newer series but then what to do when 'kernel.org' stop pushing updates to that
+newer series but then what to do when `kernel.org` stop pushing updates to that
 series is their problem, not mine. They can backport fixes, or they can update
 to an even newer series, but doing the latter may break some systems.
 
@@ -187,11 +198,11 @@ ships with YJL should be a safe generic kernel configuration but the user need
 not be restricted to those options.
 
 I would like YJL to have a tool that allows users to specify what kernel series
-they would like to use that then monitors 'kernel.org' for updates to that
-series and then creates a 'src.rpm' for them (using 'make oldconfig') that they
+they would like to use that then monitors `kernel.org` for updates to that
+series and then creates a `src.rpm` for them (using `make oldconfig`) that they
 can rebuild and install. Sometimes updates have new options so it can not be
 totally automated. Of course such a tool would need to verify the signature of
-the updated source.
+the updated kernel source to be safe.
 
 ### YJL Versioning
 
@@ -200,9 +211,9 @@ the version number of YJL. For example, the current LTS kernel I am using is
 the 6.6 series so if I shipped YJL today, it would be YJL 6.6.
 
 If this project does take off, it is probable that I will not ship a new
-version of YJL every time 'kernel.org' tags a new kernel series as an LTS
+version of YJL every time `kernel.org` tags a new kernel series as an LTS
 series. There is a good chance I will only make a new YJL for every other LTS
-kernel.
+kernel or so.
 
 The 6.6 series was initially released in October, 2023 and has a projected EOL
 of December, 2026. My guess is there will be another LTS series before I have an
@@ -210,7 +221,7 @@ installer ready, and that it will likely also have about a three year lifespan.
 
 My guess is that the initial installer will probably have kernel configuration
 that needs a lot of improvement. Updated installers with updated packages are a
-sure thing. A hyphen can be users for that, e.g. ‘YJL 6.6-3’ would indicate the
+sure thing. A hyphen can be used for that, e.g. ‘YJL 6.6-3’ would indicate the
 third installer revision of YJL that uses the 6.6 LTS kernel series.
 
 
@@ -243,12 +254,3 @@ YJL will provide the shell scripts needed to set this up, YJL will not package
 TeXLive. Third parties that want to create an RPM package repository, have at
 it, I just think distribution packaging is the wrong approach to TeXLive.
 
-
-
-
-
-
-
-
-
-