RC7 (STABLE) WeeDogLinux Arch 64 now released

[gabtech]

Hi rockedge, Thanks for the boot instructions. The absence of vmlinuz is what prompted me to ask for help. What could be making vmlinuz not to be built. I did the build process on stretchdog 32 frugally installed on an ntfs partition.

[rockedge]

I think the problem is the NTFS partition. Is it possible to build on a Linux file system like ext3?

[gabtech]

Hi rockedge

My newly built weedog can not boot. Attached is my build folder and menu.lst. it throws error 15 when booting.

[fredx181]

Hi rockedge

My newly built weedog can not boot. Attached is my build folder and menu.lst. it throws error 15 when booting.

From what I see at your screenshots is that the directory you're booting from is named "weedoggg" and in menu.lst it's named "weedog", so I guess the problem is that it doesn't match with each other.

Fred

[rockedge]

yes I agree it looks like a simple typing error. Fix up the menu.lst or rename
/mnt/sda2/weedoggg and give that a try!

let us know how you make out!

[rockedge]

To make a further report on some progress made with WeeDog64 (FirstRib).

I have successfully built a WeeDog64 (Void Linux) using the last available scripts and the plugin firstrib00-64-auto.plug. Followed by the script build_ZM.sh to set up WeeDog64 as a ZoneMinder camera and NVR security system.

It isn't all straight forward though and had to make some adjustments to then install python3 and the necessary python3 modules to run the zmeventnotification server that supplies push notifications to zmNinja which accompanies Zoneminder as a mobile (Android or Apple) or desktop app. Also this server can use hooks to then perform object and face recognition.
If during a face recognition hook occurs and the face is unknown it will store that face as an image in a /unkown_face directory.

All this is running on a newly built WeeDog64 running the LHMP, Zoneminder, ZMES and can also use Darknet-YOLO simultaneously to supply object detection on a real time camera stream. Performance is outstanding on a Dell Optiplex 990 with 8 gigs of RAM.

I give WeeDog64 a top rating in performance, low CPU loads, low CPU temps and still ripping camera streams of at least 7 fps and that with 3 netcams and 2 local web cams.

good stuff.

**

[rockedge]

A look at the current WeeDog64 (Void Linux) after further modifications and customization, that I am running currently.

[wiak]

I have successfully built a WeeDog64 (Void Linux) using the last available scripts and the plugin firstrib00-64-auto.plug. Followed by the script build_ZM.sh to set up WeeDog64 as a ZoneMinder camera and NVR security system.

I haven't forgotten about WeeDog of course. Just that it remains summer here and I know I won't be doing much computing for a few months yet, but I will come back to this one since it has lots of potential with lots that can be improved with some focussed development. I'll also get back to uses/experimenting with your new phpBB Puppy/Dog site around that same time I get back to doing some new work on WeeDog again.

It is good to hear that you have achieved so much with it rockedge and your set up is certainly a good way to test and exemplify WeeDog's good performance and overall efficiency.

It is probably true to say that WeeDog is somewhat different than most distribution variations (in this case primarily a Void Linux variation - with WeeDog initramfs) available on this forum. Most other (and perhaps all other) distribution developers tend to produce a fully polished usable out-of-the-box distro, which is not at all what I have done with WeeDog. Rather I rely on users of the build system to make something useful out of it (such as the excellent and sophisticated build you have created rockedge) which can then act as exemplars for others to build WeeDog variants of their own. I particularly hope if proves fun to work with despite the hard work, and experimentation, that is certainly involved.

wiak

[rockedge]

Hello wiak!! Enjoy the time off!

I want to report a small problem that has presented itself when I have been trying to run the ./build_firstrib_rootfs_103.sh script tonight. I need to build a new installation of WeeDog64 using one of my plug's and zoneminder install script but the build process errors out.

I just ran it last week to build the example above with Zoneminder and using WINE to run a couple of favorite Windoze programs. Mostly Photofiltre7 or Photofiltre Studio X and Total Commander. So I know it was working, although I did have a hiccup on one build and had to restart the script to finish that also had failed for similar reasons showing up now.

Now the script is failing!! Looks like a URL is not working or certificates are a problem...this is the error

Code: Select all

HTTP request sent, awaiting response... 200 OK
Length: 140704 (137K) [application/octet-stream]
Saving to: ‘sslcerts.tar.xz’

sslcerts.tar.xz                 100%[=====================================================>] 137.41K   120KB/s    in 1.1s    

2020-03-03 20:54:19 (120 KB/s) - ‘sslcerts.tar.xz’ saved [140704/140704]

[*] Updating repository `https://alpha.de.repo.voidlinux.org/current/x86_64-musl-repodata' ...
ERROR: [reposync] failed to fetch file `https://alpha.de.repo.voidlinux.org/current/x86_64-musl-repodata': Not Found
[*] Updating repository `https://alpha.de.repo.voidlinux.org/current/nonfree/x86_64-musl-repodata' ...
ERROR: [reposync] failed to fetch file `https://alpha.de.repo.voidlinux.org/current/nonfree/x86_64-musl-repodata': Not Found
sh: xbps-install: not found
sh: xbps-install: not found
sh: /tmp/firstrib00-64-auto.plug: line 6: xbps-install: not found
sh: /tmp/firstrib00-64-auto.plug: line 7: xbps-install: not found
sh: /tmp/firstrib00-64-auto.plug: line 8: pwconv: not found
sh: /tmp/firstrib00-64-auto.plug: line 9: grpconv: not found
sh: /tmp/firstrib00-64-auto.plug: line 13: usermod: not found
sh: /tmp/firstrib00-64-auto.plug: line 16: xbps-install: not found
sh: /tmp/firstrib00-64-auto.plug: line 17: xbps-install: not found
sh: /tmp/firstrib00-64-auto.plug: line 18: xbps-install: not found
sh: /tmp/firstrib00-64-auto.plug: line 19: xbps-install: not found
sed: /etc/default/libc-locales: No such file or directory
sh: /tmp/firstrib00-64-auto.plug: line 23: xbps-reconfigure: not found
cp: can't stat '/etc/X11/xinit/xinitrc': No such file or directory
sed: /etc/X11/xinit/xinitrc: No such file or directory
sh: /tmp/firstrib00-64-auto.plug: line 30: can't create /etc/X11/xinit/xinitrc: nonexistent directory
sh: /tmp/firstrib00-64-auto.plug: line 31: can't create /etc/X11/xinit/xinitrc: nonexistent directory
sh: /tmp/firstrib00-64-auto.plug: line 32: can't create /etc/X11/xinit/xinitrc: nonexistent directory
sed: /root/.xinitrc: No such file or directory
sed: /etc/system.jwmrc: No such file or directory
sed: /etc/system.jwmrc: No such file or directory
sed: /usr/bin/vlc: No such file or directory
sh: /tmp/firstrib00-64-auto.plug: line 113: xbps-alternatives: not found

researching the problem I saw that this has happened in the past with Void Linux. Maybe you can take a look and see what is happening. I am looking to fix it as well.

No worries I'm experimenting with EasyPup and ArchPup also at this time.
But WeeDog64 installs that I have running now out perform most of all the OS's I work with and have proven to be a very good platform for ZoneMinder and or a solid web server. The fact is with the plugs one can make such a bare min system or a really full and customized desktop system.

Looking forward to constructing new WeeDogs and FirstRibs!


**

[wiak]

I know it was working, although I did have a hiccup on one build and had to restart the script to finish that also had failed for similar reasons showing up now.

Now the script is failing!! Looks like a URL is not working or certificates are a problem...this is the error

Hi rockedge,

I have flu/cold at the moment but managing to fix a problem in gtkwialog that fredx182 notified me about the other day. Once I have finished that and pushed up the new gtkwialog source code changes I'll have a look at the WeeDog issue that has suddenly appeared. Yes, it may well be new ssl certificates file required - I always expected that would be something I'd have to keep an eye on or create some method of rebuilding the certs file quickly when changes occur. For the moment I'll just manually remake it if that's all the problem turns out to be. If my cold gets worse and I'm unlikely to get round to it in less than a week I'll let you know; I'm pretty sure it will be a simple fix though, but would involve putting the new certs file on firstrib github site for the build script to access it.

wiak

EDIT: You might be able to get it working in the meantime by commenting out the https: versions of the current repos being echoed for use in the build script, and removing the comments in order to activate the non-https available repo site:

Code: Select all

	# Default void repos use usr/share/xbps.d https repos, so ssl certs needed for these:
	echo "repository=${repo}/current" > usr/share/xbps.d/00-repository-main.conf
	echo "repository=${repo}/current/nonfree" > usr/share/xbps.d/10-repository-nonfree.conf
	# If no sslcertificates available can use insecure temporary /etc/xbps.d non-https repos:
	# echo "repository=http://alpha.us.repo.voidlinux.org/current" > etc/xbps.d/00-repository-main.conf
	# echo "repository=http://alpha.us.repo.voidlinux.org/current/nonfree" > etc/xbps.d/10-repository-nonfree.conf

Less secure, but would evidence the sslcerts being the actual issue. Certainly, the url (https://alpha.de.repo.voidlinux.org/cur ... l-repodata) still seems to be correct; I checked in my browser and that x86_64-musl-repodata file is certainly at that address, so looks like is sslcerts file needs updated for that repo to work).

EDIT2: that non-https site may not be available any more though (I haven't tried any build as yet, but trying to visit the page in my browser actually redirects to another https site... I'll try a build after gtkwialog finished though and fix the sslcerts since really the correct approach if that's the problem.

My cold/flu signals summer coming to an end here, so that also means my return to Linux-related work won't be too far away more generally. I'm even thinking of playing with Puppy itself since I've long toyed with the idea of making a non-woof-CE Pup using modded WeeDog build scripts with the help of something like scottman's pkg (though needs modified to work with busybox I think from earlier tests).

[rockedge]

Hello wiak,

yes I agree, I think there is a good chance it is the certs. The build fails right after their download.

Hey man I hope you feel better! Take it easy, drink a lot of fluids..hot chicken soup, you know the idea.

I read in the script about the http download but have not tried to set that up yet. I did get a few url's tested on the browser to come up although it is unknown if a build will work with the script configured for http

UPDATE : build did not work with alternative http url's
.

[wiak]

Hi rockedge,

I haven't succeeded as yet either, and also noted that alternative non-https url no longer available, but I think I may have the reason for https access error (though I could be wrong - but tests I've run suggest I may be correct). Alas I can't fix it cos the possible problem is upstream. I may be able to work around it though, as explained below.

PROCESS:

I was so curious I temporarily put my gtkwialog work aside to look further into this. I spent hours changing ca-certificates files/folders/config files, but made no difference...

However, I did have an older previous install that still worked syncing repos with command xbps-install -S (which is failing in new builds). I tried copying all the ca-certificate info from there to new build, but still xbps-install -S wouldn't work on new build. But since old install (using shared lib xbps-install was working but new build, which uses xbps-install-static, wasn't, I looked here:

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

and noted that since 03 March up to 05 March a whole series of new xbps-static builds have been compiled... (i.e. 3 builds for each of every architecture supported). I wondered why so many attempts... So I temporarily disabled the xbps-install shared lib version in the working older build and copied the new xbps-install-static binary over and tried running that, and sure enough it failed. I'll now manually download an earlier static build and try the xbps-install-static component from that - if that works then I believe that will be confirmation that something wrong with the new xbps-static build - not working with ca-certificates rather than there being any problem with the ca-certificates themselves. I'll try that new test shortly and report back.

EDIT: still downloading the static builds. If some of these work, I'll probably keep copies on firstrib github and modify script to use latest working one I can find and will inform Void there is an issue with latest builds in hope they will sort it out later.

wiak

[wiak]

Yes, above post I made is the answer. The build script works fine with older xbps-static. I'll check which if any of the more recent ones actually work, but will be fine to use the old version since it gets auto-removed and replaced with xbps shared lib version during the build. Somebody upstream has clearly made a mess of compiling newer version - I'll notify them later.

EDIT1: I spoke too soon, using xbps-static old 0.51 build: xbps-install-static -S works, and repo-data gets installed but thereafter xbps-install pkg not fetching pkg. More investigation required; this one is complicated... I'll get back to gtkwialog for now, since not much to do there and come back to this later.


EDIT2:
Good News in terms of getting things going again... :

This following xbps-static seems to be working in new builds:

xbps-static-static-0.56_5.x86_64-musl.tar.xz

It was probably the one used previously. I'll check first new one after that to see if that compile was messed up.

EDIT3: Okay, that seems to be it. We can use xbps-static-0.56. None of the others work (including these recent ones they have made). Hopefully, Void will get that sorted out upstream later. I'll put a copy of that 0.56 version on github FirstRib repo as a backup but alter the build script to wget that 0.56 version straight from Void static repo (rather than wget current xbps-static latest as script currently uses). To try fix yourself for now. In build rootfs script, change:

Code: Select all

	# The following puts xbps static binaries in firstrib_rootfs/usr/bin
	wget -c ${repo}/static/xbps-static-latest.x86_64-musl.tar.xz
	tar xJvf xbps-static-latest.x86_64-musl.tar.xz && rm xbps-static-latest.x86_64-musl.tar.xz

to:

Code: Select all

# The following puts xbps static binaries in firstrib_rootfs/usr/bin
	wget -c ${repo}/static/xbps-static-static-0.56_5.x86_64-musl.tar.xz
	tar xJvf xbps-static-static-0.56_5.x86_64-musl.tar.xz && rm xbps-static-static-0.56_5.x86_64-musl.tar.xz

wiak

[wiak]

However... There is another way of building firstrib_rootfs, which might be better, and I have managed to get that work in quick tests even with the latest xbps-static. Big advantage is not having to install certificates for ssl prior to a chroot; instead we build firstrib_rootfs outside of chroot. I didn't try that before, because I was working from first principles idea of using busybox and a package manager inside a chroot and since that worked I just stuck with it (till now). I'll probably also script the alternative method, once I get back to this, and try to give it same plugin facility - I also want to make some quick and easy docs (maybe even a simple gui installer) so no-one afraid to try it. I'm biased, but FirstRib/WeeDog is well worth playing with as a bootable and user-expandable system.

I'll get back to gtkwialog for now, though a day later than I intended (but worth the digression also).

wiak

[rockedge]

Hello wiak!

Yes! great work tracking down the problem. I for one am I big fan and user of WeeDog. I see excellent results using it for several projects and once running is as stable as operating systems get.

I work with several high level developers on the ZoneMinder project, guys from Tesla and SpaceX who were writing code for rockets, space vehicles and electric cars. These guys are very impressed with how well WeeDog actually works, even with FirstRib being in the early development stages.

It would be really awesome if one day there is a GUI to install it and some solid plug files to create different FirstRibs and WeeDogs. My plug files do set up the desktop I start with, but I will start to work on some other ones to improve the desktop, others to make the desktop with more features built in and some much more command line for special tasks...like some X10 home automation. (using X10 because the parts are so cheap since it is older tech)

So I will try out the fixes so I can go ahead and make the WeeDog I need..it will be equipped with the latest real time object detection from live camera streams and eventually supported by a powerful GPU.

Looking very much forward to working with the script version building outside of the chroot!

Don't get the kids sick and keep drinking fluids and get fresh air.

Talk to you soon!

**

[rockedge]

UPDATE:

something is wrong even though the script is running through to completion.

the plug file is not being included and the firstrib_rootfs is not building correctly or better said not completely.

[wiak]

UPDATE:

something is wrong even though the script is running through to completion.

the plug file is not being included and the firstrib_rootfs is not building correctly or better said not completely.

Ok, rockedge, I'll try later today. I didn't test with a plugin file. My simple build built to completion without issue. Surprised there is a problem with that since shouldn't really have anything to do with xbps-static, however, all problems tend to be revealing including revealing the unexpected.

Do you have a particular (not too big plugin file) you'd like me to try with?

Back later.

wiak

[wiak]

the plug file is not being included and the firstrib_rootfs is not building correctly or better said not completely.

Hi rockedge,

Build worked for me with that xbps-static 0.56 using the plugin you contributed here:

http://murga-linux.com/puppy/viewtopic. ... 69#1035969

I'll send you the scripts I used via PM shortly. I don't want to update such a temporary build script to main thread here. I can't think why your build isn't finding your plugin or not completing properly - I don't know what happens during a build if something errors out in terms of an effect on build-completion but, depending on the plugin script, I expect it could choke, though may be nothing in these thoughts related to the issue you have.

wiak

[rockedge]

I have not pinned the problem down yet but I will try out what tips you have.

Last night I ran the script and then converted the firstrib00-64-auto.plug to a shell script and after using the mount script ran it that way. I was able to then start Xnest :1 and then export DISPLAY=:1 which ran as expected.

I then ran the script to make a complete version to boot...but Kernel Panic on start! It was late so I did not pursue a fix at that time.

I am ready to test any thing you throw out there.

[wiak]

Hi rockedge,

Sorry to hear you continue to have issues.

Currently I'm running:

Code: Select all

./build_firstrib_rootfs_103.sh void void amd64 firstrib00-64-auto.plug

on my BionicDog64 system, using that modified build_firstrib_rootfs_103.sh I sent you by PM and watching the terminal screen as it xbps-installs packages according to your plugin. So far it all seems to be going fine.

All going well, once rootfs is completed, I'll run build_weedog_initramfs05_s207.sh and see if it boots for me. Certainly the firstrib_rootfs seems to be auto-building okay thus far with that firstrib00-64-auto.plug you PM'd me.

What host system are you using in your build attempt? Presumably an amd64 host system. As I said, 32bit builds will not currently work because of upstream Void xbps-static changes, but your plugin seems to be for amd64 anyway.

EDIT: The firstrib_rootfs build just completed. I note one error, but doesn't look like anything to do with FirstRib itself (something about xlunch) so I am hoping it is otherwise fine. End of build terminal output is:

Code: Select all

xlunch_4.1.1-1_amd64/etc/xlunch/logout/
xlunch_4.1.1-1_amd64/etc/xlunch/logout/xlunch.lua
xlunch_4.1.1-1_amd64/etc/xlunch/xlunch.lua
xlunch_4.1.1-1_amd64/etc/xlunch/max.lua
xlunch_4.1.1-1_amd64/pet.specs
xlunch_4.1.1-1_amd64/pinstall.sh
cp: cannot stat '/root/Build/xlunch_4.1.1-1_amd64/usr/bin/genentries': No such file or directory
Connecting to rockedge.org (31.22.4.101:80)
backgrounds.tar.gz   100% |*************************************|  246k  0:00:00 ETA
backgrounds/
backgrounds/bubbles_long_wallpaper-greyscale.jpg
backgrounds/DarkGray.svg
backgrounds/housatonic_sky2.jpg
desktop build process finished
rm: cannot remove 'firstrib_rootfs/tmp/*': Input/output error
umount: firstrib_rootfs/proc: not mounted.

Not sure though why it is saying rm: cannot remove "firstrib_rootfs/tmp": Input/output error"

I'll look into that.

EDIT2: Hmmm. I'm now on my kids computer... I hope it is just a coincidence but that Input/output error turns out to be the result of my hard disk failing completely just at the end of the build. That was on my one and only development laptop; it's a very old machine but I've never had trouble with it before. However, it is possible that its (small) SSD harddrive finally gave up because the workload of building that firstrib_rootfs was so high. That is likeliest reason, I suppose, but it is a worry; problem now is that I have no development machine and no replacement hard drive at this time (and its a smaller physical size of hd than normal required - rather special: 1.8" I think, but I've seen them on ebay in the past... sigh). I don't have particularly good most-recent backups either, but that's less of a problem - just inconvenient. Oh well, I'm away to the cafe for a long black to relax and think how best to proceed. Computers are fine when they work...

wiak