RC7 (STABLE) WeeDogLinux Arch 64 now released

[rockedge]

one thing though, I somehow changed to rox-filer toolbar icon theme and can not return the toolbar back to the default icons.

[rockedge]

I found out that xlunch works really well with weepup (firstrib)

[fredx181]

Hi wiak, did a quick test, works well building initramfs.gz with v008 and booting with bootfrom=... parameter.
I found that sound works with firefox-esr without pulseaudio (only alsa-utils installed and did "modprobe snd_hda_intel" and "alsactl init")

@rockedge

I found out that xlunch works really well with weepup (firstrib)

How did you install xlunch ?

Fred

[rockedge]

beautiful is I can open the Puppy Linux save folders in all of the Puppy's I have on this hard drive......so I clicked on xlunch binary I had set up in a Bionic64-v8 and it worked!......so I copied it over and installed menu-cache-1.1.0_1 to run the menu-generator

Code: Select all

xbps-install -Sy menu-cache

I copied from a Bionic64 setup the xlunch desktop files also along with the different components to make it work. I will have to see again the xlunch setups in several different Puppy's each slightly different..... and I just apply it to WeePup

http://xlunch.org/


start xlunch as in the screenshot

Code: Select all

#!/bin/bash

[ -f $HOME/.config/xlunch/entries.dsv ] && ENTRIES=$HOME/.config/xlunch/entries.dsv || ENTRIES=/etc/xlunch/entries.dsv
xlunch -i $ENTRIES -x +10 -y +10 -w 670 -h 600 --dontquit -W --border 5% --sideborder 10% --borderratio 5 --sideborderratio 50 --iconsize 28 \
          --background /usr/share/backgrounds/Sade.png /11 
           -I 5 -T 5 -a --columns 2 \
          --paddingswap --leastmargin 1 --iconsize 16 \
 #         --button "/usr/share/xlunch/icons/shutdown_32x32.png;;+110,-10;wmpoweroff" \
          --button "/usr/share/xlunch/icons/restart_32x32.png;;+200,-10;wmreboot" \
          --button "/usr/share/xlunch/icons/logout_32x32.png;;+290,-10;pkill X" \
          --button "/usr/share/xlunch/icons/vlc_32x32.png;;10,+150;/usr/bin/vlc" \
          --button "/usr/share/xlunch/icons/leafpad_32x32.png;;10,+250;leafpad" \
          --button "/usr/share/xlunch/icons/firefox_32x32.png;;10,+350;firefox"

or full screen ->

Code: Select all

#!/bin/bash
pd=$!
[ -f $HOME/.config/xlunch/entries.dsv ] && ENTRIES=$HOME/.config/xlunch/entries.dsv || ENTRIES=/etc/xlunch/entries.dsv
xlunch -i $ENTRIES --dontquit -W --border 6% --sideborder 6% --borderratio 20 --sideborderratio 20 \
#         --background /usr/share/backgrounds/FRACT021.GIF 
         --iconpadding 35  --iconvpadding 5 \
         --paddingswap --iconsize 38 --textpadding 1 \
         --highlight /usr/share/icons/hicolor/48x48/apps/highlight.png
kill $pd

[rockedge]

right now I am trying to get xarchiver to run....it will be simpler to just add it to /upper_changes because I have had it running in the chroot'ed version and it was great to have....I am working on getting that running in WeePup

and I still can't get the default rox-filer toolbar icons back .....yet

and I have not got the sound to work yet...looks close though

now have palemoon running alongside firefox...next build only palemoon installed for testing

[westwest]

When running VLC from firstrib inside another distro, the VLC equalizer doesn't function at all.
There are some error messages in the terminal about "not linking to apulse",
and about "no presets found".

I suppose a specific set of files should be mounted with "mount_chroot"?
And if so, how can i find out which ones?

Also, is it possible to mount and unmount files "on the fly" after chrooting into firstrib?

Thanks!

[wiak]

When running VLC from firstrib inside another distro, the VLC equalizer doesn't function at all.
There are some error messages in the terminal about "not linking to apulse",
and about "no presets found".

I suppose a specific set of files should be mounted with "mount_chroot"?
And if so, how can i find out which ones?

Also, is it possible to mount and unmount files "on the fly" after chrooting into firstrib?

Thanks!

Sorry, I never use VLC anymore, so have no idea about it. I presume you are talking about version of VLC installed using xbps package manager and similarly with apulse (though I never use that either). I doubt mount_chroot or umount_chroot would come into that - it would be about installing packages with xbps. On the otherhand if you are using some external sfs containing VLC (as firstrib_extras.sfs, for example) then you would need to make sure that sfs contained all the required dependencies (or that xbps could directly install them without conflict).

As far as mounting/umounting is concerned, you should be able to use such commands as normal, if that is what you mean. I.e. make a dir and mount a filesystem onto it, and then umount it once finished. But perhaps you mean something else in which case you'd need to explain the context.

Hopefully someone can then hope you out with both issues.

wiak

[rufwoof]

Not using Firstrib myself, but a thought that comes to mind is to install Oscar's apulse https://www.smokey01.com/OscarTalks/ and run vlc using that

./apulse vlc
or for browser ...
./apulse ./firefox

Is /etc/asound.state bind mounted as part of the chroot along with /dev/snd (/dev/dsp ???)

Perhaps also try running vlc from the command line to see what messages it throws out.

I know that with some Puppy versions of vlc the equaliser doesn't work well. Same with visualisations i.e. click the box to activate and ... crash.

[rockedge]

@rufwoof thanks for the suggestion and I am trying out the extracted apulse.pet

for fun I made an ISO burned it to create a bootable live CD and DVD.

used the components from Puppy Linux Bionic64-v8 plus the firstrib_firmware_modules.sfs and the directories /work and /upper_changes then modified the isolinux.cfg and grub.cfg with the necessary lines to boot. One ISO was 202 meg and the other a full 1.8 gig

it almost booted! went all the way to the endless loop with that setsid error we've seen before

noticed that using the basic stock version of firstrib_rootfs and making a smaller initramfs.gz around 28-30 meg and then booting connecting to the network and then using xbps-install,
install base-minimal (in this case) xorg jwm xterm rox geany firefox palemoon guvcview bash mc
all after firstrib is started so they land in /upper_changes. This allows for fairly quick boot times

also noticing that firstrib with the Bionic Puppy Linux kernel idles very well at 0% CPU 0 load and does run excellent.....very responsive with firefox and blazes with palemoon which I copied from a Bionic64 save folder

firstrib32 is using 152 meg of RAM
firstrib64 is going at around 800 megs RAM but is really loaded and some big pieces were put into the initramfs.gz which the 32 bit one has most installed after boot

[wiak]

noticed that using the basic stock version of firstrib_rootfs and making a smaller initramfs.gz around 28-30 meg and then booting connecting to the network and then using xbps-install,
install base-minimal (in this case) xorg jwm xterm rox geany firefox palemoon guvcview bash mc
all after firstrib is started so they land in /upper_changes. This allows for fairly quick boot times

Once I have made switch_root build initramfs version the initramfs.gz will be very small so amount actually loaded into RAM will be also small. The main firstrib_rootfs will then converted into a 01firstrib_rootfs.sfs and mounted rather than all loaded into RAM. Actually that could be arranged for current chroot version too. Will be a while though; school holidays here for next two weeks and I'm looking after our two kids during that period so not able to focus as intensely on firstrib for that period, though I am working on the development.

From the downloads I'm guessing around 10 people are trying or tried most recent build initramfs of firstrib. Not a lot, but enough that I'd feel guilty if I didn't continue with the promised next stage!

wiak

[wiak]

By the way, the new switch_root build_initramfs script is hoped/planned to be backwards compatible with any existing firstrib_rootfs builds (including any existing upper_changes folder), so should just be a matter of running the new build initramfs script to convert existing firstrib_rootfs to work. Main difference from user's point of view will be that it will boot fast (since only small initramfs needs loaded into RAM) and most of the filesystem will be mounted rather than all loaded in RAM (though can implement copy, or part-copy, to RAM option later of course).

switch_root version of initramfs build now working in draft form. I just have a few relatively easy odds and ends to tidy up (and consider) before uploading test version. Main thing I'm considering is the init to be used after the switch_root to main root filesystem from the small initramfs.

To keep things at its simplest, I want that to remain a simple shell script, except that I want a proper init binary to be process ID 1. To cut a long story short, the switch_root will call up /sbin/init, which in simple version will call a simple shell script via busybox init binary in conjunction with an inittab file (in typical sysVinit fashion the shell script will be /etc/rc.d/rc.sysinit, which the build initramfs script is auto-generating. Later, in the likely case someone extends the system to use Void's runit-void package instead, the symlink /sbin/init will instead end up calling /usr/bin/runit-init instead of the busybox one (and inittab and rc.sysinit is not used in that later scenario).

wiak

[rockedge]

excellent news....and I am standing by for a test.

I have manged to install Hiawatha, mariadb and PHP 7 packed with modules and have it running a test WordPress site...and almost Zoneminder after I copied from a working viersion from Bionic64-v8.

I am having trouble installing the PERL DBI module with both cpan and cpanm
also with perl I can not successfully install this module

I think it is one of the last hold ups from being able to start zoneminder.

The Void Linux development environment with the gcc compiler is acting up and will not work....yet

[wiak]

I'm naturally playing around with initramfs contents quite a lot during development so wrote a helper script to decompress/modify/recompress. Mainly just using gz compressed initramfs, but simply made different versions of same script for xz and for conversion between gz/xz.

Find them here, with some usage details:

http://www.murga-linux.com/puppy/viewto ... 59#1028959

[wiak]

Sorry, had to repost the modify initramfs gz scripts. Don't know how it happened but I somehow edited them after testing prior to uploadind and accidentally changed gzip to gz, which broke them... Just fixed that, but haven't had time to retest but hopefully okay now. See previous post for more details.

wiak

[wiak]

Taking much longer than I intended. Rushed a bit and couldn't remember what I did and broke the switch_root version I already had basically working (albeit incomplete)...I should have been using git. I admit to almost throwing in the towel because of resulting frustration and some lack of motivation generally. However, more positively, I finally resurrected the draft switch_root build initramfs script that I had messed up and in sudden breakthrough have my devices all now being auto-detected with modules/firmware auto-loaded, so suddenly lsmod list is huge (but that's nice). Still lots to do/test though, and only been doing initial switch_root version tests on internal hard drive builds thus far. The reality now is that it is not really far away from test release upload, but a few things to still sort out and a lot to tidy up and document.

Oh... also just realized/noticed that BionicPup32 also uses an fdrv, which explains why my wifi worked booting BionicPup32 itself but not when booting using BionicPup32 zdrv with firstrib (the firmware for my wifi is in BionicPup32 fdrv... No such problem with BionicPup64 arrangement, which is what I always use myself, since everything is in the zdrv).

Anyway, just posting to let you know I'm probably taking at least a few days break to clear my head before continuing, but I will be back...

wiak

[wiak]

build_firstrib_initramfs02_s001.sh (small initramfs02.gz switch_root version) now posted to first post of this thread for download/testing.

NOTE WELL some filename changes required:

Need 2-digit numeric as follows:

00firstrib_firmware_modules.sfs
NNfirstrib_rootfs.sfs
where NN is 00 up to 99 depending on required layer position (usually

01firstrib_rootfs.sfs since 01 is for lowest layer).
NN<someother>.sfs (e.g. I also have gimp loading at boot as

02gimpXXX.sfs)

The grub config needs to use initramfs02.gz rather than earlier initramfs.gz

Please refer to (revamped) first post of this thread of details, and start with a default build for testing is recommended; please let me know how it goes.

wiak

CHANGES

# Revision 0.0.1 with udev support/hardware auto-detection. Date: 14 July 2019
# This script tested with BionicPup vmlinuz (but should work with Void vmlinuz/firmware/modules if installed)

# The created initramfs/init includes save persistence to bootpartition/bootdir/upper_changes directory.
# The final root filesystem is a layered filesystem (overlayfs, though trivial to change to aufs)
# Lowerdir layer "${lower}" is actually a stack of layers, one of which (usually the lowest) is
# a previously built main NNfirstrib_rootfs. The rest of that stack are (optional) additional
# numbered NN*.sfs files (where NN is a number in range 01 to 99).
# 00 number is reserved for required name of optional 00firstrib_firmware_modules.sfs
# Higher numbered sfs files are mounted in higher layers so override underneath layer contents.
# NNfirstrib_rootfs is generally named 01firstrib_rootfs since it is usually wanted on lowest layer.
# NOTE WELL SPECIAL FirstRib feature:
# The squashed filesystem 01firstrib_rootfs.sfs created by this build script will be used
# if it is copied into /mnt/bootpartition/bootdir. However, you can INSTEAD put a copy of the actual
# uncompressed NNfirstrib_rootfs directory there as an alternative to an sfs. Whilst taking up
# more disk storage space that alternative has advantage of being more responsive and easy to modify.
# 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 (e.g. renamed from bionicpup zdrv) 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

# To boot the resultant FirstRib system you can now:

# Create a directory, for example, /firstrib, on partition you will boot from
# containing the files:

# initramfs02.gz
# vmlinuz
# If using vmlinuz from 32 or 64 bit BionicPup you also need
# 00firstrib_firmware_modules.sfs (e.g. renamed from zdrvXXX.sfs)
# NNfirstrib_rootfs.sfs or NNfirstrib_rootfs uncompressed directory
# where, NN is usually made 01 (for lowest layer) but can be 01 to 99.
# Note that NNfirstrib_rootfs.sfs file will be used by default if provided.
# Any additional sfs files, which should be named NN<something>.sfs

# Followed by creating a grub4dos or grub2 menu config to boot the system.

# Example grub4dos menu.lst and grub2 grub.cfg entries:

# For grub4dos
# (Example shows using (hd0,0) i.e. /dev/sda1 boot partition of harddrive
# Change following to the harddrive boot partition you are actually using)
# This example is for slow boot device, hence using optional usbwait value:
#
# title FirstRib (Void Linux Flavour)
# root (hd0,0)
# kernel /firstrib/vmlinuz usbwait=12 bootfrom=/mnt/sda1/firstrib
# initrd /firstrib/initramfs02.gz

# For grub2 (but change hd0,msdos1 to boot partition you actually use):
#
# menuentry 'FirstRib on /dev/sda1' {
# set root='hd0,msdos1'
# linux /firstrib/vmlinuz usbwait=12 bootfrom=/mnt/sda1/firstrib
# initrd /firstrib/initramfs02.gz
# }

[wiak]

NOTE that the build_firstrib_initramfs02_s001.sh script is not itself anything to do with Void Linux. In theory, I imagine, if you decompress a pupXXX.sfs (e.g. that for BionicPup64) and call it firstrib_rootfs, the build initramfs script would write a new rc.sysinit script to it and, I think, make it bootable (as an uncompressed dir named 01firstrib_rootfs, though first you would have to make /sbin/init a symlink to /sbin/init-BB and maybe some more alterations). I haven't had time to try that (sleep time here now), but will tomorrow (the devx might even be able to be made to work for that arrangement...). I will experiment and report on that one - not sure what the end result would be since different rc.sysinit script - though original pup /sbin/init and rc.sysinit could be left and that might work better for that case (in either case I may tailor build_firstrib_initramfs02 script to optionally create a firstribpup of that sort, maybe using option of aufs or overlayfs ... which would be a new firstrib initramfs form of Puppy... But that would not at all be my focus, which remains Void Linux flavour with xbps).

Per my first post of this thread comment (quoted above) regarding this new build_firstrib_initramfs02_s001.sh script. Just for fun, I used the script on an actual but uncompressed pupXXX.sfs renamed to firstrib_rootfs to use resultant initramfs02.gz to boot that actual Puppy root filesystem:

unsquashed BionicPup64 puppy_bionicpup64_8.0.sfs
renamed the resulting unsquashed directory to firstrib_rootfs
modified its contents very slightly:
made dir /sys
made its sbin/init simply a symlink to its /bin/busybox
renamed its rc.sysinit rc.sysinitPUP
symlinked its lib/modules to usr/lib/modules, and similarly
symlinked its lib/firmware to usr/lib/firmware (since that's currently FirstRib-expected Void Linux arrangement)
Then ran script ./build_firstrib_initramfs02_s001.sh
Finally copied the script-produced 01firstrib_rootfs.sfs (or could have used the actual uncompressed folder renamed to 01firstrib_rootfs) and the initramfs02.gz to /mnt/sda5/firstrib (which is where I was booting from).
and it successfully booted (with FirstRib grub contents) to command prompt with hw devices auto-detected/modules auto-loading.
Then ran: xwin
and X and JWM came up as attachment shows.
Keyboard in X didn't work with this FirstRibPup first attempt (but mouse did) and icons missing (not surprising since FirstRib rc.sysinit doesn't prepare environment for traditional JWM Pups). But does work and could be made to work well probably! But no prioritiy or intention of mine. Just tried it as proof of concept. Back to actual Void Linux xbps-package manager capable version of FirstRib WeeDog for me now...

wiak

[wiak]

So I've just had another break-through - have FirstRib WeeDog booting now with actual Void Linux kernel and modules/firmware.

The problem with the Void Linux kernel is that it isn't of the 'huge kernel' Puppy compile type so doesn't have many drivers built in hence actually no use just bolting on a firmware_modules sfs. I didn't want to have to compile a Void-compatible huge kernel myself, since that would limit the rolling-release ability of Void (since I'd have to keep up with such compile).

Anyway, I have addressed the issues in a successfully completed test build now, such that offical Void kernel working fine with FirstRib WeeDog and I will publish additional scripts to automate the necessary additions for Void kernel usage (BionicPup components still perfectly useful for simpler builds however).

@rockedge: using Void's own kernel etc should fix the compile buildsystem issues you were having when attempting to compile ZoneMinder since FirstRib WeeDog will be fully official Void Linux compatible then.

wiak

[wiak]

OOPS. Sorry.

I only just noticed I accidentally posted up the wrong switch_root initramfs build script a few days ago. The correct one has file name: build_firstrib_initramfs02_s001.sh (which I correctly named in the release announcement).
The one I posted was a very early non-working one. Pity no-one gave feedback and I could have sorted it out quickly.

I'll repost in a little while with correct one. I'll just double check it to make sure I haven't modded it since then by accident...

EDIT: Unfortunately, thinking I had a good backup here on the forum, prior to making my intended extra backup, I temporarily hacked away at the good build script... I would now have to go back to the backup just prior to that well-tested good one and try to remember what fixes I needed to make to that... This would take some time and a lot of further testing. Five downloads, presumably some tested it? But true, five downloads is not a lot of interest anyway. Maybe better I just publish a working iso one day, should I ever make one, since of more use to many and thus a slight chance of more feedback. As things stand, I get the impression only a few 'developers' (aside from you rockedge and fred) are downloading my scripts, presumably just for ideas rather than to contribute usefully. Well, the old script I accidentally uploaded has some of the ideas in it, so maybe that will be useful enough - but the loss of the good complete working one is a real pain to me. Reminder to myself - better backups...

EDIT2: Though I've lost the working last build initramfs02 script, I just remembered I still have a copy of the modified init that I used to boot with Void Linux kernel last night. That has some of the missing code in it, so I might be able to fix this sooner rather than later (was almost at the couldn't be bothered stage but will maybe still do it afterall - for the five or more silent downloaders... sigh - hardly worth it really ).

wiak

[wiak]

re: my immediately previous post regarding wrong upload and lost original...

Well, turns out lucky I had that later version on the initramfs/init and rc.sysinit that worked with actual Void Linux kernel. Using diff checks, I have been able to compare these files with code of the last almost correct copy of the build initramfs02 script. I have thus managed to (eventually) regenerate it back to the working state I 'think' it was - certainly in the one and only test I've since bothered doing, it booted fine as it did before but all the other tests I did will need repeated for certainty. Its 'regeneration' took over an hour, though only around 10 lines of code turned out to have been temporarily 'lost'; but lucky since might have taken days had I not found these more recent init and rc.sysinit development fragments, which also contained most of the 'lost' code... I've taken many backups now... but testing definitely required now.

Anyway, please refer to the important differences to older build initramfs script to previous announcement of this scripts release (for example zdrv renaming slightly different as explained):

http://www.murga-linux.com/puppy/viewto ... 90#1032590

Main details including installation/usage are in revamped first post of this thread along with the new build script itself: build_firstrib_initramfs02_s001.sh

I'm off to sleep now and hope all is now well for tomorrow...

wiak