RC7 (STABLE) WeeDogLinux Arch 64 now released

[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

[wiak]

RC5 release announcement in following post.

wiak

[wiak]

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

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

[EBored]

How secure is this distro ? More secure from puli distro ?

[DevsAd]

@ wiak

How can we reconcile the restrictions in your identical edits above and your final paragraph here ?

What do others have to say about wiak's personal right to discriminate unfairly ?

[rockedge]

@EBored

Since you can adjust almost any parameter before the build one can make the distro one intends to create, as secure or insecure as desired.

Since it's inherently a multi-user system you could make it blow Puli away like dust if security is so paramount.