RC7 (STABLE) WeeDogLinux Arch 64 now released

[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

[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