RC7 (STABLE) WeeDogLinux Arch 64 now released

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

RC7 (STABLE) WeeDogLinux Arch 64 now released

#1 Post by wiak »

Version 2.0.8 -RC7 (STABLE) release CHANGES 14Jun2020:

Developer option StartMenu choice 'exitX' removed.

wiakwifi modified to work from StartMenu -> Applications -> Internet|System -> Internet XXXXXX

"Internet Reconnect" menu choice now: "Internet Connect or Reconnect".
"Internet Reset" menu choice now: "Internet Connect New"

The above StartMenu Internet XXXXXX menu choices now work for either/both root user or special (wheel group) user weedog.
--------------------------------------------------------------------------------

Download/install details from the forum at: https://weedoglinux.rockedge.org/viewto ... p=208#p208

wiak

Further discussions will take place, and feedback will be answered, on above forum.

-------------------------------------------------------------------------------------------------
OLD VERSIONS but still important documentation/information follow:
LATEST RELEASES ARE:
build_weedog_initramfs05_s207.sh
Previous Release Announcement (21Sept2019) and details remain very relevant:
http://www.murga-linux.com/puppy/viewto ... 92#1037492

build_firstrib_rootfs_104.sh
The earlier release (17Sept2019) details remain most relevant:
http://www.murga-linux.com/puppy/viewto ... 51#1037251
-------------------------------------------------------------------------------------------------------

Please see next post and those after for earlier docs (including those for model01 chroot version of the initramfs) and downloads for FirstRib utilities (such as mount_chrootXXX.sh, umount_chrootXXX.sh, modify_initramfs_XX.sh etc).

NEW MULTI-DISTRO WeeDog Release announcement. Currently builds flavours: void, ubuntu, debian, devuan (Arch Linux flavour under development)

For latest CHANGES, including optional inram00.plug use for zram swap, see here:

http://www.murga-linux.com/puppy/viewto ... 69#1035869

For DOWNLOADS of MAIN BUILD SCRIPTS, see foot of linked post:

http://www.murga-linux.com/puppy/viewto ... 24#1035524

distro can currently be one of: ubuntu, debian, devuan, void

release can currently be one of: oldstable, stable, testing, unstable; or xenial, bionic, dingo; stretch, buster, sid; ascii, ceres, beowulf

arch can currently be one of: amd64, i686 (i386 if debian/ubuntu), arm64 (though build_weedog_initramfs needs modded for arm64 use).

DOWNLOAD locations for some useful build system utilities such as for modifying initramfs and others for facilitating chroot alterations of firstrib_rootfs are at this post:

http://www.murga-linux.com/puppy/viewto ... 57#1028957

DOWNLOAD locations for additional/optional USER-CONTRIBUTED firstrib plugins, utilities and howtos:

The default build_firstrib_rootfs script only produces a simple root filesystem. However, it is normal practice to extend that build using a pre-created firstrib plugin, which allows the final distro to be as simple or complex as the plugin creator allows. I am collecting user-contributed plugins (howtos and utilities) and listing their download locations at the following page post:

http://www.murga-linux.com/puppy/viewto ... 29#1029029

Please contact me concerning omissions and updates to user contributions thereafter, wiak

Please read the remainder of current first post for extra information.

Note that the previous, older model04 of FirstRib WeeDog files/details can be found at: http://www.murga-linux.com/puppy/viewto ... 18#1029018

The FirstRib WeeDog Linux build system

consists of two simple shell scripts, FirstRib build_firstrib_rootfs_XXX.sh, which relies on upstream distro repos, and (independent WeeDog initramfs) build_weedog_initramfsXX_sXXX.sh,

plus some optional plugins (e.g. firstrib00.plug*) and helper utilities (e.g. modify_initramfsXXX.sh, mount_chrootXXX.sh etc).

The system builds rapidly, is easily user-modified, and is very efficient.

WeeDog initramfs is really the key component to WeeDog distro (i.e. the controlling backend of the system)., which provides its special rollback upper_changes type facilities via its numbered sfs or numbered uncompressed directories layers.

FirstRib itself is really just the default build_firstrib_rootfs part. The result of which, like most distros nowadays on murga forum, depends also on upstream repos for its user frontend functionality (i.e. packages...). FirstRib build rootfs is defined by its key design feature of "busybox static plus native package manager" with extension via plugin module (firstrib00.plug). Best is when native package manager is usable on its own in FirstRib, such as Void xbps can be, otherwise latest FirstRib obtains it, either as native package manager (preferred, and as in current version), or via some kind of bootstrap skeleton, such as debootstrap or arch-bootstrap.

The default build creates a minimum WeeDog Linux distro (after which you can install bash, coreutils, X desktop components etc). A fully built up WeeDog Linux distro, requires a firstrib00.plug creator, who can provide the full desktop experience, or otherwise, and my hope is that the whole community can feel able to involve themselves in such builds of their own or helping others, producing multiple WeeDog Linux versions.

You can also take an existing root filesystem of some distros (e.g. Slackware) and "WeeDog-it" such that the resulting booted distro provides all WeeDog features in terms of rollback capability and changes=RAM and so on. Example of frugal installed WeeDog running Slackware:

http://www.murga-linux.com/puppy/viewto ... 11#1035211


QUICK BUILD/TEST INSTRUCTIONS

To build and run default WeeDog

Simply copy the two scripts, build_firstrib_rootfs_XXX.sh and build_weedog_initramfsXX_sXXX.sh to an empty directory (the /mnt/bootpartition/bootdir you will finally boot from would be a good choice, but any empty dir will do).

Though you can add extra stuff later, if you want to use target distro's Linux kernel and firmware (recommended), it would be advantageous to also copy the attached relevant distro plugin file firstrib00.plug_distro_release_arch to same directory (the plugin causes build_firstrib_rootfs_XXX.sh to also install target distro's linux kernel and firmware/modules as required when using build_firstrib_initramfs05_sXXX.sh <distro_name>). You can edit firstrib00.plug_distro_release_arch if you wish to add extra packages and code if you wish (anything, including packages and configs for full desktop build) or you can easily add extra stuff later. See below link for some firstrib00.plug* details (early info was for Void Linux, but plugins now available also for ubuntu, debian and devuan):

http://www.murga-linux.com/puppy/viewto ... 04#1034404

Then, on an Internet-connected host Linux system (e.g. Puppy or DebianDog), execute:

./build_firstrib_rootfs_XXX.sh distro release arch plugin_name

For example:Here is quick info on the two new scripts:

Code: Select all

# ./build_firstrib_rootfs_XXX.sh --help

Usage:
./build_firstrib_rootfs_XXX.sh distro release arch [filename.plug] or
./build_firstrib_rootfs_XXX.sh distro release arch [filename.plug.tgz]
NOTE WELL that primary plugin (e.g. firstrib00.plug) is not a script,
it is simply a list of commandlines without any hash bang shell header.
Also NOTE that a tgz (or tar.gz) form of plugin must contain the primary
plugin. It can also contain a plugins directory, which itself contains
other plugins and/or executable scripts. These get copied into 
firstrib_rootfs/tmp so that primary plugin can subsequently source or
execute the plugins dir contents from /tmp/plugins/*
A primaryplug.tar.gz plugin should contain two first level items in its
archive: primaryplug.plug plugins/
For example, firstrib00.plug.tar.gz should contain firstrib00.plug
alongside directory plugins/

-v --version    display version information and exit
-h --help -?    display this help and exit
FOR EXAMPLE: NOTE: I 'think' I tested ubuntu bionic amd64 with WeeDog initramfs, but I've been doing so many tests I can't remember - hopefully fine. I certainly tested debian buster amd64 and devuan beowulf amd64. I did not test any i386 builds (but did build an arm64 firstrib_rootfs, but can't as yet build initramfs for that till I modify the script further with arm64 busybox alternative - anyway, I don't have any arm64 hardware myself)...

Code: Select all

./build_firstrib_rootfs_XXX.sh ubuntu bionic amd64 firstrib00.plug_ubuntu_bionic_amd64
FOR SOME EXTRA DETAILS on build_firstrib_rootfs, see post:

http://www.murga-linux.com/puppy/viewto ... 51#1037251

Code: Select all

# ./build_weedog_initramfs05_s201.sh.tar --help

Usage:
./build_weedog_initramfs05_sNNN.sh [OPTIONS]

-v --version    	display version information and exit
-h --help -?    	display this help and exit
distro_name		(i.e. void, ubuntu, debian, or devuan)
			auto-insert Linux distro modules/firmware into
			initramfs and output associated Linux kernel;
			all of which must be pre-installed into
			firstrib_rootfs build.

Optional second argument is mksquashfs compression (or "default")
Optional third argument is "huge" (or "default") initramfs
"huge" includes 01firstrib_rootfs.sfs inside initramfs/boot/initramfsNN
Optional fourth argument is busybox_url (in case, e.g. arm64 required)

EXAMPLES:
./build_weedog_initramfs05_sNNN.sh void  # or debian, ubuntu, devuan etc
./build_weedog_initramfs05_sNNN.sh void "-comp lz4 -Xhc"
./build_weedog_initramfs05_sNNN.sh void default huge

Once booted, set up shadow passwords with pwconv and grpconv and
REMEMBER to set: passwd root
FOR SOME EXTRA DETAILS on build_weedog_initramfs05, see post:

http://www.murga-linux.com/puppy/viewto ... 92#1037492

That second script creates the initramfsXX.gz and spits out the vmlinuzXXX (that you could rename to simply vmlinuz) that you need to boot the resultant WeeDog system.

The default build sometimes only takes a few minutes to complete ready for booting and test!

Example grub4dos menu.list:

Code: Select all

 title FirstRib (Void Linux Flavour)
root (hd0,0)
kernel /firstrib/vmlinuzX.XX usbwait=12 bootfrom=/mnt/sda1/firstrib
initrd /firstrib/initramfs05.gz
NOTE (revision s204 plus): If no usbwait parameter given (best) then weedog waits on bootpartition being successfully mounted, otherwise the delay is fixed at usbwait=NN value in seconds.

The remainder of the information below was specifically for WeeDog Void Linux flavour, but some may be useful whilst working with one of the several other new WeeDog flavours.

Network Connectivity

Once booted, for simple setting up ethernet or wifi manually from commandline, refer to post:

http://www.murga-linux.com/puppy/viewto ... 22#1031022

Audio setup

Sound modules should be loaded automatically on boot with most recent FirstRib initramfs, however, for more help on getting alsa and/or pulseaudio to work refer to:

http://murga-linux.com/puppy/viewtopic. ... 88#1031588

Or if you want to immediately build a Void Linux base system

see this post here:


http://www.murga-linux.com/puppy/viewto ... 49#1029049

FirstRib Void Flavour comes installed with full Void Linux package manager xbps

https://wiki.voidlinux.org/XBPS#Basic_Usage

Though WeeDog starts as a boot to commandline system, you can use xbps (e.g. xbps-install, xbps-remove, and xbps-query packages) to easily build a complete desktop system. Forum member rockedge has provided some nice screenshots in this thread of desktop versions he has created (including complex ZoneMinder compile/install) using the older initramfs build, and newer builds (rufwoof and rockedge) too:

http://murga-linux.com/puppy/viewtopic. ... 19#1034419

http://murga-linux.com/puppy/viewtopic. ... 47#1034447

and fredx181 provided the following useful related post (but also should xbps-install ncurses-base for bash backspace to work at commandline):

http://www.murga-linux.com/puppy/viewto ... 18#1031218

The most efficient way to locate packages available from Void Linux repositories is per the following Void wiki page:

https://docs.voidlinux.org/xbps/packages/files.html
============================================================================

In more detail and more generally:

It is advised to read the rest of this thread and the following couple of posts...

At terminal commandline opened at that directory, enter commands:

Code: Select all

./build_firstrib_rootfs_XXX.sh  # where XXX is either an x86_64 or i686 version depending on your host Linux.

followed, once finished, by:

./build_firstrib_initramfs0X_sNNN.sh  [arguments]
# for latest switch_root initramfs model 0X.
# void, debian, ubuntu, or devuan is first argument, which uses the upstream distro's kernel/modules/firmware from firstrib_rootfs install of linuxX.XX
Refer to: ./build_firstrib_rootfs_XXX.sh --help for details on the arguments
To boot WeeDog (using a previously installed grub4dos or grub2 boot loader)

Copy the following automatically built components (named as shown) to your /mnt/bootpartition/bootdir of choice (e.g. /mnt/sda2/firstrib):

Code: Select all

vmlinuz (or vmlinuzX.XX etc if using Void Linux kernel)
Note that for vmlinuz can use appropriate 32 or 64 bit vmlinuz from BionicPup for now if you wish. If using that case you also want a modified/processed copy of its zdrvXXX.sfs.

For some extra information on using the Void Linux kernel see post:

[url]http://www.murga-linux.com/puppy/viewtopic.php?p=1033007#1033007[/url]

[b]If using Void Linux kernel (preferred way forward)[/b], the built firstrib_rootfs needs to at least include xbps-install: linux or linuxX.XX (currently linux4.19), ncurses-base, and linux-firmware-network, and optional small extra wifi-firmware. Or simply install ncurses-base, and template: linux (which also brings nvidia, amd, i915 and more graphics drivers).  [b]You can install these extras via[/b] ./mount_chroot.sh on your host build system (i.e. in a chroot, followed by exit, and then ./umount_chroot.sh).
 
[b]NOTE WELL:[/b] For initramfs05, if using BionicPup kernel instead of Linux Void kernel, it is no longer sufficient to simply rename e.g. Bionicpup zdrv. Rather, you need to convert the zdrv sfs by placing it in same directory as utility zdrv_convert.sh and running command:
	./zdrv_convert.sh <filename of Puppy zdrv>
from the same directory you store a copy of BionicPup zdrvXXX.sfs

initramfs05.gz

NNfirstrib_rootfs.sfs or NNfirstrib_rootfs uncompressed directory
  where, NN is usually made 01 (for lowest layer) but can be 01 to 99.
-------------------------------------------

NOTE WELL SPECIAL FirstRib feature:
 Instead of or in addition to sfs files you can instead use uncompressed directories containing what would otherwise be the content of such squashed filesystems. For example, instead of providing say 01firstrib_rootfs.sfs for use as lower layer during boot you can instead provide a directory of name 01firstrib_rootfs that contains what would be the unsquashed contents of that sfs file.

The same applies to ANY additional sfs you might want to also load at boot time: you can alternatively use a directory containing what would otherwise be the uncompressed contents of the sfs instead.
You can mix sfs files and unsquashed contents of other sfs files for boot-time layer mounting.
Whilst taking up more disk space, this facility makes editing of individual layers easy when systemis not in use. It also allows a user to easily implement a rollback feature: 
   any upper_changes directory can be renamed in the form NNupper_changes (e.g. 50upper_changes) such that it will be loaded read-only in appropriate NN-signified layer and a new read-write upper_changes directory will be auto-created on next boot. Alternatively, for similar purposes,  upper_changes can be made into a squashed filesystem named in the form NNupper_changes.sfs
You can thus arrange to rollback as far as you like by simply removing current rw upper_changes dir.

Layer "upper_changes" contains changes which are bind mount to chosen partition save directory
Layer "/mnt/layers/merged" contains the overlay result of all above layers merged together 
Initramfs/init does a switch_root to that real rootfilesystem, /mnt/layers/merged
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.
If provided, 00firstrib_firmware_modules.sfs is also loaded and available.
----------------------------------------------------------
You need to specify: bootfrom="<location>" in grub configurations
  where, for example, location can be the likes of /mnt/sda1/firstrib or wherever...
In grub configs you can also specify usbwait=delay_in_seconds. e.g. usbwait=10 for slow boot devices,
You can also specify rdsh0 and/or rdsh1 rdsh2 rdsh3 on grub linux/kernel line to source initramfs/init plugin /mnt/bootpartition/bootdir/rdshN.plug or to start debug shell if plugin doesn't exist or is empty.

On grub linux/kernel line you can now specify upper_changes save location:
There are four alternative "changes=" modes: empty arg, changes=RAM, changes=readonly, changes="path2dir"
1. No changes argument on grub kernel line: Use upper_changes in /mnt/bootpartition/bootdir
2. RAM: All changes go to RAM only (/mnt/layers/RAM/upper_changes). i.e. non-persistent
3. readonly: overlay filesystem is rendered read only so it cannot be written to at all
4. path2dir: store upper_changes in specified path/directory at upper_changes subdirectory

[size=18][b]****NEW (in build initramfs Revision 1.0.2 and above):[/b][/size]

[b]The trim modules code in the initramfs/init (i.e. modprobe -r etc...) now force keeps ehci, xhci, and sdhci modules[/b] to ensure boot ability of usb-connected devices (i.e. previously could get kernel panic on kernel unable to switch_root to /sbin/init).

[b]Can now externally change that trim modules code section via plugin modules_remove.plug[/b]. If empty file of that name put in /mnt/bootpartition/bootdir, the modules will not be trimmed at all. Alternatively, any code placed in that plugin will be used instead of the default initramfs/init modules trim code (allowing easy fix of any such issues).

[b]From Revision 1.0.0 onwards:[/b]
grub kernel-line copy2ram option, which 
causes all NNsfs, NNdirs, and rdshN.plug files to be copied to RAM tmpfs
and mounts the NNsfs and/or NNdirs from there. One result of that is
that when either of the following grub kernel-line option combinations
is used, the bootdevice (e.g. usb stick) can be umounted and ejected:

1. changes=RAM at same time as copy2ram
   (upper_changes then stored only in RAM: non-persistent)
2. changes=readonly at same time as copy2ram
   (also only using RAM and writes not allowed) 
3. changes=<path to changes directory> specified, where
   changes_partition is different from initial bootpartition
   (since bootdevice then not being used it can be unmounted).

Example grub4dos menu.lst and grub2 grub.cfg entries

Examples show using (hd0,0) i.e. /dev/sda1 boot partition of harddrive
Change following to the drive boot partition you are actually using
This example is for slow boot device, hence using optional usbwait value
The bootfrom parameter is required and must be accurate:

Code: Select all

   For grub4dos
   Example shows using (hd0,0) i.e. /dev/sda1 boot partition

   title FirstRib (Void Linux Flavour)
   root (hd0,0)
   kernel /firstrib/vmlinuzX.XX bootfrom=/mnt/sda1/firstrib
   initrd /firstrib/initramfs04.gz

   For grub2 (but change hd0,msdos1 to boot partition you actually use):

   menuentry 'FirstRib on /dev/sda1' {
     set root='hd0,msdos1'
     linux /firstrib/vmlinuzX.XX bootfrom=/mnt/sda1/firstrib
     initrd /firstrib/initramfs04.gz
   }

Note: if any of rdsh0 and/or rdsh1 rdsh2 rdsh3 rdsh4 rdsh5 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.

Example: grub4dos that specifies storing upper_changes directory on a different partition:

   title FirstRib (Void Linux Flavour)
   root (hd0,0)
   kernel /firstrib/vmlinuzX.XX bootfrom=/mnt/sda1/myfirstrib changes=/mnt/sda2/firstrib2
   initrd /firstrib/initramfs04.gz
   
Can also use:

changes=RAM (for no persistence).
changes=readonly (for a readonly system, so no writes allowed).
Leaving changes out altogether results in /mnt/bootpartition/bootdir/upper_changes being used.

copy2ram
(causes all NNsfs, NNdirs, and rdshN.plug files to be copied to 
RAM tmpfs and mounts the NNsfs and/or NNdirs from there).
altNN=path2dir # alternative location for NN sfs/dir files
Shutting-down/re-booting the default base system from the commandline:

Use commands:

Code: Select all

poweroff -f  # for forced shutdown
reboot -f  # for forced reboot
For more information about FirstRib, please refer to the thread posts that follow this one

ALSO, some of the build scripts contain built-in documentation in the form of comment blocks (especially at immediate beginning and immediate end). Please read them.

In particular, for more information on build_firstrib_rootfs_XXX.sh (which can also be used inside a Linux host chroot using provided mount_chroot.sh and umount_chroot.sh utilities), and on firstrib00.plug build plugin facility refer to post:

http://www.murga-linux.com/puppy/viewto ... 57#1028957

You can also refer to: http://github.com/firstrib/firstrib

Note that, I have not pruned the system for size.

By default Void provides many libs un-stripped, includes docs and man pages for each package, and keeps a copy of downloaded .xbps install files under /var/cache/xbps. Leaving these in helps with future development but bloats the size somewhat.
You can of course strip these parts out in your own experiments/designs based on FirstRib.
Also, void packages are all archived in /var/cache/xbps; these can be removed.
Finally, Void provides a LOT of firmware. That could also be pruned down and I may work on a script to do that pruning later, but that is not a priority for my own needs - even a ten year old computer generally has plenty storage space anyway and large hard disc storage has nothing to do with RAM used (WeeDog tends to be very efficient in that regard).

For those interested, code for last released chroot initramfs model01 can be found at following link:

https://github.com/firstrib/firstrib/bl ... r008pre.sh

wiak

In practice all firstrib-related scripts provided are to be used, per normal disclaimer: at your own risk.
Last edited by wiak on Sun 14 Jun 2020, 10:03, edited 290 times in total.

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

FirstRib utilities. For example: mount_chroot, umount_chroot

#2 Post by wiak »

PLEASE FIND CURRENT FirstRib Utilities (mount_chroot, modify_initramfs etc) attached to foot of this older post and refer to the post immediately after this one for more details


wiak

In practice all firstrib-related scripts provided are to be used, per normal disclaimer: at your own risk.
Attachments
modify_initramfs_gz.sh.tar
remove the dummy tar and chmod +x
(1.68 KiB) Downloaded 447 times
modify_initramfs_gz2xz.sh.tar
remove the dummy tar and chmod +x
(1.71 KiB) Downloaded 462 times
modify_initramfs_xz.sh.tar
remove the dummy tar and chmod +x
(1.69 KiB) Downloaded 456 times
modify_initramfs_xz2gz.sh.tar
remove the dummy tar and chmod +x
(1.68 KiB) Downloaded 493 times
mount_chrootver007.sh.tar
remove the dummy tar and chmod +x
(1.53 KiB) Downloaded 522 times
umount_chrootver007.sh.tar
remove the dummy tar and chmod +x
(845 Bytes) Downloaded 589 times
Last edited by wiak on Wed 18 Dec 2019, 05:31, edited 37 times in total.

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

how to use firstrib_rootfs in chroot on a Linux host syste

#3 Post by wiak »

This post contains earlier documentation that is still relevant (particular on how to use firstrib_rootfs in a chroot on host Linux system via ./mount_chrootXX.sh and ./umount_chroot.sh

NOTE that (past/some-still-current) FirstRib Build script files are also archived in this post.

See this next link for some info about firefox with sound:

http://murga-linux.com/puppy/viewtopic. ... 88#1031588

Alternatively, see below for how to use firstrib_rootfs under a chroot running on a host Linux system.

Miscellaneous Notes

The rootfs differs slightly for 32bit i686 builds and 64bit x86_64 builds so there are two build_firstrib_rootfsXX scripts provided (one for each). Now, however, the initramfs creation script is identical for 32bit and 64bit builds (so only one build_firstrib_initramfsXX script needs downloaded. Note also that, no overlayfs_moduleXXXX.tar.gz is needed or downloaded any more. Instead, that overlayfs module should be provided in firstrib_firmware_modules.sfs (or built directly into kernel used). Note also that, if using firstrib_firmware_modules.sfs, it must contain any firmware required (even if such firmware also build directly into the kernel); on my system I therefore needed to add firmware for iwlwifi into the BionicPup32 zdrv squashfs before using it (didn't need to do that when using BionicPup64 zdrv since iwlwifi firmware already in there for my system; an alternative is to add extra firmware to upper_changes/usr/lib/firmware).

FirstRib provides a small Linux rootfs buildsystem shell script containing only around 40 lines of simple code
(the rest of the script being comments/documentation, which you are advised to read).


The build rootfs script, which can be run on most any modern Linux host system, builds a new small Linux system, taking only a few minutes to download and complete the basic build, which can then also be used from the host system or booted independently via a suitable initramfs. Aside from any bug-fixing, I intend keeping the build script very simple so it is easy to be read and understood by users. i.e. without error checking or convoluted code complexities (despite temptations). If anyone wants to use firstrib build script as an exemplar for a more complicated version, they are welcome to fork it of course. I may, however, later produce a small, separate, simple frontend gui to build_firstrib_rootfs*.sh as a convenience. A small simple build_firstrib_initramfs script for a suitable initramfs is also being worked on.


FirstRib rootfs (and bootable WeeDog) starts as a busybox-based commandline system but absolutely easy for user to add full X desktop GUI too

This first version uses Void Linux repositories and package management system xbps.

FirstRib has been designed (simple small script) for learning/experiment purposes, to encourage both non-guru-devs and guru-devs involvement (though experienced hands much appreciated of course, thanks), but since it contains a full dependency resolving package manager, you can build it up to anything you like... (with the additonal help of googling/experimenting etc... that's the point - simple beginning). Of course, for a Void Linux system, a person could simply begin with a full Void Linux rootfs download straight away, but that would defeat the purpose of FirstRib's tiny, simple buildscript start.

Some details about FirstRib (Void Linux flavour) package manager xbps:

Xbps is simple to xbps-install, xbps-remove, and xbps-query (search) packages. For some details see:

https://wiki.voidlinux.org/XBPS#Basic_Usage

You can find plenty of other Void documentation here: https://wiki.voidlinux.org/Main_Page
and reddit forum here: https://www.reddit.com/r/voidlinux/

Using the same design concept, I may later produce alternative FirstRib flavours for different
repo/package_manager usage.

FirstRib build system provides optional modular plugin facility and
ability to specify void repo base address to use per below description:


You can specify the url base address of the void repo you want to use by creating an entry in optional text file "firstrib.repo". For example:

Code: Select all

repo=http://alpha.us.repo.voidlinux.org/
You can also now use a text file "firstrib00.plug" to specify additional commands you want undertaken in the chroot part of the build. For example:

Code: Select all

xbps-install -y coreutils file mc
firstrib00.plug can contain as many commandlines as you wish done. If no firstrib.repo or firstrib00.plug files are provided, the firstrib build script will work by default as it did for previous version.

NOTE that you can use alternative module plugin files having any filenames you like.
To get build_firstrib_rootfs*.sh to use one of these alternatives, instead of optional firstrib00.plug, you should specify its file name as an argument when running the build script. For example:

Code: Select all

./build_firstrib_rootfs-i686.sh mybuild1.plug
Hopefully, you will upload your firstrib00.plug creations so others can copy your special firstrib builds.
There should be no need to modify build_firstrib_rootfs*.sh itself with this plugin facility.

See next post for attached simple exemplars for firstrib.repo and firstrib00.plug:

http://www.murga-linux.com/puppy/viewto ... 57#1028957


BUILDING FirstRib

Two versions of FirstRib buildscript (build_firstrib_rootfs) are provided: one for x86_64 systems, and one for i686 32-bit systems.
The scripts are purposively simple by design (no error checking).

To build FirstRib rootfs you just run the system-appropriate script (x86_64 or i686), as root user, from an otherwise empty directory (build_firstrib-rootfs, mount_chroot.sh and umount_chroot.sh scripts have to be put in there before using them).
Make sure all of these scripts are made executable before trying to run them (e.g. chmod +x ./build_firstrib-rootfs-*.sh).
Then, to make build simply open a terminal and cd into the directory where the build script is and enter command:

Code: Select all

./build_firstrib rootfs-i686.sh
if building on a 32bit system, or

Code: Select all

./build_firstrib_routfs-x86_64.sh
if building on a 64bit system.

It only takes a few minutes to build...

USAGE:

To chroot into the resultant firstrib_rootfs/ simply execute the provided shell script:

Code: Select all

./mount_chroot.sh
Once you are finished using FirstRib simply enter the command:

Code: Select all

exit
from the console you are working from, and then, to clean up the chroot bind mounts, enter command:

Code: Select all

./umount_chroot.sh
It is recommended that, in addition to examining/reading the build_firstrib_rootfs shell script to see how it works (around 40 lines of code plus the rest being comment/explanations), you similarly also examine the scripts mount_chroot.sh and umount_chroot.sh. These are only a few lines of code each.
-----------------------------------

The x86_64 build has been tested on XenialDog64 and BionicPup64 but most recent 64 bit systems would do.
The i686 build has been tested on XenialDog32 but most recent 32-bit systems would do as a host. You could even build FirstRib on Void Linux itself (or inside an already working FIrstRib come to that!...)

Note, that early firstrib releases produced a root filesystem only. As such it contained and needed no firmware of
its own as yet, since it was designed to be run in a host system container or chroot. When used in a chroot like that, the host Linux system
provides the required internet connectivity (via ethernet or wifi or whatever host provides). Recent rootfs builds can be used in similar manner via a chroot inside Linux host (using ./mount_chrootXX.sh, followed by exit, followed by ./umount_chrootXX.sh commands).

Installing additional apps in FirstRib: building up the system

To buiild the system to what you require you need to sync it with upstream repos and then install whatever apps you want using the provided xbps package manager.

For example, to Sync/update the repos and then
install midnight commander file-manager, you could enter the command:

Code: Select all

xbps-install -Su mc
If you want to install bash, you will also need to install tiny package ncurses-base if you want backspace key to work correctly (or you can install full ncurses instead, which has ncurses-base as a dependency). ncurses-base includes the required /usr/share/terminfo directory:

Code: Select all

xbps-install -S bash ncurses-base
Looking inside an xbps package:

By default, xbps keeps copies of the installation packages it downloads in directory /var/cache/xbps. You can safely delete these to save space, or if you want to see what is inside an xbps package, they are simply tarred up and compressed (by xz I think). You can therefore unpack and look inside by copying the package.xbps to an empty directory and then using:

Code: Select all

tar xvf packagename.xpbs
Once you have finished working with FirstRib, you enter the command exit to leave the chroot shell, and then clean up the bind mounts. The attached convenience script, "umount_chroot.sh", can be used after the exit if you wish.
-------------------------------------
Of course, when running under a chroot, firstrib_rootfs behaves like a full install so everything done/installed gets saved anyway...

wiak

https://github.com/firstrib/firstrib


**********************************************************************************************************


NOTES for if you are using initramfs02 instead of initramfs04 to boot:

The FirstRib WeeDog Linux build system

consists of two simple shell scripts, build_firstrib_rootfsXXX.sh and build_firstrib_initramfsXXX.sh.

To build default WeeDog, simply copy these two scripts to an empty directory (the /mnt/bootpartition/bootdir you will finally boot from would be a good choice, but any empty dir will do) and then execute them in order on an Internet-connected host Linux system. The default build only takes a few minutes to complete ready for booting and test!

i.e. At terminal commandline opened at that directory, enter commands:

Code: Select all

./build_firstrib_rootfs_XXX.sh  # where XXX is either an x86_64 or i686 version depending on your host Linux.

followed, once finished, by:

./build_firstrib_initramfs02_sNNN.sh  # for latest switch_root initramfs model 02
Note that this new switch_root initramfs model supercedes the original chroot initramfs model.

To boot WeeDog (using a previously installed grub4dos or grub2 boot loader)

Copy the following automatically built components (named as shown) to your /mnt/bootpartition/bootdir of choice (e.g. /mnt/sda2/firstrib):

Code: Select all

vmlinuz
Note that for vmlinuz can use appropriate 32 or 64 bit vmlinuz from BionicPup for now if you wish. If using that case you also want to copy its zdrvXXX.sfs renamed to 00firstrib_firmware_modules.sfs
initramfs02.gz
NNfirstrib_rootfs.sfs or NNfirstrib_rootfs uncompressed directory
  where, NN is usually made 01 (for lowest layer) but can be 01 to 99.
  Note (special WeeDog facility): 
    You can use the actual uncompressed firstrib_rootfs (if renamed to NNfirstrib_rootfs) instead of NNfirstrib_rootfs.sfs if the latter is not provided or its extension changed to say .sfsDISABLED.
    That makes quick mods to NNfirstrib_rootfs easy and also it is more responsive since uncompressed.
You can also supply additional sfs files, which will be loaded at boot time. These should be named NN<something>.sfs (using unique values for NN, again from that range 01 to 99). The value of NN determined layer position with 01 being lowest layer (note that NNfirstrib_rootfs can thus be moved to any layer position too).

Example grub4dos menu.lst and grub2 grub.cfg entries

Examples show using (hd0,0) i.e. /dev/sda1 boot partition of harddrive
Change following to the drive boot partition you are actually using
This example is for slow boot device, hence using optional usbwait value
The bootfrom parameter is required and must be accurate:

Code: Select all

# For grub4dos (but change hd0,0 to boot partition you actually use):

title FirstRib (Void Linux Flavour)
 root (hd0,0)
 kernel /firstrib/vmlinuz usbwait=12 bootfrom=/mnt/sda1/firstrib
 initrd /firstrib/initramfs02.gz

# For grub2 (but change hd0,msdos1 to boot partition you actually use):

menuentry 'FirstRib on /dev/sda1' {
 set root='hd0,msdos1'
 linux /firstrib/vmlinuz usbwait=12 bootfrom=/mnt/sda1/firstrib
 initrd /firstrib/initramfs02.gz
}
Shutting-down/re-booting the system from the commandline:

Use commands:

Code: Select all

poweroff -f  # for forced shutdown
reboot -f  # for forced reboot
For more information about FirstRib, please refer to the thread posts that follow this one

ALSO, the build scripts contain all built-in documentation in the form of comment blocks (especially at immediate beginning and immediate end). Please read them.

In particular, for more information on build_firstrib_rootfs_XXX.sh (which can also be used inside a Linux host chroot using provided mount_chroot.sh and umount_chroot.sh utilities), and on firstrib00.plug build plugin facility refer to post:

http://www.murga-linux.com/puppy/viewto ... 57#1028957

You can also refer to: http://github.com/firstrib/firstrib

Experimenting with sfs boot-time loading/layers

As an experiment, I have gimp sfs loading on my WeeDog. I tried loading BionicPup64 devx just for fun on layer 02 (renamed 02devxYYY.sfs) alongside 01firstrib_rootfs.sfs. Alas that caused a kernel crash on boot, which is not surpising since probably several Void Linux libs on default build, so should be using Void Linux kernel and firmware/modules if wanting to compile. Nevertheless, to trick the system, I tried putting BionicPup64 devx on lowest layer (renamed 01devxYYY.sfs) alongside renamed 02firstrib_rootfs.sfs and the system successfully booted with, for example, gcc and strip commands recognized. I'm not saying it would successfully compile in that state in practice, since, really should be using Void kernel and firmware/modules for that, as I said; it doesn't so don't waste your time... So for proper gcc use initramfsXX with kernel=void and install the necessary kernel/modules/firmware in pre-built firstrib_rootfs: linuxX.XX [or template: linux for that plus graphics drivers], ncurses-base, linux-firmware-network, wifi-firmware).

NOTE that the build_firstrib_initramfs02_s001.sh script is not itself anything to do with Void Linux. In theory, I imagine, if you decompress a pupXXX.sfs (e.g. that for BionicPup64) and call it firstrib_rootfs, the build initramfs script would write a new rc.sysinit script to it and, I think, make it bootable (as an uncompressed dir named 01firstrib_rootfs, though first you would have to make /sbin/init a symlink to /sbin/init-BB and maybe some more alterations). I haven't had time to try that (sleep time here now), but will tomorrow (the devx might even be able to be made to work for that arrangement...). I will experiment and report on that one - not sure what the end result would be since different rc.sysinit script - though original pup /sbin/init and rc.sysinit could be left and that might work better for that case (in either case I may tailor build_firstrib_initramfs02 script to optionally create a firstribpup of that sort, maybe using option of aufs or overlayfs ... which would be a new firstrib initramfs form of Puppy... But that would not at all be my focus, which remains Void Linux flavour with xbps).

wiak

In practice all firstrib-related scripts provided are to be used, per normal disclaimer: at your own risk.
Attachments
firstrib.repo.tar
remove the dummy tar and place in build_firstrib*.sh directory
(42 Bytes) Downloaded 507 times
Last edited by wiak on Tue 27 Aug 2019, 04:47, edited 6 times in total.

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

#4 Post by wiak »

Utilities to modify (decompress, allow modification, then recompress) initramfs gz or xz, or convert one to the other.

Usage: Very short/simple commandline scripts (easy to read/understand). Note well that the process needs carried out on a Linux-compatible filesystem (though /tmp can generally be used when underlying fs not otherwise Linux format). Run script fom terminal at same directory as where the initramfs is held:

Code: Select all

./modify_initramfs_XX.sh <initramfs_filename>
or

Code: Select all

./modify_initramfs_XX.sh --help
Works with FirstRib initramfs, BionicPup initrd.gz, BionicDog initrd1.xz and similar.

I wrote the gz one because I needed to often modify the initramfs whilst experimenting. You may similarly find them useful on occasion...

Per simple scripts only firstrib philosophy, I resisted writing one script only (with required selection logic). Not much to them - I've no interest in making them more sophisticated at this stage.

If you need alternative versions (e.g. no compression or alternative compression, or different compression factors) should be easy enough to modify.

Extract from running the gz-based script:
File initramfs02.gz has been decompressed into directory initramfs02_decompressed
and a cd command to that directory has been made.
At this stage, you can use this new shell or another shell terminal
or gui program to modify the initramfs contents.
For example, you can edit the initramfs/init shell script if you wish,
or add/remove contents from/to this initramfs02_decompressed directory
via shell commands or your favourite filemanager.
Once you have completed your modifications, simply type: exit
A new date-stamped initramfs02 gz will then be created in same directory
as the original initramfs02.gz and this initramfs02_decompressed directory
will be automatically deleted.
Alternatively, if you simply want initramfs02_decompressed, close this terminal.
wiak
Attachments
modify_initramfs_gz.sh.tar
remove dummy tar and chmod +x
(1.68 KiB) Downloaded 457 times
modify_initramfs_xz2gz.sh.tar
remove dummy tar and chmod +x
(1.68 KiB) Downloaded 457 times
modify_initramfs_xz.sh.tar
remove dummy tar and chmod +x
(1.69 KiB) Downloaded 443 times
modify_initramfs_gz2xz.sh.tar
remove dummy tar and chmod +x
(1.71 KiB) Downloaded 448 times
Last edited by wiak on Tue 16 Jul 2019, 11:14, edited 10 times in total.

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

Older model04: FirstRib default WeeDog Linux build system

#5 Post by wiak »

The following are build notes for the older WeeDog initramfs04 version

The build system related to initramfs04 model are attached at foot of this post.

Please see second post of thread post and those after for current docs and downloads for FirstRib utilities (such as mount_chroot, modify_initramfs etc).

The FirstRib WeeDog Linux build system

consists of two simple shell scripts, FirstRib build_firstrib_rootfsXXX.sh, which relies on upstream distro repos, and (independent) WeeDog build_firstrib_initramfsXXX.sh,

plus some optional plugins (e.g. firstrib00.plug) and helper utilities (e.g. modify_initramfsXXX.sh). The system builds rapidly, is easily user-modified, and is very efficient.

WeeDog initramfs is really the key component to WeeDog distro (i.e. the controlling backend of the system)., which provides its special rollback upper_changes type facilities via its numbered sfs or numbered uncompressed directories layers.

FirstRib itself is really just the default build_firstrib_rootfs part. The result of which, like most distros nowadays on murga forum, depends also on upstream repos for its user frontend functionality (i.e. packages...). FirstRib build rootfs is defined by its key design feature of "busybox static plus native package manager" with extension via plugin module (firstrib00.plug). Best is when native package manager is usable on its own in FirstRib, such as Void xbps can be, otherwise latest (under development/test) FirstRib obtains it, either as native package manager (preferred, and as in current version), or via some kind of bootstrap skeleton, such as debootstrap or arch-bootstrap.

The default build creates a minimum WeeDog Linux distro (after which you can install bash, coreutils, X desktop components etc). A fully built up WeeDog Linux distro, requires a firstrib00.plug creator, who can provide the full desktop experience, or otherwise, and my hope is that the whole community can feel able to involve themselves in such builds of their own or helping others, producing multiple WeeDog Linux versions.

You can also take an existing root filesystem of some distros (e.g. Slackware) and "WeeDog-it" such that the resulting booted distro provides all WeeDog features in terms of rollback capability and changes=RAM and so on. Example of frugal distro WeeDog running Slackware:

http://www.murga-linux.com/puppy/viewto ... 11#1035211


QUICK BUILD/TEST INSTRUCTIONS

To build and run default WeeDog

Simply copy the two scripts, build_firstrib_rootfsXXX.sh and build_firstrib_initramfsXXX.sh to an empty directory (the /mnt/bootpartition/bootdir you will finally boot from would be a good choice, but any empty dir will do).

Though you can add extra stuff later, if you want to use Void Linux kernel and firmware (recommended), it would be advantageous to also copy the attached plugin file firstrib00.plug to same directory (the plugin causes build_firstrib_rootfsXXX.sh to also install void linux kernel and firmware/modules as required when using build_firstrib_initramfs04_sXXX.sh kernel=void). You can edit firstrib00.plug if you wish to add extra packages (such as bash and base-minimal) and code if you wish (anything, including packages and configs for full desktop build) or you can easily add extra stuff later. See below link for some firstrib00.plug details:

http://www.murga-linux.com/puppy/viewto ... 04#1034404

Then, on an Internet-connected host Linux system (e.g. Puppy or DebianDog):

Execute ./build_firstrib_rootfsXXX.sh to build the main root filesystem (which will be produced as both uncompressed directory firstrib_rootfs and squashed version called 01firstrib_rootfs.sfs). Once that has completed (assuming you have opted to use Void Linux kernel/firmware and modules):

Execute ./build_firstrib_initramfsXXX.sh kernel=void
That second script creates the initramfs.gz and spits out the vmlinuzXXX (that you could rename to simply vmlinuz) that you need to boot the resultant WeeDog system.

The default build only takes a few minutes to complete ready for booting and test!

Example grub4dos menu.list:

Code: Select all

 title FirstRib (Void Linux Flavour)
root (hd0,0)
kernel /firstrib/vmlinuzX.XX usbwait=12 bootfrom=/mnt/sda1/firstrib
initrd /firstrib/initramfs04.gz
Network Connectivity

Once booted, for simple setting up ethernet or wifi manually from commandline, refer to post:

http://www.murga-linux.com/puppy/viewto ... 22#1031022

Audio setup

Sound modules should be loaded automatically on boot with most recent FirstRib initramfs, however, for more help on getting alsa and/or pulseaudio to work refer to:

http://murga-linux.com/puppy/viewtopic. ... 88#1031588

Or if you want to immediately build a Void Linux base system:

For some tips, see this post here:

http://www.murga-linux.com/puppy/viewto ... 49#1029049

FirstRib Void Flavour comes installed with full Void Linux package manager xbps

https://wiki.voidlinux.org/XBPS#Basic_Usage

Though WeeDog starts as a boot to commandline system, you can use xbps (e.g. xbps-install, xbps-remove, and xbps-query packages) to easily build a complete desktop system. Forum member rockedge has provided some nice screenshots in this thread of desktop versions he has created (including complex ZoneMinder compile/install) using the older initramfs build, and newer builds (rufwoof and rockedge) too:

http://murga-linux.com/puppy/viewtopic. ... 19#1034419

http://murga-linux.com/puppy/viewtopic. ... 47#1034447

and fredx181 provided the following useful related post (but also should xbps-install ncurses-base for bash backspace to work at commandline):

http://www.murga-linux.com/puppy/viewto ... 18#1031218

The most efficient way to locate packages available from Void Linux repositories is per the following Void wiki page:

https://docs.voidlinux.org/xbps/packages/files.html
============================================================================

In more detail and more generally:

It is advised to read the rest of this thread and the following couple of posts...

At terminal commandline opened at that directory, enter commands:

Code: Select all

./build_firstrib_rootfs_XXX.sh  # where XXX is either an x86_64 or i686 version depending on your host Linux.

followed, once finished, by:

./build_firstrib_initramfs0X_sNNN.sh  [kernel=void]
# for latest switch_root initramfs model 0X.
# kernel=void is optional argument, which uses Void kernel/modules/firmware from firstrib_rootfs install of linuxX.XX
To boot WeeDog (using a previously installed grub4dos or grub2 boot loader)

Copy the following automatically built components (named as shown) to your /mnt/bootpartition/bootdir of choice (e.g. /mnt/sda2/firstrib):

Code: Select all

vmlinuz (or vmlinuzX.XX etc if using Void Linux kernel)
Note that for vmlinuz can use appropriate 32 or 64 bit vmlinuz from BionicPup for now if you wish. If using that case you also want a modified/processed copy of its zdrvXXX.sfs.

For some extra information on using the Void Linux kernel see post:

[url]http://www.murga-linux.com/puppy/viewtopic.php?p=1033007#1033007[/url]

[b]If using Void Linux kernel (preferred way forward)[/b], the built firstrib_rootfs needs to at least include xbps-install: linuxX.XX (currently linux4.19), ncurses-base, and linux-firmware-network, and optional small extra wifi-firmware. Or simply install ncurses-base, and template: linux (which also brings nvidia, amd, i915 and more graphics drivers).  [b]You can install these extras via[/b] ./mount_chroot.sh on your host build system (i.e. in a chroot, followed by exit, and then ./umount_chroot.sh).
 
[b]NOTE WELL:[/b] For initramfs04, if using BionicPup kernel instead of Linux Void kernel, it is no longer sufficient to simply rename e.g. Bionicpup zdrv. Rather, you need to convert the zdrv sfs by placing it in same directory as utility zdrv_convert.sh and running command:
	./zdrv_convert.sh <filename of Puppy zdrv>
from the same directory you store a copy of BionicPup zdrvXXX.sfs

initramfs04.gz

NNfirstrib_rootfs.sfs or NNfirstrib_rootfs uncompressed directory
  where, NN is usually made 01 (for lowest layer) but can be 01 to 99.
-------------------------------------------

NOTE WELL SPECIAL FirstRib feature:
 Instead of or in addition to sfs files you can instead use uncompressed directories containing what would otherwise be the content of such squashed filesystems. For example, instead of providing say 01firstrib_rootfs.sfs for use as lower layer during boot you can instead provide a directory of name 01firstrib_rootfs that contains what would be the unsquashed contents of that sfs file.

The same applies to ANY additional sfs you might want to also load at boot time: you can alternatively use a directory containing what would otherwise be the uncompressed contents of the sfs instead.
You can mix sfs files and unsquashed contents of other sfs files for boot-time layer mounting.
Whilst taking up more disk space, this facility makes editing of individual layers easy when systemis not in use. It also allows a user to easily implement a rollback feature: 
   any upper_changes directory can be renamed in the form NNupper_changes (e.g. 50upper_changes) such that it will be loaded read-only in appropriate NN-signified layer and a new read-write upper_changes directory will be auto-created on next boot. Alternatively, for similar purposes,  upper_changes can be made into a squashed filesystem named in the form NNupper_changes.sfs
You can thus arrange to rollback as far as you like by simply removing current rw upper_changes dir.

Layer "upper_changes" contains changes which are bind mount to chosen partition save directory
Layer "/mnt/layers/merged" contains the overlay result of all above layers merged together 
Initramfs/init does a switch_root to that real rootfilesystem, /mnt/layers/merged
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.
If provided, 00firstrib_firmware_modules.sfs is also loaded and available.
The module handling code can be re-written via optional plugin: initramfs04modules.plug
----------------------------------------------------------
You need to specify: bootfrom="<location>" in grub configurations
  where, for example, location can be the likes of /mnt/sda1/firstrib or wherever...
In grub configs you can also specify usbwait=delay_in_seconds. e.g. usbwait=10 for slow boot devices,
You can also specify rdsh0 and/or rdsh1 rdsh2 rdsh3 on grub linux/kernel line to source initramfs/init plugin /mnt/bootpartition/bootdir/rdshN.plug or to start debug shell if plugin doesn't exist or is empty.

On grub linux/kernel line you can now specify upper_changes save location:
There are four alternative "changes=" modes: empty arg, changes=RAM, changes=readonly, changes="path2dir"
1. No changes argument on grub kernel line: Use upper_changes in /mnt/bootpartition/bootdir
2. RAM: All changes go to RAM only (/mnt/layers/RAM/upper_changes). i.e. non-persistent
3. readonly: overlay filesystem is rendered read only so it cannot be written to at all
4. path2dir: store upper_changes in specified path/directory at upper_changes subdirectory

[size=18][b]****NEW (in Revision 1.0.2):[/b][/size]

[b]The trim modules code in the initramfs/init (i.e. modprobe -r etc...) now force keeps ehci, xhci, and sdhci modules[/b] to ensure boot ability of usb-connected devices (i.e. previously could get kernel panic on kernel unable to switch_root to /sbin/init).

[b]Can now externally change that trim modules code section via plugin modules_remove.plug[/b]. If empty file of that name put in /mnt/bootpartition/bootdir, the modules will not be trimmed at all. Alternatively, any code placed in that plugin will be used instead of the default initramfs/init modules trim code (allowing easy fix of any such issues).

[b]From Revision 1.0.0 onwards:[/b]
grub kernel-line copy2ram option, which 
causes all NNsfs, NNdirs, and rdshN.plug files to be copied to RAM tmpfs
and mounts the NNsfs and/or NNdirs from there. One result of that is
that when either of the following grub kernel-line option combinations
is used, the bootdevice (e.g. usb stick) can be umounted and ejected:

1. changes=RAM at same time as copy2ram
   (upper_changes then stored only in RAM: non-persistent)
2. changes=readonly at same time as copy2ram
   (also only using RAM and writes not allowed) 
3. changes=<path to changes directory> specified, where
   changes_partition is different from initial bootpartition
   (since bootdevice then not being used it can be unmounted).

Example grub4dos menu.lst and grub2 grub.cfg entries

Examples show using (hd0,0) i.e. /dev/sda1 boot partition of harddrive
Change following to the drive boot partition you are actually using
This example is for slow boot device, hence using optional usbwait value
The bootfrom parameter is required and must be accurate:

Code: Select all

   For grub4dos
   Example shows using (hd0,0) i.e. /dev/sda1 boot partition

   title FirstRib (Void Linux Flavour)
   root (hd0,0)
   kernel /firstrib/vmlinuzX.XX usbwait=12 bootfrom=/mnt/sda1/firstrib
   initrd /firstrib/initramfs04.gz

   For grub2 (but change hd0,msdos1 to boot partition you actually use):

   menuentry 'FirstRib on /dev/sda1' {
     set root='hd0,msdos1'
     linux /firstrib/vmlinuzX.XX usbwait=12 bootfrom=/mnt/sda1/firstrib
     initrd /firstrib/initramfs04.gz
   }

Note: 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.

Example: grub4dos that specifies storing upper_changes directory on a different partition:

   title FirstRib (Void Linux Flavour)
   root (hd0,0)
   kernel /firstrib/vmlinuzX.XX usbwait=12 bootfrom=/mnt/sda1/myfirstrib changes=/mnt/sda2/firstrib2
   initrd /firstrib/initramfs04.gz
   
Can also use:

changes=RAM (for no persistence).
changes=readonly (for a readonly system, so no writes allowed).
Leaving changes out altogether results in /mnt/bootpartition/bootdir/upper_changes being used.

copy2ram
(causes all NNsfs, NNdirs, and rdshN.plug files to be copied to 
RAM tmpfs and mounts the NNsfs and/or NNdirs from there).
Shutting-down/re-booting the default base system from the commandline:

Use commands:

Code: Select all

poweroff -f  # for forced shutdown
reboot -f  # for forced reboot
For more information about FirstRib, please refer to the thread posts that follow this one

ALSO, some of the build scripts contain built-in documentation in the form of comment blocks (especially at immediate beginning and immediate end). Please read them.

In particular, for more information on build_firstrib_rootfs_XXX.sh (which can also be used inside a Linux host chroot using provided mount_chroot.sh and umount_chroot.sh utilities), and on firstrib00.plug build plugin facility refer to post:

http://www.murga-linux.com/puppy/viewto ... 57#1028957

You can also refer to: http://github.com/firstrib/firstrib

Note that, I have not pruned the system for size.

By default Void provides many libs un-stripped, includes docs and man pages for each package, and keeps a copy of downloaded .xbps install files under /var/cache/xbps. Leaving these in helps with future development but bloats the size somewhat.
You can of course strip these parts out in your own experiments/designs based on FirstRib.
Also, void packages are all archived in /var/cache/xbps; these can be removed.
Finally, Void provides a LOT of firmware. That could also be pruned down and I may work on a script to do that pruning later, but that is not a priority for my own needs - even a ten year old computer generally has plenty storage space anyway and large hard disc storage has nothing to do with RAM used (WeeDog tends to be very efficient in that regard).

Note that the currently provided switch_root initramfs model04 (build_firstrib_initramfs04XXX.sh) for most users probably supercedes the original chroot initramfs model01. However, for those interested, the last chroot initramfs01 model will later be updated with the relavent latest initramfs model04 features. Code for last released chroot initramfs model01 can be found at following link:

https://github.com/firstrib/firstrib/bl ... r008pre.sh

wiak

In practice all firstrib-related scripts provided are to be used, per normal disclaimer: at your own risk.

OLD VERSIONS (i.e. model04 initramfs):
Attachments
firstrib00.plug_void_default_anyarch.tar
Just remove the dummy tar
(273 Bytes) Downloaded 433 times
build_firstrib_rootfs_i686_008.sh.tar
Just remove the dummy tar and chmod +x
(8.21 KiB) Downloaded 424 times
build_firstrib_rootfs_x86_64_008.sh.tar
just remove the dummy tar and chmod +x
(8.28 KiB) Downloaded 472 times
build_weedog_initramfs04_s102.sh.tar
Just remove the dummy tar and chmod +x
(19.43 KiB) Downloaded 373 times
build_weedog_initramfs04_s102_README.tar
Just remove the dummy tar
(9.86 KiB) Downloaded 418 times
zdrv_convert.sh.tar
just remove the dummy tar and chmod +x
(1.85 KiB) Downloaded 440 times
Last edited by wiak on Wed 28 Aug 2019, 23:12, edited 15 times in total.

wanderer
Posts: 1098
Joined: Sat 20 Oct 2007, 23:17

#6 Post by wanderer »

hi wiak

very cool

so core plus package manager ?

from the void repositories

i have to look up void


edit i used your links to read about void

still reading


wanderer
Last edited by wanderer on Sat 25 May 2019, 02:36, edited 2 times in total.

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

#7 Post by wiak »

So where from here?

Well, there are lots of options.

I'm planning to keep/make the system multi-user since I've always found that to be an unnecessary weakness of old Puppy.

Easiest is to simply use adduser, addgroup commands of busybox, but you could install package 'shadow' and set up shadow passwords (which comes with PAM authentication as a dependency) if you wish. For now, lets go simple/less-secure:

Code: Select all

adduser puppy
Or for PAM and shadow passwords:

Code: Select all

xbps-install -S && xbps-install shadow

You probably thinking you want X windows already. I'm resisting that until I've made an initramfs of my liking and have FirstRib booting on its own. But if you want, I think you'd need to install something like:

Code: Select all

xbps-install -S xorg-minimal xorg-fonts xf86-input-synaptics xf86-video-intel bash ncurses-base
depending on your hardware, and then add a window manager of your choice, but I'll come back to all this later, since I'll have to try it myself too...

and, assuming you have installed at least fonts, you could similarly, as an X app example:

Code: Select all

xbps-install -S leafpad
So it is all pretty trivial to expand...

Also, there are other ways of constructing the original FirstRib (such as installing xpbs from sources) so I may or may not be experimenting with that first. What I'm provided thus far is just the result of my initial experiments... You can always of course use the several rootfs possibilities Void Linux upstream provides itself - but that would defeat the purpose of building your own specially configured/tuned one. More easy to learn a lot from such small beginnings.

More to come.

wiak

EDIT: Like any distro build work, you want to have plenty free space on your system of course; the distro will grow... A few GB free is good I expect. For booting on its own, your going to need firmware, which is a bit of a size issue since the Void package linux-firmware being general purpose is pretty huge (around 80MB compressed, 500MB uncompressed!) so will be good later to identify own firmware and arrange only to include that. Remember Void packages include docs and everything and some things remain unstripped so that is another issue to work on (a distro stripper utility). Also, xorg-minimal isn't at all small! so if you are musher0 and want an anorexic distro you'd need to investigate a smaller Xvesa or tinyX kind of package addon (you can easily use your own xbps package repo with Void Linux using the xbps-rindex command to set it up). There is a lot of fun to be had from these simple beginnings/learning though - worry about distro size/stripping later...
Last edited by wiak on Mon 26 Aug 2019, 22:01, edited 1 time in total.

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

#8 Post by wiak »

Just play with FirstRib system wanderer. Just need to run the build... script from a terminal starting from an empty directory on your system. (choose either 64bit or 32bit build script depending on your system. Then from same terminal, you can run FirstRib in a chroot simply by running the provided startup script ./mount_chroot

You can then add/remove whatever packages you like (see my post a few posts above for suggestions). For example:

Code: Select all

xbps-install -Su
xbps-install -S bash
xbps-install -S file
xbps-install -S shadow
or more simply, if you want them all:

Code: Select all

xbps-install -Su bash file shadow
Basics of using the package manager here:

https://wiki.voidlinux.org/XBPS#Basic_Usage

Once finished, enter exit command, and then, from same terminal cleanup by running provided script ./umount_chroot. The scripts are all just a few lines long, so you should examine them to see how it all works.

Like I said in first post, FirsRib builds in a few short minutes (your host Linux machine needs Internet connection of course.

Please let me know if you don't understand anything or run into problems at this stage.

wiak
Last edited by wiak on Thu 30 May 2019, 07:59, edited 1 time in total.

wanderer
Posts: 1098
Joined: Sat 20 Oct 2007, 23:17

#9 Post by wanderer »

hi wiak

just ran it
built fine
very fast

edit: unbelievably tiny script
unbelievable

very cool

will continue to play and learn
and report

wanderer

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

FirstRib/WeeDog USER CONTRIBUTIONS

#10 Post by wiak »

latest revision of this post is Wed 05 Oct 2019, wiak

User-contributed firstrib00.plug/PLUGINS
and other user-provided UTILITIES, programs, scripts and HOWTOs

------------------------------------------------------------------------------------
LIST FORMAT:

creator:distro_flavour:itemname_if_relevant: link to plugin download page
,which may include details and instructions and information on any limitations/system-requirements etc
------------------------------------------------------------------------------------
FirstRib Build firstrib_rootfs (root filesystem) PLUGINS:

rufwoof:void:desktop http://murga-linux.com/puppy/viewtopic. ... 78#1035078
rufwoof:void:desktop_earlier_version: http://murga-linux.com/puppy/viewtopic. ... 66#1034966
rockedge:void:jwm_simple_desktop: http://murga-linux.com/puppy/viewtopic. ... 69#1035969
rockedge:void:zoneminder_draft: http://murga-linux.com/puppy/viewtopic. ... 09#1035609
rockedge:void:zoneminder_working_build_steps: http://murga-linux.com/puppy/viewtopic. ... 39#1037039
westwest:void:desktop_experiment: http://www.murga-linux.com/puppy/viewto ... 87#1035087
-------------------------------------------------------------------------------------
WeeDog UTILITIES:

rufwoof:all_distros:merge-changes.sh: http://murga-linux.com/puppy/viewtopic. ... 65#1035465 # for merging multiple NNchanges.sfs files
rufwoof:all_distros:save.sh: http://murga-linux.com/puppy/viewtopic. ... 65#1035465 # for saving changes in RAM as an sfs
rufwoof:void_alldistros?:/etc/rc.shutdown quite details save changes arrangement used by rufwoof: http://www.murga-linux.com/puppy/viewto ... 11#1038811
SFR/artsown/rufwoof:void:traytemp & trayclock: http://www.murga-linux.com/puppy/viewto ... 59#1037459 # tray temperature icon (along with tray clock method of rufwoof)
-------------------------------------------------------------------------------------
WeeDog HOWTOs

rufwoof:all_distros:Audio,asound.conf: http://murga-linux.com/puppy/viewtopic. ... 35#1035235
rufwoof:void:Audio,Jack: http://murga-linux.com/puppy/viewtopic. ... 63#1035263
rufwoof:all_distros:info_re_btrfs: http://murga-linux.com/puppy/viewtopic. ... 01#1028501
fredx181:void:X_twm_openbox_intro:http://www.murga-linux.com/puppy/viewto ... 18#1031218
watchdog:all_distros:change_root_jails:http://www.murga-linux.com/puppy/viewto ... 31#1029031
rufwoof:void:How to use official Void Linux root filesystems with WeeDog initramfs: http://www.murga-linux.com/puppy/viewto ... 40#1038040
http://www.murga-linux.com/puppy/viewto ... 57#1038057
wiak:void:How to use official Void live for LXDE WeeDog: http://www.murga-linux.com/puppy/viewto ... 50#1038650
wiak:void:How to make bootable WeeDog iso:http://www.murga-linux.com/puppy/viewto ... 82#1038282
rockedge:void:How to boot WeeDog on VBox using BionicPup32 to set things up:http://www.murga-linux.com/puppy/viewto ... 73#1038273 http://www.murga-linux.com/puppy/viewto ... 07#1038307
wiak:all_distros:Some notes on pruning firmware and modules installed: http://www.murga-linux.com/puppy/viewto ... 50#1038350 http://www.murga-linux.com/puppy/viewto ... 68#1038368
-------------------------------------------------------------------------------------
MISCELLANEOUS

wiak:slackware:weedog-it: http://www.murga-linux.com/puppy/viewto ... 11#1035211
-------------------------------------------------------------------------------------
LINK back to main first post of this thread: http://murga-linux.com/puppy/viewtopic. ... 56#1028956
Last edited by wiak on Mon 07 Oct 2019, 07:03, edited 55 times in total.

watchdog
Posts: 2021
Joined: Fri 28 Sep 2012, 18:04
Location: Italy

#11 Post by watchdog »

I have been keeping experimenting with a precise chroot jail taking suggestions from this thread and rufwoof posts.

http://www.murga-linux.com/puppy/viewto ... 62#1018462

Here is a collection of scripts to run some software from every puppy in the jail:

audacitychroot:

Code: Select all

#!/bin/sh
export LC_ALL=C
mount --bind /dev /mnt/sdb1/cnt/dev
mount --bind /proc /mnt/sdb1/cnt/proc
mount --bind /sys /mnt/sdb1/cnt/sys
mount -t devpts devpts /mnt/sdb1/cnt/dev/pts
xhost +
mkdir -p /mnt/sdb1/cnt/tmp/.X11-unix
mount --bind /tmp/.X11-unix /mnt/sdb1/cnt/tmp/.X11-unix
chroot /mnt/sdb1/cnt audacity "$@"
firefoxchroot:

Code: Select all

#!/bin/sh
export LC_ALL=C
mount --bind /dev /mnt/sdb1/cnt/dev
mount --bind /proc /mnt/sdb1/cnt/proc
mount --bind /sys /mnt/sdb1/cnt/sys
mount -t devpts devpts /mnt/sdb1/cnt/dev/pts
cp /etc/resolv.conf /mnt/sdb1/cnt/etc/resolv.conf
mount --rbind /etc/machine-id /mnt/sdb1/cnt/etc/machine-id 
xhost +
mkdir -p /mnt/sdb1/cnt/tmp/.X11-unix
mount --bind /tmp/.X11-unix /mnt/sdb1/cnt/tmp/.X11-unix
chroot /mnt/sdb1/cnt firefox "$@"
palemoonchroot:

Code: Select all

#!/bin/sh
export LC_ALL=C
mount --bind /dev /mnt/sdb1/cnt/dev
mount --bind /proc /mnt/sdb1/cnt/proc
mount --bind /sys /mnt/sdb1/cnt/sys
mount -t devpts devpts /mnt/sdb1/cnt/dev/pts
cp /etc/resolv.conf /mnt/sdb1/cnt/etc/resolv.conf
xhost +
mkdir -p /mnt/sdb1/cnt/tmp/.X11-unix
mount --bind /tmp/.X11-unix /mnt/sdb1/cnt/tmp/.X11-unix
chroot /mnt/sdb1/cnt palemoon "$@"
xsanechroot:

Code: Select all

#!/bin/sh
export LC_ALL=C
mount --bind /dev /mnt/sdb1/cnt/dev
mount --bind /proc /mnt/sdb1/cnt/proc
mount --bind /sys /mnt/sdb1/cnt/sys
mount -t devpts devpts /mnt/sdb1/cnt/dev/pts
cp /etc/resolv.conf /mnt/sdb1/cnt/etc/resolv.conf
mount --rbind /etc/machine-id /mnt/sdb1/cnt/etc/machine-id
mount --rbind /etc/gtk-2.0/gdk-pixbuf.loaders /mnt/sdb1/cnt/etc/gtk-2.0/gdk-pixbuf.loaders 
xhost +
mkdir -p /mnt/sdb1/cnt/tmp/.X11-unix
mount --bind /tmp/.X11-unix /mnt/sdb1/cnt/tmp/.X11-unix
chroot /mnt/sdb1/cnt xsaneshell "$@"
cupschroot:

Code: Select all

#!/bin/sh
export LC_ALL=C
/etc/init.d/cups stop
mount --bind /dev /mnt/sdb1/cnt/dev
mount --bind /proc /mnt/sdb1/cnt/proc
mount --bind /sys /mnt/sdb1/cnt/sys
mount -t devpts devpts /mnt/sdb1/cnt/dev/pts
mount --bind /mnt/sdb1/cnt/var/run/cups /var/run/cups 
mount --bind /mnt/sdb1/cnt/var/spool/cups /var/spool/cups
cp /etc/resolv.conf /mnt/sdb1/cnt/etc/resolv.conf
xhost +
mkdir -p /mnt/sdb1/cnt/tmp/.X11-unix
mount --bind /tmp/.X11-unix /mnt/sdb1/cnt/tmp/.X11-unix
mount -t tmpfs -o size=10M tmpfs /var/spool/cups
chroot /mnt/sdb1/cnt /etc/init.d/cups start
closechroot:

Code: Select all

#!/bin/sh
umount /mnt/sdb1/cnt/tmp/.X11-unix
umount /mnt/sdb1/cnt/sys
umount /mnt/sdb1/cnt/proc
umount /mnt/sdb1/cnt/dev/pts
umount /mnt/sdb1/cnt/dev
#umount /mnt/sdb1/cnt/etc/gtk-2.0/gdk-pixbuf.loaders
#umount /mnt/sdb1/cnt/etc/machine-id
#umount /var/run/cups
#rm /var/spool/cups/tmpfs
#umount /var/spool/cups
xhost -

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

#12 Post by wiak »

Okay, I have the shadow passwd thing worked out now. I'll just double-check a few details and then fix the post above. I will probably add a small part of it to FirstRib build script (but not all since I want to keep a basic core FirstRib and extras to be added as additional module).
wiak

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

#13 Post by wiak »

To keep things simple, I decided not to bother with shadow passwords and PAM authentication in earlier post on setting up a puppy user:

http://www.murga-linux.com/puppy/viewto ... 18#1029018

but for those who want it, follow same step of creating /etc/passwd and /etc/group as in above link.

Then install shadow package (with includes PAM authenication):

Code: Select all

xbps-install -S shadow
Then you can turn on passwd shadowing with the command:

Code: Select all

pwconv
and, if you wish, group shadowing, with the command:

Code: Select all

grpconv
That shifts the user passwd to /etc/shadow, which is only readable by root user. If you run into any problems setting that up, just let me know and I'll try and sort out your issue.

You can find some good info on this here:

https://www.techrepublic.com/article/ho ... mand-line/

https://www.dell.com/support/article/nz ... 59?lang=en

https://www.dell.com/support/article/nz ... 59?lang=en

wiak

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

#14 Post by wiak »

A little tip if you are in a hurry.

It is pretty easy to make FirstRib into a full Linux Void root filesystem. Or a smaller one that contains a pre-selected range of packages to get you going. That ability is also useful for finding the names of packages used in Void Linux too in case you just want to use your own subset.

Some of the packages available from the Void Linux repos are templates /metapackages that simply bring down dependencies to help build different sizes of Void Linux systems. So you can use FirstRib same way you might use debootstrap from Debian and then script around the result such as fredx181 did with his mklive-Stretch debian scripts.

For example, here is a template for a 'minimum' system (just check out the 'dependencies' shown: these are the packages it will install):

https://github.com/void-linux/void-pack ... l/template

You'll get all of these simply be issuing command:

Code: Select all

xbps-install -R base-minimal
Also available is:

base-system (this is much bigger)
base-chroot
base-devel
base-files
base-voidstrap

You have to check them out to see what the difference is. For example:

https://github.com/void-linux/void-pack ... l/template

or use the wonderful xbps-query command to view dependencies/template-contents from FirstRib prompt. For example:

Code: Select all

xbps-query -Rx base-system | less
I don't know much about Void Linux myself yet. I'm just picking this info up as I go along playing with FirstRib, which is so fast and easy to install on my existing XenialDog or Puppy system...

wiak

EDIT: If you are interested in light-weight container implementation, void repos can provide that too:

https://voidlinux.org/news/2017/12/adve ... iners.html

and here is some further nice docs on void:

http://www.troubleshooters.com/linux/void/

I'll start thinking about some alternative initramfs modules now so FirstRib can be booted standalone with save persistence using overlayfs. I'll likely be a (long) while contemplating possibilities for that though so invent your own meantime!

wanderer
Posts: 1098
Joined: Sat 20 Oct 2007, 23:17

#15 Post by wanderer »

hi wiak

i am trying to build your system and reading about void

looks great

really powerful but understandable


thanks for doing this


wanderer

wanderer
Posts: 1098
Joined: Sat 20 Oct 2007, 23:17

#16 Post by wanderer »

hi wiak

everything working fine for me
using the 32 bit version

wow this is really cool

thanks

wanderer

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

#17 Post by rockedge »

you caught my attention...so I am going to set up what you have built.

Looks interesting and I will report if successful..

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

#18 Post by wiak »

rockedge wrote:you caught my attention...so I am going to set up what you have built.

Looks interesting and I will report if successful..
Thank you.

User avatar
Keef
Posts: 987
Joined: Thu 20 Dec 2007, 22:12
Location: Staffordshire

#19 Post by Keef »

Been playing with this on Fatdog, and all working nicely.
In case it is useful to know, sh is a symlink to dash, so behaves differently to bash - no command history, and backspace and arrow keys don't work etc.
If you install and use bash, you will have to 'exit' twice - first from bash, then from the original shell.
I've installed 'base-system', plus mc, nnn, nano and lynx.

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

#20 Post by rockedge »

I created a directory next to a group of frugal puppies called /FirstRib and I put the scripts into it, ran the build, 64 bit.
looks to be successful and was done quickly on the Bionic64-v8 host system

then put both mount and unmount scripts into /FirstRib and ran the mount script and it worked. I used your examples and installed bash and file then used the exit command and ran the unmount script. And added the user root and webuser:webgroup

I then ran the mount script again and the command prompt reflected the bash being installed as noted in the screenshot
Attachments
Screenshot(28).png
(93.64 KiB) Downloaded 1025 times

Post Reply