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
Code: Select all
./build_firstrib_rootfs_XXX.sh ubuntu bionic amd64 firstrib00.plug_ubuntu_bionic_amd64
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
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
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
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
Use commands:
Code: Select all
poweroff -f # for forced shutdown
reboot -f # for forced reboot
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.