RC7 (STABLE) WeeDogLinux Arch 64 now released

[wiak]

Just a reminder that you can build_firstrib_rootfs using alternative void repos (I'm busy building using rockedge's plugin right now and .de repo was proving a bit slow; tho could be my internet provider causing slowness...). To use alternative repo just create text file firstrib.repo and put single text line:

Code: Select all

repo="url_of_repo"

https://voidlinux.org/usage/xbps/#introduction

Tier 1 Mirrors

http://alpha.de.repo.voidlinux.org (EU: Germany)
http://beta.de.repo.voidlinux.org (EU: Germany)
http://alpha.us.repo.voidlinux.org (USA: Kansas City)
http://mirror.clarkson.edu/voidlinux/ (USA: New York)
http://mirrors.servercentral.com/voidlinux/ (USA: Chicago)

Tier 2 Mirrors

http://mirror.aarnet.edu.au/pub/voidlinux/ (AU: Canberra)
http://ftp.swin.edu.au/voidlinux/ (AU: Melbourne)
http://ftp.acc.umu.se/mirror/voidlinux.eu/ (EU: Sweden)
https://mirrors.dotsrc.org/voidlinux/ (EU: Denmark)
http://www.gtlib.gatech.edu/pub/VoidLinux/ (USA: Atlanta)
https://void.webconverger.org/ (APAN: Singapore)
https://youngjin.io/voidlinux (APAN: South Korea)
http://ftp.lysator.liu.se/pub/voidlinux (EU: Sweden)
http://lysator7eknrfl47rlyxvgeamrv7ucef ... /voidlinux (EU: Sweden)

wiak

[wiak]

In your firstrib00-64.plug, rockedge, this is a problem:

Code: Select all

tar xvfz xlunch_4.1.1-1_amd64.tar.gz
cd xlunch_4.1.1-1_i386

i.e. At line 348: the i386 above should be amd64.

To save me rebuilding, I just manually completed the xlunch-related commands later using umount_chroot007.sh

wiak

[rockedge]

Thanks wiak...I noticed also and have fixed it in the uploads.

I also fixed in /usr/local/bin/xluncher3 the wmreboot and wmpoweroff to reboot and poweroff so the xlunch logout from there works

I am thinking about having only one source for the plugs and build_ZM.sh and using a github location.

UPDATE: started here -> https://github.com/techrockedge/weedog-ZM



*

[rufwoof]

Just a reminder that you can build_firstrib_rootfs using alternative void repos
.
.

Code: Select all

repo="url_of_repo"

.
.

If you are operating a Tier 2 mirror and would like to be on this list, please either file a pull request or reach out to maldridge[at]voidlinux.eu.

Caution : voidlinux.eu is not AFAIK actually under the control of voidlinux. Recall a warning being put out by voidlinux not to trust that site/url, so the same would also apply to emails. That said, maldridge I believe does post news items on the official voidlinux website, so it might be OK, but then again that could be a intentional spoof.

...dig ... https://voidlinux.org/news/2019/02/void ... -gone.html

12.02.2019
VoidLinux.eu Is Not Ours
We would like to warn people of a domain name that is no longer under Void Linux control. voidlinux.eu lapsed in its original registration, and was purchased by an unknown 3rd party before Void Linux could regain ownership. At this time, please assume that anything involving voidlinux.eu is not related to Void Linux, and should be considered potentially malicious. Of course, if the person who owns the domain now would like to transfer it to our control, we’d be grateful, and will update voidlinux.org to indicate if this happens.

Our official domain is VoidLinux.org.

[seaside]

LATEST RELEASES ARE:


build_firstrib_rootfs_103.sh:

Put sleep 1 on either side of "rm /usr/bin/xbps*.static" in the chroot part of void functions. Doing so in hope fixes issue forum member seaside had. Basically giving time to make sure installs being made in chroot by xbps static version are completed before deleting it and thereafter continuing installs using the shared library xbps version. Won't do any harm anyway.

So I'd much appreciate if seaside could test the new scripts to see if this attempted fix works.

wiak

wiak,

I've tested and the failure is not caused by a timing factor. It has to do with using an older C library version (2.15) distribution. None of the newer version distributions I tested needed a sleep.

Cheers and Thanks,
s
(Playing with older distributions can be injurious to sanity )

[wiak]

I've tested and the failure is not caused by a timing factor. It has to do with using an older C library version (2.15) distribution. None of the newer version distributions I tested needed a sleep.

Thanks seaside, I'll take out the sleeps for next version.

wiak

@rufwoof: Thanks. I just copied and pasted from Void site, but you are correct, I also know about that warning re:void.eu domain not being owned by Void anymore. I'll delete that bit. I see somebody is running what seems to be a fake Void/Linux page, in Spanish, at the main web address voidlinux dot eu. Maybe dodgy to visit that. I have no idea what their point is and why they don't simply negotiate to transfer it back to official Void.

[wiak]

I am thinking about having only one source for the plugs and build_ZM.sh and using a github location.

UPDATE: started here -> https://github.com/techrockedge/weedog-ZM

Thanks rockedge. I presume you will add that link to the main thread post about your system and remove the files available there?

Eventually I may do something similar with the core build scripts, but for the moment my firstrib github site is not up-to-date and I intend rebuilding it.

wiak

[rufwoof]

@rufwoof: Thanks. I just copied and pasted from Void site, but you are correct, I also know about that warning re:void.eu domain not being owned by Void anymore. I'll delete that bit. I see somebody is running what seems to be a fake Void/Linux page, in Spanish, at the main web address voidlinux dot eu. Maybe dodgy to visit that. I have no idea what their point is and why they don't simply negotiate to transfer it back to official Void.

Juan, who has done NetBSD work, and wrote X binary package system (xbps) lives in Spain. Goes under the sig xtraeme, so perhaps originally it was the xtraeme binary package system ?? Looks like he's active again with voidlinux, something like a massive 700+ pull requests/commits last month !!! Could be a case of personal history/issues as it does seem odd that the .eu hasn't been released. As long as everyone concerned is aware of avoiding .eu then that fades into being a non-event.

[rufwoof]

Just a reminder that you can build_firstrib_rootfs using alternative void repos (I'm busy building using rockedge's plugin right now and .de repo was proving a bit slow; tho could be my internet provider causing slowness...). To use alternative repo just create text file firstrib.repo and put single text line:

Code: Select all

repo="url_of_repo"

Now that I have my local repo inside a file filesystem, I've just snitched rockedge's code for hiawatha and I'm installing that as part of my core installation set ... which means I can use a local web server to serve up the repo. Just finished rsync'ing the local repo and it looks like hiawatha is serving OK so about to try that firstrib.repo build option. I have had to add rsync'ing of the static folder as well as I saw that being used in the build scripts.

BTW a recent build earlier today with the lastest versions of build script all worked OK for me (using the official/main repo).

[rufwoof]

hiawatha web server, as per the voidlinux bin, can't be set to serve as root and without root the web server hasn't the permissions to serve up the content of a local repo.

As a alternative, running - as a quick test

Code: Select all

python2 -m SimpleHTTPServer 80

as a web server (serving up files in the current working directory) and running that as root, and setting the firstrib.repo to point to http://0.0.0.0 as the repo server ... seems to have worked.

So basically, mount the repo file filesystem, cd into that and run the above python2 command with a & to background it ... to start the repo being served via http, and set firstrib.repo content to point to that.

[rockedge]

rufwoof did you try to declare the /local_repo as an Alias in the hiawatha .conf and adjust the permissions of the /local_repo with

Code: Select all

chown -R www-data:root  /the/path/to-the/local_repo

to the hiawatha.conf add

Code: Select all

Aiias = /local-repo:/the/path/to-the/local_repo

restart hiawatha with :

Code: Select all

killall hiawatha
hiawatha

this may work to serve the local_repo over

Code: Select all

http://localhost/local_repo

Also look at the Directory block configuration here https://www.hiawatha-webserver.org/manpages/hiawatha


*
*

[rufwoof]

Hi rockedge. I did start down that path, but then dropped that repo file filesystem (copied back a backup) in mind that the next rsync might not like the ownership changes. Thanks for the pointers. I intend to have a play with the setup/configuration but using a smaller data set as the 42GB current repo data set takes half a hour just to copy.

[wiak]

For the moment I'm feeling that build_firstrib_rootfs and build_weedog_initramfs05 appear now to be working well and are sufficiently flexible for most current needs.

The continuing development of rockedge's JWM desktop plugin along with its custom use of hiawatha webserver, Zoneminder, and so on, is very useful and important, as is the interesting ongoing developments/desktop/etc ideas and implementations of rockedge - with special mention there going to the merge-changes utility. Presumably they will have their own thread soon, since there is alot to detail about them.

For my part, the stability of the current build system allows me to start playing with it myself too! But also, it would be good to find ways of encouraging others to try it all out and eventually maybe contribute (since there is no end to what we can do with it). I'm therefore thinking of making a small initial iso (for those who initially may have an aversion to building via scripts, perhaps not realizing just how easy the system is to build). But along with that iso maybe then include a menu driven quick install of chosen desktop sort of facility.

So far we have mainly been focussing on Void-based system, but Debian/Ubuntu/Devuan based systems (also using WeeDog initramfs) would also be useful contributions (and pretty easy to build up into full WeeDog controlled desktop systems since plenty of experience of Debian-based systems on this forum more generally).

Any ideas and implementations concerning any of the above would be very welcome - or other ideas/implementations altogether. As far as I'm concerned most developments in terms of building up full desktop working systems is very much up to the community who chose to use the build system/WeeDog initramfs facilities. So basically, I'd like to see a small iso put together, either coming with the simplest of desktops or simple commandline-based, but in either case with a quick-install script/menu/whatever to build up the system into fuller form. I'd be happy if anyone produced such, since I may be slow getting round to anything myself (being spring here now and so I'm out and about not coding so much probably).

I know it is easy to simply build system from scratch using the build scripts and provided/modified firstrib plugins, but might be found easier by others to boot wee iso with menu for more - developing that menu system for alternative desktops would provide a fertile ground for further contributiosn/ideas IMO. Main thing I would hope for would be something very simple in every sense to start with at least.

EDIT: for the most part, should be simple to source already produced firstrib00 plugins from an already booted small WeeDog.

wiak

[rufwoof]

Just running a build with a alternative save method that uses a tar of the /mnt/layers/RAM/upper_changes folder i.e. for when booted with changes=RAM, where otherwise all changes would be lost at shutdown/reboot.

cd to hdd save storage location and ...
tar --exclude='run' --exclude='mnt' -zcvf snapshot.tgz /mnt/layers/RAM/upper_changes

Along with a rdsh3 kernel boot parameter (and/or rdsh3.plug) that pauses within initramfs where the upper_changes folder is empty at that point, but can have the tar file extracted to populate it with the save tarfile content i.e. tar xvf /mnt/sda1/snapshot.tgz

Different/separate save files could be created at different times and the choice of save file loaded made by storing snapshot.tgz to different names and selecting which of those to be loaded during bootup.

[wiak]

Just running a build with a alternative save method that uses a tar of the /mnt/layers/RAM/upper_changes folder i.e. for when booted with changes=RAM, where otherwise all changes would be lost at shutdown/reboot.

Using tar like that is a good way of excluding anything you don't want to save, and also, the result being an archive file, it could be easily compressed as you go, and would also work with non-Linux underlying filesystems, such as ntfs. On Linux filesystems, rufwoof, aside from being able to easily exclude (and handy the save being a file sometimes), what is the advantage to simply copying the inram upper_changes folder to an external media folder for use if wished during next boot?

EDIT: Ah... or is that tar being untarred back into the overall system next run (such as tinycorelinux does with its small tarred up save file) rather than just untarring back an upper_changes folder (I think that's what it is? EDIT2: no, I think what you're meaning is untarring back upper_changes folder on reboot whist still in copy2ram mode, so untarring back to the otherwise empty inram upper_changes?).

wiak

[rufwoof]

I'm running with changes=RAM so upper_changes folder is in ram. 'save' just tar's up that folder excluding /run and /mnt folders storing that tar file on hdd.

rdsh3 has upper_changes created in ram, but empty at that point. With rdsh3 kernel boot parameter the rdsh3.plug I'm using with that currently looks like ...

Code: Select all

CD=`pwd`
cd /mnt/layers/RAM
clear
read -s -n1 -t 10 -p "Press <ENTER> or <SPACE> within 10 seconds to NOT AUTO LOAD THE SAVE FILE "
if [ $? -eq 0 ]; then # ENTER (or space) pressed
	clear
	echo "Press <ENTER> or <SPACE> to continue booting without loading a save file"
	echo -n "Or press any other key to drop to initramfs shell "
	read -s -n1 SELECT
	if [ "$SELECT" != "" ]; then
	    clear
	    echo "Populate (OR NOT) /mnt/layers/RAM/upper_changes as desired/required"
	    echo "i.e. cd /mnt/layers/RAM;tar xvf /mnt/sda1/snapshot.tgz"
	    echo
	    echo "Run 'exit' when done to resume bootup"
    	    setsid cttyhack /bin/sh
	fi
	clear
else
    tar xf /mnt/sda1/snapshot.tgz
fi
cd $CD

so on bootup it pauses for 10 seconds (at the rdsh3 point) and if no keyboard action occurs it just carries on booting and automatically loads the save file (tar). Or if Enter is pressed it prompts to either press Enter again to resume bootup (with upper_changes remaining empty i.e. no save file loaded), or any other key to drop into initramfs shell (for instance to load a different save file into upper_changes or whatever).

My current save.sh script that runs within the main system currently looks like

Code: Select all

cd /mnt/layers/RAM
if [ -f /mnt/sda1/snapshot.tgz ]; then
    if [ -f /mnt/sda1/snapshot.tgz.bak ]; then
              mv /mnt/sda1/snapshot.tgz.bak /mnt/sda1/snapshot.tgz.old
    fi
    mv /mnt/sda1/snapshot.tgz /mnt/sda1/snapshot.tgz.bak
fi
tar --exclude=\'run\' --exclude=\'mnt\' -zcvf /mnt/sda1/snapshot.tgz upper_changes

i.e. creates the save tar file (snapshot.tgz) of upper_changes (that's ram based). Keeping three copies (the one just created, old one renamed to .bak, and former .bak renamed to .old).

Manually you could rename/copy snapshot.tgz as you liked, i.e. have multiple choice of 'saves' to load as desired.

Using a compressed tar file to store upper_changes as you say makes it more portable. Just copying upper_changes folder/content to hdd if it was for instance a windows partition being used to store that and file/folder permissions etc. could be converted/lost.

Could have used mksquashfs/unsquashfs in a similar fashion, but tar is in in the default initramfs whereas mksquashfs isn't.

[wiak]

Manually you could rename/copy snapshot.tgz as you liked, i.e. have multiple choice of 'saves' to load as desired.

Using a compressed tar file to store upper_changes as you say makes it more portable. Just copying upper_changes folder/content to hdd if it was for instance a windows partition being used to store that and file/folder permissions etc. could be converted/lost..

Ah yes, that works nicely. Sorry I was just up and rushing about taking my partner to her work and just quickly glancing at your previous post. Now I'm away for a coffee...

wiak

[rufwoof]

Other changes I've made is to the hot corner detection script, that monitors the mouse location and launches skippy-xd (window selector) if the mouse moves into the bottom left corner, or xlunch (program launcher) if the mouse moves into the top left corner. Along with xload an volumeicon that were installed via the package manager (xbps-install), I've scripted a battery level indicator (100% charged at present so all blue, but as the available power level declines it turns progressively red); Also a caps lock indicator (lower case a and upper case A); Also a cpu temperature indicator that along with showing the temperature as a digital readout, changes colour (orange when 'relatively warm', red when 'hot'). I snitched code from others to do the automatic .svg image file creation for those.

Having that all in the single 'hot corner' script means I can refine how often each is tested/updated. hotcorners is tested at every loop, as is caps lock, whereas the temperature and battery levels are at around 10 second interval updates. Which all helps to lower overall cpu usage and keep the system cooler.

The date/time jwm tray clock ... as pretty much standard for me, has it function as a show/hide desktop when left mouse clicked, show jwm menu when right mouse clicked. I don't bother with multiple desktops as I tend to have each window maximised and just flip between windows rather than desktops.

Script as attached (xload is loaded separately - as part of .jwmrc).

[rufwoof]

Rather than running wiaks build firstrib script, a alternative is to use the voidlinux tarball to set up the main filesystem. Here's my notes for that (so its only using wiak's build_weedog_initramfs script). Sorry, they are quite lengthy, but better that than nowt.

Code: Select all

Download the voidlinux rootfs live image tarball from
https://a-hel-fi.m.voidlinux.org/live/current/

For instance I downloaded the x86_64 rootfs tarball ...
https://a-hel-fi.m.voidlinux.org/live/current/void-x86_64-ROOTFS-20181111.tar.xz

Extract it to firstrib_rootfs and use that as the firstrib rootfs

mkdir /mnt/sda1/VL
mv void*.tar.xz /mnt/sda1/VL
cd /mnt/sda1/VL
mkdir firstrib_rootfs
cd firstrib_rootfs
tar xvf ../void*.tar.gz
cd ..

Do the chroot preparation i.e. mount binding proc ...etc.
and copy your current /etc/resolv.conf

mount --bind /proc firstrib_rootfs/proc
mount --bind /tmp firstrib_rootfs/tmp
mount --bind /dev firstrib_rootfs/dev
mount --bind /sys firstrib_rootfs/sys
mount -t devpts devpts firstrib_rootfs/dev/pts
cp /etc/resolv.conf firstrib_rootfs/etc/resolv.conf

chroot into that

chroot firstrib_rootfs

and run 
xbps-install -Su 
...so we can xbps-install things

Run
xbps-install linux 
... to install void linux vmlinux and initrd into firstrib_rootfs/boot

use xbps-install ... to install other things if desired (or just leave as-is).

ALSO SET THE ROOT PASSWORD SO ITS NOT THE DEFAULT voidlinux i.e. as root run 'passwd'

Make other edits as appropriate ... see mine as of *A* below

'exit' to exit the chroot

umount all the mounts

umount -lf firstrib_rootfs/tmp
umount -lf firstrib_rootfs/proc
umount -lf firstrib_rootfs/dev/pts
umount -lf firstrib_rootfs/dev
umount -lf firstrib_rootfs/sys

and run weedog initramfs build script on that
./build_weedog_initramfs05_s203.sh void "-comp lz4 -Xhc"
When that finishes you'll have a frugal style vmlinuz..., initramfs... 01firstrib_rootfs.sfs (my 01firstrib_rootfs.sfs is 470MB file size).

I'm using grub4dos menu.lst entry of

title VL
   root (hd0,0)
   kernel /VL/vmlinuz-5.2.17_1 bootfrom=/mnt/sda1/VL changes=RAM inram_sz=100%
   initrd /VL/initramfs05,gz

Once booted you'll have a cli system.
Set up networking, network connect and xbps-install as desired

With my rdsh3.plug and rdsh3 kernel boot parameter added, along with save.sh script then that adds persistence option (still a work in progress to make it more generic) i.e. currently generally unavailable. A alternative is not to store changes in ram (i.e. exclude the changes=RAM kernel boot parameter) but in a upper_changes folder located on hdd, but that means all changes are persistent.

Likely once up and running you'll want to install other things like xorg, chromium ..etc
xbps-install xorg chromium libreoffice .... whatever


*A*

Networking notes :

I use wifi, so I create a /etc/wpa_supplicant/wpa_supplicant.conf file that looks like

ctrl_interface=/run/wpa_supplicant
ctrl_interface_group=wheel
eapol_version=1
ap_scan=1
fast_reauth=1
update_config=1

# Add here your networks.
network={
  ssid="VM123456-2G"
  psk="abcd1234"
}

i.e. has my ssid and password (modified here to hide the actual ssid/password I use)

ifconfig shows my wireless device name to be wlp2s0, so to connect I run ...

wpa_supplicant -i wlp2s0 -c /etc/wpa_supplicant/wpa_supplicant.conf -B
dhcpcd

For alsa sound, my default card is card 1 (yours may be card 0)
and I create a /etc/asound.conf containing

defaults.pcm.card 1
defaults.ctl.card 1

pcm.!default {
	type plug
	slave.pcm "dmixer"
}

# Cant get it to work with plugequal as the slave

pcm.dmixer  {
 	type dmix
 	ipc_key 1024
 	slave {
		pcm "hw:1,0"
		period_time 0
		period_size 1024
		buffer_size 4096
		rate 44100
	}
	bindings {
		0 0
		1 1
	}
}

ctl.dmixer {
	type hw
	card 1
}

ctl.equal {
    type equal
}

pcm.plugequal {
    type equal
    card 1
    slave {
		pcm "dmixer"
	}
}


To initialise alsa at bootup I run
echo "alsactl init" >>/etc/rc.local

To actually install alsa I use ...
xbps-install alsa-tools alsa-utils alsa-plugins

[wiak]

Yes, WeeDog initramfs (to some extent) is, as I've stressed in the past, pretty much distro-agnostic (but depends if underlying root filesystem contains core controlling parts that depends on its the distro's own official initramfs - such as Puppy, for example).

So same technique, you outline rufwoof, can (and has been) used to take the rootfs contents of live Void Distros (e.g. I used the full LXDE one) and similarly the root filesystem from Slackware live. Just need the root filesystem, make sure it contains the kernel and modules installed, and then "WeeDog-it" using build_weedog_initramfs script. See attached LXDE Void in operation on attached image here:

http://murga-linux.com/puppy/viewtopic. ... 78#1033478

As touched upon in first post of this thread:

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

I also, but ultra-briefly, described the process here some while ago:

http://www.murga-linux.com/puppy/viewto ... 55#1033855

But thanks, rufwoof, for documenting the process in a proper and detailed HowTo. It might also encourage someone to take a Puppy distro and try to WeeDog-it.

I did that early on, just for an experiment, with some success (and posted about it, but can't remember where),

[EDIT: was here: http://www.murga-linux.com/puppy/viewto ... 49#1029849 but that was an attempted build from scratch - easier to add WeeDog intiramfs to ready made Puppy rootfilesystem as I did with Slackware and Void LXDE root filesystems]

but Puppy internal control/operation depends quite a bit on its own initramfs organisation and its package management depends on various spec files that need to be made available. I'm sure it would be quite simple to work around most of that if anyone wanted the WeeDog facilities via WeeDog independent initramfs use on Puppy, but probably not worth the bother in Puppy's case. WeeDog official Slackware live is nice though.

wiak