From 54b63448df4e616a75f687b56cf4f0801c42434e Mon Sep 17 00:00:00 2001 From: YellowJacketLinux Date: Fri, 11 Oct 2024 00:37:32 -0700 Subject: [PATCH] more work --- CH9Config/01-NetworkConfig.sh | 51 +++++++++++++++++++++++ PRENINE.sh | 12 +++--- README.md | 50 ++++++++++++++++++++-- THE-PLAN.md | 78 ++++++++++++++++++----------------- 4 files changed, 142 insertions(+), 49 deletions(-) create mode 100644 CH9Config/01-NetworkConfig.sh diff --git a/CH9Config/01-NetworkConfig.sh b/CH9Config/01-NetworkConfig.sh new file mode 100644 index 0000000..71fb20c --- /dev/null +++ b/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 diff --git a/PRENINE.sh b/PRENINE.sh index 68bd375..5e42e3e 100644 --- a/PRENINE.sh +++ b/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 - 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 +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}/USBFlash fi diff --git a/README.md b/README.md index 640ce15..cded12b 100644 --- a/README.md +++ b/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 ----------- diff --git a/THE-PLAN.md b/THE-PLAN.md index 04ad3b3..c028bf3 100644 --- a/THE-PLAN.md +++ b/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. - - - - - - - - -