Puppy Linux Discussion Forum

Wow, that's great rockedge. Weird that apt didn't consider that missing package a dependency but that probably means that in some situations it isn't (?). And well done PPM for fetching the missing part!

Working right now on a WDLGO_Bionic32 so its firstrib_rootfs will be able to be used for apt_addon_BionicPup32 in similar fashion. I could make the addon for Pups smaller, as I've said, by removing the wpasupplicant and its dependency components, but I don't want to rock the boat and a few unneeded MBytes probably makes it sensible to leave in especially since I'm also using same firstrib_rootfs in WDLGO_Bionic32 distro so serving dual-purpose. I guess I'll make a WDLGO_Bionic64 at much the same time since same packages in that case (just different arch). In truth, I could possibly also make one for Raspberry Pi, even though I don't myself actually have such a device, but I will leave that possibility for future and future demands since want to take a break shortly. I really MUST learn how to use/setup Zoneminder - it remains held back by all these other (seemingly growing list of) priorities... Because of its nature, WeeDogLinux is certainly proving a fast to expanding multi-flavour system generally.

EDIT: By the way, is 'apt -f install' saying all remains well with dpkg/apt databases or is any 'dpkg --configure -a' still needed at the stage you are at? I don't know enough about the repercussions but perhaps a PPM install of that missing package could upset apt's view of the world (though I think apt will simply not know about it so may be fine).

And are you in a position (risk) of trying, even at this stage:

apt install mysql-server-core

to see if apt/dpkg has any error complaint to make; the duplicated install shouldn't cause any problems (except that apt will run any pre and post install scripts, which PPM likely just ignores.

Always psychologically disappointing to see dpkg errors, but actually I don't mind them since they usually accurately help improve the system.

wiak wrote: ↑Fri Jan 22, 2021 10:12 am

First, modified (unsquashed) the original puppy_fossapup64_9.5.sfs as I mentioned in earlier post such that:

/usr/sbin/adduser became /usr/sbin/adduserBB
/usr/sbin/addgroup became /usr/sbin/addgroupBB
/usr/sbin/chpasswd became /usr/sbin/chpasswdBB
/usr/sbin/deluser became /usr/sbin/deluserBB
/usr/sbin/delgroup became /usr/sbin/delgroupBB

viewtopic.php?p=15747#p15747

So if I understand correctly, you make these changes to puppy_fossapup64_9.5.sfs and then you are able to load 01firstrib_rootfs.sfs as a bottom layer to get dpkg support? Or is this not the latest procedure? I see some other things in the quoted post that also look relevant. Maybe there should be a general install script, which makes the changes in said post which are zoneminder specific.

s243a wrote: ↑Sun Jan 24, 2021 7:13 am

wiak wrote: ↑Fri Jan 22, 2021 10:12 am

First, modified (unsquashed) the original puppy_fossapup64_9.5.sfs as I mentioned in earlier post such that:

/usr/sbin/adduser became /usr/sbin/adduserBB
/usr/sbin/addgroup became /usr/sbin/addgroupBB
/usr/sbin/chpasswd became /usr/sbin/chpasswdBB
/usr/sbin/deluser became /usr/sbin/deluserBB
/usr/sbin/delgroup became /usr/sbin/delgroupBB

viewtopic.php?p=15747#p15747

So if I understand correctly, you make these changes to puppy_fossapup64_9.5.sfs and then you are able to load 01firstrib_rootfs.sfs as a bottom layer to get dpkg support? Or is this not the latest procedure?

That is only in development testing. It is not the latest procedure - that uses a second small addon as a layer above puppy_fossapup64_9.5.sfs, which will be developed further should anything else need alterned in layers underneath, though working fine thus far. Certainly rockedge always ends up also providing a script for anything particular to setting up zoneminder once installed thereafter.

wiak wrote:

By the way, is 'apt -f install' saying all remains well with dpkg/apt databases or is any 'dpkg --configure -a' still needed at the stage you are at?

@wiak I ran into the same reboot problem! So I renamed /sbin/init to /sbin/init-systemd and I mounted the original puppy_fossapup64_9.0.5.sfs and copied the original Puppy init file to /sbin/init and then attempted again to reboot which succeeded.

The system rebooted and loaded the firstrib_root.sfs. Apache started as a service, mysql server started manually as did Zoneminder and all systems running!

I again ran apt -f install:

root# apt -f install
Reading package lists... Done
Building dependency tree       
Reading state information... Done
0 upgraded, 0 newly installed, 0 to remove and 1 not upgraded.

Now will test a reboot again and if all goes well I'll be in the next post.

Reboot problem persisted BUT I was able to pin down an easy fix.
Turns out the /sbin/poweroff and the symlink /sbin/reboot were replaced with symlinks for systemd. I mounted a copy of the puppy_fossa64.sfs and copied the two original Puppy versions and overwrote the 2 systemd versions that were inserted during some package installation process. I then rebooted and behold......it worked like a normal Puppy Linux reboot!

So I recommend deleting the systemd symlinks:

symlink -> /sbin/init
symlink -> /sbin/poweroff
symlink -> /sbin/reboot

and replacing those 3 with the original Puppy Fossapup64 versions. That is:

file -> /sbin/init
file -> /sbin/poweroff
symlink /sbin/reboot to /sbin/poweroff 

that should fix the reboot problem after the ZM install with apt. Further testing is needed to see if that effects anything negatively

Fossapup64-WDLGO is performing well so far and I installed an image viewer:

apt install viewnior

I am going to attempt to install Python3 and opencv to see if I can go a step further and install zmeventnotification server which can provide object detection and face recognition and push notifications to mobile devices with zmNinja and I like using the desktop version that comes packaged as an AppImage

This install along with Zoneminder and the LAMP should be sufficient proof that this system can handle installing tricky, complex and complicated packages

First though before do the install of ZMES and Python, I will attempt to do the entire procedure of installing a LAMP and Zoneminder with apt from scratch on a new system!

rockedge wrote: ↑Mon Jan 25, 2021 2:58 am

Reboot problem persisted BUT I was able to pin down an easy fix.
...

Yes, that is an inevitable side-effect of using apt. It is only working as it is designed to do (which is to accurately install all the packages/dependencies and run pre and post install scripts that Ubuntu/Debian want done). In that sense it is good news - Puppy users just need to remember that apt is designed to install systemd components and so will a times overwrite some Puppy SysVinit and related Puppy scripts, which, as you say will need to be either protected somehow (maybe some expert with apt pinning) or replaced back to Puppy versions after a big apt install. C'est la vie.

In any case, the positive is that dpkg/apt is an incredibly versatile and powerful package manager. Very useful for Puppy, I think, where users can become experienced with the side-effects and thus work around them whilst gaining from the huge advantages of reliable Ubuntu/Debian repos that apt provides. Even more important when that also brings full multi-user capability with it, which many larger applications require (such as zoneminder) for full effect.

Yesterday, I finished a WDLGO_Bionic(upup) version - actually two since one for 32bit and one for 64bit. I've been testing the 32bit version ever since. The apt/dpkg part all seems fine though I'm considering taking out the unneeded wpasupplicant parts of it for the Puppy addon situation since they are not needed and would make the addon even smaller than 30MiB. Alas, I stayed up too long last night so am worn out today so publishing will have to wait till tomorrow or the day after... All working like the focal one though.

When used as a standalone WDLGO distro, the 32bit Bionic kernel + firmware/modules boots fine, but has an issue with my iwlwifi. It seems likely to me that BionicPup32 itself gets away round the issue by pre-loading the iwlwifi firmware prior to calling modprobe iwldvm (which dmesg indicates fails as if dynamic loading not in the kernel - though it is...), but I'm not sure if that's how it is done there. I won't be going to such lengths since I'm mainly wanting this one for connecting via fixed ethernet connection, which works fine (but another reason why I'm thinking of cutting the wpasupplicant packages out of it - still to decide that...). Actually, you can use the fossapup kernel+firmware/modules with it and iwlwifi works fine with that compilation out of the box - I suspect the bionicpup32 kernel could be compiled similarly and the problem would simply disappear, but I may be wrong - doesn't effect the use of its firstrib_rootfs.sfs as an apt addon for Puppy of course, since wifi already working underneath on that.

wiak

Repeated the entire procedure of installing Zoneminder and a LAMP on a stripped Fossapup64 with firstrib_rootfs.sfs loaded and mounted went smoothly using apt only!
Ended up with a working Zoneminder that seems to be functioning well and without to many hurdles to overcome. Also installed geany and viewnior using apt and fixmenu, and all those packages are working and in the menu system as expected.

Okay so now I'm thinking I'll merge ydrv_upupbb_19.03.sfs and adrv_fossapup64_9.0.5.sfs using this script I found on the Murga forum which I slightly modified the mount command to get it to work quickly without looking at it too hard, but the gist of it is to merge the 2 SFS's

 #!/bin/sh -a

[ "$1" == "" -o "$1" == "-h" ] && echo "USAGE: merge [ one.sfs two.sfs...]" && exit
 #echo "$1"
 
MERGE="/tmp/merge"
  mkdir "$MERGE"

FILES="/tmp/files"
  mkdir "$FILES"

 NUM="$#"

i=0
for  ((i=0;i<$NUM;i++)); do
   
   mount "$1" "$FILES"   
#   mount "$1" "$FILES" -o loop,ro
   cp -rp ${FILES}/* "$MERGE"
   umount "$FILES"
   sleep 1
shift
done
    mksquashfs "$MERGE"  merge.sfs

## cleanup;
rm -r "$MERGE"
rm -r "$FILES" 

I then renamed merge.sfs to ydrv_upupbb_19.03.sfs and then created a new adrv_fossapup64_9.0.5.sfs to add the changes :

/usr/sbin/adduser became /usr/sbin/adduserBB
/usr/sbin/addgroup became /usr/sbin/addgroupBB
/usr/sbin/chpasswd became /usr/sbin/chpasswdBB
/usr/sbin/deluser became /usr/sbin/deluserBB
/usr/sbin/delgroup became /usr/sbin/delgroupBB

and the duplicating of the files:

file -> /sbin/init copied to  /sbin/init-puppy
file -> /sbin/poweroff copied to   /sbin/poweroff-puppy
symlink /sbin/reboot copied to  /sbin/reboot-puppy

Using a fresh frugal Fossapup I replaced the SFS's with the new versions.
Now boot the Fossapup64 with the merged ydrv_upupbb_19.03.sfs and the new adrv_fossapup64_9.0.5.sfs.

Again reboot to create a save folder for Fossapup64.
At this point I used SFS-Load-on-the-fly to install the firstrib_rootfs.sfs file from the ISO downloaded using the script -> get_wdlgo_focal64_3.0.0-rc1-allfirmware.iso.sh

At this point the Fossapup64 is a Fossapup64-WDLGO OS.
Here used Psync to make sure the system time is good to go.
Also now those copies of the Puppy versions come into play.
Deleted:

symlink -> /sbin/init
symlink -> /sbin/poweroff
symlink -> /sbin/reboot

and replacing those 3 with the original Puppy Fossapup64 versions. That is:

file -> /sbin/init-puppy ->  /sbin/init
file -> /sbin/poweroff-puppy ->  /sbin/poweroff
symlink /sbin/reboot-puppy -> /sbin/reboot

Tested with another reboot.
Now began the Zoneminder install by testing apt by installing geany and viewnior.

First some users need to be created:

adduser www-data
adduser adm
adduser _apt --force-badname
usermod -a -G syslog adm
usermod -a -G video www-data

Now add the Zoneminder master branch Ubuntu PPA to the /etc/apt/source.lst

deb http://ppa.launchpad.net/iconnor/zoneminder-master/ubuntu focal main 
# deb-src http://ppa.launchpad.net/iconnor/zoneminder-master/ubuntu focal main

A package for gnup must be installed for apt-key to work (only one is necessary):

apt install gnupg gnupg1 gnupg2

and add the security key:

apt-key adv --keyserver keyserver.ubuntu.com --recv-keys ABE4C7F993453843F0AEB8154D0BF748776FFB04

Then went and used :

apt update
apt install apache2
apt install php
apt install mysql-server

The trick to getting mysql to work is a proper initialization:

mysqld --initialize-insecure

IMPORTANT: rename /etc/mysql/my.cnf to /etc/mysql/No-my.cnf
create a blank /etc/mysql/my.cnf in it's place!
Start mysql-server with:

mysqld -uroot &

here it is recommend to create a password for root in mysql

mysql -u root --skip-password

After connecting, use an ALTER USER statement to assign a new root password:

ALTER USER 'root'@'localhost' IDENTIFIED BY 'root-password';

Of course there are some Apache configurations done at this point which I will not go into here but now it should be okay and go ahead and

apt install zoneminder

Also more configurations and some other small details are done here resulting in a running LAMP and Zoneminder install.
I installed mtPaint the Puppy Linux version, with the PPM which worked as well OTB.

I configured 3 cameras to test: 1 local web cam and 2 network cameras results in :

I have an unusual use case that I want to try. I'm experimenting with sandboxes and containers and my current experiment is with Puli as the guest. I've made an sfs file where everything is duplicated in /cont via hardlinks. The size cost of this is small. This allows me to experiment with various scripts by blocking out what I don't want (either in /cont or /).

The merit of running Puli in a container is perhaps dubious since much of Puli's novelty functionality depends on it being able to block suspicious connections and put processes to sleep. That said experimenting with puli in various environments container / sandbox or chroot lets me lean about the inner workings of Puli without having to run a full system.

My original thought was to use ungoogled chromium as the browser to include given the high security goals of puli. However, Puli's glibc version is to old (see post) to run the ungoogled chromium portable published on this forum. My thout is this. Put ungoogled chromium in /cont/opt and the seamonky portable in /opt. Then remove the puli version of glibc in /cont and replace it with the glibc in firstrib_rootfs UbuntuFocal64. I would also like to replace all packages in /cont with those of firstrib_rootfs.

Now what I'll have is a duel system, which will include a pristine puli and one with selectively upgraded libs based on firstrib_rootfs. What I need to know is what packages are included in firstrib_rootfs so that I can remove them from /cont.

Edit: Maybe I'll just copy the firstrib_rootfs into my extracted sfs, then delete and fix symlinks (until it works), but first remembering to rename the suggested files mentioned in this thread. This would seem to be the quick and dirty approach

/usr/sbin/adduser became /usr/sbin/adduserBB
/usr/sbin/addgroup became /usr/sbin/addgroupBB
/usr/sbin/chpasswd became /usr/sbin/chpasswdBB
/usr/sbin/deluser became /usr/sbin/deluserBB
/usr/sbin/delgroup became /usr/sbin/delgroupBB

Have you tried running these commands with the renaming? My understanding is that busybox uses the name of the symlink to decide which applet to run. As a consequence, I don't think that these commands will work like this. You could replace them with a script. The script could even execute a symlink with the same name but in a different folder. This alt folder could be put int the front of the PATH variable if one wanted to try running something where the busybox functions took precedence.

s243a wrote: ↑Wed Jan 27, 2021 2:26 am

Code: Select all

/usr/sbin/adduser became /usr/sbin/adduserBB
/usr/sbin/addgroup became /usr/sbin/addgroupBB
/usr/sbin/chpasswd became /usr/sbin/chpasswdBB
/usr/sbin/deluser became /usr/sbin/deluserBB
/usr/sbin/delgroup became /usr/sbin/delgroupBB

Have you tried running these commands with the renaming? My understanding is that busybox uses the name of the symlink to decide which applet to run. As a consequence, I don't think that these commands will work like this. You could replace them with a script. The script could even execute a symlink with the same name but in a different folder. This alt folder could be put int the front of the PATH variable if one wanted to try running something where the busybox functions took precedence.

How, I think I'm going to do this is move the busybox links to the folder /usr/sbin2. That way all the relative paths should still work.

@s243a that does sound like a very interesting experiment. Please keep us informed on how it works!

I am working right now with a fully stock Fossapup64-9.0.5 with firstrib_rootfs.sfs installed and all the plugin components seem to be working as expected.
Also I have loaded the devx_fossapup64.sfs and the developer tools work. As a test I git cloned pmcputemp and compiled it successfully.
I just installed Apache2, PHP7.4, mysql-server-8.0.22 using apt, and the LAMP seems to function correctly.

I have not run the commands after the renaming yet. I do like the idea of just moving them!

Although I have used the adduser and usermod tools for the Zoneminder package install which worked well. So I have not needed the busybox version. It is correct that for the busybox applet to work, the symlink can't have the 'BB' on the end.

rockedge wrote: ↑Wed Jan 27, 2021 2:42 am

Although I have used the adduser and usermod tools for the Zoneminder package install which worked well. So I have not needed the busybox version. It is correct that for the busybox applet to work, the symlink can't have the 'BB' on the end.

Yes, I was disabling the Puppy busybox symlinks entirely. In practice I use a separate sfs (just for these apt/dpkg-required full versions of utilities not in Puppy by default) that comes in over the top of the puppy_xxx.sfs and hence eliminates the busybox symlinks. The other main sfs is the actual dpkg/apt addon. The busybox versions are not required when you have the full utilities (but there may well be other busybox applets you do want available because no full versions are on your system). Of course they can be called simply be the likes of:

'busybox mount' or 'busybox lspci' or whatever...

Actually, in WDLGO distribution I avoid the issue altogether (and keep firstrib busybox symlinks). The way I do that (and you will find it already in the current FossaPup64 addon) is that I have a static busybox in /usr/local/firstrib/bin and have that in the PATH (but not higher in precedence than any same names utilities in say /bin, /sbin, /usr/bin and so on I add /usr/local/firstrib/bin to the WDLGO system PATH). For example:

PATH=$PATH:/usr/local/firstrib/bin

Of course there are many ways to do this. It's just a matter of the system designer depending whether they want busybox symlinks at all, and where they want them to appear precedence-wise (but almost certainly not early or you end up getting restricted busybox versions of utils when full utils are on the system or may be added via package manager). Not that I wanted to keep busybox links available (despite making sure at end of PATH) because that allows for the fact that busybox can provide versions of so many utility commands even when (not or not yet) otherwise installed, but so important to avoid these busybox versions clashing and taking precedence... Generally speaking, I consider it accepted practice that non-upstream packages should be placed somewhere like /usr/local. However, /usr/bin and so on local package are almost always added to be higher precedence than existing system packages and hence you will find pretty much all systems put /usr/bin near the front of the PATH (highest precedence) whereas busybox utils, being inferior to full versions, is not wanted there, and hence my use of /usr/local/firstrib/bin at end of PATH (originally I had that static busybox in /usr/local/bin and wondered on testing why some things were failing - it was because they were getting busybox versions instead of the already available and required full versions... hence I fixed that weakness as described).

s243a's plan to put the symlinks into /usr/sbin2 as an alternative, is similar except relying on relative paths to find the /usr/bin/busybox (or wherever it is on particular system), and again the most important detail is that you'd have to put that at the end of the path to allow higher priority to full versions of the utility apps. The reason I actually moved busybox itself too is that WeeDogLinux system start with static busybox, and I want to keep that pretty highly endowed busybox available for later, but... it is very possible a system user will use package manager to install official non-static busybox, which may well overwrite the static one (I want to keep) and thus lose all the extra busybox applets (depending on what the official dynamic-lib busybox provides, but I've noted that upstream repo busybox variant generally comes with relatively few applets compared to these multi-purpose boot special static ones...). Having said all that, the latest busybox static compile I've been testing turns out to no longer include busybox rfkill, which I don't want to lose, so likely going back to using previous official busybox static release in WeeDog - indeed, the reason I haven't yet published WDLGO_Bionic32 that I made a couple of days ago, is precisely because I'm testing alternative busybox because I found that I had wpasupplicant issues with the new one (doesn't effect its firstrib_rootfs.sfs use as a Bionic upup type dpkg/apt addon, but the bootable WDLGO Bionic system is my priority of course.

Anyway, I should stop writing since need to get back to further WDLGO_Bionic testing

@wiak what are the links to get the latest plugin SFS files? Is it still using ./get_wdlgo_focal64_3.0.0-rc1-allfirmware.iso.sh to retrieve the ISO file then extract the firstrib_rootfs.sfs and use that?

rockedge wrote: ↑Thu Jan 28, 2021 1:58 am

@wiak what are the links to get the latest plugin SFS files? Is it still using ./get_wdlgo_focal64_3.0.0-rc1-allfirmware.iso.sh to retrieve the ISO file then extract the firstrib_rootfs.sfs and use that?

For the moment yes. I'm still working on WDLGO_bionic tho have just found extremely elusive reason modprobe my WiFi firmware was failing. Still not found exact fix but should resolve tomorrow and then get back to packaging the dpkg/apt addons for each.

My trial WDLGO_Bionic32 standalone WeeDogLinux distro is now working as I wish (meaning that I can also use simple wiakwifi on it to connect successfully via either ethernet or wlan on my HP Elitebook 2530p system and most others).

I'll now get back to building all UbuntuFocal and UbuntuBionic WDLGO systems and then build tailored dpkg/apt package manager addons for FossaPup and BionicPup/upup systems (they don't need the wpasupplicant components nor probably the firstrib busybox). A fair amount of work is involved in that packaging so I'm aiming to have it all posted in the form I prefer in about one week's time (maybe some earlier, depending on my finishing testing a few alternative layouts). Actually there is a lot involved since the main WeeDogLinux build scripts for firstrib_rootfs and initrd have both had many changes/updates (so need a lot of testing overall to make sure all old build plugins (new versions) still work as they should) and also I have a semi-completed additional build_lgo_firstrib_rootfs script, which I use to produce the special WDLGO systems. I may end up using the official (non-static) busybox in the final WDLGO_XXXUbuntu firstrib_rootfs result but get the script to chuck out the dpkg/apt addon-for-Puppy prior to installing that or wpasupplicant stuff since the Puppy addon requires neither... Will have to check the current script to work out how easy that change will be - basically the script would both build WDGLO standalone distro and also chuck out the two sfs filesystems required for Puppy addon (doing them both in same script will save some bandwidth else I'd have to download much the same packages twice...). Then again, simpler to use a separate special for Puppy addon script - and simpler to understand, so on second thoughts I think I'll do it that way instead since WeeDogLinux was always intended to be as much about showing how all this stuff works and making it easy for aspiring developers to build their own variants easily. Late just now so will work on these extra scripts tomorrow sometime...

Busy times and I have a lot to organise and store on gitlab also... like alone the website for WeeDogLinux I have already built to a large extent, but not yet put online. However not all will be ready to publish at this time - some will be after my summer vacations are over(!) and thereafter I'll be concentrating only on WDL website along with WDL_Ubuntu_fulldesktop (since my partner needs that one for her business use), which will be my 'clone' of existing WDL_Arch64 system (which is currently used fulltime in the business, and going strong and reliably and up-to-date since a rolling-release via Arch pacman). Hopefully rockedge will continue to work on WDL_Void systems since I'll obviously be too busy as things stand... Neither the WDLGO standalone systems nor the Puppy 'dpkg/apt' addons are a personal priority for me, but interesting to me conceptually and easy to produce via the WDLGO distro builds, and hopefully useful to some in the Puppy community. They have been a bit time-consuming and tricky to produce though... However:

All looking good now.

wiak

Have made much progress today. WDLGO_<ubuntu_variant> standalone now comes with official ubuntu (dynamic-linked) busybox rather than busybox.net static busybox, so completely official ubuntu rootfilesystem components and structure and no /usr/local/firstrib/bin/busybox in final build produced. Since the way I'm building this is via a modified build_firstrib_rootfs script, I continue to have the option of using an f_XXX.plug file that contains whatever extra commands I want, so could build as large a distro as wanted via that in usual fashion - using apt - and I currently use that plug facility to apt install busybox to produce the final WDLGO standalone system. Still work to do on the build scripts so they will be published some time later than the created isos (many things to consider to polish the WDLGO build scripts at this stage).

I have currently manually produced Puppy dpkg/apt addon from the partial result that occurs prior to the f_XXX.plug running (since I don't need or want busybox in the Puppy addon), however I am now turning my attention to automating that process since that is important longer term and also for accommodating alternative Debian-based distros in the WDLGO WeeDogLinux family.

Next report, within a few days time, should include a new iso or two hopefully. I'm keen to finish all this for the moment, with Focal and Bionic versions of both WDLGO standalone and Pup addons, and come back to it with possible enhancements later in the year. That break will also give plenty of time for others to experiment with the system(s), the reports from which always give me further ideas.

wiak

This 'report' came quicker than I expected because I have sadly just discovered an incompatibility issue with BionicPups compared to official UbuntuBionic.

Good news is that I have now completed WDLGO_Bionic32 standalone distro. The build script I'm working on that produced this also automatically extracted all components required for a Puppy Bionic dpkg/apt addon (and auto-made two sfs files out of these).

Alas, bad news, had this addon been for FossaPup the dpkg/apt addon sfs files were instantly ready to use. But... to my horror, on going to try them out in the BionicPups I discover to my horror that none of these Bionic-based Puppy distros have adopted Ubuntu-compatible lib and /usr/lib arrangements - i.e. they have arranged these lib directories via symlinks rather than the original Ubuntu way, and are therefore not directly compatible. Hence the sfs files cannot simply be loaded. In particular, the directories /lib/i386-linux-gnu, and /usr/lib/i386-linux-gnu are symlinks in Puppy, whereas in UbuntuBionic official they are actual directories. The sfs loading of WDLGO's firstrib_rootfs dpkg/apt component parts, which are absolutely compatible with upstream Ubuntu directory organisation will thus not work out-of-the-box. Of course, their contents 'could' be moved to the various places Puppy Bionic has chosen to arrange things - probably just need to copy all the libs across to /lib and /usr/lib rather than to i386-linux-gnu, but that is extra work and messy and any sfs would need rearranged accordingly. I will think about it, but probably leave such manipulations to anyone else who can be bothered...

However, I will of course be publishing the overall WDLGO_Bionic32 standalone distro iso, and, as I say, anyone who wants to take its component parts and merge it into the otherwise compatible (I hope) BionicPup32 is welcome to do so. Similarly with WDLGO_Bionic64.

Thank goodness, that the filesystem structure adopted in FossaPup64 does seem to mirror that of official UbuntuFocal and hence compatible also with WDLGO_Focal64 structure making the dpkg/apt addon a breeze. The next version of WDLGO_Focal64 will come with the two simple dpkg/apt Puppy addon sfs files which is all that is required to add apt to the Puppy system for that distro. Bit disappointing about BionicPup not being more Ubuntu filesystem compatible and I'm somewhat surprised, but that is how it is. I do hope, however, that future Ubuntu Pups take care to keep Ubuntu libs arrangement so Puppy addons such as those I can provide via WDLGO system builds can be taken easy advantage of by the Puppy community - I would certainly be willing to provide such, but not if I also have to make entirely different filesystem structured versions.

I've only just noticed the BionicPup structural difference so haven't looked into its details. I'll take a closer quick look tomorrow to see if there is a relatively simple workaround (though at a quick glance it doesn't look like a trivial fix aside from rearranging everything to suit). Not too difficult (albeit a bit time-consuming/messy) to merge (or produce rearranged sfs files) however, so if not done by me that can be a project for someone else, if they wish, once WDLGO_Bionic32 and WDLGO_Bionic64 are produced. Admittedly, these Bionic Pups weren't designed with the idea that apt or full multi-user PAM would ever be added, but annoying situation nevertheless.

More generally, the resulting issue is an example illustration of why it is generally better to keep to upstream Ubuntu lib structure if basing distro on Ubuntu repos (something I take great care over when producing WeeDogLinux distros: for example all of WDL_Arch, WDL_Void, WDL_Debian/Ubuntu/Devuan are carefully constructed to mirror the related upstream distros filesystem structures for perfect compatibility. Unnecessary lack of structural compatibility simply limits what upstream distro (Ubuntu Bionic in this case) facilities can easily be adopted/added (beyond simply using their repo packages). Tired now after that and late here - tomorrow is another day...

wiak

wiak wrote: ↑Sat Jan 30, 2021 1:23 pm

This 'report' came quicker than I expected because I have sadly just discovered an incompatibility issue with BionicPups compared to official UbuntuBionic.

Good news is that I have now completed WDLGO_Bionic32 standalone distro. The build script I'm working on that produced this also automatically extracted all components required for a Puppy Bionic dpkg/apt addon (and auto-made two sfs files out of these).

Alas, bad news, had this addon been for FossaPup the dpkg/apt addon sfs files were instantly ready to use. But... to my horror, on going to try them out in the BionicPups I discover to my horror that none of these Bionic-based Puppy distros have adopted Ubuntu-compatible lib and /usr/lib arrangements - i.e. they have arranged these lib directories via symlinks rather than the original Ubuntu way, and are therefore not directly compatible. Hence the sfs files cannot simply be loaded. In particular, the directories /lib/i386-linux-gnu, and /usr/lib/i386-linux-gnu are symlinks in Puppy, whereas in UbuntuBionic official they are actual directories.

I discovered that last night also when trying to upgrade Xenai/Puli with WDLGO_Focal64 firstrib_rootfs (see thread). I also had this issue when I was building Tiny Puduan via woof-next. As happened before it breaks gdk-pixbuf-query-loaders because this tool expects the loaders to be in a very particular place. This meant in my recent experiment that the icons on rox were broken. I was going to post about it but wanted to sleep on it.

The issue was fist addressed in the following pull requrest:
get rid of the multiarch symlink #1224

but this pull request was closed because the work was instead first done in an experimental branch, which was presumably then merged into puppy but the link to the experimental branch no longer exists . Needles to say they eventually got rid of the multiarch symlink hack.

The sfs loading of WDLGO's firstrib_rootfs dpkg/apt component parts, which are absolutely compatible with upstream Ubuntu directory organisation will thus not work out-of-the-box. Of course, their contents 'could' be moved to the various places Puppy Bionic has chosen to arrange things - probably just need to copy all the libs across to /lib and /usr/lib rather than to i386-linux-gnu, but that is extra work and messy and any sfs would need rearranged accordingly. I will think about it, but probably leave such manipulations to anyone else who can be bothered...

I think if one wants dpkg support then the puppy files need to moved into the multi-arch directories because extracting via tar can break symlinks and dpkg probably does this. If one is using the core W_LGO suite, there is no package manager included and the symlinks can be kept. In this case the W_LGO could be merged into puppy in a way to preserve the symlinks.

However, I will of course be publishing the overall WDLGO_Bionic32 standalone distro iso, and, as I say, anyone who wants to take its component parts and merge it into the otherwise compatible (I hope) BionicPup32 is welcome to do so. Similarly with WDLGO_Bionic64.

I think if we are going as far back as bionic I'd be more interested in a 32bit system but I suppose you have build scripts for these things. I will note though that there is an extra step that one must take. The puppy package manager must also be fixed because in old versions of the ppm, the multi-arch symlink will be recreated by first moving the files and then making the symlink again.

Thank goodness, that the file-system structure adopted in FossaPup64 does seem to mirror that of official UbuntuFocal and hence compatible also with WDLGO_Focal64 structure making the dpkg/apt addon a breeze.

I agree. The multiarch symlink appears to have been a mistake.

Well, I'm not blaming Puppy (devs) for adopting the filesystem structure it has. For Puppy PPM use itself I presume it all works intended and since no dpkg/apt is part of Puppy design it wouldn't matter from that perspective. Just a pity from the addon apt via sfs perspective, which effectively changes single-user PPM Puppy into some-mongrel-thing else. Also, symlinking lib destinations like that tends to otherwise work very well in practical use when it comes to simpler lib paths. For example both Arch Linux and Void tend to symlink not only lib directories but also pretty much all exececutable file directories such that most all libs end up in /usr/lib and most all executables end up in /usr/bin. Certainly that means a lot of files in single directory locations, but works great in practice since not having to add much to PATH and the libs-related PATH (such as LD_LIBRARY_PATH) or changing their orders to achieve required precedence. Debian is old-school UNIX organisation I suppose, but, presumably the Puppy devs, similarly to myself, prefer more Arch-like filesystem organisation (but drawback is that lack of upstream compatibility issue).

However... I don't know about others out there but I often wake up with possible solution to things that disturbed me just as I went to an exhausted sleep and I'm hoping that is the case this morning. On waking my brain was immediately telling me (rather than sensibly thinking about breakfast) that it would actually not be particularly difficult for me to build a second WDLGO_Bionic32 that instead of current Ubuntu filesystem structure adopted PuppyBionic filesystem structure and thus make the chucked out dpkg/apt addon sfs compatible. This would be a special WDLGO build since I'm certainly keeping Debian filesystem as standard in official debian-distro-based WDLGO releases (so Puppy dpkg-apt-addon users should use the specially provided addon sfs and not the firstrib_rootfs of WDLGO in future). I'm going out just now, but will try that trick later to day... Yes, my main interest in WDLGO_Bionic is also for 32bit version - indeed I even consider an earlier than Bionic 32bit version. Of course I'm scripting all builds in WeeDog, though they are disorganized in the case of WDLGO builds at this early stage so won't be publishing these until in appropriate close to stable form since would need heavy documentation to accompany them as they stand.

The normal WeeDogLinux build scripts are all long-ago published of course - since WeeDogLinux is primarily a keep-it-simple build script system with its own script-built initrd/init for overlayfs frugal install system control that thereafter utilises upstream official package managers and does not involve any remastering or manual/hack minimising of any upstream distro (though no harm in later minimising of course).

wiak wrote: ↑Sat Jan 30, 2021 10:12 pm

However... I don't know about others out there but I often wake up with possible solution to things that disturbed me just as I went to an exhausted sleep and I'm hoping that is the case this morning. On waking my brain was immediately telling me (rather than sensibly thinking about breakfast) that it would actually not be particularly difficult for me to [script-] build a second WDLGO_Bionic32 that instead of current Ubuntu filesystem structure adopted PuppyBionic filesystem structure and thus make the chucked out dpkg/apt addon sfs compatible. This would be a special WDLGO build since I'm certainly keeping Debian filesystem as standard in official debian-distro-based WDLGO releases

Okay, that worked with but the simplest of script mods for this one-off special build for BionicPup32 dpkg/apt/PAM addon. See attached screenshot where I have just installed nano as a simple test.

Note in the screenshot the adrv (adrv_upupbb_19.03.sfs) is actually the first part of the dpkg/apt addon (only 7.8 MiB in size). The main part of the dpkg/apt addon (apt_sfs_load_bionic_i386.sfs) is loaded after booting BionicDog32 via sfs-load and is 21.5MiB in size (both using normal gz mksquashfs compression, so could be smaller download with xz). The only thing the BionicDog32 user has to do is to rename the original adrv to ydrv_upupbb_19.03.sfs

The new adrv contains the coreutils /bin and /sbin directories part of the addon and appears in layer above puppy_upupbb_19.03.sfs and hence overwrites the busybox app links that otherwise appear in that puppy_upupbb_19.03.sfs. I expect that will work fine but further testing will be needed to ensure that. Also, I can't at this stage guarantee I have my addon filesystem structure absolutely correct for Puppy, but I think it is - easy to rebuild modified slightly if any problems are identified. I will need rockedge to test this addon soon (once published) using that testing zoneminder install - I'll likely preconfigure it with some of these zoneminder-related users and groups prior to publishing (hence a short delay before posting). On second thoughts I won't add the zoneminder-related users/groups since that wouldn't be required more generally.

EDIT: I'm more than sure now that I could make a similar dpkg_apt addon for EasyOS-Buster though I don't know when I'd get round to doing so - just the wrong time of year for me.

I'm now at that 'nice' stage, from a developing point of view, where I have scripts doing most of the work and apparently successfully, which allows me time to experiment. Once I have the 'product' it is a pleasant kind of development being able to merge some of the contents, to chop and change what is included and not included, what layers to arrange things in for best results in sfs addon files. That's how I was able to produce the first dpkg_apt addon for FossaPup64 and now I've produced the two addon sfs files (like I have done with similar BionicPup32 dpkg_apt addon), which makes usage with Puppy very simple to implement (just a couple of files to rename, a reboot, and a load addon via Puppy sfs-load utility).

Have the firstrib_rootfs built (and the addons automatically built by the script) I am happy to experiment at my leisure with chopping up the results in different ways into alternative sfs arrangements so I can use these alternative sfs forms to either lie under existing puppy files or to overwrite them (and thus provide upgrade solutions) - these are easy tasks at this stage and I'll provide any sfs addons of any such arrangement I find useful that might appeal also to others.

First will be to publish the latest WDLGO_Focal64 and WDLGO_Bionic32 standalone distro isos, along with the optional associated specially tailored two addon sfs files that can be instantly used to provide dpkg_apt_multiuserPAM capability to Puppy community distros FossaPup64 and BionicPup32. The dpkg_apt sfs addon(s) for BionicPup32 have been specially crafted to work with the older Puppy filesystem hierarchy (which deviates from standard Ubuntu/Debian approach). These could also be used experimentally with older pups that also use that older Puppy filesystem hierarchy to potentially provide upgraded libs (such as s243a has been experimenting with, via the first WDLGO_Focal64 firstrib_rootfs release, to use newer chromium in Puli/xenial distro I believe) alongside the dpkg_apt_multiuserPAM components, though for that upgrade I'd package the addons somewhat differently in that the files I want to upgrade the underlying Puppy host would be put into the adrv_addon (since that one overwrites the puppy_XXX.sfs filesystem). In the same way I already do with the apt_sfs_load_focal_amd64.sfs that one, as its file name suggests, is to be loaded by Puppy's sfs_load utility, the reason being that sfs files loaded by that mechanism do not overwrite already puppy_XXX.sfs loaded files, the main reason I did things that way being that I did not want the main addon to overwrite essential Puppy configuration files (such as these in /etc). Whether these experiments work without issue is another matter, but where there is a will there is indeed often a way...

The key thing is to have the LGO (lego-like) components, for remoulding per the experimenter's needs, which is what WeeDogLinux system was basically designed for - as well as being able to build full desktop systems to the recipe's of anyone willing to put in the time building the associated FirstRib build plugin, or modifying existing FR build plugin(s). Such versatility, flexibility, and relative simplicity, is the name of the game when it comes to WeeDogLinux system design, which differentiates it from most build systems out there. Nothing is set in stone, or inaccessible to anyone who aspires to system development activities, with WDL or its subdivision WDLGO - most anyone with basic shell scripting abilities can easily learn and use it - so make what you will with it.

There is plenty of scope and and more than I could ever try or test out on my own - be it for upstream flavour Void Linux (the original upstream package manager employed in FirstRib WeeDogLinux) or the Debian-based distros (Debian, Ubuntu, Devuan), Slitaz, or now, for providing addons for Puppy. Furthermore build_weedog_initrd can also be used with the Puppy rootfs underneath to provide overlayfs weedog init-driven capability (upper_changes with 'rollback' capability, raw or sfs layers and so on), rather than Puppy's normal PUPMODES and aufs. So much to do, so little time to try. Main thing for me soon is to concentrate on further documentation (though most all WeeDogLinux scripts have reasonably detailed documentation built in to their help/usage internal text, though it is difficult to cover all facilities/tricks in there).

Anyway, typing that was me basically relaxing/procrastinating - back to work... albeit the nice, simple, re-packaging/experimentation phase that I personally enjoy most...

I'm continuing to basically use the following earlier post notes in my attempts to install zoneminder (not configure it - that's for rockedge...):

viewtopic.php?p=15747#p15747

EDIT1: But major difference is that with new double-sfs file addon the original puppyXXXX.sfs is used and not modified in any way.

EDIT2: With FossaPup64, using the new addon sfs files I'm testing, installing zoneminder gave me this issue again:

wiak wrote: ↑Sat Jan 23, 2021 11:35 am

Oh, how stupid of me! Considering I built/use WDL_Arch64, which uses systemd, I should have thought/noticed that zoneminder install changed /sbin/init to point to systemd. I prob just need to revert that to busybox init (well, actually Puppy /sbin/init script which does various other important Puppy configurations) and all will be fine. Late just now, will try tomorrow.

/sbin/init is the first thing I should have checked... oh well, just hoping it is as simple as that and if so then this new apt facility for FossaPup64 could be very useful if not revolutionary.

Zoneminder install from Ubuntu via apt seems to (not surprisingly I suppose) result in /sbin/init being overwritten to become a symlink to systemd init rather than the essential Puppy's /sbin/init shell script... though previously the problem mysteriously went away on its own and didn't happen on installing zoneminder that I remember - maybe I did something in different order or forget... Fix is to delete the symlink in the pupsave file, just prior to rebooting, and then the original puppy init script will correctly be used.

EDIT4: Fortunately, the problem 'mysteriously disappeared' again on a second try. As long as I follow the instructions in the previous howto link carefully (and remember, puppy_XXX.sfs should not be modified with this new double-sfs addon arrangement), systemd does not try to take over on installing zoneminder.

viewtopic.php?p=15747#p15747

Zoneminder installed without issue on this second attempt and reboot via Puppy Start Menu also worked fine (no systemd accidental install issues whatsoever...).

Just as well since the above 'fix' isn't enough since if systemd does get installed it overwrites much more than that. Worth bearing that in mind - danger with using apt from Debian would be risk of systemd ever accidentally getting installed. Okay, on this occasion but only time will tell if that might accidentally happen on other installs - still useful for most installs though - just keep the risk in mind. Fortunately it is always easy to re-install a new Puppy system (and even one with backed up savefile).

I will likely be publishing the new dpkg_apt_multiuserPAM double-sfs FossaPup64 addon probably tomorrow along with similar for BionicPup32. Hopefully get round to also building/publishing the WDLGO_Focal64 and WDLGO_Bionic32 standalone bootable WeeDogLinux tiny distros too.

EDIT5: I tried installing systemd via 'apt install' just to see if it would break Puppy (i.e. overwrite Puppy files, which I imagined it would, but didn't seem to - I'm not sure, I'll have to try again). But then I rebooted and installed lxterminal via 'apt install' and this time the systemd menace has appeared so BE CAREFUL - I'm not sure if installing lxterminal was the issue or my earlier attempt to install systemd itself. Nothing I can do about such issues arising - up to the user to avoid, hence my big DISCLAIMER - maybe a very useful multiuser Puppy addition but USE AT YOUR OWN EXPERIMENTAL RISK... as always...

NOTE: I expect the above systemd-related accidental install risk can be protected against via suitable apt 'pinning' - I leave that up to the users to find and do. There may of course be someone who actually wants to install systemd in Puppy (okay, so not many!!!) but by default it would be better to prevent the 'danger' so such pinning or whatever method prevents accidental installation of systemd (if possible) can be added by default to the addon later - just experimental use stage at the moment... At that experimental stage, you could instead arrange to run the Puppy rootfilesystem as a WeeDog under weedog initrd/init control, rather than Puppy's own initrd/init. That way you would be using WeeDog's upper_changes instead of Puppy's savefile. The advantage is that you can simply renumber the upper_changes folder between reboots and then when and if something goes wrong rollback to previous upper_changes. However, most puppians are not familiar with that and so one alternative would be to always check /sbin/init to make sure it hasn't become a pointer to systemd prior to rebooting and merging the changes into your savefile...

Puppy apt addons being published via Puppy Projects ( downloads being at weedoglinux forum):

viewtopic.php?p=16601#p16601

Though I haven't published anything 'new' for a while, I'm currently polishing up (fixing) the latest build_firstrib_rootfs script. As part of the testing I've just built a minbase Firstrib Devuan64 firstrib_rootfs, which I'll convert into a WDL_Devuan64 standalone bootable system tomorrow via build_weedog_initrd. Aside from the getting these newer build scripts into full working order, I have it in mind to create a WDLGO_Devuan64 system along with dpkg_apt_PAM addons for Puppy Devuan64 release I noticed recently (advantage being no systemd-related issues with that distro).

Alas that my dev system is running out of space again; a constant battle - the system is old and only has a 64GB SSD in it, and I keep doing dev builds and am slow to tidy up thereafter (especially since I'm scared to delete anything I might need again later - I should be using git, but sometimes I can't be bothered organising what I'm doing, but suffer later...).

wiak

I am putting together a NoteCase document on how to set up a Fossapup64 with the apt add-on SFS and install a LAMP and Zoneminder.

I've done it now more than a several times and am working on writing it down since I've noticed my notes on doing these things are lacking.

The system I am building and writing about is right now at the stage that this Fossapup64 has all the proper SFS files loaded, has three package managers that work, has a fully operational LAMP and with option to switch from Apache to a Hiawatha web server and back again.
Also so far the systemd changes that break Fossapup64's have not appeared. This I expect to happen during the Zoneminder installation phase. I am constructing a simple script that will check for the change and change it back but the real fix will be to have be somehow limiting the systemd integration of those changes to /sbin/init and /sbin/poweroff during the install process.

Timing is everything @rockedge : I was just about to write you on that topic. I have a couple RTMP cameras that I want to understand setup for capture.

Thank in advance for what you've announced.

rockedge wrote: ↑Tue Feb 23, 2021 9:16 pm

I am putting together a NoteCase document on how to set up a Fossapup64 with the apt add-on SFS and install a LAMP and Zoneminder.

I've done it now more than a several times and am working on writing it down since I've noticed my notes on doing these things are lacking.

A question that just today comes to my mind is whether you arrange for zoneminder (and LAMP and so on) to run as root user or can it also be run as non-root, such as spot in the case of Puppy Linux?

The reason I suddenly ask is because I personally am about to change my habit of over a decade, in that I plan in future to autologin as non-root user and work from there. As you know, @rockedge, my usual desktop distro is WDL_Arch64, which can autologin by default as either root or weedog user. To change is a simple matter of running StartMenu -> userswitch. That will continue to be the case, as far as WDL_Arch64 is concerned - just that I am choosing to autologin personally as 'weedog' user from now on. Basically, I am going with the flow (mainline Linux distros) for various reasons: it has become complicated to run many apps if logged in as root user (for example: many browsers, including those that are chromium-based, Microsoft Teams and Skype - Arch AUR versions); despite never having been hacked whilst using Puppy or DebianDog or WDL_Arch64 when auto-logged-in as user root, I personally do not doubt it is safer to use any OS as non-root user.

It's true that it is wonderfully easy/convenient to pretty much always be user root... permission issues never arise and no need to type that word 'sudo' (though it is fair to say that using sudo in WDL_Arch64 is easy - unlike using sudo under the likes of, say, full Ubuntu, which is a horrible experience since Ubuntu seem to do everything to make that painful...). However, for those occasions when I really want to be root all the time, with WDL_Arch64, it is as I said a simple userswitch (which does not involve any reboot) to become so. Also, I can easily create a folder anywhere on my system (outside the save changes area) that can be owned by weedog user and group and contain as many sub-directories as I like - that way, for most of the dev work I do I don't even need to resort to 'sudo'.

Truth to tell, the reason this change of flow has come about is:

1. I noticed my two kids (8 and 15 years old) had independently adopted the habit of autologin as weedog (following an initial userswitch). This, it turns out, occurred naturally because they self-discovered that some large games and various animation software apps were only working out-of-the-box if run as normal user. And also because a lot of what they install comes from Arch AUR repo, which also only allows installations by non-root user; I think that's the main reason actually for their adopting 'weedog' user autoboot as their preference.

2. My partner uses WDL_Arch64 for all her business needs and, as I said, neither Skype nor Microsoft Teams would work out-of-the-box unless logged in as non-root user. Also, running business-critical software as root user does somewhat worry me in the ever-more-dangerous online world - particularly with web-browsers - more and more exploits out there now. She has been running as user root for a long time, so the issue is that her saved work is all owned by user/group root. Again, however, it was simple enough to create a /mnt/home/weedog directory owned by user/group weedog and copied all her previous work directories into that and recursively changed their user/group ownership from root:root to weedog:weedog. That /mnt/home/weedog folder can of course be shared with any other distro I use (albeit with the caveat that the user/group is best being weedog:weedog (which would be a problem to arrange for Puppy installs of course, but for the most part it is easier for me to work around that Puppy issue via chown root:root to weedog:weedog whenever I finish using Pups with that 'shared' weedog directory).

May sound complex, but actually simplicity itself. Much harder in practice to arrange Msoft Teams, Skype, ChromXXX browser, etc etc to run as user root.

Admittedly, I am also a fan of pulseaudio...

and I find that systemd works very well and is less messy to configure and administer than old SysVinit, though I actually 'really' like runit alternative too (as used in Void Linux, and thus by default in WeeDog Void variants). Though, therefore, I am not against systemd, I nevertheless do like choice, so very happy not every distro uses systemd (though runit a far better alternative than old messy sysvinit to be frank).

So, despite my distro designs being far from conventional and weedog overlayfs being independent and unique, I am becoming almost embarrassingly conventional when it comes to my preference for non-root login, pulseaudio, and (when not using runit) systemd. As we know, it is tricky to use the likes of apt on non-systemd machines - though of course that can be done and improved upon via appropriate dummy package apt pinning.

Of course there is nothing to stop WeeDog distro users choosing to autologin as root user and use the various established mechanisms for running apps such as chromium-based browsers from that --no-sandbox or special non-root-user perspective and so on... just that it is easier, I feel, to go with the conventional non-root user flow in this case IMO. An alternative approach is to use 'containers', such as in EasyOS. Void Linux provides a lean/lightweight container implementation (as a Void package)

https://github.com/void-linux/void-pack ... s/template
https://github.com/arachsys/containers

in addition to the alternative of using LXC or Docker (and also, therefore can be adopted by WeeDogLinux Void variants) though I've never tried it since that additional layer of complexity is more than I personally feel the need for.

wiak