RC7 (STABLE) WeeDogLinux Arch 64 now released

[rockedge]

I never went with pulseaudio...stuck with alsa and also use alsa-tools.

soon as firefox made sound and audacity worked on my systems I did not pursue more in audio.....yet

I am testing out xlunch, xlunch log-out and a jwm tray similar to the top hybrid tray in Puppy's Bionic32. this disappearing tray is top left and as the buttons for xlunch and xlunch-logout.
rox and mc share file manager duties.

I think I'll go ahead and do the many many steps to have a successful running ZoneMinder system using rufwoof's desktop with some modification

mostly that I am across the pond from the UK sitting here in Connecticut USA, so keyboard and timezone.And of course the components needed to get this web server going

[westwest]

Thanks for the tips about VLC in ncurses, rufwoof. However, on my setup video playback is problematic. The interface pops up, i can search and load files, sound is fine, but no display.

Errors about dbus show up when starting VLC in ncurses:
"Failed to connect to the D-Bus session daemon"
"Unable to autolaunch a dbus daemon without $display for x11..."
"Interface "dbus,none" initialization failed"
"No suitable interface module"

I've tried running it in and out of tmux, with or without dbus, with or without x11 installed, in root or with user, running dbus-launch, etc. Same result accross the board. Could not find any relevant solution on other forums either.

Any help appreciated.

[Smithy]

Hi Wiak,

1. Do you have an ISO available with basic hardware, sound and video card recognition?

2. What range of computers is it suitable for: Pentium 1 mmx, Pentium 2, Pentium 3,
Core2Duo, DualCore, Xeon, AMD, i3/i5/i7.

You know where you are with an ISO.
Can burn to disc, or open it up and transfer the files to a USB and boot with a bootloader,
Idlinux, syslinux, maggotty grub.

Wanderer’s Tiny Core was interesting because it booted up (even though it paused at a menu and should have just gone straight to the desktop imo).
But it could have done with having audio and video ready and hardware recognised.
Still it is a tiny miracle.

[wiak]

Hi Wiak,

1. Do you have an ISO available with basic hardware, sound and video card recognition?

2. What range of computers is it suitable for: Pentium 1 mmx, Pentium 2, Pentium 3,
Core2Duo, DualCore, Xeon, AMD, i3/i5/i7.

You know where you are with an ISO.
Can burn to disc, or open it up and transfer the files to a USB and boot with a bootloader,
Idlinux, syslinux, maggotty grub.

Well, the vmlinuz, initramfs.gz and main rootfilesystem (sfs file) are automatically already produced by the simple/fast two-script build system, so don't need to open up an iso to get them. You simply boot these via, as you say, grub, or could use syslinux etc (booting from harddrive or usb etc). Instructions are provided in the readme file.

Having said that, someone could easily enough make a CD bootable iso using some make iso utility or xorriso app via make-iso script (and ally might upload such an WeeDog iso to that archive he contributes to). I may make such a utility later - too busy on developing the core system build scripts at the moment though. Frankly though, it is really easy as it is without bothering with iso though - my own ten or eleven years old development laptop does have a DVD drive though (becoming rare in more modern machines).

My machine is Core2Duo - I doubt it would work on Pentium 3 or less, but the others you mention possibly okay.

Thanks to upstream Void Linux extensive firmware/module support, it supports lots of audio/video/wifi etc etc hardware I would imagine; only lots of testing could confirm that though, which is not something I can do on the little hardware I have.

You should be aware, that this is a build system - it is up to the user to build the system up to the exact form they wish (a plugin can be created so users can build any power of X desktop, for example, they wish - rufwoof provided one such firstrib00.plug for that purpose). Maybe he could produce an iso of that - but the iso would be huge because none of us has concentrated on slimming the system down (not necessary when you build it yourself really, most have plenty hard disk space or usb stick, even on old machines - it is however, very fast and efficient RAM memory-wise).

wiak

[rufwoof]

Thanks for the tips about VLC in ncurses, rufwoof. However, on my setup video playback is problematic. The interface pops up, i can search and load files, sound is fine, but no display.

Errors about dbus show up when starting VLC in ncurses:
"Failed to connect to the D-Bus session daemon"
"Unable to autolaunch a dbus daemon without $display for x11..."
"Interface "dbus,none" initialization failed"
"No suitable interface module"

I've tried running it in and out of tmux, with or without dbus, with or without x11 installed, in root or with user, running dbus-launch, etc. Same result accross the board. Could not find any relevant solution on other forums either.

If I open a tilda terminal and run vlc -I ncurses ... I get similar reports ...

Code: Select all

[user@void-live ~]$ vlc -I ncurses
VLC media player 3.0.8 Vetinari (revision 3.0.8-0-gf350b6b5a7)
[000055b2578c2890] vlcpulse audio output error: PulseAudio server connection failure: Connection refused
[000055b257964eb0] dbus interface error: Failed to connect to the D-Bus session daemon: D-Bus library appears to be incorrectly set up: see the manual page for dbus-uuidgen to correct this issue. (Failed to open "/var/lib/dbus/machine-id": No such file or directory; Failed to open "/etc/machine-id": No such file or directory)
[000055b257964eb0] main interface error: no suitable interface module
[000055b25782fd60] main libvlc error: interface "dbus,none" initialization failed
[user@void-live ~]$ 

But the sound and video are fine. Does running vlc within X play videos OK?

Try running with cvlc instead of just vlc and without the interface

cvlc /mnt/sda1/my.mp4

and ctrl-C break out of that to see what messages were shown.

Unlike X that optimises graphics, running on the framebuffer doesn't, so I guess in some cases it might not work well on some hardware/setups. However I don't know how to make tweaks in that respect. Perhaps try running cvlc --help and some of the parameters indicated there might be of use ?? (such as --fullscreen --crop maybe (wild guess)).

[rufwoof]

You should be aware, that this is a build system - it is up to the user to build the system up to the exact form they wish (a plugin can be created so users can build any power of X desktop, for example, they wish - rufwoof provided one such firstrib00.plug for that purpose). Maybe he could produce an iso of that - but the iso would be huge because none of us has concentrated on slimming the system down (not necessary when you build it yourself really, most have plenty hard disk space or usb stick, even on old machines - it is however, very fast and efficient RAM memory-wise).

I'm more for teaching to fish rather than feeding fish. My .plug is for my particular hardware such as laptop 1366x768 screen resolution. On another setup it could very well look inappropriate. Being able to build a system from a few moderately easy to read/follow scripts is educational towards knowing ones own system/setup. Having a template .plug script is easier than writing one completely from scratch. Maybe for a ISO one might use a existing ISO from another along with installing/using isomaster to swap out the vmlinuz ...etc. files within the iso with the versions that wiak's scripts build (and then save/burn that modified iso as desired). Or someone might opt to use the scripts to form a complete ready to use distro/puppy 'derivative' that they then share/support (VoidPup or whatever).

Ultimately a good build would be one where you compiled your own kernel with all required modules built into that. Doing that massively reduces the size of the final files and produces a kernel that is ideal for your hardware (voidlinux includes a massive range of firmware in its repos). Building the kernel with localyesconfig does that, but requires all things you're likely to use to be connected at the time (android phone, usb's ...etc. all connected). Voidlinux also supports musl which when used makes things smaller still.

[wiak]

I should emphasise something before you look at the attached screenshot.

build_firstrib_rootfsXX.sh does exactly what it says: it builds a root filesystem via the expedient of using a static build of busybox and native package manager (thus far using Void Linux package manager xbps). A root filesystem that could be built as small or large as you like, with or without Void Linux packages (but probably with...). Something that could be used via a chroot on an existing Linux host system. That was as far as I originally meant/intended to go.

But, I got hooked, and built an initramfs for it.

The resulting bootable FirstRib WeeDog (void flavour) system is in no way an independent distribution - it uses Void Linux repo packages for its operation. But then again, most distributions on here, including Puppy use upstream repo packages for their operation so are not actually independent either. WeeDog (void) actually uses the native package manager of the upstream repos (which is a pretty good fit, I'd say!).

However, build_firstrib_initramfsXX.sh produces an entirely independent initramfs, which provides a lot of the underlying functionality of the WeeDog distribution, including save persistence, it's own copy2ram mechanism, and its special facility of allowing either squashed filesystems for its overlays, or uncompressed directories (just by adding 2-digit number to directory or sfs file name). And easy rollback via numbered upper_changes folders. But really build initramfsXX.sh is also independent from build_firstrib_rootfsXX.sh because it can also be used as an truly independent component with other root filesystems that were not built using build_firstrib_rootfsXX.sh.

So a WeeDog Linux distro is defined (in terms of its overlay flexibility) by its entirely independent initramfs (rather than by whatever root filesystem or upstream repos that has). The attached screenshot is an illustration of what I mean. It's WeeDog Slackware - a full XFCE Slackware root filesystem booted by an initramfs created by a slightly modified build_firstrib_initramfs04_s102.sh script (so uses Slackware kernel and modules/firmware).

i.e. It is Slackware being controlled by WeeDog (initramfs). In this example, I have a behind-the-scenes 50upper_changes directory, made in the previous boot, that contains my wifi credentials and some other extras. The system as shown is now being booted in changes=RAM mode, so any further changes do not get saved (unless I copy them down to say a 51upper_changes directory for the next-time I boot. Those of you who have experience of booting a WeeDog system will recognise it from the 'inram' and so on shown in the terminal result of df command.

I doubt I will produce a build_firstrib_rootfs script for Slackware - Slackware doesn't use a dependency-resolving package manager (which I would need for firstrib use, nor a slack-bootstrap setup that I know of (otherwise I might use that). I can however build firstrib_rootfs and initramfs for WeeDog debian&ubuntu-based systems (all tried and tested) and Arch (not finished, but can certainly do that flavour too).

So WeeDog Slackware also works, just need any Slackware rootfilesystem (e.g. official one or otherwise) and then WeeDog-it by running slightly modified build_firstrib_initramfsXX.sh (next version will include the mod for Slackware use too - EDIT: DONE).

New build scripts coming soon (but still no zram options - I'm too busy experimenting... I'll add optional zram and so later).

wiak

[rockedge]

for fun I made an ISO of a WeeDog which I burned to CD-ROM that worked.
Only it was a bare bones version with no X server or much of anything except the ability to connect to the network and begin to use xbps to install everything.
And that was model 02 very much in the beginning of it's development. I think though that an ISO could be constructed that will boot when burned to CD or DVD that has some basic desktop going.

though the scripts with the flexibility of the firstrib.plug make so many more options open to building a WeeDog (firstrib Void based). Also the mount umount scripts and the ability to use WeeDog as a chroot'ed system with a Puppy Linux host is also very powerful and has many uses in that mode.

right now I am just blatantly borrowing rufwoof technology, the wiak ways, Puppy Linux scripts and config files to mix and match together all kinds of variants of WeeDog. With firstrib.plug or just starting with a basic minimal system and start adding stuff after boot.

the XXupper_changes system really works well for me and I have set up some WeeDogs with those in stages. Especially when going for broke on some more complex builds
I have pmcputemp from Puppy Linux Bionic running in a sort of different way..combining it with rufwoofs /usr/local/bin/temp script to have a changing pmcputemp icon and when clicked throws open a xterm terminal running the temp script. it's a hack but it only took a few moments to put together and it shows the temp graphically and as text. Only the little temp image is not landing in the dock on the tray and has to be used as an icon on th temp script dragged the rox pinboard.

[rufwoof]

Had a few hours now of trying to get alsa working. Added xbps-install alsaequal and attempting to get both dmix and equaliser working !!!

Seems like a link is required to get alsamixer -D equal to run once alsaequal is installed.

ln -s /usr/lib/ladspa/caps.so /usr/lib/caps.so

With /etc/asound.conf content of

Code: Select all

pcm.!default {
  type hw
  card 1
}
ctl.!default {
  type hw
  card 1
}
ctl.equal {
  type equal;
}
pcm.plugequal {
  type equal;
  slave.pcm "plug:dmix";
}
pcm.!default {
  type plug;
  slave.pcm plugequal;
}

I can play multiple streams at the same time, but alsamixer -D equal doesn't seem to make any difference no matter where the sliders are. Don't really 'get' alsa and very much in the dark with its configuration/setup.

I also had to adjust the jwm key binding to raise/lower the volume level to include the card number i.e. to a format like ...

<Key mask="C" key="Up">exec:amixer set -c 1 Master 6%+ </Key>

[Smithy]

Well if it's a new OS, just run everything through Jack, an ALSA director, but with good latency. Lowtech might know how to do it. Might as well start with a good audio system.

[rufwoof]

Thanks Smithy. Gave jack a quick once over as per the following setup under Voidlinux

Playing multiple youtubes in chrome, but running audacity and/or kdenlive at the same time and no sound from those under that basic setup (no appearance of Jack as a device in audacity after re-scanning for devices)

Code: Select all

#!/bin/bash

jack_control start
jack_control ds alsa
jack_control dps device hw:HD2
jack_control dps rate 48000
jack_control dps nperiods 2
jack_control dps period 64
sleep 10
a2jmidid -e &
sleep 10
qjackctl &

exit

Jack how to ...

xbps-install qjackctl
use the above script after adding the following into /etc/asound.conf ...

# convert alsa API over jack API
pcm.!default {
    type plug
    slave { pcm "jack" }
}

ctl.mixer0 {
    type hw
    card 1
}

# pcm type jack
pcm.jack {
    type jack
    playback_ports {
        0 system:playback_1
        1 system:playback_2
    }
    capture_ports {
        0 system:capture_1
        1 system:capture_2
    }
}

[rufwoof]

Rebooting (to clear out jack/qjackctl and asound.conf changes) and using /etc/asound.conf of ...

Code: Select all

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"
	}
}

And I can play multiple youtubes in Chromium as well as having sound playing in audacity and video/sound also playing in kdenlive.

Tried tweaking it around to get the equaliser working but no luck. The alsamixer -D equal equaliser is however accessible, but sliders have no effect. Not a great issue as vlc's equaliser is great.

[wiak]

So, per my previous post, WeeDog Slackware also works, just need any Slackware root filesystem (e.g. official one or otherwise) and then 'WeeDog-it' by running slightly modified build_firstrib_initramfsXX.sh (next version will include the mod for Slackware use too). That 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 [***all?] 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.

Now stopping myself playing with WeeDog distro combinations too much and getting back to polishing up the new scripts for upload during the coming week.

wiak

EDIT: Edited first post of thread to provide link to 'WeeDog-it' Slackware example.

EDIT: [***all?] Well my statement was the case I believe. Then later today (25Aug2019), I note, Easy Pyro resurrected as

back from the dead
...Although the [Debian repos] Buster series is intended to receive most attention ongoing

[rufwoof]

Instead of starting up a large display version of xload and two xclocks - one for analog time, another for date ... installing gkrellm and using a large scaled version of that looks nice in skippy-xd (window selector).

In the attached I've set it to show the date/time, cpu loading, cpu core temperatures and battery charge level. skippy-xd runs live so you also see the changes in those (along with any videos ..etc. that might be playing) whilst viewing the skippy-xw window selector window.

cpu's running hot in that image as I'm running a build with the modified firstrib00.plug that includes xbps-install'ing gkrellm and where the gkrellm config files for that choice of gkrellm setup/sizing are also included in the build. And its quite a hot summer midday.

[wiak]

Progress Report:

After a lot of hiccups today (having forgotten how I did such tricky bits one week ago - so much for my notes) I made a lot of progress with the latest scripts this evening. Going slower than I intended though so I expect will be a few more days prior to test release (maybe on Friday).

One thing I am doing is combining the i686 and amd64 build (Void flavour) rootfs scripts into one build rootfs script, but leaving the code for each in separate big chunks since easier to read and modify (and separate should I change my mind). I prefer there to just be one build rootfs script and one build initramfs script - also makes the documentation and maintenance easier.

Otherwise, Void parts will work just the same as current ones (zram additions to come later).

EDIT: I'm also in the process of adding option of Arch Linux to build_firstrib_rootfs since it also seems possible to use its package manager (without needing arch-bootstrap) simply alongside busybox (unlike Debian-based systems, which really need debootstrap to download whole, large, rootfs skeleton prior to dpkg/apt working). I have most of the Arch-related firstrib code written but not complete or tested. I won't be including that FirstRib Arch flavour until a later release (assuming it works...).

wiak

[wiak]

I've included

QUICK BUILD/TEST INSTRUCTIONS

in addition to a firstrib00.plug that installs the needed Void kernel components for those wishing to use Void Linux kernel/modules etc. It's contents are as follows:

Code: Select all

xbps-install -y ncurses-base linux4.19 linux-firmware-network wifi-firmware shadow
pwconv # set up passwd system
grpconv
echo -e "root\nroot" | passwd >/dev/null 2>&1 # Quietly set default root passwd to "root"

# you can add as many valid commandlines as you want in here

Note that the plugin also sets up default root passwd to simply "root", which you can change later of course.

I just noticed, that sometime since posting above instructions, some time back, on how to make firstrib00.plug to include kernel and set passwd for root automatically, I accidentally over-wrote the associated first-post-provided firstrib00.plug with an old simple one... That may have caused some perplexity to some people trying a build - sorry about that - I have re-uploaded the described firstrib00.plug with the important code in it.

I have also now tested newest build_firstrib_rootfs_100.sh successfully, and currently completed draft of the associated build initramfs script, which I am now testing. All going well I should upload these, with instructions, in a few hours time, or tomorrow if I run into any problems I need to address.

Main change you will have to make yourself aware of is simply the extra commandline arguments you must provide when running the two new build scripts. Otherwise, all should work as before, including firstrib00.plug etc for void flavour firstrib build.

wiak

[rufwoof]

For running in ram a script I've knocked up to create a NNchanges.sfs copy of upper_changes where NN is 02, 03, 04 ...etc generated each time a 'save' is run is ...

Code: Select all

#!/bin/sh
# save.sh

# Create a sfs of upper changes in ram so that changes persist across reboots
# nnchanges.sfs where nn is 02, 03 ... etc.  Starts from 02changes.sfs as
# 01.. filename is reserved for the main sfs layer filename

NEXT=1
for nextlayer in `ls *changes.sfs | sort -V | cut -c1-2`; do
       	if [ "$nextlayer" -ge 0 ]; then NEXT=$nextlayer; fi
done
NEXT=$(expr $NEXT + 1)
NEXT=$(printf "%02dchanges.sfs" $NEXT)  # add leading 0 if 2 to 9
mksquashfs /mnt/layers/RAM/upper_changes $NEXT -comp lz4 -Xhc -e var run mnt

i.e. those 02changes.sfs, 03changes.sfs ...etc. get loaded at bootup so changes are persistent across reboots.

That supports up to 99 saves (no checking of whether it rolls over to 100+), so rather than getting anywhere near that number of NNchanges.sfs files, periodically we might merge them all back to a single 02changes.sfs file using ...

Code: Select all

#!/bin/bash
# merge-changes.sh

# Merge multiple xxchanges.sfs into one (02changes.sfs and all prior NNchanges.sfs
# changes sfs files are removed once merged)

# format of what we're looking to achieve .. (note that c is the lowest (first)
# i.e. should correspond to 02changes.sfs, b is the next lowest (03changes.sfs)
# and a is the highest (04changes.sfs)) ...
#    mount -t overlay overlay -o lowerdir=/mnt/L/a:/mnt/L/b:/mnt/L/c /mnt/L/m
# As we're mounting read only (to create a sfs from) we don't need upper or work
# Note that we mount each NNchanges.sfs to a mount point named the same
# i.e. /mnt/L/NNchanges.sfs, which are all merged into /mnt/L/m ... and
# we use that /mnt/L/m to create the new 02changes.sfs 

mkdir /mnt/L 
mkdir /mnt/L/m
unset lower

for addlayer in `ls *changes.sfs | sort -Vr`; do # sorted in reverse order
	[ -z $lower ] && lower=/mnt/L/${addlayer} || lower="${lower}:/mnt/L/${addlayer}"
	mkdir -p "/mnt/L/$addlayer"
	mount $addlayer /mnt/L/$addlayer
done
sync
mount -t overlay overlay -o lowerdir=$lower /mnt/L/m
mksquashfs /mnt/L/m CHANGES.sfs -comp lz4 -Xhc
sync
umount /mnt/L/m
umount /mnt/L/*changes.sfs  # release all mounted sfs's
sync
rmdir /mnt/L/*changes.sfs
rm -rf /mnt/L
rm *changes.sfs
mv CHANGES.sfs 02changes.sfs

Both save.sh and merge-changes.sh should be stored and run from where your 01firstrib_rootfs.sfs is stored.

Haven't tested it at all other than cursory checks and it runs/produces/loads sfs's OK on my voidlinux kernel based HDD frugal setup.

[rockedge]

rufwoof..... cool script..I'm testing it out

[rufwoof]

Thanks.

Also just uploaded a replacement firstrib00.plug in post http://murga-linux.com/puppy/viewtopic. ... 78#1035078 with much more comprehensive tweaks - such as setting up mc program association/launching and right mouse click in skippy-xd now closes the program/window (left click switches to window). I have reversed the hot corner so that top left now launches xlunch and bottom left launches skippy-xd as unintentional launches tend to more often occur in the top left corner - where xlunch is easier to close (mouse remains near top corner) compared to skippy where the mouse tends to be positioned centrally over a window. i.e. clicking on the background rather than a icon/window for both xlunch and skippy results in the xlunch/skippy window being closed.

Once you're more natural with xlunch/skippy and F1 for terminal (along with mc for file manger), it a alternative desktop combination that works very well IMO.

[wiak]

For running in ram a script I've knocked up to create a NNchanges.sfs copy of upper_changes where NN is 02, 03, 04 ...etc generated each time a 'save' is run is ...

That's nice. I'll also check it out sometime when I have time. New build scripts are working but I'll still tweaking with a few alterations here and there so keep having to do long tests. So should be uploaded hopefully tomorrow.

wiak