RC7 (STABLE) WeeDogLinux Arch 64 now released

A home for all kinds of Puppy related projects
Message
Author
wiak
Posts: 2040
Joined: Tue 11 Dec 2007, 05:12
Location: not Bulgaria

build_firstrib_initramfs04_004.sh (Revision 0.0.4) uploaded

#226 Post by wiak »

build_firstrib_initramfs04_004.sh (i.e. Revision 0.0.4) uploaded to first post of this thread:

http://www.murga-linux.com/puppy/viewto ... 56#1028956

Changes:

Code: Select all

if any of rdsh0 and/or rdsh1 rdsh2 rdsh3 are specified on grub linux/kernel line the init looks for file 
/mnt/bootpartition/bootdirectory/rdshN.plug
and sources that if not empty. Otherwise it runs busybox job control shell at rdshN code position in initramfs/init script.
You should view the contents of build_firstrib_initramfs04_004.sh to see the four positions in the initramfs/init code where a plugin can be sourced (or a busybox job control debug shell started).

wiak

User avatar
rockedge
Posts: 1864
Joined: Wed 11 Apr 2012, 13:32
Location: Connecticut, United States
Contact:

#227 Post by rockedge »

hello.. I only had the one time experience that after I ran the scripts...with no modifications, that after I booted, xbps-install was completely missing. I deleted everything and started fresh with build_firstrib_initramfs04_s003.sh. Which works nicely and booted cleanly.

on a system built with build_firstrib_initramfs01_ver008pre.sh All the computers network devices including wlan was found and I could immediately connect to the network.

I am about to run the latest version and attempt some experiments.

I have ZoneMInder, Hiawatha 10.9, mariaDB,PHP 7.3.7 running fully functional, on both a 32 and 64 bit versions. They start without xorg running and come in at 17 megs. With Xorg, ZM and LHMP running and 3 cameras configured no motion detection enabled, RAM usage is around 750 megs. With no Xorg running WeeDog is running ZM in 175 megs of RAM. Also these builds use the Puppy Linux Bionic kernels.

I am going to go ahead and use the build_firstrib_initramfs04_s004.sh to construct an OS and will continue to experiment. Also want to use the Void kernel with a ZM setup to check the performance.

over all fantastic results....very stable very responsive cool CPU temps in all the working variants so far

User avatar
rufwoof
Posts: 3690
Joined: Mon 24 Feb 2014, 17:47

#228 Post by rufwoof »

rockedge wrote:over all fantastic results....very stable very responsive cool CPU temps in all the working variants so far
Ditto. For me the temperatures are comparable, as is glxgears (to get glxgears however its not mesa-utils but mesa-demos (xbps-install mesa-demos ... then run glxgears). The repos are great, for instance under Fatdog tilda is a old version, not so with Void.
[size=75]( ͡° ͜ʖ ͡°) :wq[/size]
[url=http://murga-linux.com/puppy/viewtopic.php?p=1028256#1028256][size=75]Fatdog multi-session usb[/url][/size]
[size=75][url=https://hashbang.sh]echo url|sed -e 's/^/(c/' -e 's/$/ hashbang.sh)/'|sh[/url][/size]

wiak
Posts: 2040
Joined: Tue 11 Dec 2007, 05:12
Location: not Bulgaria

#229 Post by wiak »

rufwoof wrote:massive amounts of firmware (portable), accounts for around 300MB of that 512MB I guess.
Yes, that's the main reason why, currently, the hard drive storage used by the system is comparatively large [also Void leaves many/most of its libs unstripped], which is fine by me. For those who want to create a small iso, it will of course be nice to provide a script that strips things down to say Puppy size. That won't be hard to do, I've already experimented doing so with the large number of modules Void by default provides.

I don't have a refined script for that purpose yet, but the method is simple enough, even in bash. A method that works is to use find command on say BionicPup /lib/firmware to generate a recursive txt listing of all the (relatively small amount of) firmware provided there (find command output redirected to say text file Bionic_firmwarelist). Then do the same to generate a similar list for what Void provides in its /usr/lib/firmware (say to Void_firmwarelist). Finally you cut out only the equivalent firmware of BionicPup from what Void offers; in bash the comm utility is excellent for that. Note that comm requires the input files, Void_firmwarelist and Bionic_firmwarelist to be sorted (i.e. using sort) before the comparison:

Code: Select all

comm -23 /tmp/firstrib/sorted_Void_firmwarelist /tmp/firstrib/sorted_Bionic_firmwarelist | xargs rm -rf
https://linux.die.net/man/1/comm

The same algorithm useful for lots of similar purposes (e.g. I originally used it for pruning modules whilst building a much smaller initramfs04).

Here was me generating all_modules list of Void /usr/lib/modules:

Code: Select all

cd ../VoidFull/usr/lib/modules/* && find . | sort>/tmp/firstrib/all_modules
Of course you have to be careful using a script contructed with xargs rm -rf ... but it worked fine for me and safe enough (as long as you get the script correct... or include some protection code) since only used as a one-off prune job.

@rockedge: Once things settle down I hope you could consider working on a firstrib00.plug and/or any extra addon sfs to get your Zoneminder configuration/compile published (or even a final iso). It sounds really good.

wiak
Last edited by wiak on Sun 04 Aug 2019, 01:21, edited 1 time in total.

User avatar
rufwoof
Posts: 3690
Joined: Mon 24 Feb 2014, 17:47

#230 Post by rufwoof »

Boots/runs on the wide range of kit I've tried so far, so not really bothered about the main system having all that firmware. Fine with me also. Modestly longer usb based bootup time isn't really a concern for me.
Attachments
s.png
(27.12 KiB) Downloaded 753 times
[size=75]( ͡° ͜ʖ ͡°) :wq[/size]
[url=http://murga-linux.com/puppy/viewtopic.php?p=1028256#1028256][size=75]Fatdog multi-session usb[/url][/size]
[size=75][url=https://hashbang.sh]echo url|sed -e 's/^/(c/' -e 's/$/ hashbang.sh)/'|sh[/url][/size]

User avatar
rockedge
Posts: 1864
Joined: Wed 11 Apr 2012, 13:32
Location: Connecticut, United States
Contact:

#231 Post by rockedge »

noticed after I modified /etc/rc.local

Code: Select all

# Default rc.local for void; add your custom commands here.
#
# This is run by runit in stage 2 before the services are executed
# (see /etc/runit/2).
/root/my-applications/start_net
startx
at boot WeeDog will put the machine into a desktop, jwm and rox -p default which all starts.
the system is running with out being logged in! whoami reports "root" and I can do everything and setup the desktop and add icons. When I click on rox "home" rox opens in /...reboot and they are there and all works.
I have an xterm terminal start with from /ect/X11/init/initrc that when I use exit will shut down the Xorg server and return to the command line AND the void-linux logon prompt.

Now I use "root" and the correct password and once on the system use startx and xorg starts right up but in now a different desktop. rox-filer opens up in /root all rhe previous setup is gone. So I can set this destop up just fine.

Then reboot -f the system and restart it......the system repeats the first step above and starts in the first desktop I configured and rox-filer opens /...everything is there.....I exit then void-login again, use startx .....the 2nd "root" desktop comes up also still completely configured and rox-filer now starts in /root......

kind of cool actually....it's like the commands in /etc/rc.local circumvents the login procedure.........

User avatar
rufwoof
Posts: 3690
Joined: Mon 24 Feb 2014, 17:47

#232 Post by rufwoof »

From wiak's script comments ...
# The switch_root runs /sbin/init on real rootfilesystem, which actually (ultimately) symlinks to busybox (sysv)init and executes it as PID 1. That busybox init reads file /etc/inittab, which configures init to run boot startup script, which is currently configured to be: /etc/rc.d/rc.sysinit. Should runit-void later be installed, /sbin/init should instead be symlinked to /usr/bin/runit-init, in which case /etc/rc.d/rc.sysinit will not be used.
runit is neat ..
http://www.troubleshooters.com/linux/vo ... .htm#runit
when you hear systemd enthusiasts remarking how systemd frees them from all these gruesome init scripts, remember they're talking about the first-seen-in-1983 sysvinit system, not the 2004-invented runit system. It's like a 20 year old runner bragging that he beat a 75 year old man: The systemd enthusiasts should stop doing this because it really makes them look bad.
[size=75]( ͡° ͜ʖ ͡°) :wq[/size]
[url=http://murga-linux.com/puppy/viewtopic.php?p=1028256#1028256][size=75]Fatdog multi-session usb[/url][/size]
[size=75][url=https://hashbang.sh]echo url|sed -e 's/^/(c/' -e 's/$/ hashbang.sh)/'|sh[/url][/size]

wiak
Posts: 2040
Joined: Tue 11 Dec 2007, 05:12
Location: not Bulgaria

#233 Post by wiak »

rockedge wrote:noticed after I modified /etc/rc.local
...

kind of cool actually....it's like the commands in /etc/rc.local circumvents the login procedure.........
Hmmm... Just wondering if your system has runit installed rockedge or is it using busybox init which through inittab runs rc.sysinit? The reason I'm asking is that I noticed a while back that in rc.sysinit I had put running rc.local script what seemed to me to be too early (prior to udev being run). I meant to change that but forgot about it till I just read your post.

However, if your system is using runit then rc.sysinit isn't being used anyway... so whatever effect you are observing presumably is to do with the way void runit is starting things. I'm not quite sure what you are describing but it sounds a bit weird - I would have imagined login/passwd would have always been requested. ??? Anyway, it may or may not be a small bug that will need addressed.

@rufwoof: Yes, once I read how to use it... I have to say runit is great.

wiak

User avatar
rockedge
Posts: 1864
Joined: Wed 11 Apr 2012, 13:32
Location: Connecticut, United States
Contact:

#234 Post by rockedge »

the root user ends up having 2 separate desktops!

I automated starting JWM and ROX by adding those lines to /etc/rc.local
the system boots perfectly starts both and I am in a desktop that belongs to "root". Everything functions. And no login required.

now I exit the desktop, shutdown xorg and return to the shell...which now is
"void-login:", which I now login as root using the password I have set earlier.
Then I restart xorg with "startx" and now I am in a completely different desktop. rox -p default starts and I have a "home" folder icon...I click this now and rox-filer opens up in /root........the first desktop that starts at the first boot will open "/"......

so there is 2 different desktops both belong to "root". the first only appears at the first system start with the automated start of xorg via startx in /etc/rc.local. If I exit out of it I now must login at the shell prompt...which after a startx presents and entirely different desktop...also belonging to root.

wiak
Posts: 2040
Joined: Tue 11 Dec 2007, 05:12
Location: not Bulgaria

#235 Post by wiak »

rockedge wrote:the root user ends up having 2 separate desktops!

I automated starting JWM and ROX by adding those lines to /etc/rc.local
the system boots perfectly starts both and I am in a desktop that belongs to "root". Everything functions. And no login required.

now I exit the desktop, shutdown xorg and return to the shell...which now is
"void-login:", which I now login as root using the password I have set earlier.
Is that with runit installed rockedge?

Oh, I think I understand. First time up you are starting X via rc.local, second time you drop to login shell, which starts X via "startx", which involves a different desktop. Yes, that's interesting! EDIT: On second thoughts, no I don't know what is going on there!

wiak

User avatar
rockedge
Posts: 1864
Joined: Wed 11 Apr 2012, 13:32
Location: Connecticut, United States
Contact:

#236 Post by rockedge »

Oh, I think I understand. First time up you are starting X via rc.local, second time you drop to login shell, which starts X via "startx", which involves a different desktop.
Yes, exactly. You can try it by adding "startx" to /etc/rc.local, then reboot....do something then exit X and you will come to the void-login: shell. Then login as "root" and use startx again

I just repeated it on a brand new 64 bit version

wiak
Posts: 2040
Joined: Tue 11 Dec 2007, 05:12
Location: not Bulgaria

#237 Post by wiak »

Hi rockedge,

I don't have X installed on my WeeDog at the moment since just working on lower down init matters.

I note startx script header says:

Code: Select all

#!/bin/sh

#
# This is just a sample implementation of a slightly less primitive
# interface than xinit. It looks for user .xinitrc and .xserverrc
# files, then system xinitrc and xserverrc files, else lets xinit choose
# its default. The system xinitrc should probably do things like check
# for .Xresources files and merge them in, start up a window manager,
# and pop a clock and several xterms.
I imagine that when you actually login as root, startx will find a .xinitrc file in /root, which will contain code to set things up in a certain way, whereas when you just startx from rc.local, bypassing login, then you are not in /root directory and startx does not find any ./xinitrc file, so things will be set up differently. But as I say, I can't check that just now, so just a guess really. It is interesting that doing startx from rc.local allows you to bypass login; that wouldn't be the usual method of doing so (usually done when agetty starting with "-a/--autologin root" option).

wiak

wiak
Posts: 2040
Joined: Tue 11 Dec 2007, 05:12
Location: not Bulgaria

#238 Post by wiak »

I don't want to add much more to initramfs04/init since I want to keep it simple and as unbloated as possible.

However, I am currently working on providing a [EDIT] 'changes' in RAM only mode, which is no-persistence mode (but can, if wished, usefully use previous upper_changes directory, by simply renaming that to NNupper_changes, for example 90upper_changes as one of the read-only middle layers. Note that I am not myself interested in a copy2ram mode (sfs copying to RAM), which simply uses too much RAM with little end-benefit in my opinion; Linux does a pretty good job of caching anyway...

At the same time, I'm also implementing a read-only mode, in which the merged overlay result is entirely read-only (so cannot be written to) - that mode is good for making remasters.

And also a mode that allows the upper_changes directory to be stored anywhere (rather than default /mnt/bootpartition/bootdir).

The additional code for these particular alternatives is very simple and if no new mode is specified on grub linux/kernel line then default current /mnt/bootpartition/bootdir/upper_changes will continue to be used.

As far as any more complex possible modes are concerned, which generally would require a substantial amount of additional code, these I feel should only be made available (if at all) as plugins to the relatively straightforward to understand Firstrib initramfs04/init provided. For example, using grub kernel line option rdsh1, results in initramfs/init searching for plugin rdsh1.plug and, if found, sources that plugin code quite early in the provided initramfs/init and effectively thus allows plugging in additional init code of any desired complexity/functionality without having to uncompress and then edit the initramfs cpio archive (though that is also easy to do with modify_initramfs_gz.sh utility of course).

That follows my original design aim/philosophy of what FirstRib is all about. It was intended to be a very flexible user-modifiable build system, designed on purpose as a couple of short simple shell scripts. It is not intended to provide an all-singing/all-dancing desktop user system as its default out-of-the-box build (and is thus very unlike the Puppy woof-CE build system). But I believe that, with FirstRib build system, you do not need to be some kind of Linux guru to relatively easily build a system of whatever complexity you desire; rather, FirstRib WeeDog leverages the power provided by Void Linux native package manager xbps, and not just its repositories (and thus, without user-effort, provides full access to all Void Linux system components/configuration including runit)

One plugin possibility, however:

In terms of flexibility, low-resource-usage, speed and efficiency, I have longterm/years been somewhat a fan of the way tinycore linux saves changes on shutdown via its .filetool.lst and .xfiletool.lst lists, which simply instruct the system what to archive in a tar.gz archive (which then gets untarred on reboot). That is an alternative to merging overlays (which often requires dealing with overlayfs whiteouts and so on) and I may eventually try to implement that tinycore linux mechanism in a plugin for the initramfs, though generally speaking I don't really need that extra myself.

I'm actually planning to soon move to WeeDog as my main desktop system; not because I will have built up a version for my own use that is polished up to the standard of say the XenialDog system I generally use (by fredx181), but because I really like xbps package manager and Void system with runit generally. I already feel I've personally learned/benefited a lot from it so using it daily will certainly strengthen my familiarity with it. Also, owing to the simple KISS nature of FirstRib WeeDog, and thanks to Void Linux rolling release system, I'm confident now that I can keep my WeeDog system updated (whatever shape it takes), without having to rely on the often unlikely iso-upgrades of other distro builds by their developer/creators. No reason iso's couldn't be built however, or simple scripts written for such purpose - I may or may not do any of that, but I think others are more likely to produce more polished WeeDog versions than I will anyway!

wiak
Last edited by wiak on Wed 07 Aug 2019, 21:44, edited 2 times in total.

User avatar
rufwoof
Posts: 3690
Joined: Mon 24 Feb 2014, 17:47

#239 Post by rufwoof »

wiak wrote:However, I am currently working on providing a run in RAM only mode, which is no-persistence mode (but can, if wished, usefully use previous upper_changes directory, by simply renaming that to NNupper_changes, for example 90upper_changes as one of the read-only middle layers. Note that I am not myself interested in a copy2ram mode (sfs copying to RAM), which simply uses too much RAM with little end-benefit in my opinion
Physical isolation (boot from usb, unplug usb once booted) is a great feature IMO. On my 4GB ram laptop, using the wrapper build script I mentioned in a earlier post - so its a single click action to build (vmlinuz/kernel, system with X, chrome, pulseaudio ..etc.) when using lz4 compression is around a 8 minute build time. A quick build time to the latest clean kernel and OS (rolling Void releases) is another great feature. I have seen some issues however, for instance running gparted complains about gparted.bin already being loaded (looks like the script does a grep for gparted and finds a 'grep gparted' return and bombs out; Run gpartedbin directly and it starts up OK). Seeing rockedge's posts got me wondering if perhaps two versions of the system were running concurrently, one via runit and another via init.
Last edited by rufwoof on Tue 06 Aug 2019, 16:51, edited 2 times in total.
[size=75]( ͡° ͜ʖ ͡°) :wq[/size]
[url=http://murga-linux.com/puppy/viewtopic.php?p=1028256#1028256][size=75]Fatdog multi-session usb[/url][/size]
[size=75][url=https://hashbang.sh]echo url|sed -e 's/^/(c/' -e 's/$/ hashbang.sh)/'|sh[/url][/size]

User avatar
rockedge
Posts: 1864
Joined: Wed 11 Apr 2012, 13:32
Location: Connecticut, United States
Contact:

#240 Post by rockedge »

the scripts are showing amazing potential! there is so much room for choice. The ability to make the OS as simple or as fully featured as one needs or wants is well thought out.

I will share some plugin files and perhaps a script to install zoneminder...
I really would like to create a Void package for it......
At least I think that's the case, seeing rockedge's posts got me wondering if perhaps two versions of the system were running concurrently, one via runit and another via init).
I believe this may be the case!


_

wiak
Posts: 2040
Joined: Tue 11 Dec 2007, 05:12
Location: not Bulgaria

#241 Post by wiak »

rufwoof wrote:Seeing rockedge's posts got me wondering if perhaps two versions of the sstem were running concurrently, one via runit and another via init.
I'll look into it. I suspect, like I said, just startx not finding .xinitrc when avoiding login process, but I may be wrong. Starting x from rc.local is probably not a usual practice - like I suggested, modifying the agetty start line would be the way to go normally if you want root auto logged in.

The switch_root code simply runs /sbin/init, which in void filesystem structure is a symlink to /usr/bin/init, which itself is a symlink to EITHER (but not both) busybox init or if runit installed then the symlink is automatically changed to runit-init. So both cannot be happening at the same time. And once runit package installed that symlink always points to runit-init so busybox init and the associated rc.sysinit is simply not involved. Never say never... but I say never on this occasion :-)

I would need more details about gparted. Or does it simply not work in all configurations? I will try it sometime. Really, the system arrangement is so simple most issues should be easy to address. The most powerful feature, IMO, is simply being able to add any directory you like to a middle layer (hence the way NNupper_changes can be used, rather than having to make it into an sfs at first, but the code that sorts that out is simple too.

I've also used the power of that dir-into-layer-code facility to simply load an official Void Linux graphical-based root filesystem (that's the desktop image I posted some time back) and that worked fine too (that uses 'Slim' login manager I think). I have a traditional official full install of Void Linux itself on its own partition, so all I did was copy that into a directory in /mnt/bootpartition/firstrib and then replaced its modules and firmware with those of the newer kernel I was using in FirstRib, and the result booted perfectly with WeeDog initramfs04.gz. So with FirstRib you can work with official Void images, or build something much smaller or honed to whatever underlying root filesystem you wish. The result, though expected, was nevertheless almost amazing to me - it is not usual to be able to take what is actually a full install and change it so simply into a frugal install... exciting watching it boot up (since, despite a feeling it should work, still half-expecting a dreaded kernel crash or switch_root failure).

So that Void Linux full-install being so easily transformed into a WeeDog frugal install working suggests all fine in terms of full compatability (though there may be glitches I don't yet know about of course). Funny thing is, I hadn't even tried using runit prior to that full to frugal boot 'experiment'... I just couldn't see any reason why it wouldn't work (/sbin/init ending up symlinking to runit-init), and, as it turns out, it did work...

wiak

wiak
Posts: 2040
Joined: Tue 11 Dec 2007, 05:12
Location: not Bulgaria

#242 Post by wiak »

wiak wrote:... I am currently working on providing a [EDIT] 'changes' in RAM only mode, which is no-persistence mode (but can, if wished, usefully use previous upper_changes directory, by simply renaming that to NNupper_changes, for example 90upper_changes as one of the read-only middle layers. Note that I am not myself interested in a copy2ram mode (sfs copying to RAM), which simply uses too much RAM with little end-benefit in my opinion; Linux does a pretty good job of caching anyway...

At the same time, I'm also implementing a read-only mode, in which the merged overlay result is entirely read-only (so cannot be written to) - that mode is good for making remasters.

And also a mode that allows the upper_changes directory to be stored anywhere (rather than default /mnt/bootpartition/bootdir).

The additional code for these particular alternatives is very simple and if no new mode is specified on grub linux/kernel line then default current /mnt/bootpartition/bootdir/upper_changes will continue to be used.
I have the above working in initramfs/init (just need to bolt it into the build initramfs script now).

Simple it was in terms of code needed (around 20 new lines of code in one block plus some overall code reorganisation), but came with xino issue. Not a lot of docs on that since all happening at kernel level so complete understanding would require studying kernel overlayfs C code (a difficult task indeed). I found working solutions but on try and see basis of course.

EDIT: Regarding xino (which can effect matters on overlayfs arrangements, where different filesystems being used): https://www.gnu.org/software/libc/manua ... nings.html
When you read the attributes of a file, they come back in a structure called struct stat.
... amongst various attributes, stat contains:

ino_t st_ino: The file serial number, which distinguishes this file from all other files on the same device.

dev_t st_dev: Identifies the device containing the file. The st_ino and st_dev, taken together, uniquely identify the file. The st_dev value is not necessarily consistent across reboots or system crashes, however.
I've found that having overlay mount option xino translation table on, mucked things up when upper_changes directory placed on different filesystem to underlying firstrib_rootfs, so needed mount option xino=off.

EDIT: As far as copy ALL to RAM feature, which is not the same thing as changes only to RAM since copy all to RAM would include any NNfilesystem (sfs or uncompressed), I'm still thinking of whether to implement that in default initramfs/init or as a plugin. Each new addition does bloat the build script more than I like, but to make it easier to read I continue for the main part to avoid functions so buildscript can be read in nice linear fashion without having to jump back and forwards in the script to see what each function does - the only exception being the _rdsh plug in (or debug shell function), since that is repeatedly used in the code.

A copy ALL to RAM mode, as I understand it (though personally almost never use it because it is slow and my usual dev system has only 2GB RAM sadly - yes I should buy an old extra RAM stick for it...), is just a matter of mounting a tmpfs (or using an existing one) and if copy2ram requested, cp all the NNfilesystems to that tmpfs and then mount them from there rather than from the original media - uses a fair amount of RAM (especially when the NNfilesystem is an uncompressed directory) but I guess a lot of systems having plenty RAM to spare nowadays and on smaller RAM systems user can just arrange things so very few sfs files and only very small uncompressed filesystems used (or don't use copy2ram at all since optional) - anyway copy2ram not done yet.

wiak
Last edited by wiak on Thu 08 Aug 2019, 07:06, edited 16 times in total.

User avatar
rockedge
Posts: 1864
Joined: Wed 11 Apr 2012, 13:32
Location: Connecticut, United States
Contact:

#243 Post by rockedge »

I can post different htop readouts from this version to demonstrate ->

Image

wiak
Posts: 2040
Joined: Tue 11 Dec 2007, 05:12
Location: not Bulgaria

#244 Post by wiak »

Just a comment, now that the FirstRib WeeDog system is becoming more 'mature'.

There are basically two ways of documenting enhanced builds that work with FirstRib build system:

1. A wrapper script that runs FirstRib scripts and does extra stuff around that result (so it is an external methodology). That is similar to what Fredx181 does with his mklive-stretch and similar builds using debootstrap internally and then doing a chroot inside the wrapper to add new applications or whatever.

2. Using builld_firstrib_rootfs firstrib00.plug plugin facility (and the build rootfs script also allows for alternative plugin names). That is an internal methodology. The difference is that it leverages the fact that build_firstrib_rootfs script already uses a chroot so no external chroot wrapper required. Whatever code gets added to the plugin (e.g. xbps-install some-new-package... etc etc etc) gets done inside the chroot build of the main build_firstrib_rootfs script itself. Where the same 'recipe' can be providided by a plugin rather than a wrapper, then that would be more efficient or at least neater. Having said that, either can be used (FirstRib flexibility) and sometimes, for other reasons, a combination of using both a wrapper script and a firstrib plugin may prove useful.

And the build_firstrib_initram script also has its rdsh.plug plugin facility, which effectively allows a user to plugin their own init for the initramfs to use (or some extra init code for insertion into the default init build). To some/large extent, that removes some of the possible development burden from myself, since a user/developer can modify the resulting system for their own wishes/requirements without needing the default released build scripts themselves altered (and a library of user-plugins could be usefully created for use by others).

And Void Linux repos/xbps/runit system removes an even greater burden from the maintenance needs of FirstRib Weedog since Void provides the rolling distro mechanism out-of-the-box. So, as long as Void has a long lifetime (and Void Linux upstream auto-compiling-build system should now ensure that) then so too does WeeDog - should be able to rely on it for years... unlike systems that continually need new builds every year or two in order to keep up with the times. Result is less time wasted trying to keep system up to date, or endlessly reconfiguring it or replacing it: gives more time to just sit back, drink coffee, and enjoy the system. And, with suitable wrapper/plugin combinations, rebuilds become just a one-click operation anyway (and often only a relatively few minutes to build to completion).

Last, but not least, the plugin/wrapper facilities allow a user/developer the satisfaction of building their own complex-as-they-wish specialised system, which can then be published as either a 'recipe' or, via a simple script, an iso or similar for others to use.

Actually, the very last, perhaps the raison d'être for FirstRib's design, is that the simplicity of the scripts hopefully makes them educational - re: how such systems work... (including for myself since I forget how to do things after a few months so can just re-read the scripts to remind me).

wiak

User avatar
rockedge
Posts: 1864
Joined: Wed 11 Apr 2012, 13:32
Location: Connecticut, United States
Contact:

#245 Post by rockedge »

first example is the initial boot with /etc/rc.local starting a script for network connection and startx

Image

http://rockedge.org/images2/2019-08-07- ... _scrot.png


this second screenshot shows the system after exiting X and logging in at the void-login: prompt and using startx from the shell ->

Image

http://rockedge.org/images2/2019-08-07- ... _scrot.png

Post Reply