Puppy Linux Discussion Forum

@wiak I have a clone of the WDL GitHub repo from 24Sep2021 but it does not have the pkgdetails anywhere in it. I will look some more in case.....

Glad it's no longer needed!

rockedge wrote: Thu Aug 03, 2023 3:32 pm

@wiak I have a clone of the WDL GitHub repo from 24Sep2021 but it does not have the pkgdetails anywhere in it. I will look some more in case.....

Glad it's no longer needed!

Yes, it was a bit of a worry to me, but no longer. Problem was that even in 2020 when I first googled about debootstrap complaining when perl not present, any reference to alternative pkgdetails was always met with 'install perl or tiny perl'. Since FirstRib seems to be the only place doing things this way therefore, and it was originally tricky for me to implement, I wasn't sure I could do it again. I searched again widely via google to see if anyone else had used the method, but not as far as I've ever found. However, all's well that ends well.

So, trying quick simple noX Ubuntu Jammy build. It's working, but as you might see in my temporary code, not quite to my plan.

# _getlatestfile "$debootstrap_repo" "_all.deb" "grep -vE \(nmu|ubuntu\)"
latest_file="debootstrap_1.0.128+nmu2ubuntu1_all.deb" # wiak temporarily overriding AI, i.e. _getlatestfile... since its picking useless debootstrap version (but obeying my code - I thought was best one)...

The commented out function _getlatestfile isn't actually AI code of course - just me the brains behind it, but me wrong thinking most recent would be best... That truly 'most recent' debootstrap deb file that _getlatestfile does correctly fetch turns out only to have scripts in it for Debian distros and no Ubuntu ones, such as for Jammy (goodness knows why...). The second to latest from same Ubuntu repo works fine though - which is why I end up hard-coding it for download in my current tests.

WIth the good Ubuntu debootstrap,

./build_firstrib_rootfs.sh ubuntu jammy amd64 f_00_Ubuntu_Jammy_amd64_noXsimple00_wiak-rc1.plug

is partly working...

However, overall still some code in that Debian/Devuan/Ubuntu area to tidy up again and I probably don't have time right now so may be a while before that ready and released, but not a big deal since no-one been building further Ubuntu releases in KL area. Assuming can do it in an hour or two maximum I intend quickly testing the rest of the build script with Void Linux, Arch Linux, (and Fedora maybe). Arch Linux and Void Linux should all remain fully functioning in which case I'll release as is with Debian/Devuan/Ubuntu fixed support to come later... I'll let you know once I've finished that much and published.

EDIT: but a problem. It's all to do with zstd getting used with everything so looks like debootstrap needing extras to extract correctly. Googling reveals that it is a well-known new issue with debootstrap/needs. I will have to think about this and fix later (I know exactly what the issue is though - no zstd/zstdcat when in chroot cos busybox doesn't provide it... tricky/painful, but have various ways to work round that. Easy to deal with if I accept using host installed debootstrap, which I am now inclined towards - alternatively I'm considering a statically linked musl build again, but not sure about likelihood of that - zstd involves a lot. Well:

https://gist.github.com/ryancdotorg/84275935f0b82578d8c222e2e915fc78

(putting in code tags to avoid it opening since lots of lines).

Nah, this is getting silly (and above maybe just for arm); if anything Void Linux xbps-src might be best bet for static builds, but I haven't learned much about using that. I already thought previously that it was overkill doing the debootstrap in a chroot. I don't do that for Arch Linux so I think I'll just simplify matters like the archbootstrap mechanism - then I don't need pkgdetails either - will do the Debian-part of the script re-write once I have more time in the future I think. But just found this: https://aur.archlinux.org/packages/zstd-static

wiak wrote: Fri Aug 04, 2023 9:55 am

But just found this: https://aur.archlinux.org/packages/zstd-static

this might be the game changer!

rockedge wrote: Fri Aug 04, 2023 1:49 pm

wiak wrote: Fri Aug 04, 2023 9:55 am

But just found this: https://aur.archlinux.org/packages/zstd-static

this might be the game changer!

Maybe not...

I just built it using old version of Sofiya's KLA_OT2baseCE via trizen. Managed the build (under .cache) but doesn't seem to be statically linked afterall... Pity.

I don't think I need to do the debootstrap the way I've been doing though (in own chroot) so easier not to - then don't need pkgdetails nor zstd in the chroot...

But I did have the feeling the way I did it before (in chroot) had some advantages since could work on any distro even if they themselves didn't have debootstrap installed or perl for that matter... But I think that previous method is becoming too much effort. Only effect the Debian/Devuan/Ubuntu-based builds anyway.

wiak wrote: Fri Aug 04, 2023 2:37 pm

rockedge wrote: Fri Aug 04, 2023 1:49 pm

wiak wrote: Fri Aug 04, 2023 9:55 am

But just found this: https://aur.archlinux.org/packages/zstd-static

this might be the game changer!

Maybe not...

I just built it using old version of Sofiya's KLA_OT2baseCE via trizen. Managed the build (under .cache) but doesn't seem to be statically linked afterall... Pity.

And why is this necessary, I do not understand anything about what is at stake
A test was made and the package was found to be out of date.

replaced
requires removal of zstd - if installed
zstd-static-1.5.5-1-x86_64.pkg.tar.zst :
https://gitlab.com/sofija.p2018/kla-ot2 ... line=false

Sofiya wrote: Fri Aug 04, 2023 3:35 pm

wiak wrote: Fri Aug 04, 2023 2:37 pm

rockedge wrote: Fri Aug 04, 2023 1:49 pm

this might be the game changer!

Maybe not...

I just built it using old version of Sofiya's KLA_OT2baseCE via trizen. Managed the build (under .cache) but doesn't seem to be statically linked afterall... Pity.

And why is this necessary, I do not understand anything about what is at stake
A test was made and the package was found to be out of date.

replaced
requires removal of zstd - if installed
zstd-static-1.5.5-1-x86_64.pkg.tar.zst :
https://gitlab.com/sofija.p2018/kla-ot2 ... line=false

It is simply to do with the way I was building Debian based firstrib distros. Not needed for Arch Linux builds at all.
I simply noticed Arch AUR had zstd in statically linked form, so I also fetched that but it is only partly of static construction, so not standalone executable I think.
I needed it because debootstrap now needs zstd, but up till now I was building Debian based FR in a chroot environment that only had busybox in it with no access to host distro's zstd. Same reason I was using pkgdetails since did not have access to host distro's perl from the chrrot environment, and debootstrap needs perl usually.
I will try that aur zstd package maybe anyway with libs extra, but overall I will likely use host installed debootstrap, perl, and zstd in later script versions (rather than use debootstrap for Debian build in self-contained chroot environment).

In fact, I had forgotten. I already have a 'special' skeleton FR initrd that already contains libc and zst libs. It was only a little bit bigger than the usual FR skeleton initrd (because of the inclusion of these libs), but I haven't needed it lately. I think I can just take out its zstd lib components and use them in the current debootstrap chroot environment - just a few MB. Then again, I can indeed just use the zstd-static parts since that FR skel initrd didn't contain the zstd binary itself (just the libzstd for use by kmod). I will try that, but still, I've long been thinking I should re-write the Debian-related part of build_firstrib_rootfs simply to use build host systems perl and zstd and so on - means no maintenance work likely ever for these parts.

Will however, simply add-in zstd from that old kmod version of FR initrd into the debootstrap chroot and see if that works, which I expect it will. Too much work - no worried anyone - I'll just use more typical debootstrap build using the host own libs - should be easy script modification that way and no sweat...

This re-doing Debian-build code in build_firstrib_rootfs is taking me back in time to 2017 when I was invasive enough to find out and describe how to use Debian's debootstrap on any Puppy (not just Debian-based) system. I'm glad I wrote that pretty extensive post since it not only turns out to have (admittedly without intention) seen the future to some extent, but also contains information that remains very relevant: https://oldforum.puppylinux.com/viewtop ... 63#p963063

Despite some new Pups being designed via debootstrap, the above already described an alternative approach of using debootstrap in tradition PPM-based Pups, but more important for me personally it reminds me how to use debootstrap for my own FirstRib needs (cos I've otherwise forgotten...).

Instinctively (almost) I still don't feel comfortable with simply installing debootstrap on the host system being used for FirstRib or KL FR-based builds. It then occupies /usr/lib/debootstrap and other places on whatever distro filesystem host I'm using (I haven't checked debootstrap parts location details). That's why in build_firstrib_rootfs script I previously only installed debootstrap into a separate filesystem using chroot to use it, but yes, that wee filesystem is like a mini-linux that needs several key parts such as now zstd and dependencies. I have a new experimental idea to avoid installing debootstrap on the host filesystem itself - I could get the debian section of build_firstrib_rootfs to made a very small Void Linux system by calling the build Void function in the same script (since xbps static package manager makes that pretty easy and just use it to install zstd...) and then use that for the debootstrap work in a chroot and delete that mini-Void-Linux system once the debian rootfs completed. Even the smallest useful zstd-containing Void Linux rootfilesystem is probably bigger than I want though - but the idea is sound I think, so I'll think more about that too... or maybe I'll resort to some bind mounts back to key host directories, but I resist that because I've accidentally destroyed host key directories (removed) whilst in that kind of chroot situation in the past - can't remember what the issues were, but realised could be very risky (resulting back then in my having to completely re-install the big host system...).

Or I'll simply accept straight install of debootstrap on the host - yes it is easiest way forward, but I do wonder if I'm using a different debootstrap for other builds (since Ubuntu, Devuan, and Debian all have their own different debootstrap variants), whether writing one over the top of the other is okay...

EDIT: Without trying for the very smallest just took about 20 seconds to make a default: ./build_firstrib_rootfs.sh void default amd64 build and that is 59MiB in size. Bit big, but it doesn't matter, gets removed totally after the Debian-based build is completed thereafter... But I'll see what smaller one I can make - the build_firstrib_rootfs script has some special optional variants (e.g. vmini) including one that just includes busybox and xbps-static package manager alone...
EDIT2: well, vmini build is only slightly smaller (46MiB) since xbps-static actually consists of several parts each a few MB in size, but I think around 50MiB temp root filesystem during build is fine since avoids me having to permanently install debootstrap on underlying host machine, which doesn't seem like ideal to me... The bigger no-f_plug normal build number 1 below (59MiB) includes zstd automatically - EDIT...No, I had to install zstd in plugin (and the necessary openssl and certificates and stuff needed to access Void repos), the vmini one (46MiB), doesn't:

./build_firstrib_rootfs.sh void default amd64 

./build_firstrib_rootfs.sh vmini default amd64

Void Linux is such a great upstream distro for experiments like this. Actually, if it was just a FirstRib Debian build I wanted, I can just install Void Linux Debian-debootstrap, but that's not so versatile as way I've been doing it that allows for either of Ubuntu, Devuan, or Debian debootstrap use.

EDIT3: History is that Void Linux was the distro I first aimed for in FirstRib design, hence it having so many build options in build_firstrib_rootfs; Void is just so versatile, but that makes me think of something I should add. Though script can already build amd64 (x86_64) or 32bit i686 builds, I haven't included x86_64 musl builds yet, which would be smaller too of course - I will add that next year. I had planned for arm processor builds too, but I have no suitable arm-based devices as yet so never completed that function since can't test the result (but the arm-build function would be pretty much identical other than the architecture I would think).

EDIT4: In practice I don't need that whole 59MiB temporary Void Linux build. I can remove most components from it (using FirstRIb mount_chroot.sh script, for example - wiak's razor) as long as I keep zstd and dependencies... and just keep that little special Void root filesystem as a wget fetchable tar.xz or similar archive to be quickly downloaded and temporarily used for my Debian/Ubuntu/Devuan builds - yes, I like that idea most I think. But if it ever fails, always have option to build new 59MiB alternative for same use. Thus far, after using xbps to install zstd the resulting root filesystem is only 51.3MiB after removing contents of /var/cache/xbps. I have to stop spending time on this till a few months from now, but I will quickly tonight have last experiment using the razor on that... All this just for Debian-related FR builds of course - Void Linux, Arch Linux, and Fedora FR builds don't need this anyway.

Oh well, above idea of using a mini-Void-distro as part of build_firstrib_rootfs Debian builds was a brainwave - today's coffee did its job.

The Void root filesystem resulting from ./build_firstrib_rootfs.sh void default amd64, but with zstd added, is perfectly small enough at around 57MiB because I can fetch it from my firstrib repo via wget when required - download size is less than 15MiB once tar.xz compressed, and it gets deleted once the FirstRib Devuan, Debian, or Ubuntu is completed. Of course any small distro root filesystem that contained the likes of zstd would do
for inside the chroot with this FirstRib methodology for using debootstrap; result is that debootstrap DOES NOT need to be installed on the host system itself at all.

Actually, the tar.xz remains under 27 MiB even if I include perl inside, which would have the advantage that no pkgdetails extra would be required to satisfy the needs of Debian.

I will try both, but I'm tempted to go the 27MiB direction since gets deleted at end of build anyway and won't take long to download with modern internet speeds. Yes, could take the small distro and cut it down a lot still, but that is messy, bad for future maintenance/rebuilding, and hardly seems worthwhile since the compressed-mini-rootfs gets deleted during the debootstrap build anyway.

Great thing about this idea is that mini-void-rootfs can be added to at any time should any other code be required at any stage in it - easy therefore to build and maintain, which is important for distro longevity. Funny how Void Linux would then be the vehicle for building FirstRib/KL Debian/Ubuntu/Devuan builds. Is there no end to the power of this concept? - just joking - don't panic, but the idea seems to fit our FR/KL strategies and needs anyway

Also allows for building that mini-Void for the chroot by the build_firstrib_rootfs script itself; I'll look into both idea alternatives. But alas, no time right now really...

Once I've implemented these 'fixes' FirstRib/KL builds will be possible for all of variants: Void Linux (32 and 64bits), Arch Linux, Devuan, Debian, Ubuntu, Fedora and also, via KL_full2frugal most typical full installed distros such as Linux Mint, MxLinux, Zorin and Manjaro. Exhausting really... Well I feel a bit exhausted these days anyway, but generally optimistic about developments.

I spoke too soon; the ideas above worked. Thought it would take long time to implement. I've made a quick ubuntu jammy new FR root filesystem build via new test build_firstrib_rootfs.sh, so all of Devuan, Debian, Ubuntu builds will be available again soonish afterall... and now should be a much easier to maintain permanent build option feature. Now I'll try adding to the base Ubuntu Jammy build with simple noX f_00_Ubuntu_jammy build plugin extra. I have no doubt that will work as it used to.

EDIT: yes, on a roll now; that worked too; not a small distro build since I'm not using any slim-it-down measures at all in these debootstrap builds at this time.
Using skeleton FR initrd bolt-on tricks it is easier to produce slim variants of the likes of Ubuntu Jammy in practice, but nevertheless I am happy to see the build_firstrib_rootfs.sh back able to build these from f_plugs. Debian debootstrap even with variant "minbase" was never designed to produce small distro root filesystems, so whatever results would basically need remastered to make a forum-style small distro.

But I don't see a lot of point in doing that, myself. As I say there are some relatively small root filesystems already made and available elsewhere (for example, for docker containers) that can easily be turned into a FR-based KL distro. I don't myself care to re-invent too many wheels. Instead I think it is much more sensible to take what is already out there such as docker containerised distros and so on, and turn them into the likes of KL distros with FR initrd save-on-demand or run from RAM functionality and so on.

That's particularly the case, I feel, with Debian-based distros, because debootstrap simply does not create small distos and for the most part it is best not to slim base distro down when that doesn't make it run more efficiently usually anyway. Arch Linux and Void Linux are a great deal different - it is pretty easy to build small variants of these via the likes of build_firstrib_rootfs FirstRib build system, which then provides via the f_plugin a huge amount of scope for unique creativity and very different look, feel and desktop environment.

Actually, you can slim the result down. A few years ago I did that to produce what I called a LGO build with a view to using the resulting small Ubuntu distro as a building block like LEGO.

In fact I published a FirstRib iso of it for Ubuntu FocalFossa - was around 80MB as far as I recall; basically just a very minimal FocalFossa with dpkg/apt and all the dependencies needed to make that work properly. One offshoot of that LGO production was sfs addon for Puppy's FossaPup which gave it almost perfect dpkg/apt ability (aside from issue of apt updates bringing down systemd replacements for a couple of Puppy system scripts, though not a great issue to fix since could just copy the Puppy scripts back in again after such upgrades - in fact rockedge used that to good effect those couple of years before dpkg/apt became available in more recent actual Pup builds.

So you could slim down a debootstrap built Ubuntu/Debian/Devuan FirstRib build by removing all but dpkg/apt and the dependencies of that package management system (i.e. pretty much just tiniest core system plus dpkg/apt package manager plus its dependencies). For LGO FirstRib system, I actually didn't use my already available debootstrap build at all, but instead created a modified build_firstrib_rootfs script to simply install dpkg/apt and all its dependencies one by one (rather than a whole debootstrap system then cut down...). Either way can produce an iso like that wee 80MB FR_focalfossa I'm talking about, and that was a handy commandline-only variant (to start with). I should make a LGO jammy I suppose - that will also have to wait till mid-2024. I never make inbetween Ubuntu (etc) release variants (e.g. Kinetic) since the upstream support term for these is so short I'd rather wait till new LTS release.

I could include the LGO code in usual build_firstrib_rootfs script (in fact the LGO code shared a lot of that FR script code) but in practice was easier to use a different (albeit related LGO version of the usual firstrib_rootfs build script altogether). Anyway, hopefully I can publish some LGO script builder next year to supplement the growing range of options - I still have the original scripts used, but they need updated to work now of course.

Overall obviously too big a growing TODO list, but since most of it has already been done over the years, it is surprising how quickly it could all become more generally available again I feel. Once a person gets the hang of using the FR skeleton initrd all the variants become easy to create and use I feel, so not as much work involved as might otherwise be imagined.

Very good that there are an increasing number of FR/KL distro builders around in this KL section now since encourages long term maintenance of the build system component parts too. That's the way I view the system actually, not as some kind of overall complex build system, but as a small number of simple building blocks. Once you understand the two or three main parts of that and how to use them, the rest I think is pretty easy, yet flexible in what can be done with it.

Personally I find experimenting with it all quite exciting because it is easy with the simple FR pieces to do so much (and a lot of unexplored scope). That's mainly why I am on the forum.

in fact rockedge used that to good effect those couple of years before dpkg/apt became available in more recent actual Pup builds.

I've just booted into this system and using apt update | apt upgrade did a complete system update/upgrade! Typing this from it now. This was a comprehensive enough update that I had to run a little script that returns the correct init, poweroff, reboot for a Puppy Linux and not systemd. The upgrade included systemd upgrades which swaps in the systemd links in /sbin

Also needed to chown -R the /var/run/mysqld directory to have the correct ownership. The upgrade of the mysql server changed this to Ubuntu configurations and I just with one command switch it back to Puppy Linux mysql server operations configuration.

This little bolt on SFS has functioned flawlessly since I set it up in 2020 modifying a Fossapup64-9.5 to run it.

Some screenshots of the most recent APT update/upgrade:

I originally began to experiment with the APT SFS addon to perform Zoneminder installations and updates more like the mainstream and not always Puppy Linux specialized. Also just noticed the fonts for Palemoon and other applications are different and much nicer.

Now I am tempted to try the add-on SFS on F96-CE_4 to see if there is any hope of it working. Not really important because of the deep advances being made to incorporate the APT package management into the newest woof-CE builds.

Test ready to bolt on the LGO SFS (adrv + apt SFS) to a fresh frugal of F96-CE_4

It works:

Installed apt install mc and that installed and works right after a system upgrade. And added the components to return the /sbin to a Puppy Linux state after any updates to Ubuntu's systemd by the APT package manager.

So, to make the build more automatic I've modified the latest build_firstrib_rootfs.sh script I'm working on to auto-build and use a temporary small Void Linux filesystem to use in a chroot to then build Debian-based systems (via debootstrap per usual). Of course that's a bit slower as a Debian/Devuan/Ubuntu build since the Void distro needs built first, but Debian debootstrap builds are VERY slow (and big) generally so hardly an issue.
Nevertheless, it is a matter of commenting out (and in) a couple of code lines to simply download a pre-mades small Void Linux rootfs for the same job.

The Debian/Devuan/Ubuntu debootstrap build within a zstd/perl capable mini-Void distro is working well and solves a lot of issues in practice: main thing being no need to pollute host builder platform with debootstrap code, nor need special compiled pkgdetails executable like I was using before.

Since the Debian-based builds do in fact also build a mini command-line Void Linux root filesystem, I've decided not to delete that since it generally is a useful up-to-date build output resource too (a user can delete it manually at the end of the Debian build if they wish), but nice to have what is basically a minimum Void Linux commandline-only build. However, that needs a few extra parts installed to make it bootable by FRinitrd, though for a straight build of it I will be including a simple f_plug with minimum extra install code to allow also wifi connection via simple old wiakwifi (which had a missed bug that I've now also fixed). Of course, any such Void distro can have more added to provide X desktop, Wayland, or whatever.

I wasn't meaning to work so much on this new version right now, but I realised I might forget lots I've been working out, so best for long term time savings to try and finish the changes now rather than wait till early 2024 when I hope to have more free time again... I will publish copy of the new build script for testing in a day or two - quite significant code changes, so needs more testing. Also I haven't had time to check all the Debian build types yet, nor the Fedora builds.

Using the under test new build_firstrib_rootfs script just successfully built a:

PRETTY_NAME="Devuan GNU/Linux 4 (chimaera)"
NAME="Devuan GNU/Linux"
VERSION_ID="4"
VERSION="4 (chimaera)"
VERSION_CODENAME="chimaera"
ID=devuan
ID_LIKE=debian
HOME_URL="https://www.devuan.org/"
SUPPORT_URL="https://devuan.org/os/community"
BUG_REPORT_URL="https://bugs.devuan.org/"

Been a while since it was able to do that, but all looking good again. Can build Devuan Daedalus too.

Next build test will be Fedora; I'm more interested in that than the already so many Debian-based distros.

Fedora build not working cos the upstream fdstrap script I was using for Fedora not working any more and I see no maintenance work on it for a year. However, I have some sort of fedora root filesystem hacked together now based on fdstrap - I know nothing about Fedora nowadays other than last time I played with weedogit installed variant using dnf package manager so not sure how correct the rootfs I've made is, but seems okay thus far. Will use it for now with build_firstrib_rootfs for the fedora code. Should have the tested build script available for limited testing soon.

EDIT: No, though that fedora root filesystem worked ok on my host in a chroot, it didn't work once booted. But... no idea how, I found how new dnf package manager options and seem to have fdstrap working now. Testing to see if that is true... WIthout particularly good reason, except gut feeling, I feel somewhat confident this time though.
EDIT2: yes, the resultant commandline-only fedora rawhide seemed to boot fine and dnf install package manager works. I have no idea how to get GUI environment working with this though. No simply xorg or xfce4 environment base package as far as I could fine - but truth is I just don't know how to use fedora. I'll put the commandline variant into build_firstrib_rootfs builder though.

So in small fedora rawhide. No idea about it. Had installed network manager so nmtui allowed me to connect to internet via nmtui command. Old wiakwifi also worked in earlier attempt (after installing iproute and busybox and wpa_supplicant).

Just for fun installed Wayland Weston:

dnf install weston

Thought that'd be tiny, but it installed tons of stuff...

Can't remember now if came with it or did also: dnf install weston-terminal

Its rubbish looking.

Started weston simply with command: weston
Terminal was available as wee top bar icon, so opened that in weston

Then did: dnf install firefox, and I'm posting from it now. I am ignorant about this, but I guess it is working as it should. BTW also did: dnf install sway and I ran command: sway, so that is now running in its own window on this Wayland session. Running weston-terminal again caused it to now pop-up in the sway window. Grim screenshot wouldn't work in these, sorry... Really I am just playing and have no idea what I am doing...

Wasting time. Moving on. Still to put this new code fix into build_firstrib_rootfs...

So I had finished dev work. Well, this is driving me mad... Tonight tried what worked yesterday:

./build_firstrib_rootfs.sh fedora default amd64

Tonight didn't work. Apparently new release of fedora rawhide; and dnf used no longer recognises option --use-host-config (as used in downloaded fdstrap.sh), so I edited the downloaded fdstrap.sh and took that option out and reran:

./build_firstrib_rootfs.sh fedora default amd64

and it built fine. Maybe tomorrow another new Fedora Rawhide release which needs --use-host-config. Oh well, ok, I'd put it back in again. Bit of a moving target. That's the problem with ultra-fast-moving-rolling-release; not fault of build_firstrib_rootfs.sh - and fdstrap.sh never been changed upstream for over a year. But anyway, working for me again, but only after removing that --use-host-config in fdstrap.sh (fdstrap.sh doesn't get re-downloaded if already in build dir so that's useful at least).

OOPS... looks like I had a post from yesterday here but have accidentally replaced it with this new one. Oh well, consider this newer post the newest. I can't remember already what I posted yesterday...

Just re-uploaded fdstrap.sh with current 'fix' since found fedora build was suddenly not working anymore. I expect actually my /etc/resolv.conf last minute fix in build_firstrib_rootfs.sh had broken the fedora build without me noticing... So with new fdstrap.sh the command:

./build_firstrib_rootfs.sh fedora default amd64

is I'm glad to say working again... Had though Fedora Rawhide being a constantly moving rolling release distro was cause of the problem, but probably wasn't that afterall.

As for how to turn that simple commandline distro into a GUI distro; well, Fedora (RedHat) package manager is fantastic in my opinion (better than apt/dpkg or xbps). Yes I know, some people hate systemd and RedHat therefore, but personally I also find systemd the best of the pack. Once you've used it for a bit you soon get to know where all its bits and pieces resides and how its commands work - though I remain a novice at systemd use actually. But dnf package manager... wow, it is so tidy and intuitive... But back on point - how to use dnf to install GUI. Well, like with Void Linux xbps you just need a template file (with Fedora dnf it is called a 'group') so to install, say, XFCE, you simply use command:

dnf group install XFCE

and then you have X auto installed and XFCE (and we all know how that looks and works). So, no it is not difficult at all to start building a full-featured KL distro; not if you leave upstream to do the hard work... Openbox installs with tint2 are a bit trickier since that's not a complete desktop environment - just a desktop manager...

To see what groups are available, enter command:

dnf group list --hidden

I did try: dnf group install LXQt and that booted to a graphics screen but I couldn't see where to enter my root/root login details. I haven't actually tried booting the just made Fedora Rawhide XFCE so let's hope that provides place to log in(!) or I'll have to figure out how to do it... Back soon with reboot result...

Yeah, so @geo_c and Co. The idea that it might be tricky to use build_firstrib_rootfs.sh to build a full XFCE style distro is in imagination only. All that was needed were the following (but using the today 'fixed' fdstrap.sh build-helper-utility, rather than the unfortunately faulty one from yesterday):

./build_firstrib_rootfs.sh fedora default amd64

Then, after including FR skeleton initrd, vmlinuz (huge-kernel), 00modules.sfs and 01firmware.sfs and running ./wd_grubconfig to get grub2 menu stanza, in the running distro do:

dnf group install XFCE

and you get a perfectly good XFCE-based distro to reboot into (with user:root, password:root).

Okay, so had no internet browser, so I added:

dnf install chromium

which installs 'chromium-browser' (of course, as it stands you need to run chromium-browser --no-sandbox, since running as root user here)

NOTE: once ./build_firstrib_rootfs.sh fedora default amd64 was finished building firstrib_rootfs/, I actually used command: ./mount_chroot.sh firstrib_rootfs
to enter into that filesystem (via the chroot used there) and it was there that I installed XFCE via command:
dnf group install XFCE
and then entered command 'exit' to leave the chroot, and finally
./umount_chroot.sh firstrib_rootfs
to clean up the mount points used by the chroot.
Actually, finally was really to then rename firstrib_rootfs/ to 07firstrib_rootfs/ and then booted into my shiny new Fedora Rawhide desktop (as root user passwd root)

But instead of say, dnf group install XFCE, you can give the likes of dnf group install LXDE a go - I haven't tried that one yet.
Also, later, you'd want to include the save2flash utility scripts from other KL distros so have FirstRib RAM2 save on demand support of course, but otherwise, easy as pie to build this new distro, which I'm posting from right now...

NOTE2: The end result is a pretty full-on Fedora distro so quite a number of service daemons running in background by default and a full-on XFCE so neither small nor tiny in terms of resource usage. But great to play on a Fedora system for a change - also, this, or similar Fedora build, would be the one for use in educational establishments since RedHat Certified Engineer Linux courses is main professional system admin Linux qualification (and dnf would be the package manager learned there and single-user distro like Puppy no use for that Linux system admin teaching situation - I know... because I use to teach on some RHCE courses).

NOTE3: In practice, I would create a normal user (such as spot) using terminal command:

useradd -m -G wheel -s /bin/bash spot

and logout and login again as user spot since chromium-browser needs no sandbox then and no fluffing about with 'tricks' needed. Yeah, but i don't mind using sudo thunar followed by opening root-user terminal from there to admin my system... or set permissions on other resources thereafter... Also I'd install something like geany since no text editor from this Fedora by default: dnf install geany
But yes, I love this dnf package manager - it's really intuitive to use and great (but XFCE has dnf GUI package manager available by default too).

But what if you want to try wayland with Fedora? Well easiest is just to do same as in my above post, but instead of:

dnf group install XFCE

do:

dnf group install GNOME

since Fedora uses Wayland with that...

Actually, I'm in it right now (5 min after being in XFCE build...) and it runs very nicely on this laptop of mine. I don't myself like GNOME user interface though - maybe I'm old fashioned, but still prefer XFCE style (i.e. a bit like Windows 7 look and feel really). But fun playing with GNOME and probably best current environment to test out Wayland apps. Fedora also does have group for Sway (Wayland using too):

dnf group list --hidden | grep Sway

and install it therefore with:

sudo dnf group install "Sway Window Manager"

but Sway needs fair bit more work to get it all going...

My kid just came over and said XFCE, pointing to the Desktop background squiggly image (see my desktop post above with the attached image).

viewtopic.php?p=95950#p95950y

(You can't really see it in that cropped image, but you will if you look closely at that whole desktop background provided as option by XFCE).

And sure enough, there amongst the squiggles are the distorted repeated letters: xfce

There it is plain as day....... Now I see it clearly but without the hint no way

Using the same basic plug file to build a KLF except running a JWM desktop as demonstrated in a Xnest instance set as DISPLAY=:1 started with

xhost +
Xnest :1
export DISPLAY=:1

using the chroot mount and umount scripts with the freshly built fristrib_rootfs in a Xnest instance as display :1 is very handy for configuration of a desktop because of the ability to directly read+write to and from the uncompressed firstrib_rootfs and see the results and effects of an install or configuration running immediately.

So this is just a minor matter I've thought about for a while.

Back in early 2019 when I was simply building firstrib_rootfs (had no FR initrd) and then running it under a chroot on host system I also created the script mount_chroot.sh and clean up script umount_chroot.sh

But for a long time I've been wondering why I hadn't just combined the two back then such that after exit from the chroot the clean up routine simply runs; that's what I do in similar scripts afterall...

I wondered if there might be a good reason I wanted to keep them separate, and certainly when something goes wrong it has proved useful at times to have a separate umount_chroot script. But, overall, it is more convenient not to have to run a second script...

Finally today, I decided to also therefore make a single/combined variant called mount_chroot_umount.sh

As expected it seems to work and saves that double script usage pattern. Hopefully there is no great reason I have forgotten about. I doubt it; I probably just never got round to making a combined version.

If you want it, you can download it in usual fashion:

# Utility mount_chroot_umount.sh: mount_chroot and umount_chroot scripts combined
wget -c https://gitlab.com/firstrib/firstrib/-/raw/master/latest/build_system/mount_chroot_umount.sh && chmod +x mount_chroot_umount.sh

If I am not thinking straight and something very wrong with the combined script, please let me know! - some days are like that...

if you open a terminal and then at some point run ./mount_chroot and do some stuff...
then forgetfully or accidentily close the terminal, what happens to the chroot?
should you open a new terminal and run ./mount_chroot to do some more stuff, have you created two chroots?

how do you clean up the chroot/or both chroots? does umount clean up all chroots?

williwaw wrote: Mon Aug 28, 2023 8:59 am

if you open a terminal and then at some point run ./mount_chroot and do some stuff...
then forgetfully or accidentily close the terminal, what happens to the chroot?
should you open a new terminal and run ./mount_chroot to do some more stuff, have you created two chroots?

how do you clean up the chroot/or both chroots? does umount clean up all chroots?

If you accidentally close terminal, just open it again and do ./umount_chroot.sh <dir_name>
That should clean up what you forgot.
You can check if cleaned up using simple 'mount' command on its own. If you see the chroot mounts still active you know you didn't clean them up.
If you use ./mount_chroot.sh twice, I'm not sure what happens then; I have never done that! but imagine just takes you back inside the chroot since mount binds already active so on exit just ./umount_chroot them again.

But maybe this is why it is better to use that new script: ./mount_chroot_umount.sh <dirname>
since it ends by cleaning up once you exit (but of course if you accidentally close terminal, you better open new one and ./umount_chroot.sh <dirname>
Maybe that's why I kept separate mount_chroot and umount_chroot scripts; I can't remember.

if you open a terminal and then at some point run ./mount_chroot and do some stuff...
then forgetfully or accidentally close the terminal

I do this al the time! Like wiak posted, going back and running the umount script will clean it up. I have even used the mount again first to see what state the chroot 'ed rootfs is in at that moment.

I found it's pretty robust and tolerant of forgetting to umount and going back to fix it