RC7 (STABLE) WeeDogLinux Arch 64 now released

[rockedge]

wiak!

That is awful! Hardware failure is a true bummer. What can we do to get you back up and running?

I do have good news though!...the build worked with firstrib00-64-auto. I am posting using Firefox on this brand new WeeDog64.

The desktop completed as expected and ran the second script built the WeeDog64 and the system booted and ran on the first try. Once this WeeDog64 is first started a step needs to be completed so the xlunch menu system gets initialized. Open and click on /usr/share/applications/update-entries.desktop

or in a terminal run ->

Code: Select all

xlunch-menu-update

[wiak]

wiak!

That is awful! Hardware failure is a true bummer. What can we do to get you back up and running?

Yes, it was bad timing, but when I thought about it later I remembered a couple of months ago my dev laptop refused to boot whilst claiming no system boot disk present. I think it was basically letting me know that the ssd harddisk was about to completely fail, so not overly surprising it did so as its last breath in a big WeeDog firstrib_rootfs build. I will look for another ssd for it on ebay, but meanwhile I have some other old laptops I can configure to become new dev machine - actually my wife's old laptop was almost the same model (HP Elitebook 2530p) but more conventional harddisk and with slower CPU fitted - I may just steal that harddisk out of it and put in my own dev machine and see how that goes. But I have another potential dev machine in the side-wing as an alternative anyway.

Main thing is I'm glad you achieved a successful built - I was pretty sure nothing was fundamentally wrong.

EDIT: Ok, took ten minutes to steal the harddrive out of my partner's machine and replace the SSD with that, so booting again. It's slower to first load big apps (like firefox) though the previous SSD drive was ancient probably not blazingly fast either... (apparently was 3Gb/s; I presume they mean Gbytes here though I have no idea). Pity about the defunct 1.8 inch microSATA SSD (it was only 80GB) - now just a dead rectangle of plastic and metal...

Anyway, now to reinstall/configure this machine for BionicDog64 instead of the older XenialDog64 the old harddrive has on it.

Cheers, wiak

[wiak]

So I bought an el cheapo microSATA SSD from China which was a bit bigger (128GB up from 80GB) for just NZ dollare 41 (about US dollars 26) with free shipping. Of course it will take a month or more to arrive and I'm just hoping I bought correct interface model and that it's reasonably fast... Bit of a gamble but hardly breaking the bank.

Meanwhile I'll use the old spin-up type HD from old machine that I've swapped into my development laptop. Will do for now.

wiak

[wiak]

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

Hello rockedge,

I've finally found the actual fix [EDIT: turned out only for x86_64 builds] (rather than having to use and older 0.56 xbps-static compile (which only worked with x86_64 builds, not 32 bit builds anyway). So the following should work correctly with latest xbps-static compile, so the main build_firstrib_rootfs_103.sh script works afterall, as long as you run it as explained below.

I haven't actually tried a new 32-bit build yet, but I expect this to work in either 32bit or 64bit builds.

Solution:

Use the build_firstrib_rootfs_103.sh provided at download link:

http://www.murga-linux.com/puppy/viewto ... 24#1035524

But when running it, precede the line by setting the following variable (or simply export it first):

Code: Select all

XBPS_ARCH="x86_64"
(or XBPS_ARCH="i686" for 32bit builds; this one didn't work...)

For example:

Code: Select all

XBPS_ARCH="x86_64" ./build_firstrib_rootfs_103.sh void void amd64 firstrib00.plug_void_default_anyarch

Apparently, most compilations of xbps-static examine that XBPS_ARCH variable to find out the relevant architecture to use. Without it being set, most choke. Simple as that.

I'll try with 32bit build later, but I'm expecting this is the solution [only for x86_64 builds...]. I lost my 32bit host install when my disk drive failed, hence my not trying 32bit build yet... Won't take long to reinstall of course.

Rather than modifying the documentation, I'll soon modify the build script to set that variable within it, and upload a new script in a day or two. There are a few extra minor changes I also want to make to the script, which I'll do at the same time. Later I'll also work on a non-chroot version; a useful alternative I spoke of before.

EDIT: Unfortunatly, the above is only working for x86_64 builds, not for i686 builds (i.e. XBPS_ARCH=x86_64 works with latest xbps-static compiles, but there is no latest i686 xbps-static build and the last is version 0.51_1 but that version does not work correctly whether XBPS_ARCH=i686 is set or not...). Looks like for i686 32bit builds I'd have to compile a newer version of xbps_static binary myself; I don't know, which version was used previously that used to work - probably that 0.51_1 compile, but something has changed somewhere (upstream I guess) so that doesn't work now anyway.

EDIT2: NOte that I am also continuing to experiment with the build_firstrib_rootfs that doesn't require a chroot prior to using xbps-static. That is also working fine for amd64 (x86_64) case, but again not working for i686 builds (it correctly begins by fetching i686-repodata, but thereafter can't find the packages...), which is very frustrating (though personally I only use 64bit builds). I've raised an issue at xbps github. I'm only creating my firstrib_rootfs using this alternative method line by line manually at present though I'll make a complete script soon. Sadly it looks like there is less and less interest in supporting i686 architecture in the Linux world more generally.

wiak

[rockedge]

excellent work wiak!

I see now what you are saying....I will try a run in a few....must get cat food before the government shuts us all down for corona virus concerns

I will report on the results! The system built after the first work around is running very well so I am back to recommending WeeDog for the cool projects

[wiak]

The system built after the first work around is running very well so I am back to recommending WeeDog for the cool projects

Nice to hear, rockedge, though I can't help but wonder if WeeDog is the least understood and used distribution in the OS universe... But that's fine. It does have some love, and it remains a fun distraction for me and most especially a good target for added future developments. Biased though I certainly am, I can't help but consider it a bit of a hidden gem that is actually quite easy to use. I certainly do need to improve the documentation with that ease of use in mind though and simple gui frontend would always significantly help bring notice of its ease of use to the Linux distro public.

On the other hand, it may simply be that most of us can't be bothered building up a Linux distro from simple core parts, which to a large extent is really what WeeDog is all about. Nice to have that simple script build ability though for those who are in the mood to try their hand at it.

wiak

[wiak]

Further good news. One day only after raising issue on xbps github page that xbps-static for i686 system not working, a kind soul there (Duncaen) prepared an i686 compilaton of the latest xbps-static version:

https://github.com/void-linux/xbps/issues/250

I've successfully tested it on my XenialDog32 host system via build command:

Code: Select all

XBPS_ARCH=i686 ./build_firstrib_rootfs_103.sh void void i386 firstrib00.plug_void_default_anyarch

Note that I modified firstrib00.plug_void_default_anyarch to use linux kernel 4.19 prior to running this (since linux alone was unsuccessful trying to install kernel 5.4.25_1 for some reason, which is not a problem of the latest i686 xbps_static however - presumably i686 version of kernel 5.4.25_1 not in the repo...).

Owing to some debian bad habits, I wrongly used name i386 in my script for the Void rootfs builds; it should be i686. Similarly I used amd64, which for Void should actually be x86_64. In the next update of build_firstrib_rootfs script I'll fix these naming errors. Not sure when I'll upload new version, but shouldn't be long away.

Great to have 32bit builds working again!

wiak

[wiak]

Well it has been a long time since I uploaded any new build_firstrib_rootfs script, but have now uploaded new build_firstrib_rootfs_104.sh

Changes.

Nothing much and below are only if you are building distro type Void:

1. Included export XBPS_ARCH=x86_64 or i686 in the build script so new xbps-static compile works correctly without needing to manually export that variable at the command line.

2. For Void builds, the available architectures to put on commandline are now either amd64 or i686 (not i386, which was an earlier mistake in naming I used). In actual fact Void refers to amd64 as x86_64, but to avoid confusion I have left things as amd64 (since it means the same thing, and also to Debian-type systems).

3. If firstrib.repo file hasn't been made to indicate the repo="url" you want to use, then build_firstrib_rootfs script now presents you with a list of Mirrors. I've included that because it can make a BIG difference in creation/download speed if you pick an active mirror near to your geographical location.

NOTE that, upstream at Void, xbps-static has recently been recompiled. Until I raised an issue at xbps github that new compile had only been done for x86_64 and not for i686 and as a consequence i686 firstrib_rootfs builds were no longer working. However, an i686 compile was then added upstream and both x86_64 and i686 firstrib_rootfs builds are working fine again.

wiak

[rockedge]

Nice wiak! Nice.....

Excellent work and a good job! Very helpful and I am immediately going to be using the new script.

I will report later today. Thanks for the great effort wiak.

as they say down my street..."you're the Man!" (as in "The Man")

[wiak]

I'm currently working on version of build_firstrib_rootfs that does not require use of chroot internally. It's pretty much working. It is a really a demonstration of just how clever the Void package manager xbps is; I may be wrong, but I don't think it is possible to do something similar with Debian dpkg/apt. In practice I can build a Void-based rootfs very quickly in a few commandlines, but the script I'm writing is aimed at keeping plugin facility working and also keeps the alternative distro build modes (Debian/Ubuntu/Devuan) though these remain unchanged and do require chroot during the build.

Potentially it is a big advantage for Void not requiring chroot since makes it easy to implement alternative plugin methods since files can be directly accessed in the host system at any time during the build. One slight drawback is that xbps-install is no longer in PATH /usr/bin and a new option to xbps-install needs to be added to any lines in which it appears. So plugins need a conversion to the new form; but... for most of the time the only conversion required is an extremely simply sed one-liner.

I hope to upload the new (alternative) build_firstrib_rootfs script later today or tomorrow following some plugin testing. I'm keeping both methods since the chroot method will work on some very basic systems that the non-chroot method would not work on (since non-chroot relies on underlying host ca-certificate handling as far as I understand it).

wiak

[rockedge]

Completed a build successfully using v104 with firstrib00-64-auto.plug and produced a WeeDog64.

The entire process ran really well. I later ran the script to install ZoneMinder and a LHMP

Code: Select all

./build_ZM.sh

Next phase is to install python3 and the components for event push notifications and object detection / face recognition.

[rockedge]

Hello wiak,
I've read your post and definitely keep both versions of the script alive. I can test the new version right away, this WeeDog is running great and I can enjoy leaving it in a good working order and go build another with a more intricate plug file

v104 worked great, so a good reason to keep it going as well !!

[wiak]

Hi rockedge,

Glad all is going well with your current builds.

My end feeling on working further with this is that there is NO other package manager so self-contained/stand-on-its-own-capable as Void Linux xbps. Makes autobuild distro building clean and easy like a breath of fresh air. Effectively, you can run static xbps build from most ANY Linux distro without caring about distrospecs or any other need from underlying distro.

Yes, definitely, keeping/maintaining both versions is very useful - the way I'm writing the new script makes it almost identical in operation for the most part though. Hence I'm currently naming the new script build_firstrib_rootfs_nonchrootvoid_104.sh since plugin handling and so on left exactly the same. It will be easier to add additional plugin handling though. The Debian/Ubuntu/Devuan routines also remain unchanged (still use a chroot) as I said.

wiak

[rockedge]

I used an ArchPup32 to run the most recent scripts and successfully built a WeeDog32 (Void Linux).

I used the firstrib00-32-auto.plug to create the desktop. It really runs well idling with 99.3 megabytes of used RAM.

and I added palemoon as a second browser and pUTTY for the SSH client.

I would like to add something that will create the desktop disk drive / partitions icons and mange mount and umount of them

[wiak]

Looks good rockedge.

Interesting you are using an ArchPup. When I finish this latest nochrootvoid script I'm planning to complete that FirstRib Arch build function, so a standard Arch can also be made as a firstrib_rootfs. Some may like that option (though Void likely to remain my own preference). I left a place-holder for that Arch capability, but summer was about to come here so finishing that was put on hold; from previously looking into it I think I can manage that though. Will need chroot mechanism though since more like debootstrap as in Debian builds.

Whichever distro firstrib_rootfs gets produced, will still use same WeeDog initramfs build to complete of course.

wiak

[wiak]

build_firstrib_rootfs_nochrootvoid_104beta1.sh uploaded to downloads post:

http://www.murga-linux.com/puppy/viewto ... 24#1035524

In many/most cases, user should be able to use with existing firstrib build rootfs plugin file after one slight conversion through sed as follows (and as documented in the script itself):

Code: Select all

sed -i 's%xbps-install%sxbps/usr/bin/xbps-install -r firstrib_rootfs%g' <plugin_name>

I've attached a simple converted original plugin to this post that I used with amd64 build (for 1686 build, linux entry in plugin doesn't work since i686 needs earlier kernel such as linux4.19 in plugin list instead).

Generally, using this no chroot required for void rootfs build script works much the same as standard build_firstrib_rootfs_104.sh script. Only main user difference is that the build pauses and asks confirmation that you accept the ca-certificate for the selected repo. Just enter 'y' and build will then proceed.

One big advantage of this alternative build firstrib_rootfs script is that it involved no messy mount, chroot, umount situation. That also means it is easier to modify the script to do extra processing in some additional plugin system (though existing plugin faculty kept for backwards compatibility (other than the simple sed conversion above) and because it works. I will maintain both this nonchrootvoid script and the original which does use a chroot for void linux packages install.

wiak

[wiak]

Well my new 128GB SSD arrived today from somewhere in China. Need that to replace the old 80GB SSD that had suddenly refused to be read or written or talk to me in any way in my main (old) laptop that I use for development. I currently, temporarily, have an old (slow... yawn...) mechanical harddrive of some type swapped into it from another machine, but now I can return it to its former glory...

wiak

[rockedge]

excellent news wiak! Sounds like the performance will be really good.

I used the beta script with the firstrib00-64-nochroot.plug and it looks successful. I am about to run the next script to make a boot able system


Update: Did a second run with firstrib00-64-auto-nochroot.plug and it went somewhere awry. It somehow also trashed my BIonic64 system which I had to manually do a hot shutdown and upon reboot will not start the xorg server any more.

I think the first run worked and I have no idea why the second run with the other plug file got so wacked out.

[wiak]

Update: Did a second run with firstrib00-64-auto-nochroot.plug and it went somewhere awry. It somehow also trashed my BIonic64 system which I had to manually do a hot shutdown and upon reboot will not start the xorg server any more.

I think the first run worked and I have no idea why the second run with the other plug file got so wacked out.

Well, it would be perfectly possible to trash a system with a plugin used with the non-chroot script, so that's a disadvantage to be sure - the plugin writer has to take responsibility. Reason I say that is that since a chroot is not used to execute the commands in the plugin, the underlying host filesystem is available and hence possible to trash it. Not sure if that is what happened with the plugin you used, but it is certainly quite possible. I doubt the build script itself otherwise trashed your system, but it's beta and only further tests would reveal that one way or the other.

It's worth keeping non-chroot method for tricky plugin situations, where direct access to host filesystem makes some things easier, but probably best not to recommend it in general since considerably more dangerous... Indeed, with that in mind I will probably move the script to a post of its own, with warnings...

wiak

[rockedge]

Hi wiak,

the first run using the plug file that creates the desktop but when booted starts on a login command line and needs a manual start of startx to get the desktop. This plug file worked in the non-chroot mode. But the version that creates the setup for autologin failed and somehow damaged the Bionic64 host system. Not a big deal since I just deleted the save folder and started Bionic64 fresh and new, I was prepared that something may go wrong. Until I've run it a few times and saw how operates I would use a disposable host OS

The chroot'ed script builds a good version of both plug files.

I like the Void version the most and spend most of the time using it. With some more tweaking and adding a few scripts here and there WeeDog could be a great desktop. Some point I will have to go back and see about building an ISO that will boot. Even though the scripts are super easy to use and give great results, most willing to test it out would be enticed by an ISO

Otherwise on another WeeDog64-104 all systems are a Go, and I'm seeing some really stable operation of a LHMP, ZoneMinder, zmeventnotification server, object detection, face recognition and running a X10 usb transceiver to a X10 receiver that places ON and OFF DIM or BRIGHT signals on the house electrical wiring which X10 lamp modules plugged into outlets can read those commands by address and turn lights and appliances on and off or dim and brighten. This WeeDog is running a bunch of daemons and background scripts while the CPU is staying nice and cool and over all load is 1.30 over 4 cores and 4 threads