Adventures with a FirstRibIt Build of Noblepup64

[rockedge]

I have made a Noblepup64-FR that I am posting from right now.

Screenshot.jpg (37.13 KiB) Viewed 1077 times

I can't install with APT. Updates fine but throws errors...for example:

attempt to install ffmpeg so I can install TAS-1.17 PET

Screenshot(2).jpg (70.47 KiB) Viewed 1078 times

I am running in a normal mode writing directly to the upper_changes directory. Palemoon is running and the system is connected via eth0 and eth1 (blade server with 2 Ethernet cards)

[williwaw]

and what happens if you run "dpkg-statoverride"

same error with apt on other attempted pkg installs?

[rockedge]

@williwaw I was able to fix the apt install problem by creating the group ssl-cert.

After that the install of midnight commander and ffmpeg finished without an error!

[Clarity]

This is a question where I admit that I am infantile in FirstRibIT utility. Note: This is not taking issue with anyone, rather this post is rhetorical.

Understanding this, as I understand that some/most of the distros listed on Distrowatch are built from scratch; aka compiled to a final instance.

WoofCE will take one of these distros and remakes a Puppy from that base. A WoofCE distro made from an original base to be rebuild into a new PUP distro. This includes special tweaking that sometimes is needed to occur to make a stable PUP.

Now, we are trying to use FirstRibIT to take the output of a WoofCE to make a new distro??? I am sure it can be done, but, at what benefit or cost?

From one point of view, is this a good use of the utility? In other words one is taking a base made from a base to make a new base. This overlooks the WoofCE design for its remastering tool to include all of the nouances that exist in the WoofCE packaging of its distros. This seems to be a pathways to potential issues beyond the intent of FirstRibIT. Further, WoofCE's remastering will produce an ISO, OOTB, in its production allowing flexibility in user use. For now, FirstRibIT does not do so.

Why not do what WoofCE does? Namely take a distro, from distrowatch, built from scratch and then FirstRibIT just as it has been used thus far in the KL area of the forum?

The distros we see in this KL area are building from 'base' distros found on distrowatch. Here, any issue resolution is contained within the FirstRibIT production; nowhere else. Thus far in the KL area, there is no base from a base to a new base which would make issue resolution a bit of a problem; not to mention who would you report the issue to.

Is this concept logical? My question refers may better be stated: "Should FirstRibIT, at least for now, be used to take a base distro (not a base from a WoofCE base or any other builder) to build new KLs?"

[TerryH]

... "Should FirstRibIT, at least for now, be used to take a base distro (not a base from a WoofCE base or any other builder) to build new KLs?"

This is exactly what it does. With the old weedogit script I built many different distro installations. It appears @rockedge just decided to have some fun using NoblePup64 to trial FirstRibIt.

I still have installations (some via weedogit, some manually), including Mabox, Xero Linux( Arch based KDE, no longer producing releases), PCLinuxOS Debian.

[rockedge]

It appears @rockedge just decided to have some fun using NoblePup64 to trial FirstRibIt.

Yes! That is exactly what I am doing...have a lot of fun and finding out Noblepup64 works really well so far with the FirstRibIt treatment.

I broke it and deleted the /upper_changes and I rebooted and back better now than it was, as I figure out what slight tweaks it needs.

Important tweak directly after first boot in a terminal, this will make apt work nicely:

Code: Select all

addgroup ssl-cert 

I am going to go ahead and back up the /upper_changes so I can give this system the "ZoneMinder Test"
Will rename devx_upup64n_24.04.sfs to 09devx_upup64n_24.04.sfs and reboot back into normal frugal write RAM to upper_changes directly mode

[wiak]

I broke it and deleted the /upper_changes and I rebooted and back better now than it was, as I figure out what slight tweaks it needs.

Important tweak directly after first boot in a terminal, this will make apt work nicely:

Code: Select all

addgroup ssl-cert 

Thanks for that ssl-cert fix rockedge. I will also add the simple build plugin capability to firstribit such that you can tweak such fixes in at build time with simple plug file.

Is this concept logical? My question refers may better be stated: "Should FirstRibIT, at least for now, be used to take a base distro (not a base from a WoofCE base or any other builder) to build new KLs?"

The great thing about FR and KL building overall is that there are no rules of usage or thus restrictions.

But think about it, debootstrap from Debian is used for building several distros here, including debiandog and latest Puppy and an FR debian-based build if you want it. What is debootstrap other than a build system that makes a base build of Debian distro (and of various sizes/complexities). Similarly firstribit can use woof-CE as the builder for a base; I have in fact already advocated/hoped for a small core woof-CE build capability, that could be used like debootstrap (woof-CE becoming a base of a debootstrap base sometimes even), since that would be particularly useful more generally in the FR way of building distros since a plug file that used package manager and config commands would then be used to complete the full distro build per user wishes/needs.

Note that we don't 'compete' with Debian, but that doesn't stop us using its facilities for new distro release purposes; there are many many Debian-based distro creations, which have their own trademark release names (Ubuntu, MX Linux, Bodhi, for example).

Artificially limiting how build systems are used isn't necessary.

[Clarity]

Thanks everyone.

[FeodorF]

Hi @rockedge , this Noblepup64 was very hard to find on the forum.

I gave it a spin and suffered a crashing PaleMoon browser. Guess it is already an AVX/AVX2 build v.33.3.0 .
As I am still on old hardware with BIOS 2010 and Intel core duo 2,6 GHz. I gave the SSE2 SeaMonkey build
v. 2.53.18.2 a chance and this combo works fine for me; posting of it right now.

I used the same installation method as described right there: viewtopic.php?p=129545#p129545

Code: Select all

root@puppypc2151:~$ ~/seamonkey/seamonkey
/usr/bin/lsb_release: line 8: warning: setlocale: LC_ALL: cannot change locale (C.UTF-8): No such file or directory
root@puppypc2151:~$ 

Regards,
Feodor

Noblepup64-FR-pic-012.png (24.82 KiB) Viewed 610 times

[geo_c]

It appears @rockedge just decided to have some fun using NoblePup64 to trial FirstRibIt.

Yes! That is exactly what I am doing...have a lot of fun and finding out Noblepup64 works really well so far with the FirstRibIt treatment.

I broke it and deleted the /upper_changes and I rebooted and back better now than it was, as I figure out what slight tweaks it needs.

Important tweak directly after first boot in a terminal, this will make apt work nicely:

Code: Select all

addgroup ssl-cert 

I am going to go ahead and back up the /upper_changes so I can give this system the "ZoneMinder Test"
Will rename devx_upup64n_24.04.sfs to 09devx_upup64n_24.04.sfs and reboot back into normal frugal write RAM to upper_changes directly mode

How does this work with a pup exactly? Does it grab all the pup sfs files and number them? or combine them into one 07rootfs.sfs?

[rockedge]

@geo_c This is what the frugal install directory looks like after becoming a FirstRibIt subject.

Screenshot(5).jpg (27.32 KiB) Viewed 567 times

Screenshot(6).jpg (53.3 KiB) Viewed 564 times

[geo_c]

Screenshot(6).jpg

That's what I thought, so it numbers the sfs files.

I've been playing around with layers more these days. Building a daily driver of KLV-KDE-plasma I decided not to do a Psuedo-Full-Install. Instead I simply loaded up a fresh upper_changes with pipewire-jack and other applications and squashed a 20geoapps.sfs layer. It comes out to only 600MB squashed.

That leaves a few layers underneath for things like updates to filemnt or other special layers. And then I figure when it comes to special configs for different machines or things that I might change often, like added .desktop files in/usr/share/applications or maybe pipewire-jack configs in /etc, I'll keep uncompressed directory layers starting at 50. That way they are easy to change.

So my KLV-KDE-plasma multi-install directories look like this, a couple of the 50 layers are still empty, but you see I have one with network connections, being that this system is duplicated on different machines, I can access my common networks on these different machines and copy the network configs into the 54 layer and then copy that layer from machine to machine. Also I have applications that I'm starting with sudo command in special desktop files. Those can be added on one machine and quickly migrated to a new instance or new machine.

And that would be the answer to @Clarity's question about why someone might want to do this with a puppy, easy manipulation of filesystem layers:

[wiak]

That's what I thought, so it numbers the sfs files.
...

That leaves a few layers underneath for things like updates to filemnt or other special layers. And then I figure when it comes to special configs for different machines or things that I might change often, like added .desktop files in/usr/share/applications or maybe pipewire-jack configs in /etc, I'll keep uncompressed directory layers starting at 50. That way they are easy to change.
...
And that would be the answer to @Clarity's question about why someone might want to do this with a puppy, easy manipulation [of compressed sfs or uncompressed normal directory layers]

Above is indeed among the advantages. No need at all to compress directory layers that take up little space anyway, and ease of modifying them whenever wanted is hugely useful - adding new small utilities... whatever... Firstribit really takes advantage of that (and has provided these futuristic advantages/capabilities since 2019... alas the jealous comments that have tried to write it all off as uncreative flat tyres, when actually leading the way opposite... I have no idea what any Linux development is to do with religion but oddly several of those who criticise myself seem to include that as a basis so perhaps FR is evily good. BEWARE! ). Really it is why FR initrd/init is designed that way - a fundamental improvement on what was already out there that has not been realised by most for its fundamental game-changer nature (too busy trying to protect the distros they already love, but not willing to see the improvement FR offered).

I actually didnt push it all that much (no distrowatch attempts, for example), despite some claiming otherwise. Rather I've left the FR/KL key strengths to be discovered by those adventurous enough to try it and really explore its nature. Certainly, weedogit, and more so, firstribit and KL_full2frugal, were released to demonstrate the inherent power of the FR layering arrangements. But never matters to me if few use it, as long as I can!

As for this forum finally 'getting it' about being better to use official package managers with upstream repos... well Debiandog started that on this forum (albeit via Sickgut Pussy Linux) but FirstRib took the idea to a whole new simpler level via combination of busybox and void linux variant static compiled xbps package manager, but also allowing debian, devuan, ubuntu, Arch linux builds via bootstrap build script systems such as Debian's debootstrap. And FR provided Puppy with addon sfs working dpkg/apt facility as another contribution to help. Times change. Actual history gets forgotten or ignored on purpose it sometimes seems, but that doesnt matter; what is important is that we have the facility and can do it.