Announcing firstribit

[wiak]

Thanks. Exactly what I needed.

Here in the American Midwest, we call that weather.

In the beginning of June, it hailed 4 times in 1 week.

I'm in Southeastern Asia. Tropical thunderstorm is pretty tropical

[esos]

Thanks Waik for the reply.
Spiral:
After ran snapmergepuppy files are created in /mnt/layers/RAM/ and /mnt/layers/uc_ro

after ran save2flash
/usr/bin/save2flash: line 9: yad: command not found
Merging /mnt/layers/RAM/upper_changes onto /mnt/layers/uc_ro...
/usr/bin/save2flash: line 13: kill: (2074) - No such process

Root or User - No saving at quit
---------------------------------------------
4m:
After ran snapmergepuppy files are created in /mnt/layers/RAM/ and /mnt/layers/uc_ro

after ran save2flash
/usr/bin/save2flash: line 9: yad: command not found
Merging /mnt/layers/RAM/upper_changes onto /mnt/layers/uc_ro...
xargs: invalid option -- 'd'
BusyBox v1.36.1 (2023-05-27 20:06:42 UTC) multi-call binary.

Usage: xargs [OPTIONS] [PROG ARGS]

Run PROG on every item given by stdin

-0 NUL terminated input
-a FILE Read from FILE instead of stdin
-o Reopen stdin as /dev/tty
-r Don't run command if input is empty
-t Print the command on stderr before execution
-p Ask user whether to run each command
-E STR,-e[STR] STR stops input processing
-I STR Replace STR within PROG ARGS with input line
-n N Pass no more than N args to PROG
-s N Pass command line of no more than N bytes
-P N Run up to N PROGs in parallel
-x Exit if size is exceeded
/usr/bin/save2flash: line 13: kill: (1402) - No such process

No saving at quit.
----------------------------------------
austrumi-1.8.5 is not working.

[rockedge]

File may contain malware, automatic download disabled. Continue to download at own risk

kind of an odd warning looking at the download Sourceforge site for austrumi-1.8.5

[wiak]

...
No saving at quit.
----------------------------------------
austrumi-1.8.5 is not working.

When system doesnt have yad installed you get error messages, but they just mean no gui and didnt stop save2flash working in my tests. Snapmergepuppy just does the save more directly and doesnt use yad. If fileschange in /mnt/layers/uc_ro then that is actually a bind mount to the save persistence folder, so the save happened and should be seen on reboot.

To test, I usually just create a quick new file using the likes of the command:

touch anyjunk

Then I do a save2flash or a snapmergepuppy from a terminal. Some distros insist on sudo ...

Then I reboot and check the file is there.

austrumi is weird and I only succeeded in getting that one to basically boot to commandline as far as I recall; left it in menu in case anyone wanted to try it from that stage.

[williwaw]

@wiak

I see many of the same scripts and components to be downloaded with firstribit as using a plugfile with the older buildsystem using plugfiles.

In laymans term, would you be king enough to explain how a build would differ using the older plug file method and the new firstribit script?

say for instance building a KLV the older way, with a plug file that includes xfce
and
applying firstribit to void-live-x86_64-20240314-xfce.iso found at
https://repo-default.voidlinux.org/live/current/

[wiak]

@wiak

I see many of the same scripts and components to be downloaded with firstribit as using a plugfile with the older buildsystem using plugfiles.

In laymans term, would you be king enough to explain how a build would differ using the older plug file method and the new firstribit script?

say for instance building a KLV the older way, with a plug file that includes xfce
and
applying firstribit to void-live-x86_64-20240314-xfce.iso found at
https://repo-default.voidlinux.org/live/current/

A similar question would be "what is the difference between xubuntu and linux mint xfce?".

KLV xfce (airedale, for example) is built from scratch starting only with busybox and void linux package manager xbps, so the distro creator can make it contain anything they wish.

Absolutely nothing wrong with using the probably larger in size xfce root filesystem from void linux made frugal via firstrib and provided with save2flash capability via KL script written by fredx181. Biggest likely difference is that forum community can help shape what goes into KL release and the latter is configured to start in Puppy favoured root user desktop.

There are arguments for and against both approaches. Main thing for me is that FR can do either, but for special purpose smallest reasonably useful distros KL makes sense since starts as small as possible. People here have objected to my opinion that distros, in terms of their underlying Linux functionality and apps they can install are fundamentally not particularly unique. To me, that is a mark of mature system design, efficiency, compatibility and adherence to defined/industry-agreed standards. But, KL/FR is lego-like in approach; can use only the key bricks you want to use and many of these bricks, such as save2flash and many more, are forum designed.

But yes, you can use most any KL utility with official upstream rootfilesystems, which to me suggests that the central focus of importance in this forum is not any distro, but rather the frugal install expertise, projects, and utilities we are expert at here.

[williwaw]

...... from void linux made frugal via firstrib and provided with save2flash capability via KL script written by fredx181............and the latter is configured to start in Puppy favoured root user desktop.

to clarify..........
firstribit will produce
a frugal install
with save to flash (save on demand)
optimized to run as root

while the older build system produces
frugal install
save to flash
but not optimized to run as root?

[wiak]

...... from void linux made frugal via firstrib and provided with save2flash capability via KL script written by fredx181............and the latter is configured to start in Puppy favoured root user desktop.

to clarify..........
firstribit will produce
a frugal install
with save to flash (save on demand)
optimized to run as root

while the older build system produces
frugal install
save to flash
but not optimized to run as root?

As far as running as root is concerned it is usually the other way round. FirstRib, in terms of its initrd and overlayfs functionality has no interest in how the underlying root filesystem does things and most distros (and therefore the result of using firstribit) are running as normal user by preference though that is easily changed by some reconfiguration of course (but then you'd probably want to include other forum utilities such as run-as-spot or whoever since many internet-facing apps nowadays shy away from running as root.

firstribit is much simpler way to produce a working frugally installable distro to the build it from near-scratch build_firstrib_rootfs method so most any forum member will likely find firstribit pretty simple to use whereas many may struggle somewhat - depending on their scripting and Linux abilities) with build_firstrib_rootfs plugin methodology - though template example plugs make that relatively simple too. As I've mentioned elsewhere a while back, I am planning to (eventually) allow the (optional) use of plug file with firstribit too, but in a special release that will likely first decompress the main root filesystem and then apply the plug instructions prior to (optionally) compressing back up again; that would allow adding or subtracting from the underneath original root filesystem (i.e. a way to produce say a mini-Linux Mint).

[dancytron]

Built one with Debian Live Bookworm LXQt. All worked as expected on my Windows 7 era desktop.

Save2flash worked after I installed yad.

Dan

Runs with sound and bluetooth on my $32 Gen 3 Chromebook with no extra fussing with it.

OTB it is pipewire but not wireplumber. Updating to wireplumber seemed to just work.

Took forever to boot up. The 1st time around I thought it had locked up. I think different compression should fix that.

I'm going to see if I can slim it down, install Chrome, and turn off all the silly extra passwords.

[esos]

Thanks Wiak, save2flash/snapmergepuppy is working fine. Archbang works also.
Austrumi64-4.9.4 can not write to upper_changes/work directories during booting and stop there.

[wiak]

Thanks for the austrumi report with boot screenshot. The can't change directory message on boot is just a warning that doesnt mean anything in this boot arrangement. I'll remove the message next time I upgrade FR initrd, but that won't be soon.

I'll take a quick further look at austrumi, but it never did work properly on my attempts. It has a complex arrangement as far as I recall, which simply may not work with firstribit (yet I think I had it succeeding up to a commandline in previous weedogit).

I won't spend long on that one since otherwise have new firstribit ready to release.

[dancytron]

To set up a development environment, is what I want is to unsquash the 08filesystem file and rename it .../BookwormQt/upper_changes, an empty 08filesystem folder, and to rename the existing upper_changes to something like 09-FRscripts?

Then to create the new 08filesystem.sfs just resquash upper_changes??

Layers

ram rw layer
upper_changes (root file system)
90_FRScripts (static)
12KL_gtkdialogGTK3filemnt64 (static)
08_filesystem (empty)

[wiak]

To set up a development environment, is what I want is to unsquash the 08filesystem file and rename it .../BookwormQt/upper_changes, an empty 08filesystem folder, and to rename the existing upper_changes to something like 09-FRscripts?

Then to create the new 08filesystem.sfs just resquash upper_changes??

Layers

ram rw layer
upper_changes (root file system)
90_FRScripts (static)
12KL_gtkdialogGTK3filemnt64 (static)
08_filesystem (empty)

That would be typical FR pseudo full install arrangement. Yes, I think should work. Since it involves other numbered layers anyway, I think you 'may' not need the 08-filesystem directory at all (once you've renamed the 08filesystem to upper_changes), but try it with first...

Looks like you are about to become our first FR'd BookwormPup64 developer

[wiak]

NEW RELEASE INCLUDING FirstRibIT fxxxit PLUGFILE SUPPORT

progname="firstribit.sh"; version="022"; revision="-rc1" #Revision Date: 07July2024

Download (via git) and install per first post of this thread. You might like to keep copy of previous one in case of issues, but so far so good with my tests.

Main changes:

Includes simple after build plugin support, which should provide ultra-simple distro editing/remastering support, via suitable plug commands
You are encouraged to later provide your own plug files as templates for use by other firstribit users and resultant FR/KL-related distro developers.

Code: Select all

Usage: firstribit.sh --help

Simply execute this script with command:

./firstribit.sh optional_f_it_plugname

The plug file is just a list of extra commands you want done, such as further wget commands to include your own addon layers; it is not done in a chroot but just directly on main build host filesystem. A simple example is attached to first post of this thread, which simply prints a "ALL GOOD TO GO!!!" message at the end of build. Developed plugins can be used as templates for other builders; I am planning one that makes a chroot of unsquashed 08filesystem, which like the other FR build system script (build_firstrib_rootfs) would often allow use of official upstream package manager... and thus complete remasters to bigger or much smaller distro size... However, don't wait for me...; aside from quick maintenance to this release I have to get on with other non-computer-related things for quite a while to come.

Also, I removed austrumi since I never managed to get that booting to more than a commandline using my own simple init, which was not useful.

Main new distros added:

Fedora (just download suitable Fedora iso prior to using firstribit on that).

Since many distros are actually spins of Debian/Ubuntu/Devuan or of Arch Linux, I have also included two generic menu items for distros that don't otherwise have any menu choice. More generally I am keeping other distros with own functions in case I want to do something different with any of them.

It turned out that getting save2flash to work with FR of tinycorelinux was far from simple, but that should now also be working. Anyone interested in FR_TCL development might find the way I installed the extra tcz apps: bash, findutils and so on useful, and can have a look at how I did that in the relevant firstribit TCL-related function. The mechanism employed could be extended to automatically find TCL dependencies and thus become a new FR_TCL app for installation via addon tcz(sfs) files (which can also be used uncompressed per FR normal flexibility...). Note that whilst there has been earlier work here to make a TCL puppy linux lookalike, this firstribit variant is an actual FR/KL distro that provides close to normal TCL look and feel but with full KL flexible featureset. I suspect, with some further development, this FR_tcl could become an extremely fast useful little FR/KL distro and might be able to use both the FR addon layers method AND get the upstream symlink TCL package managers working (but latter would take some effort maybe). Note that, currently, Puppy Linux kernel/modules/firmware is used with FR_TCL since normal TCL kernel does not provide overlayfs support. Also remember that TCL itself (and thus the initial FR version of it), by default, requires an ethernet connection for internet use. NOTE: after save2flash on reboot you will be asked for login username for host "box". Just use tc as the username (no password required). You can alternatively keep autologin working by deleting file /var/log/autologin just prior to running save2flash such that /var/login/autologin file is not there on reboot.

I may of course have accidentally broken some distro installs that worked before. Just let me know if that turns out to be the case..., and some distros that have menu choices still have not been tested by myself.

[wiak]

Whilst a firstribit 4MLinux boots fine, and save2flash is all ready to go... the snapmergepuppy part of save2flash requires the underlying distro to include a package for full xargs, which is normally part of findutils package in most distros. By default, 4MLinux only uses busybox for its xargs functionality, but full xargs is required.

4MLinux reminds me very much of Puppy Linux.

[wiak]

Regarding FR of TinyCoreLinux. Unfortunately, I spoke too soon. Yes, save2changes appeared to work and stuff ended up in upper_changes because of that. Alas, on reboot whatever ended up in upper_changes effected things negatively for TCL such that it no longer managed to boot to desktop. Oh well, I'll look into that sometime (maybe future later...) and hope to find what is going on there since I really think TCL would be good wee FR/KL distro if can make that work...

EDIT: turned out to be minor issue. See my immediate next post for simple workaround.

[wiak]

Oh well, FR tinycorelinux issue seems utterly minor. Just login if asked with username: tc and no password.
Turns out TCL writes an empty file /var/log/autologin and save2flash was saving that, which happens to prevent autologin... So another quick way round the issue is to: rm -f /var/log/autologin just before using save2flash and on next boot FR_TCL will autologin again. Fixing that better not worth bothering about more at the present. Workaround good enough for me at this stage.

[wiak]

To set up a development environment, is what I want is to unsquash the 08filesystem file and rename it .../BookwormQt/upper_changes, an empty 08filesystem folder, and to rename the existing upper_changes to something like 09-FRscripts?

Then to create the new 08filesystem.sfs just resquash upper_changes??

Don't know if you managed to get this working, but I just tried it myself and there is a 'trick' to it, which I'll detail here.

I'm assuming a pristrine install, but you could indeed take an existing upper_changes if it had something in it and rename it to something like 50upper_changes. However, in the following, with pristine install there may still be an empty upper_changes. Using a different distro just delete any empty upper_changes and then do the following (this is assuming for FR_Bookwormpup64):

Code: Select all

mv 08pupXXXXX.sfs D08pupXXXXX.sfs   # just using a 'D' at front to make it not be seen as a numbered layer so not used
unsquashfs D08pupXXXXX.sfs  # to get an unsquashed/uncompressed version and then make that the read/write upper_changes:
mv squashfs-root upper_changes

# the extra needed trick to get pseudo full install working here is to provide suitable init and poweroff substitute for those of Puppy in the upper layer (upper_changes) by doing the following (can alternatively use filemanager to do this work):
mv upper_changes/usr/sbin/init upper_changes/usr/sbin/initD  # that is just to disable that puppy init script which we don't use...
mv upper_changes/usr/sbin/poweroff upper_changes/usr/sbin/poweroffD  # that is just to disable that puppy poweroff script which we don't use...
mv 25KL_forkpup_type1/usr/sbin/init upper_changes/usr/sbin/init  # that is to provide a simple init for our FirstRib needs...
mv 25KL_forkpup_type1/usr/sbin/poweroff upper_changes/usr/sbin/poweroff  # that is just to provide a simple poweroff script for our FirstRib needs

You don't need to do anything else. Just boot the result and then you can use the likes of apt and all changes will be appearing in upper_changes which you can save2flash and then squash back up again as a remaster... Note that upper_changes is top layer here (previously 08puppyXXX was below adrv layer) but seems to work anyway. EDIT: Of course, if you don't mind an extra sfs anyway, you don't really need to 'remaster' 08puppyXXX.sfs. Instead you could just rename the normal upper_changes to anything with high value 2-digit filename, such as that 50upper_changes and make an extra sfs out of that. Same result in the end but using one extra sfs layer. These are two of the conveniences of FR-based installs: no problem using uncompressed layers and have lots of such layers to play with - of course there is a slight resource usage associated with each additional mounted layer. But with the pseudo full install method you should be able to remaster 08puppyXXX.sfs and then rename it all back to non-numbered form for use as a normal Puppy... i.e. using firstribit as a remastering helper method.

For most other distros only one sfs file is involved (08filesystem.sfs). For example: FR_LinuxMint. For that case you would unsquashfs 08filesystem.sfs and name the result upper_changes. However since only that one sfs involved, for that scenario you do need to make a dummy empty layer such as an empty directory named, say, 08dummy. Then that pseudo full install will work. FR_BookwormPup64 doesn't need any 08dummy since already has several read-only sfs layers remaining.

[dancytron]

No, I didn't get it working.

It worked to get to the login screen, but it didn't know the firstbit password anymore.

I tried a few things that didn't work and was getting ready to post something.

I'll setup again try again with the new instructions later.

edit: I"m using Debian Live Bookworm LXQt version from the Debian website and chose the Debian Live option (26 iirc but maybe 27).

[rockedge]

It worked to get to the login screen, but it didn't know the firstbit password anymore.

the login should be the defaults for Debian Live Bookworm LXQt

[Sofiya]

With a little magic we get the EndeavorOS Wayland Arch desktop

[exton]

@wiak

Hi,

I found your post the other day. I have now tested FirstRibIT with Fedora, Manjaro and Zorin. Everything works very well (as expected).

This method (to run different Linux distros from a Frugal install) deserves much more attention. I have therefore written a simple instruction about how to use FirstRibIT and published it on my Linux sites and on various Linux Facebook groups.

Link to my instruction...

[wiak]

@wiak

Hi,

I found your post the other day. I have now tested FirstRibIT with Fedora, Manjaro and Zorin. Everything works very well (as expected).

This method (to run different Linux distros from a Frugal install) deserves much more attention. I have therefore written a simple instruction about how to use FirstRibIT and published it on my Linux sites and on various Linux Facebook groups.

Link to my instruction...

This is great. Thank you exton.

[Luluc]

I made a frugal install with the firstribit script and the official Ubuntu 20.04 CD image and it seems to work well.
Well, it boots. There is that.

But I can't log in. The firstrib user is selected automatically, but 'firstrib' doesn't seem to be the right password.
Empty password doesn't work either.
root:root and root:[empty password] won't work either.

The official Ubuntu documentation says it's very, strictly, positively, absolutely, hugely, immensely, horribly, tremendously, unsurmountably, mind-numbingly, ohmygodly FORBIDDEN to log in as root on Ubuntu. They go as far as disabling the su command because you know, we are all children who should ALL and ALWAYS use special kindergarten scissors OR ELSE.

Anyway, does anyone here know a solution to this Mordac style "security"?

Edit: BTW, Spiral didn't work for me. It says it's "looking for root partition" or something then "press Exit to boot" but it doesn't boot, it throws a kernel panic.

[wiak]

I made a frugal install with the firstribit script and the official Ubuntu 20.04 CD image and it seems to work well.
Well, it boots. There is that.

But I can't log in. The firstrib user is selected automatically, but 'firstrib' doesn't seem to be the right password.
...

My internet connection is too poor right now to check. I've had similar user;password failures with some distros but forget the details. I'll try to test later and come back to you about the matter.

[wiak]

I made a frugal install with the firstribit script and the official Ubuntu 20.04 CD image and it seems to work well.
Well, it boots. There is that.

But I can't log in. The firstrib user is selected automatically, but 'firstrib' doesn't seem to be the right password.
...

My internet connection is too poor right now to check. I've had similar user;password failures with some distros but forget the details. I'll try to test later and come back to you about the matter.

I might not be working further on firstribit for a few months now as I move towards alternative ideas for its provision, but I'll try a ubuntu tonight and let you know if login matters worked for me or not. Might well not...

[mikeslr]

@wiak

I made a frugal install with the firstribit script and the official Ubuntu 20.04 CD image and it seems to work well.
Well, it boots. There is that...

I've had the same problem with Kubuntu and IIRC LinuxMInt-Cinnamon. When you first published firstribit you provided instructions regarding what variations of a login password to try including, IIRC, checking what password publishers of the distro may have used. [Pre-1st cup of coffee, so I'm haven't searched for the relevant posts]. I've also tried something-like [hazy memory ] manually creating an upper chamber with an argument creating passwords in the appropriate location. All my efforts were unsuccessful. As no one else mentioned this problem, I figured it was either me or my equipment. But I wondered if sofiya's publications which run as spot was a choice or a necessity.

At any rate, when you have the time to work of firstribit again consider if it would be possible to assign a default password rather than leaving it up to the user to engage in the routines of 'hit or miss' and web-search.

[rockedge]

Yes there is a trick to the password situation. We had to experiment to actually login to some of the distros that during the FirstRibIt process don't go through their normal intallation procedures and occasionally don't have the root password set at all.

Also possible to manually create a user and assign a password via the chroot'ed method.

Before I go through the steps to find and retrieve the info I can offer what I remember.....use the 2 scripts mount_chroot.sh and umount_chroot.sh to mount the uncompressed rootfs of the distro. Once in the system running in a chroot mode, on the terminal command line change the root password using passwd

There are some other steps that can be done for other scenarios depending on the FirstRibIt'ed distro but also revolve using these scripts to mount the root file system in a chroot.

This might help @wiak track down those steps we took to get the login's squared away,

Another note: Look on the oldforum (Murga) in the FIrstRib archives....that's where there is some of the original info on getting through this problem.

[wiak]

I made a frugal install with the firstribit script and the official Ubuntu 20.04 CD image and it seems to work well.
Well, it boots. There is that.

But I can't log in. The firstrib user is selected automatically, but 'firstrib' doesn't seem to be the right password.
...

My internet connection is too poor right now to check. I've had similar user;password failures with some distros but forget the details. I'll try to test later and come back to you about the matter.

I might not be working further on firstribit for a few months now as I move towards alternative ideas for its provision, but I'll try a ubuntu tonight and let you know if login matters worked for me or not. Might well not...

I am downloading latest Ubuntu iso just now Luluc, but it is big... and late at night here. I suspect Ubuntu set passwords in its usual own initrd, which firstribit replaces with FR initrd. Firstribit script uses the method of changing root passwd and spot and/or firstrib user password I (not being a plural we) first devised in introducing the original firstrib filesystem build system in early 2019. However, that may not be working with the upstream Ubuntu. I personally did also explain back in 2019 how to use mount_chroot followed by umount_chroot to force passwd resetting in these chroot modes (since that was one of the primary purposes of my creating these utilities), but that does need uncompresssion of the root filesystem, which is not exactly convenient when the compressed Ubuntu sfs is of the order of 5GB! May be the only way though. If so, better will be to use a specially make FirstRib-based Ubuntu distro such as the Ubuntu Noble variant I have been working on at home. I haven't published that yet, since still working on it, and I am currently only using Sway/Wayland with it, though KDE would likely be simple to do instead since, like XFCE, the upstream KDE dev team of Ubuntu (probably) make such distros almost trivial to get working reasonably smoothly out-of-the-box. Making KDE better than that out-of-the-box format takes considerable extra work however. But first I wait on Ubuntu iso download to check what current firstribit can do with it. No chance at all I can ever test all firstribit build-capable distros for that passwd issue, and no chance at all I will - but checking situation per your request for this Ubuntu iso case. Will report back tomorrow even if I don't also provide a fix (since my uncompress following by chroot 'trick' would be painful for this case).

Actually, there is another mechanism involving FR initrd overlays that I sometimes employ instead to deal with particularly difficult matters such as, maybe, Ubuntu perhaps using software to discourage setting a root password. I will think about that too to see if might be applicable in this case - I may already have done so in the past, but I forget now so will rethink the matter.

[Luluc]

@wiak

I absolutely appreciate your interest and effort, but I think I must suggest that you drop that goal and forget about it. I am not that interested anymore. I mostly wanted to see what firstribit could do. I wanted to see how much I would be able to customize my own installation and well, tinker with it. But none of that is really important. If you still want to investigate it for the sake of your own project then sure, go ahead by all means. And if you do, I will heed whatever advice you have to provide and try again and get back to you with my reports of success or failure, hoping that it will help you improve your project. But if you're spending your time on this because of me, then I suggest you forget about it.

Moreover, whether it matters or not, I am not interested in the latest Ubuntu. I like Focal Fossa because of old packages. If I were to use very new stuff, I'd sooner go with pure Debian or Spiral. Like I said, Spiral/firstribit failed completely on me. But do I really want Spiral? What I like about Spiral is
1. It provides a very nice whole-disk encryption installation that pure Debian does not. The official Debian installer is pretty disappointing really.
2. I really like the BTRFS, and Spiral provides a very nice, very BTRFS-aware installation. Everything is installed as subvolumes, even the root (/) directory, and Grub is pre-prepared to be able to load snapshots at boot. I really think that Debian should be providing those things, but anyway...

All those benefits go out the window in a frugal installation though. Besides, I have been using FossaDog and I am 97% happy about it. I'm just not very happy with fonts. Debian has better fonts and fonts matter a mad awful frigging lot to me. I hold a lot of grudge against distros that have bad fonts. Ubuntu could be better in that aspect. For example, the 'Monospace' font I use on Debian and Ubuntu looks short (as opposed to tall) and unpleasant on Ubuntu. I have detected other flaws in Ubuntu. But I digress. The thing is, I will probably just stick with FossaDog and move on.

Thank you very much.