Puppy Linux Discussion Forum

Compiled a new build with ( kernel-6.5.0-0.rc6 ) and firmware (6.5.0-0.rc6 ),initrd,vmlinuz
Loading went smoothly, all functions work correctly
The test shows that this works correctly with the native kernel.

anyone who wishes to can test
ISO: 1.1GB
https://drive.google.com/file/d/1uRvQi2 ... sp=sharing
SHA1-MD5sum:
https://drive.google.com/file/d/1Bs8V8G ... drive_link
Kernel:
https://drive.google.com/file/d/1VvoPTW ... drive_link
my addition to make the sound work in root:
https://drive.google.com/file/d/14WeDad ... sp=sharing
New version 14poorercputemp_usrlocalbin-0.3.x86_64.sfs.
https://drive.google.com/file/d/1WiaaBf ... sp=sharing

@Sofiya I also am running a freshly built model and extracted the native kernel and built the initrd.gz
The kernel is Fedora 6.5.0-0-rc6 and I deleted the contents of /usr/lib/modules and /usr/lib/firmware and use the 00modules.sfs and 01firmware.sfs

rockedge wrote: Wed Aug 16, 2023 8:01 pm

@Sofiya I also am running a freshly built model and extracted the native kernel and built the initrd.gz
The kernel is Fedora 6.5.0-0-rc6 and I deleted the contents of /usr/lib/modules and /usr/lib/firmware and use the 00modules.sfs and 01firmware.sfs

Screenshot_2023-08-16_19-58-47.png

That's exactly what I do

@Sofiya I take the /usr/lib/firmware and squash it to 01firmware-6.5.0-0-rc6, then delete the contents.

When I built the rootfs there were 5 directories still mounted and I had to use the chroot mount/umount utilities to prepare the firstrib_rootfs to squash correctly.
Did you experience this also? I am getting ready to run again with the same 2 plug files.

@wiak Looks like this command to add a build.log text file caused the problem as the build script was finishing! (bfr is a symlink!)

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

rockedge wrote: Wed Aug 16, 2023 8:15 pm

@Sofiya I take the /usr/lib/firmware and squash it to 01firmware-6.5.0-0-rc6, then delete the contents.

When I built the rootfs there were 5 directories still mounted and I had to use the chroot mount/umount utilities to prepare the firstrib_rootfs to squash correctly.
Did you experience this also? I am getting ready to run again with the same 2 plug files.

yes i had the same
these links don't work again

_get_FR_initrd (){
  wget -c --no-check-certificate https://owncloud.rockedge.org/index.php/s/HRZhsnouSm3Gpf3/download -O modify_initrd_gz.sh && chmod +x modify_initrd_gz.sh
  wget -c --no-check-certificate https://owncloud.rockedge.org/index.php/s/CXixDo8Dd2rtxSQ/download -O initrd-latest.gz
  wget -c --no-check-certificate https://owncloud.rockedge.org/index.php/s/8aFjxy5QrjfyI8o/download -O w_init
}

@Sofiya Must be slow.....I will go check it.....this is a test from just a moment ago ->

@wiak Just finished another build and it looks good except that the firstrib_rootfs still has directories mounted.

This time the chroot mount/umount did not clear it. I had to go manually to the bottom of the sub-directories to umount manually to get it to work.

rockedge wrote: Wed Aug 16, 2023 8:39 pm

This time the chroot mount/umount did not clear it. I had to go manually to the bottom of the sub-directories to umount manually to get it to work.

It's possible I've messed up, but I can't look into any of it for at least a few days unfortunately. I've run out of time and have some big home matters I need to attend to.

I ran into some major problems relating to copying in /etc/resolv.conf owing to it being a symlink in fedora and maybe other new systemd distros.
I keep thinking I've fixed the issue, but each 'fix' has brought its own problems. I need to find some good spare time to really think about the issue and find a proper fix if my most recent build_firstrib_rootfs.sh script hasn't fixed things (I thought it would). Make sure you are using the most recent build_firstrib_rootfs.sh script and the associated most recent mount_chroot.sh script. These were both changed (had to be - since same issue arises for both). Please always download the latest always prior to trying a new build per the following fetch lines:

wget -c https://gitlab.com/firstrib/firstrib/-/raw/master/latest/build_system/build_firstrib_rootfs.sh && chmod +x build_firstrib_rootfs.sh
wget -c https://gitlab.com/firstrib/firstrib/-/raw/master/latest/build_system/mount_chroot.sh && chmod +x mount_chroot.sh

If anyone uses the not most current version of scripts I'm going to have no idea what is going on. Sorry I don't have time to test today - I want to - but just can't.

OH, please from now on always check and report the version and rc number and Revision date of the scripts since then at least I can try to find out what issue might be.
My own builds last night, just prior to bed, seemed to work fine, but I do need more tests.

rockedge wrote: Wed Aug 16, 2023 8:39 pm

@wiak Just finished another build and it looks good except that the firstrib_rootfs still has directories mounted.
Screenshot(30).jpg

This time the chroot mount/umount did not clear it. I had to go manually to the bottom of the sub-directories to umount manually to get it to work.

So it is like trying out any distro and issues arising. I need details.

For example what was build_firstrib_rootfs.sh and mount_chroot.sh Version and rc numbers, and also their Revision dates? Without these I have no idea. These kinds of matters are exactly what I am working on. Come on guys, development needs accurate reports and everyone keeping on the same page in terms with keeping up with most recent published build scripts... or nothing can be checked and fixed.

wiak wrote: Wed Aug 16, 2023 10:50 pm

rockedge wrote: Wed Aug 16, 2023 8:39 pm

@wiak Just finished another build and it looks good except that the firstrib_rootfs still has directories mounted.
Screenshot(30).jpg

This time the chroot mount/umount did not clear it. I had to go manually to the bottom of the sub-directories to umount manually to get it to work.

So it is like trying out any distro and issues arising. I need details.

For example what was build_firstrib_rootfs.sh and mount_chroot.sh Version and rc numbers, and also their Revision dates? Without these I have no idea. These kinds of matters are exactly what I am working on. Come on guys, development needs accurate reports and everyone keeping on the same page in terms with keeping up with most recent published build scripts... or nothing can be checked and fixed.

@wiak Hi
since I have a photographic memory, I skimming through your last scripts see that in line 20 in "addons_f.plug_nokernel"line 27 in "addons_f.plug_includes_kernel" the name of the build folder is changed to ( mv firstrib_rootfs 07firstrib_rootfs ) , this will not allow unmounting, since the name will change from ( firstrib_rootfs ) and the unmount code will look for this is the name ( firstrib_rootfs )

wiak wrote: Wed Aug 16, 2023 10:50 pm

rockedge wrote: Wed Aug 16, 2023 8:39 pm

@wiak Just finished another build and it looks good except that the firstrib_rootfs still has directories mounted.
Screenshot(30).jpg

This time the chroot mount/umount did not clear it. I had to go manually to the bottom of the sub-directories to umount manually to get it to work.

So it is like trying out any distro and issues arising. I need details.

For example what was build_firstrib_rootfs.sh and mount_chroot.sh Version and rc numbers, and also their Revision dates? Without these I have no idea. These kinds of matters are exactly what I am working on. Come on guys, development needs accurate reports and everyone keeping on the same page in terms with keeping up with most recent published build scripts... or nothing can be checked and fixed.

@wiak Hi
since I have a photographic memory, I skimming through your last scripts see that in ( addons_f.plug ) line 20-27, the name of the build folder will be changed to ( 07firstrib_rootfs ) , this will not allow unmounting, since the name will change from ( firstrib_rootfs ) and the unmounting code will look for this is the name ( firstrib_rootfs )

# Finished doing the INSIDE_CHROOT stuff so can now clean up the chroot bind mounts:
	umount -l firstrib_rootfs/proc && umount -l firstrib_rootfs/sys && umount -l firstrib_rootfs/dev/pts && umount -l firstrib_rootfs/dev
    rm -f firstrib_rootfs/etc/resolv.conf && mv firstrib_rootfs/etc/resolv.confORIG firstrib_rootfs/etc/resolv.conf  # put back resolv.conf to its original form
	rm -rf firstrib_rootfs/tmp/*

I think if you comment out this line, everything will be unmounted

@Sofiya I think that is what is happening. Good catch!

I am now doing a run without the addons_f.plug file included. I am used to doing it all manually so no problem to set up system with a raw firstrib_rootfs.
Already have downloaded the accompanying SFS files from earlier builds.

Sofiya wrote: Thu Aug 17, 2023 12:05 am

wiak wrote: Wed Aug 16, 2023 10:50 pm

rockedge wrote: Wed Aug 16, 2023 8:39 pm

@wiak Just finished another build and it looks good except that the firstrib_rootfs still has directories mounted.
Screenshot(30).jpg

This time the chroot mount/umount did not clear it. I had to go manually to the bottom of the sub-directories to umount manually to get it to work.

So it is like trying out any distro and issues arising. I need details.

For example what was build_firstrib_rootfs.sh and mount_chroot.sh Version and rc numbers, and also their Revision dates? Without these I have no idea. These kinds of matters are exactly what I am working on. Come on guys, development needs accurate reports and everyone keeping on the same page in terms with keeping up with most recent published build scripts... or nothing can be checked and fixed.

@wiak Hi
since I have a photographic memory, I skimming through your last scripts see that in ( addons_f.plug ) line 20, the name of the build folder will be changed to ( 07firstrib_rootfs ) , this will not allow unmounting, since the name will change from ( firstrib_rootfs ) and the unmounting code will look for this is the name ( firstrib_rootfs )

Code: Select all

# Finished doing the INSIDE_CHROOT stuff so can now clean up the chroot bind mounts:
	umount -l firstrib_rootfs/proc && umount -l firstrib_rootfs/sys && umount -l firstrib_rootfs/dev/pts && umount -l firstrib_rootfs/dev
    rm -f firstrib_rootfs/etc/resolv.conf && mv firstrib_rootfs/etc/resolv.confORIG firstrib_rootfs/etc/resolv.conf  # put back resolv.conf to its original form
	rm -rf firstrib_rootfs/tmp/*

I think if you comment out this line, everything will be unmounted

Our posts must have crossed. I was saying the same to rockedge earlier that I had to move the addons_f.plug code line cos any cd in there would do as you say above. I have since moved that line and re-uploaded, but only had time to test very quickly. Mind you, I don't see any cd in the addons_f.plug I myself posted, but since that is intended as user-editable that was the issue I imagined could happen.

I squashed all the SFS into xz 1M block compression files and managed to get a working ISO at 965 M

And the KLF 965 megabyte ISO does boot smoothly using the extracted Fedora kernel! I am using it in a QEMU VM so I am not seeing any noticeable differences in system boot/start speeds between the ISO with the zstd compressed SFS's and the xz compression.

Keeping the ISO under 1 G is a goal if possible but not necessarily important.

Really fun driving the KLF Fedora system in a virtual machine and playing around with the cutting edge of cutting edge. Though it's hard to match the Void Linux type distro's for efficiency of resource usage and KLV's are totally fun in their own right. Can not forget the Arch types either.......

The dilemma now is which to use now, KLA or KLF or KLV ??

Must mention I am building all of the KL's using Puppy Linux F96-CE_4 which has all of the tools onboard ready for action to make building all the way to a running system which itself hosts with QEMU or VirtualBox, possible.

Having assembled the assembly with the LXDE working environment, booted up and looked at this squalor ..... just Delete it. Although I always liked lxde, this time something didn’t hook

Announcement:

Build KL Fedora Rawhide XFCE - no longer builds for unknown reasons