Build KL_Fedora Rawhide XFCE (or GNOME-Wayland)

[rockedge]

@Sofiya downloading it now.....getting ready for a QEMU launch........

[rockedge]

Quickly put together KLF logo

[rockedge]

Started smoothly! And only thing is the updater notification does not change back to no updates.
Using right now to take screenshots, size them with mtpaint and open the forum with Chromium.......

Screenshot_2023-08-13_22-06-09.jpg (8.6 KiB) Viewed 1509 times

[wiak]

Added UExtract desktop into the 12KL at /usr/local/share/applications; haven't tested

(In first post attached addons_f.plug) Took off the D in front of poorercputemp when downloaded and added sudo to its /etc/xdg/autostart desktop

[wiak]

extract from fdstrap.sh, where $rootfs will contain firstrib_rootfs pathname all going well (since $1 is firstrib_rootfs). @rockedge, do you have realpath and mktemp commands on your build system?

Code: Select all

rootfs=$(realpath "$1")
...
tmp=$(mktemp -d)
mkdir -p "$rootfs" "$tmp/rootfs"
...
mv "$tmp"/rootfs/fedora/* "$rootfs"

If continues not to mkdir firstrib_rootfs automatically, and you have realpath and mktemp commands on your system, you should insert a few echo debug commands (e.g. echo $rootfs) into the fdstrap.sh script that was auto-downloaded and run build_firstrib_rootfs commandline again to work out why firstrib_rootfs is not being auto-created. Without that working, you are probably not building in /tmp either and quite a few parts of fdstrap.sh won't be working as intended by its author then and you may have to resort to the manual hacks, which is not ideal of course.

@rockedge did you check your host system that you are building on has realpath command and mktemp command on it? I am currently building KLF on Linux Minut, but shouldn't matter. You shouldn't need to create firstrib_rootfs empty directory manually or have failed first run.

Good if you put some echo debug statements in your fdstrap.sh to see where it is loosing track of where it stores things (it is a tricky little script to understand but does create a temporary Fedora build directory in /tmp and only at end it moves the contents of its rootfs/fedora directory made there into actual bootfrom directory firstrib_rootfs. That command rootfs=$(realpath "$1") should be finding the actual location of bootfrom dir $1 (where $1 refers to firstrib_rootfs directory which is made thereafter by mkdir -p "$rootfs". The name 'rootfs' is also used but not as a variable for the temporary build directory that was assigned by mktemp -d command in fdstrap.sh per above extract.

[Sofiya]

Started smoothly! And only thing is the updater notification does not change back to no updates.
Using right now to take screenshots, size them with mtpaint and open the forum with Chromium.......

Screenshot_2023-08-13_22-06-09.jpg

YOU also have or only I have in the assembly?
With what it can be connected

[wiak]

I'm sure you know this is one way to get filemnt to auto-open iso files or sfs files you just need to right-click in Thunar and select Open With Default Applications the appropriate filemnt variant (CD, SFS) shown in the drop down list in there, making sure the one used is set as default from then on. Thereafter it should just work.

EDIT:
You can also use Options in Rox to set the terminal it uses to say xfce4-terminal if you want.

I haven't installed missing deps for wex or Precord in my base build (e.g. ffmpeg [ffmpeg-free], urxvt-unicode or xterm or similar, giblib) so haven't tested their correct operation. lame is a dependency of Precord.

EDIT2. wex not working for me - can't find audio device 'pulse'; and that's just for a start... Not essential... works for me in Zorin lite so may be possible to fix. I expect Fedora using pipewire and don't know anything about that; once I do I'll try fix wex (maybe not).
EDIT3: that ffmpeg-free from Fedora Rawhide repo looks like doesn't include X11grab - that's not too surprising since everything moving to Wayland... I suspect wex not going to survive long... plenty alternatives to install.

[rockedge]

@wiak further diagnosis is showing that on line 715 in build_firstrib_rootfs8.sh when ./fdstrap.sh firstrib_rootfs is called to execute it is failing.
The $1 token is not populated for some reason so in the fdstrap.sh rootfs=$(realpath "$1") statement the $1 argument is empty. So the following statements cause errors and the script goes to the end. No idea why this is happening.

build_firstrib_rootfs8.sh

Code: Select all

wget -c https://gitlab.com/tearch-linux/applications-and-tools/fdstrap/-/raw/main/fdstrap.sh && chmod +x fdstrap.sh
./fdstrap.sh firstrib_rootfs
cd firstrib_rootfs
mkdir -p etc/udhcpc # needed to receive udhcpc default.script

@Sofiya Do you mean merge the 2 different build PLUG's? I don't understand the message completely

[wiak]

@wiak further diagnosis is showing that on line 715 in build_firstrib_rootfs8.sh when ./fdstrap.sh firstrib_rootfs is called to execute it is failing.
The $1 token is not populated for some reason so in the fdstrap.sh rootfs=$(realpath "$1") statement the $1 argument is empty. So the following statements cause errors and the script goes to the end. No idea why this is happening.

build_firstrib_rootfs8.sh

Code: Select all

wget -c https://gitlab.com/tearch-linux/applications-and-tools/fdstrap/-/raw/main/fdstrap.sh && chmod +x fdstrap.sh
./fdstrap.sh firstrib_rootfs
cd firstrib_rootfs
mkdir -p etc/udhcpc # needed to receive udhcpc default.script

Sorry, accidentally edited your post. Ooops....

That's weird what you say; I don't have any such problem. Why would fdstrap.sh not be found (well I mean the argument 1 parameter passed to it) if it is there? Anyone else having that problem (Sofiya?)??

By the way Precord actually works once I install lame and alsa-plugins-pulseaudio (and optionally for other than mp3 encoding: ffmpeg-free). I could likely therefore make wex work too (but would need alien libgiblib put into /lib64; probably not worth it since X screencasts will not work once we using Wayland anyway; also need non-free codecs installed, but wex would work with libgiblib stolen from other distro).

[wiak]

I just noticed you seem not to be using most current build_firstrib_rootfs.sh rockedge. I don't fetch fdstrap.sh from tearch anymore (that is commented out). I had to modify it slightly so newer build_firstrib_rootfs.sh should be fetching from firstrib repo. Not sure if connected with your issue tho.

I can't make any logical sense out of $1 being empty for you... tricky one....

[Sofiya]

@Sofiya Do you mean merge the 2 different build PLUG's? I don't understand the message completely

I mean, and you have the same - the update notice doesn't change back to no updates. in your build.

[rockedge]

@wiak Totally strange actually....I hard-coded the rootfs="/mnt/sdc3/KLF-a_builder/firstrib_rootfs" and it worked like clockwork.

I am using version="8.0.0"; revision="-rc1"

@Sofiya I noticed that also, but suddenly it changed back when clicked something but I couldn't always repeat it.

[Sofiya]

I have " firstrib_rootfs " created automatically
i use this

[rockedge]

Maybe it's this F96-CE_4 that's playing a role in this. If I just create the firstrib_rootfs manually before starting the the build script then it all works smoothly. Or if I hard-code the path in the script it works perfectly. the realpath statement is receiving an empty token

@Sofiya that's the same one I am using.....

[Sofiya]

Maybe it's this F96-CE_4 that's playing a role in this. If I just create the firstrib_rootfs manually before starting the the build script then it all works smoothly. Or if I hard-code the path in the script it works perfectly. the realpath statement is receiving an empty token

@Sofiya that's the same one I am using.....

I collect in KLA-OT2

[rockedge]

I just ran a build after manually creating the firstrib_rootfs directory which finished successfully in 8 minutes.

Now practicing making the initrd.gz and extracting the 6.5.0 kernel. So the estimated time for making distro that is frugally installed without compressing anything and an existing boot loader would be under 15 minutes to be up and running.

@wiak Because of the fast build speeds I was able to make around 20-25 distro's today. I am also going to use the new functionality of the addon_f00.plug in a redesign of the KLV-Airedale and KLV-Spectr PLUG files. Moving most of the finishing customization to an addon_f00.plug to compliment the KLV PLUG.

It's going to be really cool.

On some of those distros I installed CUPS and was able to get it up and running in a fairly straightforward manner.........

[Sofiya]

@Wiak
Yes, I keep forgetting to ask, we need " w_init " for KLF-Rawhide ?

[wiak]

@Wiak
Yes, I keep forgetting to ask, we need " w_init " for KLF-Rawhide ?

No. The FR skeleton initrd.gz contains default w_init already and that is used if no external one is in the boot directory. Usually the external one is exactly the same as the internal-to-initrd one; it does get used instead of the internal one though if it is availabe and thus good for experimenters who want to hack how the initrd operates since most of the main first init code is infact in w_init.

You could actually also use the w_init from KL_full2fr since that is a special one (not well-tested however) that adds tons of extra potential layers below 00modules layer. The lower than 00modules addons are also to be numbered within the range 01 to 99 and are kept in a subdir of the bootfrom directory (simply named with the underscore character). I'm sure that would work as a special external w_init with KLF-Rawhide too, but the normal default w_init we use in the likes of KL OT2 is what is inside FR initrd so could be used too, but not required.

[wiak]

Maybe it's this F96-CE_4 that's playing a role in this. If I just create the firstrib_rootfs manually before starting the the build script then it all works smoothly. Or if I hard-code the path in the script it works perfectly. the realpath statement is receiving an empty token

@Sofiya that's the same one I am using.....

Definitely something weird with your system. Calling a script with an argument firstrib_rootfs of course results in firstrib_rootfs being put into variable 1. Try with a simple test script - really sounds like something fishy happening in F96-CE that you should investigate since that is so fundamental. Whilst fdstrap.sh is a pretty complex-in-operation little script that use of $1 happens very early on... "firstrib_rootfs" should be there... and certainly is on my system (Linux Mint) host and clearly fine on Sofiya host distro too. What build host distro are you using Sofiya?

[wiak]

Here is what I suspect. The fdstrap.sh code near top includes:

Code: Select all

shift
while getopts -- ':v:' OPTION; do
    case $OPTION in
    v)
      version="${OPTARG[@]}"
      ;;
    *)
      echo "usage: fdstarp (rootfs) [options]"
      echo "    -v : use custom version (default: rawhide)"
      exit 1
    esac
done

I'm wondering if your F96-CE is not doing that correctly? Maybe some busybox command version of something that needs full version? I'm suspecting getopts, but I don't even know if busybox includes that - could you put an echo debug statement into that loop to see if it is working okay and not hanging and not messing up somehow? Or maybe it is a busybox realpath or something - I don't know if that would mess with the code logic, but it's the only thing I can think of that might be different/relevant in a Puppy distro. The reason I suspect this is actually the 'shift' which will shift the first argument such that you are ending up with "" instead of "firstrib_rootfs".

SOLVED I think... See my post here: viewtopic.php?p=96377#p96377

Also, try a simple:

echo HERE "$1"

just before rootfs=$(realpath "$1")

to see if 1 originally passed correctly as "firstrib_rootfs". Then the issue on your host system must surely be something to do with that 'shift' and so on.

Also you should put a debug statement: echo rootfs is "$rootfs" just before line: mkdir -p "$rootfs" "$tmp/rootfs"

[Sofiya]

Maybe it's this F96-CE_4 that's playing a role in this. If I just create the firstrib_rootfs manually before starting the the build script then it all works smoothly. Or if I hard-code the path in the script it works perfectly. the realpath statement is receiving an empty token

@Sofiya that's the same one I am using.....

Definitely something weird with your system. Calling a script with an argument firstrib_rootfs of course results in firstrib_rootfs being put into variable 1. Try with a simple test script - really sounds like something fishy happening in F96-CE that you should investigate since that is so fundamental. Whilst fdstrap.sh is a pretty complex-in-operation little script that use of $1 happens very early on... "firstrib_rootfs" should be there... and certainly is on my system (Linux Mint) host and clearly fine on Sofiya host distro too. What build host distro are you using Sofiya?

What build host distro are you using Sofiya?

KLA-OT2

[Sofiya]

for KLF-Rawhide with blue color

Code: Select all

[ "$PS1" = "\\s-\\v\\\$ " ] && PS1="\[\e[0;34m\]┌──\[\e[0m\][ \[\e[0;33m\]\u\[\e[0m\]\[\e[0;32m\]@\[\e[0;34m\]\h\[\e[0m\] ] [ \[\e[0;34m\]\t\[\e[0m\] ]\n\[\e[0;34m\]├── \[\e[0;32m\]\w\[\e[0;34m\]\n\[\e[0;34m\]└>\[\e[0m\] "

[wiak]

Ah... still weird, but I 'think' it is the realpath on your F96-CE isn't getting the full path and maybe just resulting in $rootfs is "firstrib_rootfs" rather than full path to "firstrib_rootfs". A bit of a guess, but that would blow things... Again, I'm suspecting busybox version causing the issue - use full version...

EDIT: Having said that, the busybox realpath should surely be enough. I'm confused...

[wiak]

Yeah, it is because F96-CE is using busybox realpath. Here is simpler script that is modded to use busybox realpath. If you run it with that, the output is:

Code: Select all

# ./test.sh firstrib_rootfs
HERE EARLY dollar one is firstrib_rootfs
realpath: firstrib_rootfs: No such file or directory

which is WRONG

If instead, I remove the busybox reference and use a full realpath, the output is:

Code: Select all

# ./test.sh firstrib_rootfs
HERE EARLY dollar one is firstrib_rootfs
NOW dollar one is
rootfs is /media/mcewanw/archive/FR_debby/firstrib_rootfs

which is CORRECT (correctly what to expect after the shift command).

The full realpath doesn't need the item to already exist, the busybox realpath does...
So, moral is: be careful using Puppy as a host for build systems cos of busybox limitations. Not usually an issue but, truth be told, can be, and is likely to be a recurring problem with other types of mainline app install scripts sometimes.
So yes, if using Puppy as host build system, one simple solution is to first mkdir -p firstrib_rootfs before doing the rest. The other option is to put a full realpath in the distro (it is a small binary) or modify fdstrap.sh to always mkdir initial firstrib_rootfs (as you did, rockedge), but that's a bad idea more generally since I rely on upstream fdstrap development.
I've added a note to that effect at top of first post. Let me know if any other issues when using Puppy as build host please. If you had used KLV-Airedale for the build I am sure there would be no such issues though.

Code: Select all

#!/bin/bash
set -e
echo HERE EARLY dollar one is $1
rootfs=$(busybox realpath "$1")  # modded to use busybox realpath HERE - wiak
version="rawhide"
shift
while getopts -- ':v:' OPTION; do
    case $OPTION in
    v)
      version="${OPTARG[@]}"
      ;;
    *)
      echo "usage: fdstarp (rootfs) [options]"
      echo "    -v : use custom version (default: rawhide)"
      exit 1
    esac
done
echo NOW dollar one is $1
echo rootfs is $rootfs
exit

[rockedge]

@wiak Both KLV OS's are running the scripts as expected. So when using Puppy Linux (F96-CE) easiest and cleanest method is just manually create the firstrib_rootfs directory before running the build script. Once in place the build runs like clockwork. It seems that changing the script by hard-coding the path doesn't work as well and that method should not be used. Because the path to firstrib_rootfs is dynamic and changes depending on where the build occurs. Best way is the manual directory creation before building. Otherwise building using F96-CE_4 is working well.

Or use KLV or KLA to make a KLF!

[Sofiya]

Test ISO KLF-a.iso ends up at 1228 M with all SFS components using gzip or zstd compression, and now for the "does it boot?" test......

Looks good so far.......

Screenshot(8).jpg

And just after login and some small simple appearance customizations. This is booting like lightning fast!
Screenshot(9).jpg

Total time from initial building to boot-able ISO was under 30 minutes including extracting a brand new fresh kernel.

If interested in examining how to make a boot-able ISO and or testing a running KLF Rawhide ->
using zstd compression: KLF-a.iso 1.20 G
using xz compression: KLF-axz.iso 1.07 G

@rockedge Hi
Today I think let me try with a new kernel your image, I download it, I install it, but I can’t boot.
loading reaches half and that's all

[rockedge]

@Sofiya I'll check to see if it will start on QEMU

[Sofiya]

Tested with Linux Kernel 6.4.7 arch1-1 flight normal

[rockedge]

Getting ready to get back to a FR-Fedora build after using a git pull on the FR_build GitHub repo to get the latest versions of the build script and the rest of the utilities to put together a KLF system. Using the basic default Fedora plug and addons_f.plug (includes kernel version).

Created a directory /mnt/home/KLF-C_components with the files to start the build process. Note I am using Puppy Linux F96-CE_4 to run the build and to ensure a smooth operation, created the firstrib_rootfs manually before starting and created a symlink to the build script named bfr.

Screenshot(22).jpg (20.16 KiB) Viewed 1155 times

Starting the build by open a terminal in the KLF-C_components directory and using the command to start the script and produce a log file:

Code: Select all

./bfr fedora default amd64 f_00_fedora_gui.plug 2>&1 | tee build.log

After the build script completes this is the result using addons_f.plug_includes_kernel.tar:

Screenshot(23).jpg (41.01 KiB) Viewed 1151 times

This build used addons_f.plug_no_kernel.tar:

Screenshot(26).jpg (37.48 KiB) Viewed 1142 times

Errors encountered but do not seem to effect the build run outcome ->

Code: Select all

Failed to set locale, defaulting to C.UTF-8
Fedora rawhide openh264 (From Cisco) - x86_64    56 kB/s | 115 kB     00:02    
Errors during downloading metadata for repository 'fedora-cisco-openh264':
  - Status code: 404 for https://mirrors.fedoraproject.org/metalink?repo=fedora-cisco-openh264-rawhide&arch=x86_64 (IP: 140.211.169.196)
  - Status code: 404 for https://mirrors.fedoraproject.org/metalink?repo=fedora-cisco-openh264-rawhide&arch=x86_64 (IP: 8.43.85.73)
Error: Failed to download metadata for repo 'fedora-cisco-openh264': Cannot prepare internal mirrorlist: Status code: 404 for https://mirrors.fedoraproject.org/metalink?repo=fedora-cisco-openh264-rawhide&arch=x86_64 (IP: 8.43.85.73)
Fedora - Rawhide - Developmental packages for t 7.9 MB/s |  73 MB     00:09    
Ignoring repositories: fedora-cisco-openh264
Last metadata expiration check: 0:00:25 ago on Wed Aug 16 17:13:47 2023.
Dependencies resolved.

this error showed up 4 times but also did not seem to effect the successful build outcome

Code: Select all

  Installing       : dnf-4.16.2-2.fc39.noarch                           215/225 
  Running scriptlet: dnf-4.16.2-2.fc39.noarch                           215/225 
⚠️ /proc/ is not mounted. This is not a supported mode of operation. Please fix
your invocation environment to mount /proc/ and /sys/ properly. Proceeding anyway.
Your mileage may vary.

[rockedge]

@wiak after the 07firstrib_rootfs was finished there were still mounted directories contained in it so a squash was not possible.

To fix that I used the mount tool to chroot 07firstrib_rootfs, then exited and did the umount script. That had it ready to squash and work with.