First Rib with Plug script.

[fredx181]

@Sofiya

we changed the way in snap-ex
when researching it was found that the latest package update breaks our output to the console to select save / not save.which is really sad.

Perhaps I didn't follow enough from this thread, but I just checked on KLA-OT2baseCE-2.7 and Save/NoSave from console at shutdown works OK for me.

[Sofiya]

@Sofiya

we changed the way in snap-ex
when researching it was found that the latest package update breaks our output to the console to select save / not save.which is really sad.

Perhaps I didn't follow enough from this thread, but I just checked on KLA-OT2baseCE-2.7 and Save/NoSave from console at shutdown works OK for me.

@fredx181 mmm..... I don't even know what to say.
I'm at a loss then why do I have it as described above ? KLA-OT2baseCE-2.7 ( iso919 МБ ) - https://mega.nz/file/LgcDhSYJ#bXfwdMDve ... 5GLWqSX6kk . definitely tested it ???

[fredx181]

@Sofiya

we changed the way in snap-ex
when researching it was found that the latest package update breaks our output to the console to select save / not save.which is really sad.

Perhaps I didn't follow enough from this thread, but I just checked on KLA-OT2baseCE-2.7 and Save/NoSave from console at shutdown works OK for me.

@fredx181 mmm..... I don't even know what to say.
I'm at a loss then why do I have it as described above ? KLA-OT2baseCE-2.7 ( iso919 МБ ) - https://mega.nz/file/LgcDhSYJ#bXfwdMDve ... 5GLWqSX6kk . definitely tested it ???

Not sure what you mean, yes I tested 2.7 and no problem as I said.
For you not ok ?

It works exit but the window with selection elements is not visible.only at random you can switch.

What you see exactly ? could be a timing issue. (I experienced with systemd that the shutdown console info can distort the Save/NoSave dialog)

[Sofiya]

@Sofiya

Perhaps I didn't follow enough from this thread, but I just checked on KLA-OT2baseCE-2.7 and Save/NoSave from console at shutdown works OK for me.

@fredx181 mmm..... I don't even know what to say.
I'm at a loss then why do I have it as described above ? KLA-OT2baseCE-2.7 ( iso919 МБ ) - https://mega.nz/file/LgcDhSYJ#bXfwdMDve ... 5GLWqSX6kk . definitely tested it ???

Not sure what you mean, yes I tested 2.7 and no problem as I said.
For you not ok ?

It works exit but the window with selection elements is not visible.only at random you can switch.

What you see exactly ? could be a timing issue. (I experienced with systemd that the shutdown console info can distort the Save/NoSave dialog)

yes, that's exactly what it looks like at the beginning, correctly, as it should be, then 6 lines of text appear on top, and the selection field disappears

[fredx181]

@Sofiya After some experimenting I found that the fix for me was adding sleep 3 in /usr/local/etc/rc.local.shutdown (to avoid interference with systemd info output)

Code: Select all

  stop)
	clear
	sleep 3
	/usr/local/bin/snap-ex </dev/console >/dev/console 2>&1

Apparently it doesn't work for you, perhaps experiment with increasing the sleep value a little (e.g. 5 edit: or decreasing perhaps ) just in case it's a timing issue, not sure about that.
Btw, just to mention, on v2.6 it worked ok for me just the same.

Another thing (may not be important) there's /usr/local/bin/snap-ex in 07KLA-OT2baseCE-2.7.sfs and in 10KLA-OT2basesettings.sfs . (the latter is the "fixed one")

[Sofiya]

@Sofiya After some experimenting I found that the fix for me was adding sleep 3 in /usr/local/etc/rc.local.shutdown (to avoid interference with systemd info output)

Code: Select all

  stop)
	clear
	sleep 3
	/usr/local/bin/snap-ex </dev/console >/dev/console 2>&1

Apparently it doesn't work for you, perhaps experiment with increasing the sleep value a little (e.g. 5 edit: or decreasing perhaps ) just in case it's a timing issue, not sure about that.
Btw, just to mention, on v2.6 it worked ok for me just the same.

Another thing (may not be important) there's /usr/local/bin/snap-ex in 07KLA-OT2baseCE-2.7.sfs and in 10KLA-OT2basesettings.sfs . (the latter is the "fixed one")

Thank you very much @fredx181
Increasing to sleep 5 fixed my issue
So with my build with the Arch core, everything is fine and I can publish it to everyone else
Or does it work badly with the new kernel and it is not necessary to publish it ???

Code: Select all

#! /bin/sh
# from FossaDog64

case "$1" in
  start)
# no-opt
	;;
  restart|reload|force-reload)
	echo "Error: argument '$1' not supported" >&2
	exit 3
	;;
  stop)
	clear
	sleep 5
	/usr/local/bin/snap-ex </dev/console >/dev/console 2>&1
        ;;
  *)
	echo "Usage: $0 start|stop" >&2
	exit 3
	;;
esac

[fredx181]

@Sofiya

Increasing to sleep 5 fixed my issue

Ok, nice !

So with my build with the Arch core, everything is fine and I can publish it to everyone else
Or does it work badly with the new kernel and it is not necessary to publish it ???

Don't know, in general with the new Arch kernel it works fine for me from quickly testing, but about the Save/NoSave isssue: did it work OK for you using sleep 3 with the kernel from 2.6 (Upup kernel) ?. If it was the same, I'd say that the new kernel makes no difference .
Perhaps there's a better fix than adding sleep <value>, don't know either, systemd config is difficult with these unorthodox things, I guess.

[Sofiya]

Don't know, did it work OK for you using sleep 3 with the kernel from 2.6 (Upup kernel) ?.

it was working fine until the update came

yes, it works the same way with both this and that kernel I'll post it, maybe someone will like the new kernel

[wiak]

Funnily enough I conveniently just used FRmake_initrd.sh

I had been trying to make a FR frugal install of Void Linux xfce upstream rootfs musl version, so downloaded the musl iso of that and extracted the inside rootfs (which was a .img file inside another .img file... sigh). Then I extracted the contents of that in uncompressed form into a folder named 07/.

My idea was to simply then open up FR skeleton initrd-latest and extract all the /usr/lib/modules and put a copy into the FR initrd before letting ./modify_initrd.sh compress it all up again... Pretty huge initrd.gz of course results, but that doesn't matter.

I also extracted Void's vmlinuz (not a huge-style kernel) from Void's iso.

Finally ran ./wd_grubconfig to get grub2 menu stanza and rebooted using the result. Hmmm... didn't boot. Was it cos musl I wondered - couldn't see any issue with that. But then I remembered: Void, like Arch and most distros now, compresses each individual of its modules using zst and busybox modprobe used in FR initrd can't handle that. But that made me recall that I had extended code in FRmake_initrd such that it would uncompress each module before inserting the boot-necessary ones into the skeleton FR initrd. Final result being an initrd.gz of around 20MB, and that booted fine (once I had used the mount_chroot trick to set root passwd...).

In fact I am posting from that FirstRib-driven musl-based Void Linux XFCE right now (logged in to root desktop).

But I didn't do this for fun. I purposively suddenly wanted that musl-based distro to make it easy for me to compile statically linked small musl-based binary to replace lost one.

[Sofiya]

@Sofiya

we changed the way in snap-ex
when researching it was found that the latest package update breaks our output to the console to select save / not save.which is really sad.

Perhaps I didn't follow enough from this thread, but I just checked on KLA-OT2baseCE-2.7 and Save/NoSave from console at shutdown works OK for me.

Here, probably, the idea was not accurately expressed, meaning the update of the Arch packages

[rockedge]

@wiak I ran several builds of KLV using PLUG similar to an Airedale type distro very successfully using the latest build scripts.

No problem auto creating /firstrib_rootfs when doing Void Linux builds. I did not have success with the PLUG split with an addon_f.plug and had to return the PLUG to a monolithic form.

The build was fast and produced a totally usable KLV distro.

[wiak]

I did not have success with the PLUG split with an addon_f.plug and had to return the PLUG to a monolithic form.

Just curious why you had problem with that. It is a simple way to automate what you would do manually anyway.

I hope you don't put addons_f.plug on the build_firstrib_rootfs.sh command line - that would be wrong. It isn't an argument to the build command. Instead it is simply used if the build_firstrib_rootfs.sh script sees it in the same directory as itself - it is simply sourced (. addons_f.plug) so all the commands you put in it are done as if you typed them. i.e. all build_firstrib_rootfs.sh script contains at the end (once chroot stuff is done) is the very simple check for existence (emptiness actually) of ./addons_f.plug, or did you accidentally call it addon_f.plug rather than addons_f.plug? The exact name is important The code involved at end of build_firstrib_rootfs.sh code is simply this:

Code: Select all

[code][ -s ./addons_f.plug ] && . ./addons_f.plug  
 
 # for downloading layer addons and FR utils (e.g. 12KL...sfs; 11rox...sfs, wd_grubconfig)

[/code]

[wiak]

I did not have success with the PLUG split with an addon_f.plug and had to return the PLUG to a monolithic form.

Did you accidentally call it addon_f.plug rather than addons_f.plug? The exact name is important The code involved at end of build_firstrib_rootfs.sh code is simply this:

Code: Select all

[ -s ./addons_f.plug ] && . ./addons_f.plug  
 
 # for downloading layer addons and FR utils (e.g. 12KL...sfs; 11rox...sfs, wd_grubconfig)

Just curious why you had problem with that. It is a simple way to automate what you would do manually anyway.

It is simply used if the build_firstrib_rootfs.sh script sees it in the same directory as itself - it is simply sourced (. ./addons_f.plug), where the two dots at the front have space between them and thus first dot means 'source' in bash, so all the commands you put in it are done as if you typed them.

[rockedge]

or did you accidentally call it addon_f.plug rather than addons_f.plug? The exact name is important

Yes, exactly. My mistake....file name was incorrect

Go for another try with these and then I'll try to put together a PLUG for a minimal KLV build. Again I have the PLUG's spread out all over the place and need to do some house cleaning.

[rockedge]

This PLUG will with the build script will create a OS that boots to console, xbps package manager, midnight commander (mc), Networkmanager (nmtui for command line network connecting) and pulseaudio. There are 3 users configured: root, spot, weedog with passwords matching the name. spot and weedog have sudo powers.

I have test run this several times building a firstrib_rootfs which I squashed using PackIt and zstd compression. Then in a frugal install of KLV-Airedale or KLV-Spectr simply replace the 07KLV-airedale_rootfs.sfs with the newly created 07XXX_rootfs.sfs or leave it as an uncompressed directory with a 2 digit prefix like for example: 07firstrib_rootfs

f_00_Void_KLV_no-kernel_noX_FR-team-minimal.plug

Code: Select all

# f_00_Void_KLV_no-kernel_noX_FR-team-minimal.plug
# version="3.2.0"; revision="-rc7"
# Kennel Linux Void outfitted with no X server and no kernel **uses Puppy Linux kernel**
# Creation date 24Sep2021; Revision date: 14Aug2023
# Copyright Kennel Linux team; Licence MIT

# build this via terminal commands:build_firstrib_rootfs.sh
# export CONNECTION_TIMEOUT=-1  **not needed with versions greater than v501**
# ./build_firstrib_rootfs.sh void default amd64 f_00_Void_KLV_no-kernel_noX_FR-team-minimal.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, Desktop configuration

#xbps-install -y gvfs-smb gvfs-mtp gvfs-cdda

# Optional packages
#
xbps-install -y dosfstools squashfs-tools wget

# Browser selection

# 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
#xbps-install -y NetworkManager
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

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

## 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/Downloads


# 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


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

# Clean Up
#

rm /var/cache/xbps/*
# rm /var/cache/fontconfig/*

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

The versions of firstrib_rootfs.sfs I completed when squashed moderately (level 9) with zstd the resulting SFS is 197 M

Once booted in just several minutes using the XBPS package manager install Xorg and JWM, or Gnome, XFCE4 or which ever desktop that is available in the Void Linux repos.

[rockedge]

Example of a QEMU run of a distro put together from the results of a build using f_00_Void_KLV_no-kernel_noX_FR-team-minimal.plug

Using xbps-install -y xorg jwm rox to install a desktop and with a copy to and modification of /root/.xinitrc to include the statements to start JWM and Rox with a pinboard after login and startx in a terminal. Other than that modification it is all at default configurations ->

note: running in 125 M of RAM as reported by htop

Screenshot(13).jpg (40.9 KiB) Viewed 1412 times

[rockedge]

Ran a minimal build then added a Gnome desktop and added the modifications for /root/.xinitrc and /home/spot/.xinitrc to start gnome-session with startx to try it out and see how involved it is. Gnome was up and running fairly quickly. I find using it bulky and slow. The machine's fans are running at medium speeds which is not a good sign of efficiency and being light on resources.

Screenshot(14).jpg (32.18 KiB) Viewed 1405 times

Screenshot(16).jpg (16.26 KiB) Viewed 1404 times

[wiak]

Ran a minimal build then added a Gnome desktop and added the modifications for /root/.xinitrc and /home/spot/.xinitrc to start gnome-session with startx to try it out and see how involved it is. Gnome was up and running fairly quickly. I find using it bulky and slow. The machine's fans are running at medium speeds which is not a good sign of efficiency and being light on resources.

Yes, I don't understand why Ubuntu and so on focus on GNOME. Well, I suppost upstream GNOME have made it easy for them to adopt Wayland, and that is one good thing about occasionally using GNOME: you can experiment more easily in a sophisticated wayland-based environment. However, I actually don't like the GUI/interface GNOME provides; maybe I'm old fashioned about that, but XFCE just works efficiently enough on all my machines and has an interface I'm very comfortable with. Yes, a bit like old Windows interface, but maybe that is one thing Windows got a bit right? Sometimes, change of user-interface, simply for changes sake, is not it seems to me a good thing actually. Fashions come, fashions go.

[rockedge]

Totally agree. Just used Gnome for an hour and turned it off. XFCE4 is far better for me. Even JWM + Rox is more fun to use because it's really light and fast. I am just using it with minor minor customization. I just connected with FTP using midnight commander to he host and grabbed the inst-xbps script package along with the time update and run-as-user scripts package. It all works and made setting up a usable system in a really short amount of time and effort.

It's primitive but at 127 M of RAM and 0% CPU at idle can't beat it for compact. Really the sky is the limit having the xbps package manager from the onset.

The XFCE4 desktop version is far more complete and customization from the start is comprehensive.

There are very few limits as to what direction to go in with it. Great thing is I can make a distro like this very quickly so scrapping it and starting a fresh one is the way I do it to try thing out. With a little skill all of it can be done at build via PLUG.

The tiling WM Spectrwm in KLV is really efficent and once one gets used to working on a tiling window manager it's hard to return to the "heavier" stacking WM. For no frills real work production the KLV-Spectr type is worth looking into.

So far all experimental and not really following a path or road....just what seems cool to try at the moment and see what it all can do.

Installed xLuncher-1.0.0.xbps package which worked OOTB and I am not looking for any comlicated JWM menu and rely on xLuncher to make the menu. It is cool to be able to try out all sorts of things and wipe the slate clean and try something slightly or a lot different each following each new firstrib_rootfs version!

[Sofiya]

Honestly, thanks to firstrib_rootfs, we have reached a new level with unlimited possibilities, and with a little imagination and effort, you can get an amazing system to your liking and needs.

[wiak]

@rockedge
@Sofiya
and other firstrib/KL builders

I'm having a bit of a problem (though I know what the issue is and the fix) with very latest build_firstrib_rootfs.sh so fedora builds not working with it (maybe nothing else either...). It is yet another problem to do with resolv.conf nowadays most often being a symlink to /run... Issue therefore is that older simple cp code wouldn't overwrite it as required. Actually handling needs to be different depending if symlink or actual files in both host and in part-built firstrib_rootfs. Not just a matter of using option -L for follow symlinks, but involving that.

I'm testing fedora builds with my 'fix' right now, but don't expect much build success with current gitlab build script. Trouble is different distros had/have different scenarios regarding this so i fixed one and broke the other last night! Will report when all seems fixed again... I was hoping I was finished for now, but there is no such thing...

EDIT: Fedora Rawhide currently building - going fine with my new code here. Will have to try it thereafter with Void, Arch and Debian builds to double-check all will work with same code. I think they will...

[Sofiya]

@rockedge
@Sofiya
and other firstrib/KL builders

I'm having a bit of a problem (though I know what the issue is and the fix) with very latest build_firstrib_rootfs.sh so fedora builds not working with it (maybe nothing else either...). It is yet another problem to do with resolv.conf nowadays most often being a symlink to /run... Issue therefore is that older simple cp code wouldn't overwrite it as required. Actually handling needs to be different depending if symlink or actual files in both host and in part-built firstrib_rootfs. Not just a matter of using option -L for follow symlinks, but involving that.

resolv.conf is a symbolic link to /run/systemd/resolve/stub-resolv.conf by default.
and if you just stop it at the time of assembly ?

sudo systemctl stop systemd-resolved
sudo systemctl disable systemd-resolved

what if use dnsmasq for resolv.conf ?

[rockedge]

I see the resolv.conf error also though it has not seemed to have caused too much of a problem as far as I can tell so far.
In my builds the error mentions a resolv.confORIG that can't be found

[williwaw]

I tried a few builds, as posted in the KLV-Airedale-RT with full Real Time Kernel 6.1.38-rt13 thread,
and a few builds. as posted in the Build KLV mini; single script thread.

I can see the benefits of having your own plug file to build with, and have no need to try to over simplify the build process with too many scripts when I think using ./build_firstrib_rootfs.sh void default amd64 f_00_Void_KLV_XFCE_no-kernel_FRteam-minimal.plug notation will do just fine.

except that the f_00_Void_KLV_XFCE_no-kernel_FRteam-minimal.plug in the command above builds a 639Mb firstrib-rootfs vs. a 260Mb firstrib-rootfs built with the plug called in the more minimal Build KLV mini; single script method.

./build_firstrib_rootfs.sh void default amd64

is correct, but you maybe need a minimum f_ plug file as argument too if result is to contain enough packages to boot.............

Well, needs FR initrd.gz, huge kernel, 00modules sfs, 01firmware sfs, vmlinuz to boot resulting firstrib_rootfs renamed to 07firstrib_rootfs of course.

@rockedge or @wiak
if one wishes to pull in FR initrd.gz, huge kernel, 00modules sfs, 01firmware sfs, vmlinuz , and other neccesary components, can this be specified in the plugfile?

I realize I could probably just download the latest KLA iso and swap out the 07firstrib-rootfs with the one from my minimal build, but what is the typical non-KLV mini; single script method for putting the necessary files and components together?

[wiak]

@rockedge or @wiak
if one wishes to pull in FR initrd.gz, huge kernel, 00modules sfs, 01firmware sfs, vmlinuz , and other neccesary components, can this be specified in the plugfile?

No, not in the f_00 plug file. That wouldn't work. The f_00 plug file is used in a chroot into the partially build firstrib_rootfs so it can't see the 'outside world' (host filesystem) while f_00 plug commands are running. If you want to download these components you either just do so on the host using wget to gitlab firstrib, or you put the download (wget) commands inside an addons_f.plug just prior to doing the build. As I've said, the addons_f.plug is also executed (sourced actually) by build_firstrib_rootfs.sh but only after all the chroot (f_00plug) stuff has finished and therefore back seeing the host filesystem by that time.

The KLVmini script is an illustration of an alternative way of doing the same as you ask - downloading stuff when not in the chroot. I didn't write that specially for anyone, but as an example to everyone of that other way (instead of, or can be in addition to, addons_f.plug) of doing exactly what you ask in terms of pull in these components.

[wiak]

I tried a few builds, as posted in the KLV-Airedale-RT with full Real Time Kernel 6.1.38-rt13 thread,
and a few builds. as posted in the Build KLV mini; single script thread.

But did some or all of your builds work? That's what I need to know at the moment since I'm trying to fix an issue I had in the most recently altered build_firstrib_rootfs.sh script. Was fine in the past, but recent fedora-related build required some changes that resulted in some bugs when building other distro variants that I am trying to sort out.

As I said to rockedge, it is really important, if feedback is to be useful and not ambiguous, that you always use most recent build scripts and when issue does arise tell me version and revision number of the scripts used and Revision date. Some simpler scripts just have revision date. I can't otherwise sort out what is going on when issue arises.

[wiak]

I see the resolv.conf error also though it has not seemed to have caused too much of a problem as far as I can tell so far.
In my builds the error mentions a resolv.confORIG that can't be found

That much almost certainly means you are using an old revision of the build_firstrib_rootfs.sh script. You have to understand I am trying to fix an issue right now so updating frequently and you must use the latest or you can expect fails for sure. Current version (published yesterday) is 8.0.0 rc5 and contains line:

Code: Select all

[ -e firstrib_rootfs/etc/resolv.confORIG ] && mv firstrib_rootfs/etc/resolv.confORIG firstrib_rootfs/etc/resolv.conf  # put back resolv.conf to its original form

My understanding would be if /etc/resolv.confORIG doesn't exist no error message should be mentioned and if it does exist no error message should occur either - it should just get renamed.
Older versions of script, from day or two ago didn't check for existence so error message often occurred.

[wiak]

resolv.conf is a symbolic link to /run/systemd/resolve/stub-resolv.conf by default.
and if you just stop it at the time of assembly ?

sudo systemctl stop systemd-resolved
sudo systemctl disable systemd-resolved

what if use dnsmasq for resolv.conf ?

Exactly. And not all hosts are using systemd at all so this situation depends on build system too and methods being used by that. As I mentioned to rockedge it is very important if starting a new build to always download the very latest build_firstrib_rootfs.sh (and also mount_chroot.sh if using that at all) from gitlab firstrib. I am changing the script every day to sort out issues relating to matters like this. If anyone ever uses an old version of the build_firstrib_rootfs.sh script they are on their own! Current version uploaded last night is 8.0.0 rc5 and also best to quote that and also Revision date of script any time issues arise or I can't fix.

[wiak]

I see the resolv.conf error also though it has not seemed to have caused too much of a problem as far as I can tell so far.
In my builds the error mentions a resolv.confORIG that can't be found

That much almost certainly means you are using an old revision of the build_firstrib_rootfs.sh script. You have to understand I am trying to fix an issue right now so updating frequently and you must use the latest or you can expect fails for sure. Current version (published yesterday) is 8.0.0 rc5 and contains line:

Code: Select all

[ -e firstrib_rootfs/etc/resolv.confORIG ] && mv firstrib_rootfs/etc/resolv.confORIG firstrib_rootfs/etc/resolv.conf  # put back resolv.conf to its original form

My understanding would be if /etc/resolv.confORIG doesn't exist no error message should be mentioned and if it does exist no error message should occur either - it should just get renamed.
Older versions of script, from day or two ago didn't check for existence so error message often occurred.

That above code line still isn't correct (maybe...) I noticed (needs -L to handle symbolic link case of fedora fdstrap.sh build), so another revision is required to build_firstrib_rootfs.sh. Unfortunately I can't do it today or at least not just now to I deal with other (non-computing) stuff I have been putting aside. build_firstrib_rootfs.sh version 8.0.0 rc6 revision date 17Aug2023 just uploaded to gitlab firstrib as well as associated umount_chroot.sh script version="3.0.1"; revision="-rc4" same revision date. That's all I can do for the moment... maybe even a few days. Expect issues - did some big developments to several scripts recently so will take time for this to settle down. Be patient please and do some manual fixes to resulting builds if building right now and issues arise. Will fix later for sure.

[rockedge]

@wiak All of my reports today are results from build runs using:

Code: Select all

build_firstrib_rootfs.sh
version="8.0.0"; revision="-rc5"

As I mentioned early today I git pulled the latest from GitHub and have been running builds today using what ever the very latest commits have been.

I have not seen the resolver.confORIG problem at all today. I mentioned that I did see it before. Both builds I ran in the last hour both have still had pieces mounted but once umounted the file systems works fine. These 2 runs have been Fedora and now I am doing a KL Void minimal to start a fresh experimental platform.

Unless indicated I am using the very latest version of the build script which is version="8.0.0"; revision="-rc5" at this moment.