RC7 (STABLE) WeeDogLinux Arch 64 now released

[rufwoof]

2nd build using the new scripts but with build_weedog_initramfs05_s100.sh patched to mount with size=100% and to mount my sda3 swap partition ...

Code: Select all

--- build_weedog_initramfs05_s100.sh.orig	2019-08-29 22:07:34.784867156 +0100
+++ build_weedog_initramfs05_s100.sh	2019-08-29 22:10:31.740861058 +0100
@@ -145,7 +145,11 @@
 # Create tmpfs in RAM should grub kernel line request copy2ram or changes=RAM
 if [ \$copy2ram -eq 0 ] || [ "\$changes" == "RAM" ]; then
 	mkdir -p /mnt/layers/RAM
-	mount -o mode=1777,nosuid,nodev -n -t tmpfs inram /mnt/layers/RAM # might prefer size limit
+	mount -o mode=1777,nosuid,nodev,size=100% -n -t tmpfs inram /mnt/layers/RAM # might prefer size limit
+	# Rufwoof
+	swapon /dev/sda3
+	mount -o remount,size=13G /mnt/layers/RAM
+	# /Rufwoof
 fi
 
 cd "\${bootfrom}" # where the NN files/dirs and rdshN.plug files are

... so its more stable when running solely in ram/swap.

Video editing (kdenlive, editing a 1 hour long recording) in just ram/swap seems to be working fine

[wiak]

The more generic
metric=`expr $metric + 1`
runs slower as it starts a separate expr process per increment, but when the number of increments is low, having a script that is more inclined to work if deployed across different shells ???

Yes, maybe, but I think it is only the old Bourne shell that can only evaluate maths that way, so recommended patch $((metric+1)) should be fine and who knows some issue may not otherwise somehow crop up with 'expr' ...? Debatable I suppose.

wiak

[wiak]

https://lists.debian.org/debian-boot/20 ... 00853.html

The easy solution is to use $((metric=metric+1)) instead.

[wiak]

2nd build using the new scripts but with build_weedog_initramfs05_s100.sh patched to mount with size=100%

I'll also add the kernel line "option" to set size in next build_weedog_initramfs script.

I'll also create a linked post that contains submitted firstrib00.plug files, or maybe better simply links to where people post them (since I realise such plugins tend to get regularly updated/added-to).

EDIT: Also, a complex firstrib00.plug often needs its creator to provide extra usage instructions, so linking to firstrib00.plug contributions is better. The main scripts have licence MIT, but since the plugins are separate and only sourced if wished. Good if you put header line comments in your plugin to at least author name, revision number, and date them.

I want to give plugin contributions high prominence on this threads main first post since, aside from WeeDog initramfs provided facilities, the final distro behaviour, integration, utilities, and look and feel depends on the plugin created and used.

wiak

[wiak]

First page of thread now contains links, as below to both build script downloads, and also to user-contributed downloads/information, per below:
===============================================

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

For downloads, see here:

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, i386, arm64 (though build_weedog_initramfs needs modded for arm64 use).

Download locations for additional/optional USER-CONTRIBUTED firstrib plugins:

Please contact me concerning omissions and updates thereafter, wiak

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

[rockedge]

I am testing a almost complete version of the script that will install a LHMP and compile ZoneMinder from source using the master branch of the cutting edge development version of ZM

I will produce a copy using the format indicated by wiak.

I am hammering out the best way to complete the hiawatha.conf and set up the php.ini and /etc/php/conf.d with the symlinks for the needed PHP modules required using the script fully automated

the test is using a firstrib00.plug very similar to the draft i posted a while ago creating a desktop Void Linux based using jwm and rox --pinboard with a few tools included...to build the OS and then letting the ZM_build.sh run after the OS can boot up.

although anyone could manually use the script as a guide and install zoneminder step by step for more control on that process

First runs are showing an OS with a complete LHMP and ZM running in 275 megs of RAM


__

[tallboy]

Hi wiak, I'll play with the new tools, but please, please don't use yellow text!

[wiak]

Hi wiak, I'll play with the new tools, but please, please don't use yellow text!

Actually it was bold orange. Not using red or green in case reader is colour-blind though.

I actually like orange (and yellow) since it is the colour of the warm tropics, but maybe not the colour of cross-country skiing over frozen lakes lands.

wiak

[tallboy]

I'll put on some sunglasses!

[wiak]

Attached is WeeDog Linux void flavour running MATE Desktop Environment.

I built it using a firstrib00.plug I'm experimenting with - took ages to download all the bits on my 200kB/sec rural broadband connection though.

It's a lovely desktop to use, but its flaky for me right now - some kind of runaway process eating CPU cycles, so I can't recommend it unless I can find a fix for that.

wiak

[wiak]

I find dash a bit of a pain when it is installed and becomes system shell.

Easy way of changing back from dash to bash (and vice-versa) in Void Linux is to run the command:

Code: Select all

xbps-alternatives --set bash

that automatically symlinks everything correctly.

wiak

[rufwoof]

Attached is WeeDog Linux void flavour running MATE Desktop Environment.

I built it using a firstrib00.plug I'm experimenting with - took ages to download all the bits on my 200kB/sec rural broadband connection though.

It's a lovely desktop to use, but its flaky for me right now

https://voidlinux.org/news/2014/09/MATE-desktop.html
suggests

The minimal MATE desktop is available in the mate meta-package, and all its extra applications (Atril, Pluma, applets, etc) are in the mate-extra package. For additional functionality the ConsoleKit and upower0 packages must also be installed.

To install all MATE packages with full functionality:

# xbps-install -Sv mate mate-extra ConsoleKit upower0
# ln -s /etc/sv/dbus /var/service/
Use mate-session to start it via ~/.xinitrc

NOTE: ConsoleKit no longer exits in the repo, its now ConsoleKit2.
Also with that in firstrib00.plug it will fail as it prompts for a y/n answer and seems to default to no. Adding -y to the xbps-install parameters should override that ?? (trying it now, took less than 10 mins to build (using lz4 -Xhc compression) - just about to boot (745MB initrd sfs))

[wiak]

Attached is WeeDog Linux void flavour running MATE Desktop Environment.

I built it using a firstrib00.plug I'm experimenting with - took ages to download all the bits on my 200kB/sec rural broadband connection though.

It's a lovely desktop to use, but its flaky for me right now

https://voidlinux.org/news/2014/09/MATE-desktop.html
suggests

The minimal MATE desktop is available in the mate meta-package, and all its extra applications (Atril, Pluma, applets, etc) are in the mate-extra package. For additional functionality the ConsoleKit and upower0 packages must also be installed.

To install all MATE packages with full functionality:

# xbps-install -Sv mate mate-extra ConsoleKit upower0
# ln -s /etc/sv/dbus /var/service/
Use mate-session to start it via ~/.xinitrc

I'll try again with that suggestion if I can't otherwise fix it (problem is something to do with gvfs-related process as far as I recall, not on the system just now - probably don't need these bits at all, unless they turn out to be dependencies of some other MATE stuff). I was installing mate-extra.

I was using LXDM to start it all up.

wiak

[rockedge]

Easy way of changing back from dash to bash (and vice-versa) in Void Linux is to run the command:

Code: Select all

xbps-alternatives --set bash

very cool tip...I was looking for this for my firstrib00.plug

[rufwoof]

something to do with gvfs-related process as far as I recall

gvfsd-trash produced similar high cpu for me. After killing that it settled down. Rebooting however after saving changes and the problem returned. Repeatedly killall caja after first boot/login ... until no more caja kills occur and the cpu usage dips to near zero.

[wiak]

Hi wiak, I'll play with the new tools, but please, please don't use yellow text!

Hi tallboy,

(I'm tempted to write this in bold orange text in case you still have your snow sunglasses on...)

Once you have done a quick default build, by running the two build scripts one after the other (best/being from an empty directory you intend to boot from - be that on hard disk or usb stick doesn't matter) let us know. If you have any trouble getting that to boot, just tell us what files you have and what your grub or grub4dos configuration is (i.e. the menu.lst details you are using). When you are new to a distro, getting it to boot is trickiest on the first occasion - once you have that sorted out it becomes easy thereafter of course. I'd advise you just try to build and then boot the default

Code: Select all

./build_firstrib_rootfs_100.sh void rolling amd64 firstrib00.plug_void_default_anyarch

(or use i386 instead of amd64 for 32bit system build)

Then, once that first stage finished (can take a wee while - have a coffee and be patient), simply run second script with command:

Code: Select all

./build_weedog_initramfs05_s100.sh void

The result (takes a wee while too) should be the following files available that grub uses to boot:

01firstrib_rootfs.sfs, initramfs05.gz, vmlinuzXXXXXXX

These three are all that menu.lst needs to boot (though I normally rename vmlinuzXXXXXXX simply to vmlinuz).

My menu.lst might then be (if say using Linux formatted, say ext2, usb stick at /mnt/sdb1 with the above three files stored in directory /weedog on that):

Code: Select all

title WeeDog Linux
root (hd1,0)
kernel /weedog/vmlinuzX.XX usbwait=12 bootfrom=/mnt/sdb1/weedog
initrd /weedog/initramfs05.gz

EDIT: there is a chance above won't work if system doesn't see the usb stick as /mnt/sdb1, of course, in which case, you best to use usb stick's uuid, which you find with blkid command, instead of using: root (hd1,0) - if you don't know about uuid and blikid we can explain about it later should you have trouble getting WeeDog to boot.

Assuming your grub is working okay, that should boot up fine to the commandline. If so, you are home and dry. Obviously though you then need to learn the commands/method to get on the Internet (I always just use wifi myself but ethernet even easier) and learn how to add new apps (such as X windows - or do a second build later with a firstrib00.plug file by someone else, like rufwoof or rockedge, that has X etc all done for you). Main thing is that at any of these stages we can easily help out since been playing with this for months now so know all the tricks to get it Internet connected and so on (very simple commands to do that actually).

Good thing about using this system, is that Void Linux repos and native package manager (xbps) uses makes it easy to try out lots of desktop managers and so (JWM, or openbox, or MATE, LXDE and so on). And the resultant desktop is amazingly efficient, according to our tests, in terms of RAM and CPU used.

Finally WeeDog initramfs has some nice tricks in terms of save persistence and copy2ram and so on, and more to come - easy to learn and easy to use - worth persevering with I'd say (and not because I'm biased).

wiak

[wiak]

I made some further progress today, without adding any bloat, just fixes and a couple of facilities discussed on the thread (including option to set tmpfs size and also the rockedge discovered udhcpc default script fix). I haven't quite finished coding the small changes yet, and still have to test them, but expect to publish the new build scripts tomorrow since the changes are so small. As I say, nothing major but a couple of useful new options.

The updated scripts won't however upset any existing firstrib00.plug plugins, existing or being developed; these will work just fine as before.

Once I've released that update I'm hoping to get on with a few actual builds of my own since I've yet to prepare a desktop for my own daily use, and am keen to do so. Just for fun I might make a few ubuntu or debian builds too (extended firstrib00.plug_ubuntu/deb plugins - that should be pretty easy). I also want to play with rufwoof's merge-changes.sh script and maybe make a little make iso script since it might be worth producing a small iso for those who may never enjoy the true pleasure of Void xbps package management otherwise...

I suppose I should try and script produce a stripped down iso (for size) but seems like a lot of effort, though would be useful for copy2ram case on older computers - I'm not sure I will get round to that though since it has low priority for me.

Thereafter, learning package production via xbps-src would probably a good idea.

For anyone new to this who keeps forgetting whether the Void package manager name is xpbs or xbps (or was it just me that had that problem?); I remember the ps comes at the end because it is like the ps command used to display "snapshot of current processes" though xbps really has nothing to do with ps command of course

wiak

[tallboy]

Thank you for the guidance, wiak.

[rockedge]

learning package production via xbps-src would probably a good idea.

you and me both! I really would like to manage to make a Void package of zoneminder...once I have the steps / script worked out.

the ZM build script is doing some things that are unexpected occasionally and I am working on that. ZM as a Void package would really compact the set up as well eliminating all the development libraries need to compile

[rufwoof]

I suppose I should try and script produce a stripped down iso (for size) but seems like a lot of effort, though would be useful for copy2ram case on older computers - I'm not sure I will get round to that though since it has low priority for me.

In addition to set the default mksquashfs to lzo -Xhc, in build_weedog_initramfs05_s100.sh I modify the code to (snippet) ...

Code: Select all

# Create tmpfs in RAM should grub kernel line request copy2ram or changes=RAM
if [ \$copy2ram -eq 0 ] || [ "\$changes" == "RAM" ]; then
        mkdir -p /mnt/layers/RAM
        mount -o mode=1777,nosuid,nodev,size=100% -n -t tmpfs inram /mnt/layers/RAM # might prefe
r size limit
        # Rufwoof
        swapon /dev/sda3
        mount -o remount,size=13G /mnt/layers/RAM
        # /Rufwoof
fi

where sda3 is my swap partition. So conceptually I could load up to 13GB into ram (plus swap).

Using extreme mksquashfs compression I can get the main sfs down to 1GB, that's with kdenlive, chromium, full libre office suite, audacity ...etc. Not sure how that might fair if loaded into perhaps 1GB of actual ram and say 4GB of swap partition, suspect it would still work, but you'd have to be patient at times.

And of course you could use a swap file as a alternative to a dedicated swap partition. Difficult to test on my 4GB system, as even if I load up a 8GB sfs to load at bootup (copy2ram), the system would tend to rapidly swap out the stuff that wasn't being used and keep only the most commonly used stuff in actual ram.

One aspect of using swap is that shutdown's can be slowed by the swapoff process that's triggered as part of shutdown. If you're running solely in ram however you could just hit the power off button, but that could corrupt swap such that it wasn't loaded at the next reboot. Similarly forced/immediate reboot/power off (that runs without running swapoff) might do similar. I guess however that a startup process to clean swap could be added.