Build KL_Fedora Rawhide XFCE (or GNOME-Wayland)

[Sofiya]

After thinking, I decide to do in "Sudoers" "NOPASSWD:" only for the program " poorercputemp " it seems to work as it should be
add sudo to /etc/xdg/autostart/poorercputemp.desktop

Code: Select all

[Desktop Entry]
Encoding=UTF-8
Type=Application
NoDisplay=true
Name=poorercputemp
Exec=sudo poorercputemp

/etc/sudoers

Code: Select all

## Sudoers allows particular users to run various commands as
## the root user, without needing the root password.
##
## Examples are provided at the bottom of the file for collections
## of related commands, which can then be delegated out to particular
## users or groups.
## 
## This file must be edited with the 'visudo' command.

## Host Aliases
## Groups of machines. You may prefer to use hostnames (perhaps using 
## wildcards for entire domains) or IP addresses instead.
# Host_Alias     FILESERVERS = fs1, fs2
# Host_Alias     MAILSERVERS = smtp, smtp2

## User Aliases
## These aren't often necessary, as you can use regular groups
## (ie, from files, LDAP, NIS, etc) in this file - just use %groupname 
## rather than USERALIAS
# User_Alias ADMINS = jsmith, mikem


## Command Aliases
## These are groups of related commands...

## Networking
# Cmnd_Alias NETWORKING = /sbin/route, /sbin/ifconfig, /bin/ping, /sbin/dhclient, /usr/bin/net, /sbin/iptables, /usr/bin/rfcomm, /usr/bin/wvdial, /sbin/iwconfig, /sbin/mii-tool

## Installation and management of software
# Cmnd_Alias SOFTWARE = /bin/rpm, /usr/bin/up2date, /usr/bin/yum

## Services
# Cmnd_Alias SERVICES = /sbin/service, /sbin/chkconfig, /usr/bin/systemctl start, /usr/bin/systemctl stop, /usr/bin/systemctl reload, /usr/bin/systemctl restart, /usr/bin/systemctl status, /usr/bin/systemctl enable, /usr/bin/systemctl disable

## Updating the locate database
# Cmnd_Alias LOCATE = /usr/bin/updatedb

## Storage
# Cmnd_Alias STORAGE = /sbin/fdisk, /sbin/sfdisk, /sbin/parted, /sbin/partprobe, /bin/mount, /bin/umount

## Delegating permissions
# Cmnd_Alias DELEGATING = /usr/sbin/visudo, /bin/chown, /bin/chmod, /bin/chgrp 

## Processes
# Cmnd_Alias PROCESSES = /bin/nice, /bin/kill, /usr/bin/kill, /usr/bin/killall

## Drivers
# Cmnd_Alias DRIVERS = /sbin/modprobe

# Defaults specification

#
# Refuse to run if unable to disable echo on the tty.
#
Defaults   !visiblepw

#
# Preserving HOME has security implications since many programs
# use it when searching for configuration files. Note that HOME
# is already set when the the env_reset option is enabled, so
# this option is only effective for configurations where either
# env_reset is disabled or HOME is present in the env_keep list.
#
Defaults    always_set_home
Defaults    match_group_by_gid

# Prior to version 1.8.15, groups listed in sudoers that were not
# found in the system group database were passed to the group
# plugin, if any. Starting with 1.8.15, only groups of the form
# %:group are resolved via the group plugin by default.
# We enable always_query_group_plugin to restore old behavior.
# Disable this option for new behavior.
Defaults    always_query_group_plugin

Defaults    env_reset
Defaults    env_keep =  "COLORS DISPLAY HOSTNAME HISTSIZE KDEDIR LS_COLORS"
Defaults    env_keep += "MAIL QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE"
Defaults    env_keep += "LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES"
Defaults    env_keep += "LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE"
Defaults    env_keep += "LC_TIME LC_ALL LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY"

#
# Adding HOME to env_keep may enable a user to run unrestricted
# commands via sudo.
#
# Defaults   env_keep += "HOME"

Defaults    secure_path = /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/var/lib/snapd/snap/bin

## Next comes the main part: which users can run what software on 
## which machines (the sudoers file can be shared between multiple
## systems).
## Syntax:
##
## 	user	MACHINE=COMMANDS
##
## The COMMANDS section may have other options added to it.
##
## Allow root to run any commands anywhere 
root   ALL=(ALL) 	ALL

## Allows members of the 'sys' group to run networking, software, 
## service management apps and more.
# %sys ALL = NETWORKING, SOFTWARE, SERVICES, STORAGE, DELEGATING, PROCESSES, LOCATE, DRIVERS

## Allows people in group wheel to run all commands
%wheel	ALL=(ALL)	ALL

## Same thing without a password
# %wheel	ALL=(ALL)	NOPASSWD: ALL

spot	ALL=(ALL)	NOPASSWD: /usr/bin/poorercputemp


## Allows members of the users group to mount and unmount the  
## cdrom as root
# %users  ALL=/sbin/mount /mnt/cdrom, /sbin/umount /mnt/cdrom

## Allows members of the users group to shutdown this system
# %users  localhost=/sbin/shutdown -h now

## Read drop-in files from /etc/sudoers.d (the # here does not mean a comment)
#includedir /etc/sudoers.d

[Sofiya]

The note:

was done sudo dnf update and the 6.5.0-0-rc5 kernel was installed in the process. /usr/lib/module has 2 cores
It's not very good.

[Sofiya]

The note:
in 12KL_gtkdialogGTK3filemnt64.sfs in /usr/share/applications missing file ROX Filer and Packit

[wiak]

The note:

was done sudo dnf update and the 6.5.0-0-rc5 kernel was installed in the process. /usr/lib/module has 2 cores
It's not very good.

I don't know dnf commands since never used it before. There will be a mechanism with dnf to not install new kernel I'm sure. For the moment it won't cause any bad effects anyway since our huge-kernel will only call its own appropriate module set and you can delete the newer kernels and additions to /usr/lib/modules. But... best to read up on how to lock items against being updated - we already do something similar with Void Linux kernels. Unfortunately, I have no more time available for this just now, sorry.

[wiak]

The note:
in 12KL_gtkdialogGTK3filemnt64.sfs in /usr/share/applications missing file ROX Filer and Packit

I presume thats the missing stuff for Rox? I'll install these then and upload newer 12KL

[Sofiya]

The note:
in 12KL_gtkdialogGTK3filemnt64.sfs in /usr/share/applications missing file ROX Filer and Packit

I presume thats the missing stuff for Rox? I'll install these then and upload newer 12KL

Yes

[rockedge]

@wiak, @Sofiya I have been wondering about how this would work when updating the 07KLF_rootfs when the kernel is built in. When building KLV and creating a Void Linux kernel for it, I use 2 separate firstrib_rootfs 's. The initial system I build is WITHOUT the kernel or any kernel components.

1. Duplicate the firstrib_roots into an upper_changes.

2. Mount firstrib_rootfs with the mount script and using the xbps package manager install the Void Linux kernel.

3. Exit and use the umount script to clean up.

4. Now run the FR scripts on that firstrib_rootfs to build the initrd.gz and get the wd_init followed by running the FR script to extract the vmlinuz

The duplicated upper_changes then becomes the main KLV_rootfs and is without any kernel components so any subsequent updates will NOT INCLUDE the kernel at all. Keeping the KLV_rootfs slimmer and easier to maintain.

Most Importantly makes it clean and smooth to swap kernels in KLV and if one is to use Puppy Linux type huge kernels or a Debian Kernel or of course a Void Linux kernel makes no difference, there is nothing in the KLV_rootfs to conflict.

So in summary: we need a plug that will build the Fedora_rootfs WITH or WITHOUT the Fedora kernel. With to extract a kernel and modules and create an initrd.gz plus extract the vmlinuz, and another to build the 07KLF_rootfs. The firstrib_rootfs then is only updated for use to again extract the next version of kernel.

That should make the kernel situation in KLF much more manageable and compact.

[wiak]

The note:
in 12KL_gtkdialogGTK3filemnt64.sfs in /usr/share/applications missing file ROX Filer and Packit

I presume thats the missing stuff for Rox? I'll install these then and upload newer 12KL

Yes

Oh I see, it is desktop files. I'll put these into /usr/local/share/applications; should be found there - best to use /usr/local hierarchy where possible for non-Fedora repo apps. Someone who knows Rox and wants to use it needs to sort out the issues running roxfiler still has (including, I think in quick test, opening a terminal from it). Of course I haven't put Rox configs of any sort in main filesystem since don't know about it - but did copy Fossapup configs and put them under /usr/local hierarchy for someone to find and use appropriately:

[Sofiya]

I presume thats the missing stuff for Rox? I'll install these then and upload newer 12KL

Yes

Oh I see, it is desktop files. I'll put these into /usr/local/share/applications; should be found there - best to use /usr/local hierarchy where possible for non-Fedora repo apps. Someone who knows Rox and wants to use it needs to sort out the issues running roxfiler still has (including, I think in quick test, opening a terminal from it). Of course I haven't put Rox configs of any sort in main filesystem since don't know about it - but did copy Fossapup configs and put them under /usr/local hierarchy for someone to find and use appropriately:

/usr/share/pixmaps
in the ROX settings, the choice of icons is configured and everything will be beautiful

[rockedge]

I just ran a build and created a new KLF_rootfs. Again I had to manually create the directory firstrib_rootfs. Forgot to and the 1st run failed.

Extracted the Fedora kernel using the scripts and created the initrd. Made a boot-able ISO of it all by taking the /boot directory from KLV-Spectr and changing the some directory names......works pretty good.

Squashed the modules using gzip and the KLF_roots using zstd. Boots like lightning.

But when I updated yesterday's KLF build the kernel updated and I don't think that it is used or will behave unexpectedly since the 00Modules and 01firmware SFS 's are loading during system start, and there are 2 different vmlinuz 's.

[rockedge]

I have the Rox-filer v2.11.1 RPM package if needed grabbed from Fedora 38 3rd party repo.

I used the dnf GUI to install it. Works nicely.

[wiak]

apparently this should work:

Code: Select all

sudo dnf update --exclude=kernel*

or:

you could versionlock existing Fedora kernel, which apparently prevents new kernels being installed. Example:

Code: Select all

sudo dnf versionlock add kernel-5.2.17-200.fc30

also you can do the following in /etc/dnf/dnf.conf:

change the installonly_limit=XXX

From googling I note yum had a config setting exclude only such as:
exclude=kernel* redhat-release*

I expect you can do the same exclude= in /etc/dnf/dnf.conf

Just look up dnf commands per earlier link: https://dnf.readthedocs.io/

[wiak]

I have the Rox-filer v2.11.1 RPM package if needed grabbed from Fedora 38 3rd party repo.

I used the dnf GUI to install it. Works nicely.

maybe better to use that, but maybe not since pollutes the system a bit since not Rawhide release - that's why I want its parts (aside from .config type stuff) in /usr/local hierarchy and thus in 12KL - shouldn't be too hard to compare rpm install and figure out all the parts used.

[wiak]

I have a feeling it might be also possible to prevent the original kernel being downloaded (by XFCE group I believe) using extra --exclude=<package-file-spec> in the plug file, but I'm not sure and have no time to try today.

e.g.

Code: Select all

sudo dnf group install XFCE --exclude=kernel*

[Sofiya]

When everything is put together it will be a Super System!!!

[wiak]

TIP... which you may already do anyway:

Good way to quickly experiment is to make a temporary higher layer directory such as 15test/ or simply 15/, and put say usr/local/bin,share, whatever folders in there and add new items. Then on reboot these will be used. I do that prior to any changes I consider thereafter making to 12KL sfs addon since modifying that needs extra work, and I don't need to mess with upper_changes folder or firstrib_rootfs as an alternative.

[wiak]

When everything is put together it will be a Super System!!!

Yes, I am really impressed with Fedora Rawhide - just needs a few extras added as you say and wow, it is leading-edge fantastic. GNOME instead of XFCE works great too and is using Wayland.

[wiak]

I just ran a build and created a new KLF_rootfs. Again I had to manually create the directory firstrib_rootfs. Forgot to and the 1st run failed.

There is something wrong with what you are doing, or something anyway; I never need to manually create the directory firstrib_rootfs. The fdstrap.sh initial creation script is told to build to firstrib_rootfs so it auto-creates it (or should). The main work fdstrap.sh does is however in /tmp directory (it uses command mktemp for that purpose) - maybe your system has some issue with the /tmp build part?

When you are doing a build - keep /tmp open and then open the tmp folder fdstrap will make whilst working and see if all going well; it goes fine on my computer.

[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.

[Sofiya]

I just ran a build and created a new KLF_rootfs. Again I had to manually create the directory firstrib_rootfs. Forgot to and the 1st run failed.

There is something wrong with what you are doing, or something anyway; I never need to manually create the directory firstrib_rootfs. The fdstrap.sh initial creation script is told to build to firstrib_rootfs so it auto-creates it (or should). The main work fdstrap.sh does is however in /tmp directory (it uses command mktemp for that purpose) - maybe your system has some issue with the /tmp build part?

When you are doing a build - keep /tmp open and then open the tmp folder fdstrap will make whilst working and see if all going well; it goes fine on my computer.

I also have firstrib rootfs, it installs itself and then builds, after building I change it to 07KL_Fedora_XFCE.sfs

[rockedge]

@wiak Only with this build has this ever happened. When I first manually add a /firstrib_rootfs directory the build runs flawlessly. If I don't add it the script starts to write /etc and /var in the build directory. The temp directory is created with a hashed name and the permissions are 700 but remains empty.

After I create the /firstrib_rootfs and then run the script the /tmp/tmpXXXX is written too and populated.

When I use the build script with a KLV type PLUG I can select the repo mirror location and build runs as expected.

So far I have not tracked it down exactly why this is occuring. But if I do the manual folder creation first the Fedora builds completely successfully.

Otherwise I keep fiddling with polish and adding utilities and am impressed how well things work and how blazing fast the OS is. I will try out your suggestions with the kernel exclusion/inclusion control parameters.

Here is the Rox RPM package that has been easy to install using the dnf GUI -> r_rox-filer-2.11-1.x86_64.rpm

[rockedge]

@wiak, @Sofiya I just finished a build using --exclude=kernel* and squashed the rootfs using zstd.
Put together a boot-able ISO to launch easily in QEMU using the 6.5.0-0 kernel extracted from the firstrib_rootfs.
The ISO is under 1 gig weighing in at 998 mb. I will now try to boot the ISO in a QEMU VM............

Update: Booted almost to a desktop but ended up having to send a Ctrl-Alt-Del which this KLF responded to and rebooted.

[wiak]

Sorry, hope I haven't disrupted anything. FirstRib repo in temporary state of flux. I'm changing some components and uploading bits and pieces/replacements right now.
Will post back once ready for testing/using again shortly...

[wiak]

Okay, ready for testing - a simple but big change/facility in new build_firstrib_rootfs.sh script. At the end of the main build via f_plugin it now looks for a finish-it-all-off addons_f.plug file. If that exists it does the commands contained in that (if it doesn't exist, build process is exactly as before). If you use an addons_f.plug (recommended) it would normally just contain the likes of simple wget commands for fetching 12KL...sfs, 11r_rox...sfs and whatever extra you want to download, but could include additional commands right up to making an iso. Simple but powerful extension.

Because I'm using addons_f.plug to now fetch 12KL...sfs and so on the first post instructions have been shortened. Please read that totally revamped first post since it explains how the new build system arrangement works. Of course, the only major change is that use of end-of-build addons_f.plug; everything else remains the same so no actual re-learning to do otherwise.

A major difference between f_plugin commands and addons_f.plug commands is that all of the commands done in the f_plugin occur in a chroot to the firstrib_rootfs, but all of the addons_f.plug commands happen once the chroot stuff is completed so on the normal system.

NOTE: addon 12KL...sfs no longer contains any rox stuff. Instead the contents of that roxfiler rpm @rockedge found are now included in layer addon 11r_rox-filer-2.11-1.x86_64.sfs, which is also auto-downloaded by the first post attached addons_f.plug during the build_firstrib_rootfs.sh processing. Whilst it is possible to install the rox rpm directly, I do not myself like adding non-Fedora Rawhide packages to the system via package manager (since that in a way pollutes the package database). Instead the addon 11r_rox...sfs contains exactly the same files but dnf package database happily knows nothing about it... Actually, I did reorganise the files a little bit differently in that 11 sfs because I want it to also be usable with any Void Linux or Arch Linux build too and they have /usr/lib64 as a symlink whereas Fedora and Debian have it as an actual directory. In the 11r_rox sfs arrangement I therefore put the rox folder in /usr/lib and (in f_00_fedora_gui plugin) created a symlink from /usr/lib64/rox to /usr/lib/rox inside the Fedora Rawhide firstrib_rootfs (an irrelevant symlink until/unless 11r_rox...sfs is used of course). Otherwise I could only have used it with Fedora since the real /usr/lib64 directory would have overwritten the Void (or Arch) /usr/lib64 symlink because in higher overlay. Seems to work perfectly as it is though (for any of these systems).

[Sofiya]

@Wiak
These are just awesome additions.
The assembly was a success, like clockwork. Simply the perfect KLF distributor.
----------------------------------
make two additions:
1) add UExtract.desktop to Applications
2) add sudo to /etc/xdg/autostart/poorercputemp.desktop . ( Exec=sudo poorercputemp )

I don't know if they will notice that you need to uncomment and remove "D":

Code: Select all

# From Soniya, but poorercputemp not working for wiak right now. If you download this remove the D at front to enable the addon prior to booting:
#wget -c https://gitlab.com/firstrib/firstrib/-/raw/master/latest/build_system/14poorercputemp_usrlocalbin-0.2_1.x86_64.sfs -O D14poorercputemp_usrlocalbin-0.2_1.x86_64.sfs

@Wiak Thank you very much for such a great job and for this wonderful KLF.

[Sofiya]

For the sake of experiment, I checked by deleting /usr/lib/firmware and /usr/lib/module . Everything works fine, and most importantly, the size decreases
Since there is /usr/lib/firmware, I think you can build the firmware 01fdrv_module.sfs

[rockedge]

@wiak you definitely have gone above and beyond any expectations! I just ran a build using the new options and in under 16 minutes made a really useful KLF Fedora Rawhide distro that is usable right out of the box. Thanks for the work and can only say we only just barely touched on the possibilities.

@Sofiya I am also experimenting with removing redundant kernel pieces out of the rootfs, and will use your method on this build as I make a boot-able ISO to test run on a QEMU virtual machine.

[rockedge]

Starting a build with a directory set up as shown:

Screenshot(2).jpg (7.68 KiB) Viewed 1312 times

Code: Select all

# wiak (William McEwan) License: MIT. Created 06Aug2023 Revised: 13Aug2023
# rockedge, Revison: 13Aug2023


# Change XFCE to GNOME below if you want that instead
dnf --nogpgcheck group install XFCE -y
# dnf --nogpgcheck --exclude=kernel* --skip-broken group install XFCE -y # experimental to avoid kernel download: 
dnf --nogpgcheck install tar wget leafpad yad sudo rsync gparted chromium xmessage -y

# Optional packages
dnf --nogpgcheck install geany gvfs-smb ristretto -y
dnf --nogpgcheck install gftp htop -y


# add user spot and set password for user spot (spot:spot - root user:password is root:root)
useradd -m -G wheel -s /bin/bash spot
printf "spot\nspot" | passwd spot >/dev/null 2>&1
echo '%wheel ALL=(ALL) NOPASSWD: ALL' | (VISUAL="tee -a" visudo) # wheel group override to sudo no password required

# optionally add the following non-Fedora binaries packages (disclaimer: experimental - packages untested by me):

# If using 11rox... addon sfs addon we need a symlink to rox stored in /usr/lib/rox directory
# Folder rox stored in /usr/lib so 11rox... addon sfs also works with FR Void Linux and Arch Linux based distros
# No harm including this symlink anyway
ln -s /usr/lib/rox /usr/lib64/rox

#Avoid updating/fetching new kernels/modules later
echo exclude=kernel* redhat-release* >> /etc/dnf/dnf.conf

After all is said and done :

Screenshot(3).jpg (18.65 KiB) Viewed 1299 times

And trimmed for making an ISO:

Screenshot(4).jpg (15.89 KiB) Viewed 1299 times

[rockedge]

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 (16.83 KiB) Viewed 1292 times

And just after login and some small simple appearance customizations. This is booting like lightning fast!

Screenshot(9).jpg (13.86 KiB) Viewed 1292 times

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

[Sofiya]

.