RC7 (STABLE) WeeDogLinux Arch 64 now released

[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.

[rufwoof]

As I already run all in ram/swap, and as I have 4GB of ram + 10GB of swap, and as my firstrib_rootfs folder content is 3.6GB in total, out of interest I'm making a sfs of that with no compression (-noX -noI -noD -noF mksquashfs parameters). Doing that now.

Conceptually that will be slower than using lz4 -Xhc compression that reduces the sfs filesize down to around 1.4GB, as lz4 runs multi-core when compressing/decompressing and at speeds that can on larger systems (4 cores+) yield throughput that compares to ram speeds (less physical I/O and instead throwing decompressed data out at lighting speeds).

Purely out of interest to see if that will load and run, and if so how well it runs. Will report back later.

EDIT: Well boots ok. After first boot to cli and logging in as root, free -m indicates

Code: Select all

              total        used        free      shared  buff/cache   available
Mem:           3408         169         159        2949        3079         110
Swap:         10239         418        9821

After starting up (which also starts chromium)

Code: Select all

              total        used        free      shared  buff/cache   available
Mem:           3408         381         137        2151        2889         643
Swap:         10239        1235        9004

... and after starting up kdenlive and loading a 1 hour video for editing, as well as also starting LibreOffice calc

Code: Select all

              total        used        free      shared  buff/cache   available
Mem:           3408         867         389        1278        2151        1029
Swap:         10239        2152        8087

Operationally OK, there was a slight jitter initially on playing the kdenlive video, but that rapidly disappeared. That 2GB of swap utilisation would take some time to clear on (swapoff) shutdown but that could be circumvented.

That's with a 01firstrib_rootfs.sfs filesize of

Code: Select all

# ls -lart /mnt/sda1/VOID2/01*
-rw-r--r-- 1 root root 3529768960 Aug 31 19:39 /mnt/sda1/VOID2/01firstrib_rootfs.sfs

Initially I was directly loading that 1 hour video into kdenlive for editing from hdd. After copying that to /root so I could umount the hdd and with kdenlive editing that /root based copy of the video

Code: Select all

# df -h
Filesystem      Size  Used Avail Use% Mounted on
inram            13G  3.8G  9.3G  29% /mnt/layers/RAM
overlay_result   13G  3.8G  9.3G  29% /
run             1.7G  688K  1.7G   1% /run
dev             1.7G  8.0K  1.7G   1% /dev
shm             1.7G   23M  1.7G   2% /dev/shm
cgroup          1.7G     0  1.7G   0% /sys/fs/cgroup
tmpfs           1.7G  369M  1.4G  22% /tmp

where the .mp4 file being edited shows a size of 403746084 bytes.

For reboot I stopped kdenlive, removed the /root copy of the .mp4 file, closed Chromium and Libre Calc and as man reboot indicated

-n Don't sync before reboot or halt. Note that the kernel and
storage drivers may still sync.

and in expectation of a long wait for shutdown as swapoff might otherwise be run, I tried that reboot -n option (swap was showing 2.7GB being used at that time) ... and reboot was as good as normal (fast)

Personally I think that ram+swap option, at least for voidlinux style boots is great, as your 'ram' is just limited to the amount of free disk space. Yes on ram challenged systems having too much in swap, too little actual ram would tend to see sluggishness, but conceptually it would still run 'correctly'.

I suspect that loading into ram+swap in initrd doesn't get released and continues to remain available after the switch-root as switch-root only closes any free files (in unix everything is a file), so as swap isn't closed, it continues to remain available/used. Again at least as far as voidlinux is kernel is concerned.

Yes that is somewhat cheating as its like using hdd, but where the 'storage' area is within the swap partition instead of on a ext2/3/4/whatever partition. Would be nice if encrypted swap could be utilised, however I suspect that isn't something that could be passed over from initrd to the main system (at least I couldn't get that to work last time I tried some time back).

[rockedge]

just want to add I borrowed retrovol-0.10-x86_64.pet opened it up with xarchiver and extracted and installed manually. works really well on my WeeDog (Void).

http://www.murga-linux.com/puppy/viewtopic.php?t=69486

[rufwoof]

http://murga-linux.com/puppy/viewtopic. ... 78#1035078 updated to use functions style layout so its easier to comment out whole blocks of code/script such as if the latest version of mc has config files that don't match what is being modified within firstrib00.plug. As part of that I've also extended the script to build some source code. As isomaster isn't in the voidlinux repo and is simple enough to compile that seemed like a good starter candidate and here's the firstrib00.plug code section I've used to do that

Code: Select all

###########################################
# ISOMASTER
# Work in progress ... as a test, download isomaster source

_isomaster () {

  # Requires : xbps-install gcc make gtk+-devel pkg-config gettext

  cd /usr/src
  wget -c http://littlesvr.ca/isomaster/releases/isomaster-1.3.14.tar.bz2
  tar xvfj isomaster-1.3.14.tar.bz2

  # Simple build process that only requires us to run 'make'
  cd isomaster-1.3.14
  make
  make install

}

[wiak]

http://murga-linux.com/puppy/viewtopic. ... 78#1035078 updated to use functions style layout so its easier to comment out whole blocks of code/script such as if the latest version of mc has config files that don't match what is being modified within firstrib00.plug. As part of that I've also extended the script to build some source code.

Interesting plugin. Keep up the good work rufwoof.

WeeDog is creeping up the Distrowatch_murga rankings (a one of snapshot just for fun sample average thread views/day count), despite its short/limited exposure to the general public and taking into consideration its slow start:

http://www.murga-linux.com/puppy/viewto ... ?p=1035827

wiak

EDIT: I've completed the build script updates (including inram tmpfs size option and udhcpc default.script fix) but still have to do testing after which I'll upload tomorrow or whenever I'm satisfied all seems to be working. I've added plugin source location so you can also mount your swap via suitable code plugin (and I can also provide plugin for zram swap I think). That way you can add instructions/plugin for doing so on your related firstrib00.plug contribution pages if you wish.

[wiak]

Void Linux de repo seems to be down at the moment (or maybe too many people building a Firstrib Void root filesystem??? I hope not...), so I am making build rootfs with us repo (via using attached firstrib.repo plugin placed in same folder as build_firstrib_rootfs_NNN.sh script).

EDIT: It's odd, so I'm delaying upload of new versions of build scripts till sorted out. Is anyone else having an issue. In particular, are you able to access repo link (from your browser)? I can't.:

https://alpha.de.repo.voidlinux.org/static

EDIT2: Okay, it's back now

wiak