Puppy Linux Discussion Forum

I thought I'd give WeeDog a try. Following seeing that Duprate had Makulu working I decided to try the same Droid release. I unfortunately couldn't get it to boot to X, it only booted to tty1. Checked Xorg.log, which had a dbus error.

@Duprate Did your attempt boot without issue?

@wiak Thanks for you continued development of Weedog. Your work on this new initrd is a great innovation.

Several attempts failed. When I paid more attention to what Fred described, it worked!

1- Important to place the kernel modules inside the initrd.
2- w_changes=RAM, it didn't work for me!

Duprate wrote: Mon Sep 06, 2021 8:51 pm

Several attempts failed. When I paid more attention to what Fred described, it worked!

1- Important to place the kernel modules inside the initrd.
2- w_changes=RAM, it didn't work for me!

Thanks, I believe I have it set up OK, it booted first attempt, but not to desktop.

What is the advantage and disadvantage of 'WeeDogged' Manjaro XFCE? Now, I reply this post using manjaro XFCE. And It is very easy to use. Is Weedogged Manjaro XFCE mean that we 'puppy linux' ing manjaro XFCE? So it can frugal install on flashdisk? If so, this is very nice. I'll try it, insyaAllah. Thank you, Wiak and Fred.

recobayu wrote: Mon Sep 06, 2021 11:28 pm

What is the advantage and disadvantage of 'WeeDogged' Manjaro XFCE? Now, I reply this post using manjaro XFCE. And It is very easy to use. Is Weedogged Manjaro XFCE mean that we 'puppy linux' ing manjaro XFCE? So it can frugal install on flashdisk? If so, this is very nice. I'll try it, insyaAllah. Thank you, Wiak and Fred.

Yes, means you can frugal install it (to usb stick, hard drive, sd card, or wherever) and use addon overlayfs layer modules with it and get save persistence (or in RAM with a save back to flash on demand script). Same create process (best to follow fredx181's clearer instructions) should also work with many other distro root-filesystems.

@@TerryH and @Duprate: I haven't myself tried Makulu, but I plan to - I'm always looking for a good Linux plus Android apps solution.

EDIT: going to download Makulu iso now. That one sounds really interesting to me.

I just followed Fred's guide to do the Raspberry Pi Desktop OS (basically debian buster live installation iso).

Posting from it now.

Basically the only real difference is you need to run everything in the /live folder and you only need to rename the filesystem.squashfs to 04firstrib_rootfs.sfs.

I'll try to document what I did a little better tomorrow.

edit: This is my menu.1st entry

title Raspberry Pi Weedog
find --set-root uuid () 28692158-8947-490d-aef2-xxxxxxxxxxxxxx
kernel /RaspberryPi/live/vmlinuz2 w_bootfrom=UUID=28692158-8947-490d-aef2-xxxxxxxxxxx=/RaspberryPi/live
initrd /RaspberryPi/live/initrd.gz

There are 3 vmlinuz files. If you look in /boot/grub/grub.cfg, it will tell you which ones are which. vmlinuz2 is for 64 bit systems.

Tired of not being root already.

<-- Back to WDL Cheatsheet menu: viewtopic.php?p=36426#p36426

Duprate wrote: Mon Sep 06, 2021 8:51 pm

2- w_changes=RAM, it didn't work for me!

NOTE: The following post is quite technical. Don't bother with it at this stage unless you are particularly intersted in getting RAM modes to work - system works fine by default with direct writes to external upper_changes for persistence anyway. But I'm just writing this to document that saving RAM modes does exist as a feature should you ever need it

There is no longer any w_changes=RAM mode.

Rather, there are three alternative w_changes RAM modes, as follows:

1.
w_changes=RAM0
This mode doesn't use any existing external media upper_changes folder at all. Instead a temporary upper_changes folder is created in RAM at directory /mnt/layers/RAM/upper_changes. Any session changes will appear in there as you work, but all is lost on shutdown (since was just in RAM) though of course you can copy or rsync whatever was there out to a new external upper_changes folder for using again some other time.

2. w_changes=RAM1
This was just a variation on w_changes=RAM0 above. The only difference is that once the RAM /mnt/layers/RAM/upper_changes is created, any external upper_changes contents are copied into that on boot. Again, any new changes just appear in RAM (the external upper_changes not being used at all after boot), and these new session changes will be lost on shutdown. However, I use a simple rsync script to allow me to copy the whole lot back again to the external upper_changes folder - i.e. this provides persistence. The disadvantage of this mode is that copying in the external upper_changes contents uses up RAM unnecessarily, but in practice the method is actually nice, simple, and reliable if you keep your external upper_changes folder small in size. In fact I preferred this mode for months - but I have a technique when using it:
a. When I first install new system I tend to not put upper_changes in RAM at all but instead fill my external upper_changes with all the extra big apps I want.
b. Then I make a 'rollback' upper_changes file by simply renaming the existing external upper_changes directory as somthing like 50upper_changes (you can leave that as an uncompressed changes rollback folder or use mksquashfs to produce 50upper_changes.sfs). The next time you boot the system that 50upper_changes simply becomes top read-only layer and a fresh empty upper_changes folder becomes the topmost read/write layer. I sometimes repeat that add to system followed by rollback files (e.g. 51upper_changes, 52upper_changes). Thereafter I have usually nothing else much to add so then I alter my grub kernel config to use w_changes=RAM1 mode and often do not bother rsyncing back thereafter (and keep external upper_changes of zero or very small size).
I have a reasonably well tested rsync script for this that I'll publish later. You more likely want to use no w_changes RAM modes at all or will prefer w_changes=RAM2 mode below since it saves some RAM used:

3. w_changes=RAM2
However, the third w_changes mode (w_changes=RAM2) is more like what you'd traditionally use on DebianDogs or Puppy systems. Again upper_changes is saved into RAM at /mnt/layers/RAM/upper_changes, but difference with this RAM2 mode is that any external upper_changes folder gets automatically mounted as the topmost read-only layer (so merged as part of the overall overlay merge result). Once again, any changes that occur during a boot session get lost on shutdown OR you run a save-back to the external upper_changes folder script to get full persistence. Note however that /mnt/layers/RAM/upper_changes for this mode only contains that single boots session changes so the save back to external upper_changes script actually needs to MERGE that /mnt/layers/RAM/upper_changes and not simply clobber the external upper_changes. Complication with this RAM2 scenario is that you have to keep some overlayfs 'whiteout' marker files for layer deletions to be correctly recorded. In practice I actually currently use a probably very imperfect single-line merge-back command (in a script). Fredx181 tells me he did something similar originally in his DD-bullseye OS but felt there were potential problems of leaving unneeded whiteout markers, in which case my simple script would also need expanded to seek out unwanted whiteouts (or you could likely easily modify fred's snapmergepuppy overlayfs-related script but using the WeeDog directory layers (you can see all WD layers by simply opening your filemanager at /mnt/layers).
Anyway, for now, personally, I'm still myself using w_changes=RAM2 to boot (i.e. put that on grub kernel line) and then simply using simple rsync one-liner to merge back - I suspect that is fine for small upper_changes use, but maybe there are problems if more complex rollback scenarios - I haven't been testing this mode for long yet. The save-merge-back command I use for this RAM2 mode is simply:

rsync -av /mnt/layers/RAM/upper_changes/ /mnt/sda4/WDL_whatever/upper_changes

EDIT: that /mnt/sda4 is for my own system. You'd have to change that to match your own partition used. I actually have a few extras in the wd_saveRAM2 script I use to auto-determine which is my boot partition. Again I'll upload that wd_saveRAM2 script later rather than complicate current early testing with it just now.

Note it is very important to PUT a / at the end of /mnt/layers/RAM/upper_changes/, and NOT put a slash at the end of /mnt/sda4/WDL_whatever/upper_changes (i.e. the external media upper_changes folder), otherwise rsync makes a new upper_changes folder 'inside' the other one on external media upper_changes instead of merging as intended (try it and you will see what I mean...)

Let me know if you ever do try w_changes=RAM2 mode. I'm interested on results to see if more complex merge scheme really is required. I have suspicion that more complex removing of white out (char files) could itself cause issues and simply one-liner above isn't problematic at all for me thus far in small upper_changes situations I've been testing it with thus far. One thing I do extra though is that I use --exclude with rsync to not include certain large changes such as certain web browser caches and so on - exactly what is best to exclude is something I still have to determine.
-------------------------------

Of course, for now, to get you started, the easiest mode of all is not to use w_changes in any RAM mode at all. By default WDL init will auto-create an external upper_changes folder and auto-use that directly for persistence. Once you have the system built up the way you like it, that, I suggest is the time to consider if you want to use one of the w_changes=RAM[0 or 1 or 2] modes (primarily as a mechanism to save flash sticks from regular write cycles). In our forum-land, w_changes=RAM2 is probably what you would want on the whole I suspect.

wiak

Thanks for bringing up makulu. I tried it. I realized it's that its Debian based and therefore all my debian apps worked right of the bat.

My suggestion to other users once you're familiar with creating your own weedog.

1. Create your own sfs (could be humungous or a set of multiple sfs) of your favorite applications. I suggest you include all dependencies just in case the new distro doesn't have it. I even included some themes and fonts I preferred and some personal files.
Save it in the same folder where you installed your WDL distro. Name your sfs starting with 2 digits (ex. 05appname.sfs, 06appname.sfs). WDL will add it as layer upon booting.
2. Use portable apps. fredx181 and mikewalsh has uploaded good ones in the puppy forums.

once you boot into your WDL_distro, you will find all your apps and files are already available for use. Your portable apps are of course already pre-configured, therefore so you can already start using it immediately.
Saves a lot of time really. Your WDL distro becomes your very own.

Hi @wiak ,

I am wondering if it is possible to make a specific layer isolated or containerized.
Here's the thing. I want to be able to use puppy pre-installed apps from my fav distro but I don't have the pet files and I don't know how to create individual sfs out of those pre-installed apps, and they're many (maybe someone can point me to the right direction).

I am thinking of just loading the main puppy file as one of the layers then calling the apps i like from there. But the whole puppy might interfere with the main distro. Is there a way to kind of isolate that layer so the dependencies called by launched apps will just be coming from that specific layer i set? I haven't tried underdog, but I think it's something like that. Not sure though. thanks.

-ronriel

ronriel wrote: Tue Sep 07, 2021 3:07 am

Hi @wiak ,

I am wondering if it is possible to make a specific layer isolated or containerized.
Here's the thing. I want to be able to use puppy pre-installed apps from my fav distro but I don't have the pet files and I don't know how to create individual sfs out of those pre-installed apps, and they're many (maybe someone can point me to the right direction).

I am thinking of just loading the main puppy file as one of the layers then calling the apps i like from there. But the whole puppy might interfere with the main distro. Is there a way to kind of isolate that layer so the dependencies called by launched apps will just be coming from that specific layer i set? I haven't tried underdog, but I think it's something like that. Not sure though. thanks.

-ronriel

I'm not sure what underdog is (though I recall the name from years ago), but the name sounds like something available just by numbered layer arrangement in WDL. Of course if you load a puppy filesystem in higher layer than (say) 04fristrib_rootfs.sfs (i.e. main root filesystem being used) in WDL its contents will clobber the underlying WDL files when they collide in name. However, you could try making the puppy filesystem at an NN number BELOW firstrib_rootfs.sfs (so for example 01puppy_filesystem.sfs). That way, the main rootfs being used by WDL will take precedence but code it doesn't itself have will come through in the merge and 'should be' available - of course puppy is a complex filesystem so there may be side-effect complications but maybe not if you are 'lucky'...

EDIT: Actually, one possible problem I can think of might be for example if Puppy filesystem has major boot file like /sbin/init appearing in executable PATH at higher precedence than what firstrib_rootfs otherwise uses (for example, say /usr/sbin/init) then boot will fail because using wrong init file... SImilar side-effects could occur, though some adjustments to PATH could in theory remove these negative possibilities - anyway, may not prove to be an issue... you may be lucky... On second thoughts I 'think' it is likely that the normal WDL firstrib_rootfs/sbin/init (which may, for example, actually lie at /usr/sbin/init or /usr/bin/init depending on the underlying distro arrangement) will win out at boot anyway, but just a warning of possible type of side-effect that might just occur, but maybe fine.
EDIT2: DON'T use layer 00 though - that's a specially reserved layer for people who want to use the likes of Puppy huge kernel and a 00firmware sfs instead of copying modules directly into initrd (i.e. can keep initrd tiny is using Puppy kernel/firmware, but I won't talk further about that facility just now since a special case.
EDIT3: Note that in earlier WDL builds I used to arrange, via the build scripts that firstrib_rootfs normally was stored as 01firstrib_rootfs, but in new scripts I've changed the default position to layer 08 exactly so it is easy to insert layers below that for purposes similar to what you are asking about (though for Manjaro case I've used 04firstrib_rootfs so that previously designed 10gtkdialogXXXX would still fit in to that original layer for it - but still have these 01,02,03 layer positions free for underneath main layer experiments or simply renumber sfs files as you wish anyway).

dancytron wrote: Tue Sep 07, 2021 2:11 am

I just followed Fred's guide to do the Raspberry Pi Desktop OS (basically debian buster live installation iso).
...
Tired of not being root already.

That's interesting - I continue to wish for a Raspberry PI system - maybe I'll get one for Christmas.

I had thought you'd need to modify the initrd with one further difference - an arm version of busybox in /usr/bin? But I hadn't though of the matter further.

As for working as non-root. Yes, takes a bit getting used to. As I've described previously, my method, which I find perfectly comfortable, is to always work as admin from a filemanager opened as root user and any terminals opened from there are automatically owned by root user too and X authentication also works from that situation (and manjaro normal user is a member of wheel group so doesn't get asked for any passwd in such situation). That is:

I open terminal

and enter command:

sudo thunar

(or sudo pcmanfm if that is the filemanager being used)

and thereafter open terminals at whatever directories I am browsing and need to do admin work in.

No permission-related issues then trouble me.

When browsing as a normal user of course file downloads can only be made to filesystem directories that that normal user has permissions too. For that I usually reserve a directory out of the save folder for the normal user. E.g. on /mnt/sda4/whatever on my system and then make that directory owned by the normal user by command:

chown -R manjaro:manjaro /mnt/sda4/whatever

I then use that as main directory for user manjaro downloads/saving and so on (outside of upper_changes folder therefore). Easy to set up therefore, and comfortable to use thereafter.

<-- Back to WDL Cheatsheet menu: viewtopic.php?p=36426#p36426

Just a quick post of a simple mount script you might occasionally find useful:

wd_mount

Just remove the dummy tar and chmod +x to make the script executable. I recommend storing it in /usr/local/bin (that's where I always put WDL-linux related scripts and where the build firstrib_rootfs scripts put them) since not an upstream repo script.

usage:

wd_mount --help
usage: wd_mount <devicename> (e.g. wd_mount sdb1)>
Simple mounttool to mount device to /mnt/devicename

You will need to run it with

sudo wd_mount <devicename>

if at normal user terminal commandline.

wiak

It's not the arm version.

They issued a x64 clone of their version of Debian.

See https://www.raspberrypi.org/software/ra ... i-desktop/

I made kind of a mess of it. I'm going to do it over later this week now that I know what I am doing.

dancytron wrote: Tue Sep 07, 2021 4:53 am

It's not the arm version.

They issued a x64 clone of their version of Debian.

See https://www.raspberrypi.org/software/ra ... i-desktop/

I made kind of a mess of it. I'm going to do it over later this week now that I know what I am doing.

Oh I see. Nice to know and experiment with anyway. Should be able to make an actual arm Rasp PI WDL boot by substituting in arm busybox and arm modules/kernel and arm-compiled rootfilesystem components, but I won't know till I have such a system to try it on.

wiak wrote: Tue Sep 07, 2021 3:31 am

but the name sounds like something available just by numbered layer arrangement in WDL. Of course if you load a puppy filesystem in higher layer than (say) 04fristrib_rootfs.sfs (i.e. main root filesystem being used) in WDL its contents will clobber the underlying WDL files when they collide in name.

I see. So this is why I was getting problems. I thought numbering was ordered the the other way around.
I'll try again.

TerryH wrote: Mon Sep 06, 2021 9:42 pm

Duprate wrote: Mon Sep 06, 2021 8:51 pm

Several attempts failed. When I paid more attention to what Fred described, it worked!

1- Important to place the kernel modules inside the initrd.
2- w_changes=RAM, it didn't work for me!

Thanks, I believe I have it set up OK, it booted first attempt, but not to desktop.

Makulu Android, after long boot time delays (nothing to do with WeeDog) reached a user login. I entered makulu with password makulu. More long delays and failed to start X on my old HP Elitebook 2530p laptop (booted from usb stick cos I have not enough space left on the hard drive).

Took usb with installation files on it over to other newer laptop (also an HP Elitebook but a Folio G1 I think - i.e. much newer machine). This time put the WDL_Makulu folder with the 08filesystem.sfs and WDL initrd.gz and appropriate for the modules vmlinuz in it onto the hard drive and edited the machines grub.cfg. (Note that unlike Duprate I wasn't using any ucode.cpio addition). Once again, long boot time, and ended up at user login prompt. Entered: makulu with password: makulu and long delay but then eventually auto went straight into rather fancy X desktop... It then auto-played some fancy Makulu video and after that finished I clicked top right area and found wifi connection (since didn't have ethernet connection). Connected fine to the internet. Anbox loading took quite a while by the way, and haven't yet managed to get Google Play login to work (despite wifi being connected, google play claimed it wasn't... so I have rebooted to see if it remembers the wifi connection and Google Play happy with that (yes, that worked - android apps downloading ok now). Anyway, it works on this machine...

But wouldn't go to X in the older laptop - maybe just suitable xserver-xorg-video-intel (I forget file name) not installed, so if I try again sometime I'll try and apt install that (tricky from commandline only unless plugged into ethernet maybe - though I could also add simple wiakwifi files and that should find my wifi okay (I could even do that using an addon wiakwifi sfs module of course (including the needed udhcpc default files uses by the method employed in wiakwifi). Of course, the issue on the older laptop may be something else... which I won't likely be trying to track down - despite a nice desktop Makulu seems far too slow for my comfort anyway.

Also now booted on that 'newer' but not really very new HP Elitebook Folio from an old usb2 flash stick. Oh my goodness, talk about everything in slow motion. At least once installed on hard-disk the system worked okay (just a bit slow) but booted from an old usb2 flash stick was terrible... not usable. Funnily enough WDL_Arch64 is fine booting from usb2 flash stick as are Pups/DebianDogs, but not this WDL_Makulu - I suspect Manjaro XFCE not great speedwise from a usb2 stick either...

wiak wrote: Tue Sep 07, 2021 4:59 am

dancytron wrote: Tue Sep 07, 2021 4:53 am

It's not the arm version.

They issued a x64 clone of their version of Debian.

See https://www.raspberrypi.org/software/ra ... i-desktop/

I made kind of a mess of it. I'm going to do it over later this week now that I know what I am doing.

Oh I see. Nice to know and experiment with anyway. Should be able to make an actual arm Rasp PI WDL boot by substituting in arm busybox and arm modules/kernel and arm-compiled rootfilesystem components, but I won't know till I have such a system to try it on.

I've messed around with it to see what they are using to teach programming to kids more than anything else.

I'll see if I can get the ram mode 2 and savetoflash rsync thing working.

Is there any way to "remaster" or merge the changes folder with the .sfs file (mainly to uninstall some stuff to make it a more manageable size)?

<-- Back to WDL Cheatsheet menu: viewtopic.php?p=36426#p36426

dancytron wrote: Tue Sep 07, 2021 11:05 am

wiak wrote: Tue Sep 07, 2021 4:59 am

dancytron wrote: Tue Sep 07, 2021 4:53 am

It's not the arm version.

They issued a x64 clone of their version of Debian.

See https://www.raspberrypi.org/software/ra ... i-desktop/

I made kind of a mess of it. I'm going to do it over later this week now that I know what I am doing.

Oh I see. Nice to know and experiment with anyway. Should be able to make an actual arm Rasp PI WDL boot by substituting in arm busybox and arm modules/kernel and arm-compiled rootfilesystem components, but I won't know till I have such a system to try it on.

I've messed around with it to see what they are using to teach programming to kids more than anything else.

I'll see if I can get the ram mode 2 and savetoflash rsync thing working.

Is there any way to "remaster" or merge the changes folder with the .sfs file (mainly to uninstall some stuff to make it a more manageable size)?

Actually Fredx181 wrote a small remaster script for it long time back. May or may not need slight modification now. I'll have to look it out and report back once I find it. Off the top of my head, the resulting filesystem in /mnt/layers/merged should pretty much be the remaster required straight away now (though maybe I'm not thinking straight it being late at night here). However, you'd want to --exclude some stuff not required in the remaster. Anyway, I'll look for the remaster script Fred contributed way back. That probably used a separate temporary overlayfs just to collect all the pieces together before excluding bits and applying mksquashfs.

EDIT: just found it, but don't have time to check if will work. I remember reading it back after it was submitted, but didn't have time to test back then either and it is possible that a few things now need changed. Maybe I'll look at it again later. Attached in original form here anyway (just remove dummy tar and chmod +x and use at own risk...).
EDIT2: Just had a quick look at that old script. I believe it was for early WDL_Arch64 so not sure how many alterations it would require (definitely need the script internal 01firstrib_rootfs changed appropriately and more besides). Might be useful to someone though. Sorry I'm not able to look into making it work myself in near future.

@wiak
Extremely close to a full functioning Zoneminder on a WDL-manjaro. I have a full Hiawatha, mariadb, PHP 8 web server running and now am doing the actual ZM installation via yaourt which I have complied after installing the base development packages.

So far so good. Looks like Apache is being installed so I will have the choice of Hiawatha or Apache as the primary web server.

<-- Back to WDL Cheatsheet menu: viewtopic.php?p=36426#p36426

@TerryH
Don't know if you have an old Intel system, but just reporting that I now have Makulu booted into X desktop on my old 2008 HP Elitebook core2duo 2530p 4GB RAM machine. I've never seen it run so slow as this, but all going.

I'm booting from the hard drive (just and old slow ATA drive), but certainly better than usb2. Posting from it now using Chrome. Why so slow??? I have no idea!!! WDL with Manjaro XFCE works perfectly fine on this same old machine.

Anyway, how did I manage to get it to boot past the command line?

Well, once it asked for username, I again entered name makulu with password makulu it took ages per usual until it finally hung at some output command I cannot recall. However, at that stage, I pressed Ctrl-Alt-F1 and that took me to an already logged in as user makulu console. Oh, I forgot a step... : prior to bootin, this time I connected the old machine to my house router via an ethernet cable so that I would have Internet access...

Anyway, at the makulu user console I now entered:

sudo apt update

Quite a lot of repos were processed at that stage...

And then I entered:

sudo apt install xserver-xorg-video-intel

and per my earlier guess I installed that. Then still at that user makulu console I did:

startx

and, wonder of wonders, this time it continued booting up into X desktop! But wow, this Makulu terribly slow distro for me. I won't be using it not even on my somewhat newer HP Elitebook Folio G1 machine that has 8GB RAM and faster processor - still quite painfully slow there too though usable...

But Manjaro XFCE is fine on both (though nothing like as fast at all as WDL_Arch64 since that uses straight openbox/tint2 and not XFCE).

So possible you just need to do similar if you really want to try Makulu - apt install suitable xserver-xorg-video-xxx for your graphics adapter prior to startx.

wiak

rockedge wrote: Tue Sep 07, 2021 1:17 pm

@wiak
Extremely close to a full functioning Zoneminder on a WDL-manjaro. I have a full Hiawatha, mariadb, PHP 8 web server running and now am doing the actual ZM installation via yaourt which I have complied after installing the base development packages.

So far so good. Looks like Apache is being installed so I will have the choice of Hiawatha or Apache as the primary web server.

Oh that's good to hear! Clearly you got past the point I failed at. Hope you will be able to produce some kind of step by step howto - particularly for the mariadb part, which I simply couldn't get installed without error for some reason (well, lack of knowledge about mariadb on my part was the likely reason it seems). I rather like Manjaro, but I do not like this Makulu I'm on right now (despite it being Ubuntu Fossa Focal based - incredibly slow system - too much going on in the background for all its fancy effects I suppose). My goodness, something wrong with Makulu - using pretty much 100% CPU right now... sigh... no use to me.

So I think now that Makulu is potentially fixable (and nothing to do with WeeDog initrd anyway; it's fine) - just some unstable systemd started process running away with the CPU so slowing whole system down, but I doubt I'll look into fixing it. May or may not be machine dependent - just check with 'top' command and see if it is being over-the-top CPU greedy... shouldn't be. No such problem with WDL_manjaXFCE - it runs quite well.

EDIT (sept08): I used sudo "killall anbox" to kill the anbox process(es) and Makulu working okay on my old machine now. However, it was anbox I was interested in! I'll try and find which process is actually causing the issue on my old machine later...

Interesting note, I am running WDL-manjaro-xfce on a PowerEdge R210 II blade server. Frugally installed alongside several other WeeDog64-Void's and WeeDog32-Void with 10 other Puppy Linux variations. The machine has 2 ethernet cards, one wired to router "WormGear" as eth0
and one is wired to router "THX1135" as eth1. WDL-manjaro connects to both simultaneously, with eth0 as 192.168.0.6 and eth1 as 192.168.1.5 as it boots. Works great. First time that happened automatically.

The router THX1135 is connected to router wormgear via an ethernet switch in series. Machines connected to THX1135 can access the addresses from wormgear, but the machines on wormgear's network can not access the sub net addresses of THX1135. Good for a Zoneminder set up.

But that means with Zoneminder running on the DELL poweredge, it's web console can be accessed by "localhost/zm" or "192.168.0.6/zm" or "192.168.1.5/zm"

@wiak Thanks very much for taking the time to trouble shoot the makulu installation. I have a more recent Dell laptop with Core i5-5200U, so the intel video should work for me also. I tried makulu several years ago, it has always been a very polished distro. The inclusion of anbox, made this release interesting. Using the weedog initrd, seemed a very easy way to try anbox.

As my wife and I are having a little get-away tomorrow for a few days, I'll probably try the update path you have done when I come home next week. I have an internal Samsung SSD and 8GB RAM, so will be interesting to see how slow it is for me.

<-- Back to WDL Cheatsheet menu: viewtopic.php?p=36426#p36426

Here's a way to create a much smaller initrd, attached cr-initrd script that I made.

Code for copying only required kernel modules to the initrd (for booting) taken (but modified) from "initramfs_create" script by Tomas M <http://www.linux-live.org/>

As I wrote here: viewtopic.php?p=36144#p36144

EDIT2: Loading initrd.gz at start of boot takes a long time for me, I guess because it's so big, probably much better if the initrd.gz is much smaller, containing only the required kernel modules to boot.

It turns out for me that the initrd.gz created with cr-initrd, fixes that boot delay completely on my old HP laptop (takes just a few seconds to load initrd.gz now).
Not sure if it's the size (13.8MB) that makes the difference, it could well be that some of the code from Tomas M does it.
Also, I'm not sure if this works for everyone, feedback appreciated.
Oh, and feel free to distribute, or modify.
And IMO it would be good if this or similar would be somehow part of wiak's "modify_initrd_gz.sh"

So instead of (which will create a very big initrd, which is totally unnecessary IMO and booting can be very slow):

- Copy folders inside lib/modules from mounted 04firstrib_rootfs.sfs (e.g. 5.13.12-1-MANJARO and the other one) to: lib/modules inside "initrd_v400rc1_decompressed" dir

I ran the cr-initrd script, using as first argument the full path to the kernel modules folder in mounted 04firstrib_rootfs.sfs:
./cr-initrd /mnt/+mnt+live+mnt+sda7+WDL_manjaXFCE+04firstrib_rootfs.sfs/lib/modules/5.13.12-1-MANJARO
(in this case a symlink in /lib/modules will be created, and removed when done (even when the script is interrupted (trap mechanism)) , could possibly be modified to work different, but I didn't want to change the code from Tomas M too much).

---------------------------------------------------------------------------------------------------------------------------------------------------------

Or use as first argument the kernel booted with, e.g.
./cr-initrd /lib/modules/5.13.12-1-MANJARO or:
./cr-initrd /lib/modules/$(uname -r)
The examples are mostly for manjaro-XFCE, but can be used on WDL for any kernel that has "overlayfs" support (need to boot with the matching vmlinuz too, of course).

The script depends on existence of "initrd_v400rc1_decompressed" skeleton in the same folder (as created by wiak's "modify_initrd_gz.sh" script).

Fred

wiak wrote: Tue Sep 07, 2021 2:51 am

Duprate wrote: Mon Sep 06, 2021 8:51 pm

2- w_changes=RAM, it didn't work for me!

NOTE: The following post is quite technical. Don't bother with it at this stage unless you are particularly intersted in getting RAM modes to work - system works fine by default with direct writes to external upper_changes for persistence anyway. But I'm just writing this to document that saving RAM modes does exist as a feature should you ever need it

There is no longer any w_changes=RAM mode.

Rather, there are three alternative w_changes RAM modes, as follows:
............................................
wiak

Thank you Wiak, for the clarification. I hadn't noticed. The rush to make it work makes us careless. Now I did it like this:
1st - necessary settings saved in upper_changes folder;
2º- convert "upper_changes" into 02changes.sfs;
3rd- add in grub "w_changes=RAM2".
The swelling is over!
NOTE: I'm referring to Makulu Linux. At Manjaro it's the same thing;
Makulu works fine on my PC as well as Manjaro; I'm just testing these systems for learning purposes.
For now, I have no future plans for these distros. Your new initrd is really cool. Good luck!

<-- Back to WDL Cheatsheet menu: viewtopic.php?p=36426#p36426

fredx181 wrote: Tue Sep 07, 2021 5:08 pm

Here's a way to create a much smaller initrd, attached cr-initrd script that I made.
cr-initrd.gz
Code for copying only required kernel modules to the initrd (for booting) taken (but modified) from "initramfs_create" script by Tomas M <http://www.linux-live.org/>

That's great Fred! Improves matters greatly and actually a weight off my mind.

I was always planning to implement that same Thomas M method after the suggestion forum member gumanzoy made to you to some months back (below link),

viewtopic.php?p=24488#p24488

gumanzoy wrote: Tue May 04, 2021 8:09 pm

I have another suggestion. I use modules copy method from linux-live/Slax initramfs_create.
https://github.com/Tomas-M/linux-live/b ... mfs_create
Instead of
# copy lib/modules from /var/tmp/mkinitramfs_* to /tmp/initrdport-bullseye/

so I was following gumanzoy's comments and the development of that closely back at the time and posted my interest on the method at some stage. However, suddenly finding myself really busy employed (amongst other matters) I realized it was going to take me a long time probably to get round to that. Indeed I hinted as much (quote below) and whilst I wasn't about to ask someone else to do it I did recognise you had implemented gumanzoy's suggestion so likely could be used similarly as you now have done for WeeDog initrd slimming (so the possibility of the contribution did cross my mind ).

viewtopic.php?p=35006#p35006

wiak wrote: Wed Aug 25, 2021 1:55 am

However, one thing I'd really like to get back to is produce a small initrd for WeeDog systems in that Thomas M style you now use for the DebianDogs. But... in practice it remains such a low priority for me (too busy working for actual money nowadays - non-computer-related) that I may never get round to it, and again, I am suffering from this no-focus/lack-of-dev-enthusiasm void. I keep hoping I will snap out of the lost enthusiasm (though sometimes I'm glad I have it since frees up my time for other matters)....

Yes, the modify initrd was always just a simple quick helper script - adding that Thomas M module slim method in there will be appropriate. I hope Thomas M doesn't mind - it was certainly a great idea... and you've implemented it well. It certainly improves our systems here. The only problem I have is that Thomas M linux live code seems to be all licensed as GPL 2 whereas I want MIT licence for WDL contributions - but rather than re-write can use as separate called plugin. I guess it is a small matter, but I don't want to restrict WDL usage at all, not even for commercial use. Of course, licence of the code isn't too important in this case since only used for slimming the modules and not part of the running WDL system itself. I like Thomas M's copy_including_deps() algorithm - acts as a nice module clipper...

As for the boot WDL slow down you were experiencing - I don't myself think the size of the modules swelling the initrd has much importance in terms of that (slight delay to load 100Mb initrd) but I've always thought that loading unneeded modules might cause such issues from time to time - was just living with it for now (i.e. waiting for the time-outs...) - of course that matter is better to be addressed properly.

Anyway, your cr-initrd slim-modules script is a very big help to me. I'll probably get on top of my new-found employment eventually and be able to get back to a greater amount of WDL development (I still haven't even completed the main website for publication yet) but certainly couldn't do much extra right at this moment myself - which is another reason I suddenly decided to release that latest initrd main code.

Cheers, wiak

EDIT: Just quickly tried it from my already running WDL_Arch64:

I used modify_initrd script to decompress my existing initrd.gz
To match that initrd.gz name, I changed the following cr_initrd line (near the top of the script) from: INITRAMFS=initrd_v400rc1_decompressed to more generic: INITRAMFS=initrd_decompressed
And since new WDL initrd/init already (when already booted) has mounted 08firstrib_rootfs.sfs available under /mnt/layers/08, I simply ran cr_initrd script with command:

./cr-initrd /mnt/layers/08/usr/lib/modules/5.13.5-arch1-1/

That was after checking in /mnt/layers/08/usr/lib/modules/ to see that the kernel modules version was 5.13.5-arch1-1.
On then checking the initrd_decompressed usr/lib/modules folder, I can see that worked... This was for a slightly different WDL initrd because Arch using zst modules by default so, for quick fix, used actual (non-static) kmod and extra libs that needed in the initrd, so final initrd not as small as it could be. However, did slim it down from over 100MB to 21Mb ... excellent! Rebooting now... EDIT: Booted fine, thanks!

EDIT2: Just did the same for Makulu running on my old HP laptop. Only difference was its root filesystem has its modules in /lib/modules rather than in /usr/lib/modules (and different modules kernel version) so used:

./cr-initrd /mnt/layers/08/lib/modules/5.11.0-27-generic/

Resulting initrd.gz fell from size 86.5MB to 18.1MB. Very impressive.

Now I'll boot up my WDL_manjaXFCE install and do the same for it... except I have to reinstall it anyway cos I run out of space on my old dev laptop so temporary moved the install folder onto backup external usb drive to give me some space to try Makulu!!! Most dev work I do nowadays is actually done remotely via vnc connection to my better HP Elitebook Folio laptop that is being used as a vncserver/ssh server (including virtualGL for higher capability OpenGL accelerated graphics support). Two of us here (at least) are generally logged into that Folio server doing spreadsheet work for my partner's business... so rebooting it isn't generally an immediate option... I should set up qemu on it.

Note: this thread does miss out one major additional facility provided in WeeDogLinux build system that rockedge has mentioned here and there above. The build scripts! In particular the build_firstrib_rootfs, which allows a user to create their own root filesystem - generally using the upstream repos and official package manager of the supported 'flavours' which currently are: Void Linux, Arch Linux, Ubuntu, Debian, and Devuan. Void Linux version started it all, and remains the 'purest' in terms of making the simplest and most efficient WeeDogs - in that sense it is my favourite too (though I have personally concentrated on Arch builds, because I highly value Arch repos, including its AUR resources, for very up-to-date apps, and also its excellent Wiki, which makes my WDL_Arch dev work much easier). I haven't done much at all with the Ubuntu, Debian, Devuan builds since the forum already has the DebianDogs, and the underlying construction method of these is generally Debian's debootstrap (though the relatively recent WLGO Ubuntu variants, including dpkg/apt addon for Puppy, are not built using debootstrap).

I will be publishing the 400rc1 release versions of these soon, but pushed the skeleton kit version of the initrd out sooner since I realised it was instantly useful for the likes of booting big distros like Manjaro. The build_firstrib_rootfs script, however, makes it possible to build your completly own, tailored, root-filesystem, containing only the components (desktop, apps, and so on) you want (which might simply be busybox... ). That build_firstrib_rootfs script is what rockedge uses (via his custom Void Linux related build plugins) to great effect building his WDL_Void Linux creations for Zoneminder use and more. In fact the first and probably best WeeDogLinux creation (the original FIrstRib component) revolved entirely around Void Linux since all that required to start such builds was busybox along with a static compiled version of Void Linux package manager (called xbps) to make a suitable root filesystem NNnumbered.sfs (or uncompressed NNdirectory) for use with main WDL initrd component. In fact the build_firstrib_rootfs script allows you to create some special WLGO systems (i.e. LEGO-like assembly) - even ones that contain no package manager at all for those who prefer just to compile additions in tiniest core arrangement.

There IS a second build script which is build_weedog_initrd - that's what I use to actually assemble the skeleton initrd and it contains code to automatically push the modules from firstrib_rootfs into the initrd (obviously that can now be improved via a plugin addition of fredx181's implementation of Thomas M slim modules code).

Anyway, for now, I'll leave people to get used to WDL initrd configuration per the current 'experiments' rather than confusing the understanding via these other parts of WDL build system at present.

wiak

wiak wrote: Sun Aug 29, 2021 11:55 am

...The newer version includes a split init, the major part of which 'w_init' resides as a text file (containing bash code) on the bootdir partition so you can play with your own initrd/init mods very easily simply by editing w_init with geany (of course if you make an error, you will likely encounter the deadly 'kernel panic' then!)... Also the new init contains the new w_changes in RAM modes that allow equivalent to the likes of DebianDogs changes=EXIT mode. Otherwise the same though.
...

Wiak, regarding the w_init file downloaded from your signature link, does it overlap with the internal init or does w_init do something in addition to init? Is it necessary to put w_init in the boot folder or is it optional?

<-- Back to WDL Cheatsheet menu: viewtopic.php?p=36426#p36426

miltonx wrote: Wed Sep 08, 2021 3:08 am

wiak wrote: Sun Aug 29, 2021 11:55 am

...The newer version includes a split init, the major part of which 'w_init' resides as a text file (containing bash code) on the bootdir partition so you can play with your own initrd/init mods very easily simply by editing w_init with geany (of course if you make an error, you will likely encounter the deadly 'kernel panic' then!)... Also the new init contains the new w_changes in RAM modes that allow equivalent to the likes of DebianDogs changes=EXIT mode. Otherwise the same though.
...

Wiak, regarding the w_init file downloaded from your signature link, does it overlap with the internal init or does w_init do something in addition to init? Is it necessary to put w_init in the boot folder or is it optional?

Good question.
Putting w_init in boot folder is totally optional since really for major development/init-experiments use only... The overall init is as I've said split into two parts: init plus w_init. The first part is quite small and just used to recognise the boot media partition. Most of the clever stuff is done inside w_init. However, a copy of both known-to-work init and w_init is kept inside the initrd.gz and you don't need any w_init kept externally and generally don't want one. On boot the external one would be used if present (hence easy for developers to play-with or modify for new w_init features) but the internal to initrd w_init is generally identical anyway and will be used by default. Yeah, so don't use any external (i.e. boot folder) w_init for now... any error in that would break the boot. I forgot I had provided that external w_init in the download kit - it is identical to the one inside the initrd.gz so you can safely delete it or just leave it if you wish.

Nice to know that! Thanks!