RC7 (STABLE) WeeDogLinux Arch 64 now released

[wiak]

To report I've just run a successful build of a WeeDog64-Void

Code: Select all

./build_firstrib_rootfs_104.sh void rolling amd64 firstrib00-64-auto.plug
./build_weedog_initramfs05_s207.sh void

https://github.com/techrockedge/weedog-ZM

The plug file I used is not quite refined and could use some improvements but is still a good example of a plug file. The build was error free.

This WeeDogLinux Void version is running so well. Very good results of CPU loads at idle and CPU temps remain in the lower ranges and RAM usage at start up was 148 megs used.

I've been checking out your github site for this rockedge. Rest assured I remain keen and determined to get your zoneminder version running on some other machine I have. In fact that was my priority but in a brief experiment with creating first Arch WeeDog I had quick success so ended up concentrating on polishing that up for desktop use. Whilst that Arch config work is fresh in my brain I'll likely concentrate on any bug-fixing required prior to stable version 2.0.8 release. As I mentioned to you in PM there does seem to be some problem with registering on main WeeDog forum, at least as far as email confirmation is concerned (a bit like here on murga forum, which is surprising since WeeDog forum certainly has nice uptodate phpBB version).

Now that WeeDogLinux Arch64 rc2 is in nice running order, I will also spend some time on trying to produce a Void Linux version of same desktop config, since much of the work already done via that Arch development. But I have practical wish to have zoneminder system running, so not sure where my priorities will end up or if I'll try both tasks in parallel...

@TerryH: glad managed to sort out your wifi issues and thanks for your feedback more generally. Will try and get some better documentation prepared at some stage in terms of how weedog can be configured in different ways (e.g. the various optional boot scerios including copy2ram; having upper_changes persistence directory in RAM or in alternative directory or hard disk. How previous upper_changes folders can be made into a separate numbered sfs, which are then auto-loaded in layers and so on).

As I've said earlier, I'll leave main discussions to posts on weedoglinux.rockedge.org since best, I feel, to collect all feedback on main forum site, but many of the details of how weedog work (including interesting contributions/ideas from both rockedge and rufwood in particular are to be found in the earlier posts of this thread. A lot to read though, so will hopefully get that better documented eventually... Having said that, the latest WeeDogLinux Arch64 basically just works so technical details aren't particularly required by anyone just wanting to try it out, and no real reason for anyone to bother about underlying functionality unless they have an interest in that kind of stuff - will try to make it as user-friendly as possible anyway.

wiak

[rockedge]

Hello Terry H!

Are you still having problems logging in the the weedoglinux forum?

I was going to promote your position to allow posting without any restrictions.
This feature I have disabled after looking over whether or not it is needed for this forum, but I may have done something with your account accidentally.

I will look it over and see what I've done!

[Terry H]

Hello Terry H!

Are you still having problems logging in the the weedoglinux forum?

I was going to promote your position to allow posting without any restrictions.
This feature I have disabled after looking over whether or not it is needed for this forum, but I may have done something with your account accidentally.

I will look it over and see what I've done!

Access to the weedog forum is OK now. Just for a short time yesterday afternoon I had an issue. Logged in later it was OK, just logged in without issue.

Thanks

[wiak]

All announcements, details and feedback has been moved to only:

https://weedoglinux.rockedge.org/viewto ... p=226#p226

[wiak]

All announcements, details and feedback has been moved to only:

https://weedoglinux.rockedge.org/viewto ... p=226#p226

[wiak]

All announcements, details and feedback has been moved to only:

https://weedoglinux.rockedge.org/viewto ... p=226#p226

[rockedge]

Built a WeeDog64-Arch-RC3 under 20 minutes sucessfully.

Screenshot is RC3 running as 'root' with a jwm - rox pinboard and xLunch menu system desktop and for the user weedog it uses the stock openbox. So as I swtich user I am switching to a customized desktop for that user.

[wiak]

Unless you are a firstrib plugin builder, who wants to build their own customised build (or soon plan to be) you do not need to rebuild from the default rc3 build since the final openboxFull desktok system is identical... What is different is simply inside the build scripts themselves, with much more flexible new-build plugin handling.

Please find new RC4 version of WeeDogLinux Arch64 release 2.0.8 build script at WeeDogLinux forum first post of thread:

https://weedoglinux.rockedge.org/viewto ... 1abf2f#p42

(I meant to announce on new thread but messed it up... I'll probably fix that forum positioning error later...)

Just download the WeeDogLinux forum-provided make00arch_amd64-latest.sh into the empty directory you wish to boot the build from, make the script executable with chmod +x, and run it with the simple command:

Code: Select all

./make_Arch_amd64-openboxFull_latest.sh pause

-----------------------------------------------------------------------------------
Please note also that you can find a new "HowTo use multiple f_XXX (!) plugins and create your own" related to this RC4 build at post:

https://weedoglinux.rockedge.org/viewtopic.php?p=122

That HowTo explains both how to create your own plugins, and how to submit them for forum and WeeDogLinux gitlab publication (including details of naming conventions required for correct operation and submission).
---------------------------------------------------------------

Assuming no major errors are discovered in RC4 version of this release (which I will endeavour to quickly fix), I am planning to now have a 'feature freeze' for maybe a month whilst I build a similar f_ plugin for WeeDogLinux Void flavour.

wiak

[fredx181]

Hi wiak, finally got to trying out building weedog.

Rc4 didn't work for me, failed at stage 3 building initrd , with message vmlinuz not found (it seems to me that the kernel didn't install, nothing in firstrib_rootfs/boot and firstrib_rootfs/lib/modules)
Then I tried rc1 attached here:
https://weedoglinux.rockedge.org/viewto ... 03298f6#p6
And the build went well, booted ok and posting from it now, very nice, openbox, tint2 etc.. !
Ethernet working, went installing some programs without problems
I would prefer personally a much smaller system (2.5 GB .sfs is far from "tiny" ). should be possible I guess, didn't read yet about how to do it.
I'd suggest to do some cleaning (e.g. pacman cache in /var, it is 1 GB total) before creating the main .sfs

Fred

[rockedge]

Hello Fred,
sounds like a repo timeout occurred during your run of RC4. The sure indicator is the missing vmlinuz.

simply re-running RC4 script without deleting any files will continue where it left off and complete the build.

Good advice! Stripping out the package cache on /var makes total sense to reduce the size of the sfs. I rename the sfs so it does not load and I use the uncompressed firstrib_rootfs by naming it 01firstrib_rootfs.

Next move is to look at making the size of WeeDog smaller, at some future point in time!

I follow your DDog work since you have tackled many of these development stages already.

[fredx181]

Hi rockedge, tried rc4 several times, same error every time:

Code: Select all

Press Enter key when ready for stage3: build initrd

ls: cannot access 'firstrib_rootfs/boot/vmlinuz*': No such file or directory

EDIT: before that all seems to go well, installing lots of packages.
Does it work for you ?

Fred

[Terry H]

Hi rockedge, tried rc4 several times, same error every time:

Code: Select all

Press Enter key when ready for stage3: build initrd

ls: cannot access 'firstrib_rootfs/boot/vmlinuz*': No such file or directory

EDIT: before that all seems to go well, installing lots of packages.
Does it work for you ?

Fred

Same result here, have run several times. Checked the boot directory and it is empty, so there is no vmlinuz downloaded/created during build.

[rockedge]

I ran it RC4 successfully yesterday but I also had errors after the first stage just before it completed.

So I will run it now and see how it builds and I will report on how this run goes!

2 days ago I had to run the script 7 times using 3 different mirrors to get a completion.

I still feel this stage 3 problem is because of repo timeouts during stage 1, so I will watch closely during the run

I used a new Bionic64 and forgot this important step and my run of the script ended in the same error.

Arch Linux uses zstd decompression utility which you will need to be installed on your host build system.

[wiak]

Sorry, I'm only announcing releases here on murga forum so hadn't noticed there was feedback.

Yes, sorry guys, I had simply forgotten to push the new version up to gitlab... sigh. All was fine on my gitlab clone, which I did push last night, but the push must have failed (I was probably sleepy).

I believe that's all the problem is... nothing I think wrong with the make... build script or any of the other ones (they just weren't yet on gitlab...).

I've pushed the rc4 version up now and will test with a new build and all going well (as I expect) I'll repost the make... script up to weedoglinux forum. Please only send feedback to that site since I don't activate notifications from here but just browse when and if i get round to it

I'd suggest to do some cleaning (e.g. pacman cache in /var, it is 1 GB total) before creating the main .sfs

Yes, such 'cleaning' of cache, and documentation/man-pages etc, has been discussed earlier in thread. The pacman cache is probably all I would consider cleaning myself since disc storage size isn't an issue in my opinion, but making a trimmed version for copy2ram use was discussed as likely future project addition. Personally I prefer keeping my pacman cache because I regulary check removing and reinstalling packages and when uptodate in the cache these get used rather than having to download again. But for most that cache isn't relevant and can be simply deleted to save space (prior to building the 01firstrib_rootfs.sfs), expecially since Arch is a rolling distribution which often quickly brings users most uptodate new versions of application packages.

rockedge is working on JWM/ROX version for those that prefer that. I imagine he might also be interested in making a trim-utility/plugin (WeeDogLinux build system likes plugins... ).

wiak

[wiak]

rc4 build should be working now that I've correctly pushed my rc4 changes up to gitlab...

I've reuploaded the build script (there was nothing wrong with that - just rc4 hadn't uploaded when I thought I had 'pushed' it ...sigh).

wiak

[step]

@trockeredge, will your work on JWM/ROX be usable also to mix Openbox/ROX? That would be my first choice because it's the standard Fatdog setup.

For the record, I built and started rc3 successfully. However, the network connection didn't work. My system has ethernet only, no wifi. On first boot a small terminal popped up asking for the name of the ethernet interface. Afterwards, ifconfig showed that an APIPA IP address was associated with my ethernet, therefore no connection was possible. I didn't further investigate this issue due to lack of time.

[wiak]

Ok, I relented and removed /var/cache/pacman/pkg after build, which cuts the squashfs down to 1.5GiB, so it's nice to have a smaller sfs. But, if you take a look with Graphical Disk Map you'll see that the other main size reasons are due to things like lots of firmware/modules available from Arch to make it work on tons of hardware - that could be trimmed to at least a half if one could be bothered. But the install also includes full libreoffice including full Java, and there is libgo and webkit and some other big stuff that proves useful in practice so I don't mind it taking up a big disk space. My goodness, the whole thing could install to a 4GB usb flash stick so why bother - and disk size has nothing to do with RAM used or CPU used (just check how good WeeDogLinux Arch is using top or htop...).

So, if you really want to use time making it smaller, easiest/best would probably be to take out some of the big packages and not have that extra functionality - and use cut down ones from a specially trimmed sfs file if you like, maybe without some functionality, like Java and such like. But all that trimming will only effect disk storage size by a GB or so and have no effect on performance whatsoever. Main performance hog for all Linux is same for everyone - browsers/heavy-webpages eat RAM - making OS download files smaller has no effect on any of that. Copying specially trimmed small version Linux distros into RAM just makes that matter worse (since you end up with even less usable RAM!) and startup times from modern disks is close to as fast as RAM nowadays anyway and once in cache, well that IS RAM so as fast as can be (but actively being used RAM...). copy2ram is a waste of RAM unless you do so as a security measure of some sort or another (though it is more than doubtful that security is increased by much for all the effort - if at all really... And how many are actually using copy2ram switch in practice - not many I bet)

Yes Openbox/Rox-pinbrd could be used/added quite easily; JWM more difficult for me personally because I don't have much knowledge of configuring JWM (so rockedge the expert on that and he'd probably be best configuring Rox pinboard use too I'd imagine), but Roxpinbrd no problem to use genarally as I'm sure you would know, step. I just chose pcmanfm-desktop because I had pcmanfm already on the system and Arch Wiki gave good instructions for openbox/tint2/pcmanfm-desktop and I liked it.

Your ethernet sounds strange, step. I just have a little router provided by some ISP or other - nothing special. Just does WPA2 wifi and has some ethernet ports on the back of it. I never use ethernet - just Wifi, but I did try plugging ethernet cable in and entered the ethernet interface name when the wee terminal box popped up at boot time (my eth interface was enp0s25 (but can arrange for that to show as eth0... ask rockedge about the grub kernel line to force eth0 type naming convention), then I just hit Enter key for the questions about SSID and password (per the instructions in the terminal questions). i.e. no entry for these two. And bang, I was connected via my standard ethernet... Never heard of APIPA IP address (you sure your not running MS windows?). My ethernet connected as 192.168.1.9 (which is pretty standard expectation for me...)..

And my wifi connected now as 192.168.1.5:

Code: Select all

[root@bootstrap ~]# ip address

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp0s25: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
    link/ether 00:23:5a:c3:83:83 brd ff:ff:ff:ff:ff:ff
3: wls1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    link/ether 00:1e:65:e4:2d:c8 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.5/24 brd 192.168.1.255 scope global wls1
       valid_lft forever preferred_lft forever
    inet6 fe80::21e:65ff:fee4:2dc8/64 scope link 
       valid_lft forever preferred_lft forever

Meanwhile, my two kids and partner are all sitting at their own computers of different types all running WeeDogLinux Arch64 - two of these are on ethernet.

But, if you weren't so busy to not be bothered you should post your results at the WeeDogLinux forum since that would be more useful for me and everyone else working with it, thanks. Doesn't matter at all though. I built this for my family - end of story really. If anyone else has found it useful, well that's nice, and I help where I can and modify things to help with the ideas/needs others express. It's a build system - it exists - I use it and it is fun to receive alternative build plugins, which are also useful to me. But if only my family were using it, that would be fine too, and I would make it a private gitlab site so I don't need to worry if new versions work or not! But at least the failure brought some new feedback.

Anyway, all going again. Please, I repeat, post your feedback (if any) to WeeDogLinux forum in preference. Thnks.

wiak

[rockedge]

JWM/ROX be usable also to mix Openbox/ROX?

Yes it will. I am experimenting right now with a WeeDog64-Arch that I have the root user using JWM and ROX --pinboard and the user weedog using openbox/tint2 as the desktop.

Switch back to root user and the jwm/rox --pinboard is again used.

I have even created the user www-data and logged in as that user and could use a 3rd window manager for this user only, if so desired.

I will eventually have a plug that will create a jwm/rox desktop only and also a second plug that will offer either the jwm/rox or openbox/tint2 which could be switched back and forth according to the user logged in.

So far it seems easiest to modify the .xinitrc file for each user to start the desktop wanted. So most likely I will not write any script systems to switch desktops on the fly....UNLESS I 'borrow' some code from Puppy Linux or Fatdog.....we will see.....

[step]

@wiak, thank you for your answer. I will try again the ethernet network and post to your dedicated forum if I can't get it to work. Regarding the APIPA address, I might have hastily misread the digits because the GUI fonts were very small. Anyway, ethernet wasn't connected.

@rockeredge, thank you.

[wiak]

I'll add an .Xresources file for xterm font size next time.

wiak