Build a KLV-Airedale from Script + PLUG File

[rockedge]

The following code is a PLUG file that will build a basic KLV-Airedale.

f_00_Void_KLV_XFCE_no-kernel_WDLteam-rc5.plug

Code: Select all

# f_00_Void_KLV_XFCE_no-kernel_WDLteam-rc5.plug
# version="2.7.0"; revision="-beta20"
# Kennel Linux Void outfitted with a xfce4 desktop and no kernel **uses puppy linux kernel**
# Creation date 24Sep2021; Revision date: 02Oct2022
# Copyright Kennel Linux team; Licence MIT

# build this via terminal commands:build_firstrib_rootfs_401rc1.sh
# export CONNECTION_TIMEOUT=-1  **not needed with v501**
# ./build_firstrib_rootfs_401rc1.sh void default amd64 f_00_Void_KLV_XFCE_kernel_WDLteam-rc5.plug
# Architecture i386 will probably successfully build too as an alternative to amd64

# login is user=root passwd=root

# All the parameters/commandlines can be appropriately changed:
# Simply comment in or comment out till you have what you desire
# or add new packages to the xbps-install lists.
# You can add as many valid commandlines as you want in here.
#
# base system
xbps-install -y base-minimal ncurses-base bash eudev
xbps-install -y file mc xterm xauth
xbps-install -y shadow wpa_supplicant  # needed for most wifi
xbps-install -y ntfs-3g zstd

# set up passwd system
pwconv
grpconv
printf "root\nroot\n" | passwd >/dev/null 2>&1 # Quietly set default root passwd to "root"

# set root to use /bin/bash
usermod --shell /bin/bash root

# Set locale to en_US.UTF-8 
sed -i 's/#en_US.UTF-8 UTF-8/en_US.UTF-8 UTF-8/' /etc/default/libc-locales
xbps-reconfigure -f glibc-locales

# Set Bash as shell
xbps-alternatives --set bash

## --------------------------------------------------------------------------
## Xorg server, xfce4 Desktop configuration

xbps-install -y xorg xfce4 xfce4-panel xfce4-plugins compton picom
xbps-install -y gvfs yad
xbps-install -y gvfs-smb gvfs-mtp gvfs-cdda

# Optional packages
#
xbps-install -y geany gftp rox ffmpeg mtpaint xfce4-screenshooter
xbps-install -y octoxbps fox guvcview putty
xbps-install -y e2fsprogs yelp gparted
xbps-install -y dosfstools mtools cherrytree
xbps-install -y squashfs-tools wget gxmessage

# Browser selection
xbps-install -y firefox

# Fix Firefox Fonts 
#
ln -s /usr/share/fontconfig/conf.avail/70-no-bitmaps.conf /etc/fonts/conf.d/
xbps-reconfigure -f fontconfig


# Install Audio
#
xbps-install -y pulseaudio pulseaudio-utils alsa-plugins-pulseaudio alsa-utils
ln -s /etc/sv/pulseaudio /etc/runit/runsvdir/default/pulseaudio

# Install Network Manager
#
xbps-install -y NetworkManager network-manager-applet
ln -s /etc/sv/NetworkManager /etc/runit/runsvdir/default/NetworkManager

# Set locale to en_US.UTF-8
sed -i 's/#en_US.UTF-8 UTF-8/en_US.UTF-8 UTF-8/' /etc/default/libc-locales
xbps-reconfigure -f glibc-locales

# Add ~/Startup directory
#
mkdir -p /root/Startup
cat <<'EOF' >> /usr/local/bin/start-up
#!/bin/bash
sleep 5
user_home=$(eval echo ~${SUDO_USER})
ls $user_home/Startup/* | while read J
do
   "$J" &
done
EOF

chmod +x /usr/local/bin/start-up
 
# Setup autologin on tty1
#
cp -a /etc/X11/xinit/xinitrc /root/.xinitrc
cp -R /etc/sv/agetty-tty1 /etc/sv/agetty-autologin-tty1
sed -i 's/GETTY_ARGS.*/GETTY_ARGS="--autologin root --noclear"/' /etc/sv/agetty-autologin-tty1/conf  # editing for autologin root

# Arrange to startx in user's .bash_profile (per Arch Wiki)
# Remove this section if not wanting boot straight into X
touch ~/.bash_profile
cat <<'AUTOLOGIN' > /etc/profile.d/autologin.sh
# autologin on tty1
if [ -z "$DISPLAY" ] && [ "$(fgconsole)" -eq 1 ]; then
exec startx  # remove the exec if you want back to tty1 on exit X

fi
AUTOLOGIN

# Get and install autologin fix
#
cd /etc/sv
wget https://rockedge.org/kernels/data/XBPS_packages/agetty-autologin-tty1.tar.gz
tar xvfz agetty-autologin-tty1.tar.gz

# Use agetty-autologin-tty1 instead of agetty-tty1 
rm -f /etc/runit/runsvdir/default/agetty-tty1
ln -s /etc/sv/agetty-autologin-tty1 /etc/runit/runsvdir/default/agetty-autologin-tty1

# enable dbus service
ln -s /etc/sv/dbus /etc/runit/runsvdir/default/dbus

# Auto-editing .xinitrc to use xfce4 instead of twm
# Because I'm using exec here the script will end there so no xterms started
#
# sed -i 's/twm &/exec xfce4-session/' ~/.xinitrc

sed -i '51,$d' /root/.xinitrc
echo "/usr/local/bin/start-up &" >>/root/.xinitrc 
echo "# exec xfce4-session" >>/root/.xinitrc
echo "xfce4-session" >>/root/.xinitrc  # removed exec to allow dropping out of Xorg to console

## USER CONFIGS: Copy main configs to /etc/skel for all normal users later added
#
xbps-install -y sudo
cp -af /root/. /etc/skel
mkdir -p /etc/skel/.config /etc/skel/.cache /etc/skel/.local/share
echo Still some extra to do here re the likes of runit starting pulseaudio
echo among other user needed config bits and pieces,
echo so probably a few user-config issues noted as needing fixed here

# Give wheel group nopasswd sudo rights and create weedog as wheel group member
echo '%wheel ALL=(ALL) NOPASSWD: ALL' | (VISUAL="tee -a" visudo) # wheel group added to sudo no password required
useradd -m -G wheel -s /bin/bash weedog  # weedog in wheel group so has elevated sudo permissions
printf "weedog\nweedog\n" | passwd weedog >/dev/null 2>&1 # Quietly set default weedog passwd to "weedog"

# Give wheel group nopasswd sudo rights and create spot as wheel group member
echo '%wheel ALL=(ALL) NOPASSWD: ALL' | (VISUAL="tee -a" visudo) # wheel group added to sudo no password required
useradd -m -G wheel -s /bin/bash spot  #spot in wheel group so has elevated sudo permissions
printf "spot\nspot\n" | passwd spot >/dev/null 2>&1 # Quietly set default spot

# Create /home/spot directories
#
mkdir -p /home/spot/Desktop
mkdir -p /home/spot/Documents
mkdir -p /home/spot/Downloads
mkdir -p /home/spot/Music
mkdir -p /home/spot/my-applications
mkdir -p /home/spot/Pictures
mkdir -p /home/spot/Public
mkdir -p /home/spot/Startup
mkdir -p /home/spot/Templates
mkdir -p /home/spot/Videos


# Set permissions
#
chown -R spot:spot /home/spot
chown -R weedog:weedog /home/weedog

# add users to groups and change permissions
#
usermod -a -G audio weedog
usermod -a -G audio spot
usermod -a -G video weedog
usermod -a -G video spot
xhost +
chmod 755 /
chmod 755 /bin
chmod 755 /lib

# add sudo -spot to .desktop files
cd /usr/share/applications
sed -i 's/^Exec=/&sudo -uspot /' octoxbps.desktop
sed -i 's/^Exec=/&sudo -uspot /' octoxbps-notifier.desktop
cp /usr/share/applications/thunar.desktop /usr/share/applications/thunar-spot.desktop
sed -i 's/^Exec=/&sudo -uspot /' thunar-spot.desktop
sed -i 's/^Name=/&spot-/' thunar-spot.desktop

#### Get KLV custom packages ####
#
# Create and switch to build directory
mkdir -p /root/Build
cd /root/Build

wget ‐‐continue https://rockedge.org/kernels/data/XBPS_packages/libfontconfig1-1.12_0.x86_64.xbps
wget ‐‐continue https://rockedge.org/kernels/data/XBPS_packages/gparted-shell-1.0_0.noarch.xbps
wget ‐‐continue https://rockedge.org/kernels/data/XBPS_packages/mime-add-1.1_0.noarch.xbps
wget ‐‐continue https://rockedge.org/kernels/data/XBPS_packages/xbps-tools-1.0_3.noarch.xbps
wget ‐‐continue https://rockedge.org/kernels/data/XBPS_packages/pfind-howbig-tca-1.0_0.noarch.xbps
wget ‐‐continue https://rockedge.org/kernels/data/XBPS_packages/uextract-4.7_1.noarch.xbps
wget ‐‐continue https://rockedge.org/kernels/data/XBPS_packages/tzupdate2-2.0_2.noarch.xbps
wget ‐‐continue https://rockedge.org/kernels/data/XBPS_packages/xluncher-1.0_0.noarch.xbps
wget ‐‐continue https://rockedge.org/kernels/data/XBPS_packages/default-scripts-1.0_1.noarch.xbps
wget ‐‐continue https://rockedge.org/kernels/data/XBPS_packages/dropbear-0.81_1.x86_64.xbps
wget ‐‐continue https://rockedge.org/kernels/data/XBPS_packages/SFS-Load-2.0_1.noarch.xbps
wget ‐‐continue https://rockedge.org/kernels/data/XBPS_packages/tas-1.15_1.noarch.xbps
wget ‐‐continue https://rockedge.org/kernels/data/XBPS_packages/packit-pfind-1.0_1.noarch.xbps
wget ‐‐continue https://rockedge.org/kernels/data/XBPS_packages/gettext-1.0_1.noarch.xbps
wget ‐‐continue https://rockedge.org/kernels/data/XBPS_packages/swapper-1.2_1.noarch.xbps
wget ‐‐continue https://rockedge.org/kernels/data/XBPS_packages/backgrounds-1.0_1.noarch.xbps
wget ‐‐continue https://rockedge.org/kernels/data/XBPS_packages/run-as-users-1.5_1.noarch.xbps
wget ‐‐continue https://rockedge.org/kernels/data/XBPS_packages/inst-xbps-1.8_1.noarch.xbps
wget ‐‐continue https://rockedge.org/kernels/data/XBPS_packages/gtkhash-1.1.1_1.x86_64.xbps
wget ‐‐continue https://rockedge.org/kernels/data/XBPS_packages/pure-ftpd-1.0.50_1.x86_64.xbps
wget ‐‐continue https://rockedge.org/kernels/data/XBPS_packages/syndownload-2.0_1.x86_64.xbps
wget ‐‐continue https://rockedge.org/kernels/data/XBPS_packages/desktop-config-1.0_1.x86_64.xbps
wget ‐‐continue https://rockedge.org/kernels/data/XBPS_packages/sClock-1.5_1.x86_64.xbps


#### Install KLV custom packages ####

# Register and index packages
cd /root
xbps-rindex -a Build/*.xbps

# Install libfontconfig cache fix
xbps-install -y --repository=Build/ libfontconfig1-1.12_0

# Install gparted-shell
xbps-install -y --repository=Build/ gparted-shell-1.0_0

# Install MIME definitions 
xbps-install -y --repository=Build/ mime-add-1.1_0

# Install pfind-howbig-tca
xbps-install -y --repository=Build/ pfind-howbig-tca-1.0_0

# Install xbps-tools 
xbps-install -y --repository=Build/ xbps-tools-1.0_3

# Install uextract
xbps-install -y --repository=Build/ uextract-4.7_1

# Install tzupdate
xbps-install -y --repository=Build/ tzupdate2-2.0_2

# Install xLunch
xbps-install -y --repository=Build/ xluncher-1.0_0
xbps-pkgdb -m hold  xlunch-4.1_3

# Install default launch scripts
xbps-install -y --repository=Build/ default-scripts-1.0_1

# Install dropbear
xbps-install -y --repository=Build/ dropbear-0.81_1

# Install SFS-Load
xbps-install -y --repository=Build/ SFS-Load-2.0_1

# Install tas
xbps-install -y --repository=Build/ tas-1.15_1

# Install Packit and pFind
xbps-install -y --repository=Build/ packit-pfind-1.0_1

# Install gettext
xbps-install -y --repository=Build/ gettext-1.0_1

# Install swapper
xbps-install -y --repository=Build/ swapper-1.2_1

# Install  backgrounds
xbps-install -y --repository=Build/ backgrounds-1.0_1

# Install run-as-spot and run-as-weedog
xbps-install -y --repository=Build/ run-as-users-1.5_1

# Install inst-xbps
xbps-install -y --repository=Build/ inst-xbps-1.8_1

# Install gtkhash
xbps-install -y --repository=Build/ gtkhash-1.1.1_1

# Install pure-ftpd
xbps-install -y --repository=Build/ pure-ftpd-1.0.50_1

# Install Syndownload
xbps-install -y --repository=Build/ syndownload-2.0_1

# Install desktop configuration
xbps-install -y --repository=Build/ desktop-config-1.0_1

# Install sClock
xbps-install -y --repository=Build/ sClock-1.5_1



# Set execution permissions recursivly for binaries and scripts
chmod +x -R /usr/local/bin

# Clean Up
#

rm -r /root/Build
rm /var/cache/xbps/*

#-----------------------------------------------------------------------
echo "desktop build process finished"

Attached to this post is the build script that will build the firstrib_rootfs for a KLV-Airedale Basic
There are several more steps to create a frugal directory that will boot once the rootfs is built.

[wiak]

Code: Select all

Incomplete or invalid multibyte sequence encountered
Incomplete or invalid multibyte sequence encountered
--2022-10-03 06:05:06--  http://%E2%80%90%E2%80%90continue/
Resolving \342\200\220\342\200\220continue (\342\200\220\342\200\220continue)... failed: Name or service not known.
wget: unable to resolve host address '\342\200\220\342\200\220continue'
--2022-10-03 06:05:06--  https://rockedge.org/kernels/data/XBPS_packages/tzupdate2-2.0_2.noarch.xbps
Resolving rockedge.org (rockedge.org)... 31.22.4.101
Connecting to rockedge.org (rockedge.org)|31.22.4.101|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 8941 (8.7K)
Saving to: 'tzupdate2-2.0_2.noarch.xbps'

tzupdate2-2.0_2.noa 100%[===================>]   8.73K  --.-KB/s    in 0s      

2022-10-03 06:05:07 (189 MB/s) - 'tzupdate2-2.0_2.noarch.xbps' saved [8941/8941]

FINISHED --2022-10-03 06:05:07--

I'm trying your f_ build plug with newer build_firstrib_rootfs script I've been working on (a few weeks back) and getting above mysterious messages. I've only glanced at your f_plug contents, but don't know what above "incomplete or invalid multibyte sequence encountered" message might be about. Admittely I am in Zorin lite trying it so I should switch over to my KLV install to try a build. All I see in you plugin at above stage is a series of wget --continue lines bringing down these .xbps packages you have stored so I'm not sure what is going on. Maybe worked anyway, but thought I'd check if you have seen this before and know the cause prior to me using time looking into it more.

I'll try and get round to finishing off these newer build_firstrib_rootfs script and the one for the initrd soon - is being worked on over time though. I actually need these two new scripts working soonish since I wish to write FirstRib blog post about building from f_plugin, but can't do that till my new build_script versions are ready - at least the previous 401 version still building Void-based root-filesystem okay it seems. Wifi worked, firefox worked, audio playing youtube worked - all out of the box, so at a glance built fine for me with new script I'm working on. Just checking if reason known for above messages during build.

EDIT: It did boot by the way, once I copied the kernel/modules/firmware and initrd.gz across from my other KLV frugal install so might be fine - just wonder what above messages are all about just in case. i.e. What on earth is:

Code: Select all

--2022-10-03 06:05:06--  http://%E2%80%90%E2%80%90continue/

Maybe something to do with the following stuff (I have no idea)?

Code: Select all

#### Install KLV custom packages ####

# Register and index packages
cd /root
xbps-rindex -a Build/*.xbps

# Install libfontconfig cache fix
xbps-install -y --repository=Build/ libfontconfig1-1.12_0

[dimkr]

@rockedge Is there any automated way to rebuild the prebuilt .xbps packages?

[rockedge]

@wiak When I run a build using Fossapup64 I run into warnings throughout the process. This does not happen when building in Bionic64! Those errors you've encountered I have not seen myself yet. I like to keep wd_mount and wiakwifi on hand for deep level diagnostics and in case of emergencies.

I just ran the plug and build script from copied and downloaded from the post.

Code: Select all

 ./build_firstrib_rootfs_500rc1.sh void default amd64 f_00_Void_KLV_XFCE_no-kernel_WDLteam-rc5.plug

And after the build run script ->

Screenshot(21).png (20.74 KiB) Viewed 829 times

Now after copying the kernel and GTKDialog SFS addon including the /boot directory, this is configuration will use the uncompressed 07firstrib_rootfs
and an upper_changes for persistence will be created automatically ->

Screenshot(22).png (30.74 KiB) Viewed 829 times

This configuration is a what I call a pseudo full install

Screenshot(23).png (34.45 KiB) Viewed 822 times

Or squash the firstrib (or if in the PFI mode, upper_changes) to a 07KLV-airedale_rootfs.sfs

Code: Select all

mksquashfs upper_changes 07KLV-airedale_rootfs.sfs  -b 1048576 -comp xz -Xdict-size 100% -noappend

and arranged as shown in the screenshot ->

Screenshot(24).png (30.68 KiB) Viewed 818 times

[wiak]

Just finished my first draft of the latest build scripts - same usage as earlier though some renaming:

1. build_firstrib_rootfs.sh and 2. boot_wiak_initrd.sh (so w_names still makes sense regarding wiak initrd plugin and argument names).

It has been a long time since I build a distro via the run of these two scripts method, but happy to say it has worked on first attempt and using Void firmware and kernel with build_wiak_initrd.sh churning out an initrd containing boot modules and so on. Also tried the empty version of that initrd (i.e. skeleton initrd with huge kernel firmware/modules/vmlinuz components. Both worked. Currently posting from the Void Linux kernel KLV-Airedale64 built from the f_plugin rockedge released. One thing I want to add out of previous weedogit script is the example grub_config.txt file, since that makes setting up an existing grub install really easy and without needing to immediately understand FirstRib wiak initrd boot arguments.

I did still get the weird warning errors I posted about already (did the build using an existing KLV install as host build distro) - just seems to be something to do with wget ... the extra .xbps files from rockedges site - I have no idea what the related 'warning errors' are about but didn't seem to effect the actual build anyway as far as I can see thus far. All seems good.

So it looks like that original firstrib builds, being that for Void Linux upstream, is building fine via that simple run two-script method. What I expect may not (or may if I am particularly lucky) are the root filesystem builds for the likes of Arch, Debian, Ubuntu, Devuan, and now Fedora (I've added that one in, but not tested yet). The build_wiak_initrd.sh script hasn't had much done to it at all and probably could do with me revisiting parts of it. Seems generally fine though, so depends how much time I have later - one thing that is a bit tricky is whether /lib/modules or /usr/lib/modules hierarchy is being used upstream - I believe most are now going for /usr/lib/modules and so on, but I have to test that. I don't intend catering for older filesystem hierarchy since too much work to maintain. In fact maintenance is the biggest problem when multi-distro build capability is involved - requires so much testing then. I'll probably at least concentrate on maintaining Void Linux builds and also Arch Linux; I will try to get Ubuntu/Debian/Devuan/Fedora still building, but will take a while and specially if upstream goal posts keep changing (repo and file names, for example). I am however trying to automate as much as possible so I don't have too much work to do updating such required information.

I'll publish these two newest build scripts soonish via their FirstRib gitlab site eventually. First I'll release test versions on FirstRib forum for download after login - in case I can get any useful feedback/bug reports that way.

I'll also put firstribit.sh (previously named weedogit.sh) on same site once I have revamped the previous version to reflect naming convention change to original FirstRib project name.

I hadn't planned to update the build scripts at this time, but I needed to so I could write tinylinux.info blog post on how to use them...

[rockedge]

@wiak That's great news! I ran 2 builds this morning so far. One on Fossapup64 and the other on Bionic64-CE. There are errors that I will note later during the build on Fossapup64. These errors and warnings do not seem to impact the over all end product which works smoothly. Of course the PLUG is open to customization to for anyone wanting to shape the systems being built.

When run on Bionic64-CE with the exact same build script and PLUG, there are no error or warnings and the distro works. It is easy to add in the needed packages for the Void Kernel in the PLUG file. I found running with a Void Linux Kernel is best in a pseudo full install because the kernel updates can be managed in an official way by using vkpurge to clear out old kernels when not used. In some FirstRib-Void's the kernel upgrade would be in upper_changes but the lower version kernel is in a lower layer and is still present. It all still works but I experienced with some FirstRib builds the upgraded kernel would be installed each time but only the original kernel would ever be used. It was hit or miss if the vkpurge utility would work correctly. This is not a problem when upgrading the system in a pseudo full install.

It is possible to put a xbps hold on the kernel version to prevent an upgrade.

Both builds are the very basic KLV-Airedale64 and running nice and brisk. Great QEMU machine OS.

[wiak]

In some FirstRib-Void's the kernel upgrade would be in upper_changes but the lower version kernel is in a lower layer and is still present. It all still works but I experienced with some FirstRib builds the upgraded kernel would be installed each time but only the original kernel would ever be used. It was hit or miss if the vkpurge utility would work correctly.
...
It is possible to put a xbps hold on the kernel version to prevent an upgrade.

Unless there was something wrong with Void Linux vkpurge implementation I expect on running system it should remove the old kernels okay (though aside from knowing what it is used for I know nothing about vkpurge operation); yes that would be via deletions in upper_changes. However, a problem would remain that vkpurge could do nothing about. When using Void Kernel you need the initrd to contain modules that work with that kernel. vkpurge knows nothing about the initrd so the modules in there would always be for the old kernel unless removed manually or done so by some extra utility - such a utility could be made of course. However that same problem would also be the case for pseudo-full-install, which does make me wonder why vkpurge (plus changing initrd) gave any problems. Generally should 'hold' kernel version unless also changing initrd though.

I'll download BionicPup64 (any particular download version, and where, best to try) so that I can check build on Fossapup64 versus build on that Bionic. I don't think build_firstrib_rootfs has anything to do with the messages, but I'd like to make sure - the messages I get are very strange to me so I have no idea what they relate to, but yes, build seems to have gone fine according to simple tests thus far.

Just looked at vkpurge man page, maybe it is a problem related to:

vkpurge only lists or removes kernel versions that are:

not currently booted.
not provided by any installed xbps package

Probably better having some simple utility to remove kernel components ourselves and fixing up initrd for new kernel. But not needed for KLV-AIredale since it relies on external modules and huge kernel(?). I think in DebianDog kernel just gets pinned? I just did similar for WDL_Arch64 to avoid such issues, so seems easiest to 'hold' kernel under Void unless new build. Such issues don't exist with real full install of course, which is maybe its biggest advantage (despite its disadvantages).

[rockedge]

@wiak I finally logged the build script output. Maybe look into adding a logging mechanism to the script or come up with piped command so I can respond to the first query and watch the progress on the console AND have a log file generated.
I came close enough to copy the error which is the same thing over and over. I found a reason once on stackexchange but didn't pursue it too far and I switched back to Bionic to build with the script.

Code: Select all

ERROR: ld.so: object '/usr/lib/x86_64-linux-gnu/libgtk3-nocsd.so.0' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.

Code: Select all

[*] Unpacking packages
xbps-triggers-0.124_1: unpacking ...
base-files-0.142_14: unpacking ...
glibc-2.32_2: unpacking ...
libcrypto1.1-1.1.1q_1: unpacking ...
libssl1.1-1.1.1q_1: unpacking ...
openssl-1.1.1q_1: unpacking ...
run-parts-4.11.2_1: unpacking ...
ca-certificates-20211016+3.83_1: unpacking ...
WARNING: cannot create kvm:24 system group (missing groupadd)
The following group must be created manually: kvm:24
WARNING: cannot create plugdev:26 system group (missing groupadd)
The following group must be created manually: plugdev:26
WARNING: cannot create usbmon:27 system group (missing groupadd)
The following group must be created manually: usbmon:27
Creating system directories/symlinks...

These do not seem to effect the overall build on Fossapup64.

I did run into the exact error that you posted as well:

Code: Select all

ERROR: ld.so: object '/usr/lib/x86_64-linux-gnu/libgtk3-nocsd.so.0' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.
Incomplete or invalid multibyte sequence encountered
Incomplete or invalid multibyte sequence encountered
--2022-10-05 23:57:12--  http://%E2%80%90%E2%80%90continue/
Resolving \342\200\220\342\200\220continue (\342\200\220\342\200\220continue)... failed: Name or service not known.
wget: unable to resolve host address '\342\200\220\342\200\220continue'
--2022-10-05 23:57:12--  https://rockedge.org/kernels/data/XBPS_packages/libfontconfig1-1.12_0.x86_64.xbps
Resolving rockedge.org (rockedge.org)... 31.22.4.101
Connecting to rockedge.org (rockedge.org)|31.22.4.101|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 499950 (488K)
Saving to: 'libfontconfig1-1.12_0.x86_64.xbps'

And that error ERROR: ld.so: object '/usr/lib/x86_64-linux-gnu/libgtk3-nocsd.so.0' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored. is thrown a lot in Fossapup64 but does not happen in Bionic64.

[wiak]

@wiak I finally logged the build script output. Maybe look into adding a logging mechanism to the script or come up with piped command so I can respond to the first query and watch the progress on the console AND have a log file generated.

Yes, will add a logging mechanism rather than just tee the build command output. No idea about the build log 'complaints' - it seems to me that they all get themselves sorted out by the end. Odd the ones involving wget at the very end though - I do suspect these are something to do with the way local xbps repo is configured, but again, seems to manage to install anyway, which is fine... I can live with that!
No idea at all why no such reports occur with BionicPup - as I said I will try builds from Fossa and Bionic. Recently my builds have all been made on Zorin Lite, and then I tried KLV-Airedale which gave identical build log, and in both cases the final distro build came out fine as far as I have noticed thus far anyway. Really most interested to know the reason for that last set of messages concerning wget and install xbps files - why an issue and why BionicPup says 'no issue'? Oh well... Shouldn't matter what Linux distro you use for the host build, and doesn't really seem to matter at the end of the day.

I'll experiment further this evening since I have that grub_config.txt extra to add anyway.

[rockedge]

@wiak The 2 new RAM modules came in the mail, are installed and the 2008 DELL VOSTRO 1500 is now with 4 GiB of RAM running nicely with KLV-Airedale-beta20 and beta20.2.

The memory upgrade makes this machine with KLV run as well as a DELL INSPIRON laptop half it's age or better!

[wiak]

@wiak The 2 new RAM modules came in the mail, are installed and the 2008 DELL VOSTRO 1500 is now with 4 GiB of RAM running nicely with KLV-Airedale-beta20 and beta20.2.

The memory upgrade makes this machine with KLV run as well as a DELL INSPIRON laptop half it's age or better!

That's good to hear. In theory my old HP 2530p could be upgraded to 8GB via 2x4GB sticks if I could get the correct models RAM cheaply. I once missed a cheap deal at auction for two such chips - I should look again but kind of rare I for the particular brand I think (not sure - no big deal, but 8GB is nice and hefty if I could get it).

Meanwhile, was going to resurrect FirstRib Arch64 build (FR_arch64) but unfortunately the build_firstrib_script hung and I thought must be introduced mistake in my Arch-related build code, but no... turned out busybox.net is down so was hanging there when trying to do wget of busybox... I suppose I should put in some kind of timeout warning message... Meanwhile hoping busybox.net comes up again soon. Late here so will wait till tomorrow. By the way, related to my Arch f_plug, when you build KLV with f_ void plugin, if a package you request via xbps is no longer available does that just get ignored or does the xbps line miss out all the other stuff then? I certainly had that issue with Arch f_plugin previously and feel something like that also occurred with Void f_plugin one time when gtkdialog no longer available from Void repo when you plugin was still requesting it back then? I found a different way to use pacman to avoid that issue and should work for Void xbps too if you do have that problem occasionally; though maybe xbps just ignores single missing package and just gets on with downloading/installing the rest?

I thought I had an unexpected bonus situation this evening by the way. I downloaded BionicPup64 with the idea of trying the build_firstrib_rootfs script with it, but I already know Fossapup64 simply won't boot for some reason on this new machine of mine so thought no hope for BionicPup64, but actually it did boot, but then my celebration was soured because despite my copying over appropriate wifi firmware it refused to recognise wifi when using BionicPup - maybe I'll try a long ethernet cable to my router tomorrow and see if eth being recognised. Just want to test the new build script and to see if also no errors reported building KLV if using host BionicPup64. So tomorrow is another day.

[rockedge]

if a package you request via xbps is no longer available does that just get ignored or does the xbps line miss out all the other stuff then?

It seems that xbps will continue on despite running into a package that's not available. I have seen that for some reason occasionally Firefox was not being installed but the rest of the packages would be on that same xbps-install command line. Other times it would not and if Firefox was the first package on the line, the rest would fail. But the next separate xbps-install command line will be executed as expected.

Overall I will need to experiment and see how much abuse xbps can take with missing packages.

despite my copying over appropriate wifi firmware it refused to recognise wifi when using BionicPup

Would changing to a newer huge kernel fix the WiFi firmware/module problems? I have kernel 5.4.5-rt3 going in the Bionic64 that I lean on to run the build scripts, make the rootfs SFS's, and create the hybrid ISO images.

I found Bionic64 to be quite flexible when it comes to swapping kernels.

[wiak]

Would changing to a newer huge kernel fix the WiFi firmware/module problems? I have kernel 5.4.5-rt3 going in the Bionic64 that I lean on to run the build scripts, make the rootfs SFS's, and create the hybrid ISO images.

I found Bionic64 to be quite flexible when it comes to swapping kernels.

Yes, that should work. I'll do that later today.