Puppy Linux Discussion Forum

Announcing the release of the WDLGO_UbuntuFocal64 bootable distro.

These README notes created 20Jan2021 and revised 20Jan2021.

Download the (simple non-EFI) iso via the get_wdlgo_focal64_3.0.0-rc1-allfirmware.sh script available here:

https://weedoglinux.rockedge.org/viewto ... p=332#p332

This distro a full-multiuser capable but an absolutely minimum dpkg/apt package manager UbuntuFocal64 compatible system. Except can be made much smaller using slimmed down firmware/modules (fwmods sfs) and deleting docs/man/locale pages etc.

However... being "an absolutely minimum dpkg/apt install" it is primarily provided for development/educational/experimental purposes. DISCLAIMER: USE ENTIRELY AT YOUR OWN RISK!

Since you may need to google many things whilst learning how to use it, you may find it most useful booted into a virtual machine (or chroot into uncompressed firstrib_rootfs; though in chroot need to run its /root/.profile to set the executables' PATH).

Whilst the provided iso should boot (on non EFI machines anyway) out-of-the-box, there are things the user needs to do to make it connect to the Internet and basically 'work'. For example, it does not contain udev support (though that could be user-added) so user needs to know their ethernet or wlan interface details and load the appropriate modules (e.g. for iwlwifi module is iwldvm). Below usage is an exemplar, which refers to modprobe of wifi module for my own system only. You need to substitute for whatever your system needs:

Usage:
(Note: default is boot to RAM with no persistence unless copied from /mnt/layers/RAM/upper_changes. If using options /mnt/sda1/wdlive or /mnt/sdb1/wdlive then these wdlive directories must be created and formatted ext2/3/4 first - idea copied from rockedge's recent WD_Void. You can press tab on boot menu to change these save folder locations)
1. Once booted login as user root, passwd root (ignore FossaPup kernel saying bionicpup64, this WDLGO distro is definitely Focal Fossa)
2. Load wifi module

modprobe iwldvm

# my system only - you need to find your own interface module requirements (maybe, for example, from running Puppy lsmod report)

or load ethernet module

modprobe e1000e

# my system only

3. connect to internet using the provided simple wiakwifi script:

wiakwifi reset

# on next boot just use 'wiakwifi reconnect'
and follow the script instructions to connect

4. Update the apt repositories

apt update

And here you will probably get some Error messages concerning some 'security-related' repos... That's because no provision is provided in this 'to-be-user-developed' system for setting correct system time that apt requires. Here is one approach (of many):

5.

apt install tzdata

# and enter your timezone info when asked during installation

Then you can try something simple first, like apt install file or apt install nano.

You will probably need to use the likes of DuckDuckGo or Google from now on... Check your system time via utilities such as hwclock and so on. As I said this is a distro for learning on, developing, and merging into other distros as an addon to provide them with dpkg/apt facilities. A dedicated developer can of course build it up into a full polished distro, though a Ubuntu/Debian debootstrap-type build far easier for that in most cases. No debootstrap was used in its creation...

Anway, apt works, but understand that apt expects a full Debian/Ubuntu system underneath (one that includes all so-called 'essential' packages such as provided by a debootstrap build); this distro only includes the minimum for dpkg/apt to work (well, could be smaller if I took out wpasupplicant and its many dependencies+firmware), but not all Debian/Ubuntu 'essential' packages. That's the disadvantage - you will often get dpkg/apt complaining and have to resolve the issue yourself (good for learning...). But in practice I found it easy to apt install, for example, openshot-qt (but check tips below), so the system is far from being a 'toy'...

Using apt to install further commandline apps/utilities will often work fine (so excellent for building a commandline-only UbuntuFocal system. But you can also build full X desktop with it (but expect dpkg/apt issues to resolve along the way...). One tip for graphical installs:

glib is generally used by X windows apps rather than only plain libc, and apt simply expects it to be there (the X-type apps do not list it as dependencies so apt does not know...). So good idea if trying to install such apps, and sometimes avoid apt errors at end is to pre-install glib items with:

apt install libglib2.0-0

and maybe:

apt install libglib2.0-bin libglib2.0-data

You will definitely need to master various dpkg/apt fixing commands, such as (but not only):

apt -f install
dpkg --configure -a
apt list --installed | less
dpkg --list

and sometimes maybe need to reinstall individual deb packages forcibly with the likes of:

dpkg -i --force-depends <deb-package-name>

It is possible to use the 01firstrib_rootfs.sfs part of this distro as an addon for FossaPup64, but should be slimmed down first to not overwrite some existing crucial FossaPup64 config files. I will later upload a modified 01firstrib_rootfs.sfs purely for that purpose, whose contents could alternatively be permananently merged into a FossaPup64 for the same funtionality. BUT big DISCLAIMER!!!! DO NOT TRY THIS ON AN EXISTING FossaPup64 install (you WOULD almost certainly break it if you did) - such addon is for experiment only at YOUR OWN RISK and should only be attempted if you know what you are doing and on a specially made new frugal install of the underlying FossaPup.

Good Luck and use as you wish but entirely at your own risk!
Feedback is welcome either here or at https://weedoglinux.rockedge.org/viewtopic.php?p=332

EDIT: Forgot to add how to use it in typical frugal install via grub4dos menu.lst and similar. Here is the menu.lst stanza I use (substitute in the uuid and directory you put the files in):

title WDLGO_focal64 UUID method (on my system ata-interfaced SSD harddrive)
find --set-root uuid () a36a6ce1-8c76-4aca-be99-5fc57039z299
kernel /WDLGO/development/vmlinuz w_bootfrom=UUID=a36a6ce1-8c76-4aca-be99-5fc57039z299=/WDLGO/development
initrd /WDLGO/development/initrd.gz

In that frugal install configuration the upper_changes save folder goes by default into /WDLGO/development (which is on /mnt/sda1 on my own system). The only files you need to copy from the iso to there would be: 01firstrib_rootfs.sfs, 00fwmodsXXX.sfs, initrd.gz,and vmlinuz

wiak

note iso md5sum : 563c484af6016b0e4a0c1d137c4f630c wdlgo_focal64_3.0.0-rc1-allfirmware.iso

I see there have been quite a few downloads now. Will be grateful if you can let me know of any major issues, particularly since I'm working right now on the plugin version for Puppy's own FossaPup64 as I first intimated here:

viewtopic.php?p=15406#p15406

This addon/sfs-plugin can most simply be loaded into FossaPup64 using sfs load-on-the-fly. However, since it is impossible for dpkg/apt to know what is already in FossaPup64, in this simple scheme, it is best to start with the slimmest Pup possible and then build it up again using dpkg/apt facility (as things stand in FossaPup64, you can usefully just remove adrv since that itself is just an addon for some apps). Nevertheless, for packages that FossaPup's PPM/pkg have trouble installing, dpkg/apt FirstRib plugin might well successfully do the job since using official Ubuntu package manager - so might already have that useful function of making it easy to install any complex package that Puppy PPM/pkg is failing with.

As I said in previous post, you can already experiment simply by using the existing 01firstrib_rootfs.sfs provided in the WDLGO_UbuntuFocal64 iso as the addon for Puppy's FossaPup64. However per the DISCLAIMER/WARNING, do so at your own risk and I suggest DO NOT use that on an already installed FossaPup64 that you don't want to break(!). Perfectly safe experiment if you make a new Puppy FossaPup64 install simply for the experiment (that you don't mind breaking), and, as I say, you can make such an install without the adrv (indeed, if you want to build a permanent dpkg/apt capable Puppy in this manner you could do so by first slimming down the original FossaPup64 as much as possible (best minimum would be just enough that FossaPup64 boots to a command line but sufficient that you can load the FirstRIb sfs addon, which will become the main system and provide the default official Ubuntu dpkg/apt package manager - you could probably merge it in onboot as a new adrv or ydrv (I haven't experimented much with these), or indeed simply take the contents of the firstrib_rootfs and merge them in permanently (rather than as an sfs) into the new dpkg/apt version of FossaPup64. End result is that you will still have a Puppy (using its initrd and underlying system files etc) and still therefore have all the well-loved PUPMODES you are used to. i.e. a new kind of Pup that uses official Ubuntu package manager to access its repos, but still a Pup.

As I've acknowledged in my previous FirstRibFossaPup thread:

viewtopic.php?p=15406#p15406

wiak wrote: ↑Mon Jan 18, 2021 3:06 am

Yes, I know there have been discussions and some practical successes with using apt installed via PPM on Puppy but this FirstRib can provide a more flexible plugin/bolt-on different approach (and some discussions only got as far as being able to use apt-cache search - FirstRib addon can provide the full thing):

2017 mikeslr discussing josephjp2424's pupjibaro jessie distro
http://murga-linux.com/puppy/viewtopic.php?p=940753
2018 how to use apt in Puppy thread by s243a (up to apt-cache search anyway)
(includes some general forum thread discussion on Pros/Cons of using apt in Puppy)
http://www.murga-linux.com/puppy/viewto ... ?p=1010671

Prior to release my modified 01firstrib_rootfs.sfs for the purposes of a Puppy FossaPup64 dpkg/apt addon I will be examining it carefully to see what I can more safely cut out. There are some parts of the existing 01firstrib_rootfs.sfs that are likely to overwrite some existing FossaPup64 files (albeit temporarily since its an sfs load) so should be able to prune the 01firstrib_rootfs.sfs to become a safer apt_addon.sfs. Even as it stands, the addon (as 01firstrib_rootfs.sfs) is only 31MiB in size (and that is compressed with normal gz compression - only a bit over 20MiB if compressed with xz the way Puppy itself usually nowadays is).

Actually, the WDLGO_UbuntuFocal64 distro itself would only be a less than 30MiB download if I used xz compression with the mksquashfs and provided the firmware component separately (or provided a very slim firmware_modules.sfs for a particular or limited number of systems. However, I preferred to use gz compression and provide full firmware_modules set so would work for as many of you who might like to try it as possible.

wiak

WeeDogLinux is very flexible when it comes to sfs (or uncompressed raw directory) layer handling. In particular, the sfs files can have any name as long as their names begin with two digits (NN) in the range 00 to 99 (with r/w upper_changes folder being the very top layer). What is particularly useful about that is that the NN value precisely specifies which layer from bottom to top that the sfs will appear on. Hence allows easy rearrangement (just change the number...).

But Puppy scheme... oh my goodness. adrv, fdrv. pupXXX.sfs, ydrv, zdrv - that's it! Not exactly flexible, sorry. Also, never having researched it before, I had no clue which (ro) sfs ends up nearest to the top layer (which is the r/w save folder). Issue is that I need the dpkg_apt.sfs addon (which is actually the 01firstrib_rootfs.sfs file) to appear in layer anywhere below the (ro) pupXXX.sfs in order not to overwrite same-named files within Puppy itself. So I uncompressed pup initrd.gz to see if I could fathom the layering order - one look and decided "forget it"... Better to just experiment and know for sure.

Anyway, with FossaPup64:

The adrv provided by that is optional (just contains some of the apps like Abiword).

So for one attempt, I took the main filesystem of WDLGO_UbuntuFocal64 (being simply 01firstrib_rootfs) and put it in my fossapup64 boot folder renamed as the replacement adrv. Alas, that ends up on top of pupXXX.sfs so overwrites vital Puppy files (I know this because I checked with cat /root/.profile and the puppy version had been overwritten), so that is no use - don't do that!

Then I tried it as a ydrv instead; nope... same result. Don't do that!

However, I already knew the following simple method works (thank goodness for this):

First of all, I repeat earlier WARNING/DISCLAIMER. This is experimental and the filesystems involved are complex so I cannot reliably tell you the 01firstrib_rootfs.sfs (30MiB) addon will not break the FossaPup64 install (but it works fine for me so far and hopefully will prove reliable). I take no responsibility, therefore, if you try this on your already working FossaPup64 install - indeed, I strongly advise you not to do that (for now at least) and instead simply make an alternative pristine install of FossaPup64 simply for this experimental dpkg/apt FirstRib_FossaPup64 mongrel purpose. Up to you, but do not blame me however you do it or whatever happens!...

(Apparently) successful method I used:

1. Either with or without the original FossaPup64 adrv sfs (I prefer without since I'm planning to use dpkg/apt to install most future packages on my Pup system), boot a pristine FossaPup64.

2. Easiest next step is to simply reboot and choose to allow a save folder to be created.

3. Once rebooted, open Rox and go to the fossapup64 boot directory (where you have previously place the FirstRIb file 01firstrib_rootfs.sfs).

4. Now either right click on 01firstrib_rootfs.sfs and select sfs-load to use it, or use Puppy Menu - System - Boot Manager to do the same thing.

5. You can now use apt to install new files. My simple tests at this stage were with the commandline apps nano and edbrowse as follows:

apt update
apt install nano
(similarly for edbrowse package later)

After accepting to install. I checked nano basically worked, which it did.

I also entered command:

apt -f install

just to double-check all had completed and worked well as far as apt/dpkg-database was concerned; all was fine.

6. You have two choices prior to shutting down. Either:

i. leave 01firstrib_rootfs.sfs loaded

That way it will be auto-mounted next time you boot the system and apt will continue to be available.

or

ii. unload it prior to shutting down. That way, 01firstrib_rootfs.sfs addon will NOT be auto-loaded on next boot so apt command will not be available (until you sfs-load 01firstrib_rootfs.sfs again). However, nano will still work since the installation files for that will have ended up in the Puppy save folder (unless you instructed the system not to save).

And that is all there is to it. You now have a FirstRib-FossaPup64 system that (optionally) doesn't need to use PPM/pkg at all from now on, but can use official Ubuntu dpkg/apt package manager (which is WeeDog philosophy by the way - simple base system plus official package manager). Ideal would be to slim down the FossaPup64 to be just sufficient to boot and provide Puppy system scripts - then the FirstRib 01firstrib_rootfs dpkg/apt used to install all the major apps via that official dependency-resolving package manager.

So could end up being quite a revolutionary development for Puppy generally, if you prefer that official Ubuntu package manager approach. Still a Puppy in every other sense of course (pupmodes all work as normal, and so on...).

If things go wrong such that apt or dpkg complain about something (which is very possible since Puppy may not contain some packages Ubuntu/Debian considers 'essential' and that apt expected) see my first post above for some resolution 'tricks'. It can always be fixed for sure, and the more you install the less possible problems to encounter since apt will always install whatever dependencies a package control file says it needs (but sometimes 'essential' packages are not in these dependency lists...).

Hope this proves useful (particularly to install some complex apps that Puppy itself otherwise struggles with). It is certainly useful for me.

Notes:

The current 01firstrib_rootfs.sfs does contain wpasupplicant (and its dependencies) that aren't needed for this addon-for-Fossapup64 situation. They shouldn't cause any problem (I think) but a waste of space. Since the methodology of creating this addon is fresh in my mind I plan, however, to produce a second WDLGO_UbuntuFocal64 that does not include these wpasupplicant packages (will still work as an independent distro for ethernet connection though...). You can use that 01firstrib_rootfs.sfs instead therefore, but existing one is fine for now (as long as you remember the DISCLAIMER above...).

It is important to understand that this WDLGO_UbuntuFocal64 01firstrib_rootfs.sfs (around 30MiB in size) is only able to be used as an addon for equivalent Puppy; that is FossaPup64. Do not try using it with any other Pup unless you want to break that other system - the files requied in the addons are not the same. Whilst the construction method (which is tricky) is fresh in my mind it is possible I could produce an equivalent WDLGO system for another Ubuntu or Debian distribution, which will contain a suitable 01firstrib_rootfs.sfs addon for that distro release variety. The files required for a Bionic variant, though similar, are unfortunately not identical so there is some work involved so no promises I'll get round to it. All such depends on the amount of feedback/interest shown and WeeDogLinux development priorities more generally, but it certainly can be done.

As an alternative to loading the addon as an sfs (which is probably the best approach at this stage) a developer could of course merge the files in permanently to their Puppy build. That would be a good method to build a brand new type of Pup that didn't include Puppy Manager at all - perhaps as an experimental branch at woof-CE, but I have nothing to do with that.

wiak

reserved.

I now have the addon working (though how safe I have no idea...). I will document how to do it (AT YOUR OWN RISK) shortly - just have one more test case I wish to examine...

reserved

Turns out that I didn't need to actually modify the FirstRib 01firstrib_rootfs.sfs. It can be used straight away as a dpkg/apt package manager addon for official Puppy FossaPup64 (but only that Pup with this one) per the how to in my second post of this thread here:

viewtopic.php?p=15623#p15623

It will be interesting to know how well it performs at installing larger apps. Good thing about apt is that when problems do arise, they can usually be resolved successfully (once you become experienced with using it), so this could be an important addon for Puppy users.

Looking forward to any feedback/results to see if worth my building versions for other Pups later. If you are going to try this do read the post notes and disclaimer carefully though - this is experimental at this stage until confirmed otherwise via general usage.

@wiak I happen to be using a Fossapup64 at this moment to construct WeeDog32-Void's and it will be no problem setting up a fresh version of it on the same drive and try to attach the firstrib_rootfs to the Fossapup64 and see if I can install ZoneMinder with all the pieces (Apache,MySQL,PHP7) from the Ubuntu iconner PPA for it.
I use the PPA to install ZoneMinder and a LHMP (Hiawatha,MySQL,PHP7) via a script for Puppy Linux Bionic and Fossa distro's. The script(s) use Pkg from @sc0ttman to add the ZM PPA and install all the parts.

I will check the instructions and see if I can actually do the complete installation of ZM into Fossapup64 using apt by attaching this to Puppy at boot and the Ubuntu PPA.

rockedge wrote: ↑Thu Jan 21, 2021 8:10 pm

I use the PPA to install ZoneMinder and a LHMP (Hiawatha,MySQL,PHP7) via a script for Puppy Linux Bionic and Fossa distro's. The script(s) use Pkg from @sc0ttman to add the ZM PPA and install all the parts.

I will check the instructions and see if I can actually do the complete installation of ZM into Fossapup64 using apt by attaching this to Puppy at boot and the Ubuntu PPA.

That will be an interesting test case and you may find apt has some (fixable) issues on such an install. Of course, with FossaPup64 as it stands, it is always going to be more 'efficient' to use Pkg when it successfully completes the task (which, admittedly, reports indicate it is very good at doing - unlike old PPA). What I'm really pointing to with the addon is that a Puppy could be designed from scratch to use an addon like 01firstrib-rootfs.sfs - i.e. a seriously stripped-down FossaPup64 (made at woof-CE level) with such an addon for installing all the actual Ubuntu-provided apps.

It has to be understood that the dpkg/apt addon system cannot know what apps are already installed in FossaPup and hence the reason would be most efficient to use most-stripped-down FossaPup as possible.

There is an issue I know about that can result in dpkg/apt failure when used as an addon for FossaPup64

Since the pup_xxxx.sfs takes precedence in the layering scheme, same-named files in there will over-write some parts of the dpkg/apt addon. For example, the addon contains full PAM adduser addgroup system so pup_xxx.sfs messes that part of the install up since it already has adduser and addgroup as symlinks to busybox (in /usr/sbin). That messes up installation of those apps that depend on full adduser/addgroup being installed - and I think Zoneminder will be included in that problem situation. The best would, as I said, to start with as cut down FossaPup64 as possible and allow the addon to do the work with its full PAM adduser system. It is a simple fact that full adduser deb package (with addgroup and dependencies) is a dependency of apt, so that is an essential.

Otherwise zoneminder should install fine but apt/dpkg will (correctly) report configuration errors since it will not be able to set up the users/groups required during installation since busybox adduser does not have the full options required.

One dpkg/apt reported error you may also come across at times is "failed to open package info file var/lib/dpkg/available for read". That's because that wasn't created by default in the firstrib_rootfs build process and I temporarily have left that file out since I don't know if my method of generating it is correct. But if you that issues occurs, you can get rid of that error by generating the 'available' file with command:

cat /var/lib/apt/lists/*_Packages >/var/lib/dpkg/available

Not sure, but you may have to also then issue command:

dpkg --configure -a

which is a useful command to get dpkg to attempt to reconfigure packages anyway.

When apt produces a list of packages that have config-type errors, one thing that I try (and 'sometimes' fixes things) is to go to /var/cache/apt where the deb packages and individually use dpkg to install the packages that have errors using:

dpkg -i --force-depends <package deb name>

That won't work with the adduser issue though, since apt can't wipe out Puppy's already in place adduser (symlink to busybox). Might be worth trying to slim down the FossaPup64 to get rid of these adduser and addgroup symlinks... Of course I'd really like to see a barebones FossaPup64 being produced such that the 01firstrib_rootfs.sfs dpkg/apt addon doesn't get wasted by pupXXXX.sfs overwriting some vital files. Putting firstrib_rootfs.sfs on higher layer to pupXXXX.sfs isn't a solution since then the addon overwrites essential puppy scripts (can't win that way...).

Other large apps that don't involve adduser group control, such as openshot-qt have installed fine via the addon for me however.

Note that if sc0ttman's Pkg program is successfully managing to install zoneminder that would be fine. However, it has to be understood that debian packaged include pre and post install scripts so though Pkg may successfully install the packages and dependencies it would perhaps silently also fail to run some of these pre and post install scripts since it is them that require full adduser and more... The difference in that case is that dpkg/apt will not pretend that all is correct - that's why you can really rely on it when it reports no further errors, which is why DebianDogs, which work as pure debian-apt-dpk-based systems rarely ever fail to install any repo available app whereas Puppy sometimes fails. Many apps have simple pre and post install debian scripts that Puppy handles correctly, but that, frankly, won't always be the case. A full WDL_Ubuntu system will also install upstream repo apps perfectly since also full Debian-system compatible.

wiak

The Pkg package manager does a good job in the script installing the Zoneminder components.
But for proof of concept and experimental research I am going ahead and attempting to do the same except with apt. I have successfully installed 01firstrib_rootfs.sfs in a stripped down Fossa64-9.0.5 (removed adrv.sfs). The apt package manager responds as shown in the screenshot:

I used a pristine Fossapup64-9.0.5 with the adrv.sfs removed and replaced with 01firstrib_rootfs.sfs.
Booted the Puppy and then used SFS-Load-on-the-fly to install 01firstrib_rootfs.sf.
Re-booted and created a save folder.
Opened a terminal and used:

apt update

Just starting to explore using it.

So, based on what I said in my last post re Puppy busybox adduser symlink etc clashing with multiuser firstrib_rootfs add-on, I unsquashed pupxxx.sfs and renamed adduser, addgroup to adduserBB (for busybox version) and so on. Remade pupxxx.sfs and tried installing Zoneminder via apt add-on with that altered pup. As I thought, this attempt got much closer. apt -f install ended up saying only two dpkg error package issues remaining to be addressed: I'm not on computer just now (android phone) but I think rsyslog and Zoneminder debs themselves remained to configure successfully. The issue still just a passwd related one - due, no doubt, to pupxxx.sfs overwriting the addon versions of /etc/passwd and similar. Fixing that would take a bit of careful work and probably involving re-making pupxxx.sfs again... I expect once rsyslog successfully configured from dpkg point of view Zoneminder install would also be happy...

Installing other big apps that don't need multiuser passwd set up would not have such dpkg error issues. Of course, final solution would be careful remaking of fossapup64 pupxxx.sfs to work out of the box with the multiuser PAM system the add-on can provide.

The problem is not dpkg/apt. In fact dpkg apt is telling the truth that the post install Debian scripts are not succeeding on standard Puppy due to passwd-related files and utilities not being correct or accessible. Puppy developers could address that most easily at the woof-ce creation stage. PPM/pkg is simply not processing ( or silently allowing errors) the Debian/Ubuntu pre and post install scripts that the deb packages provide. So a separate zoneminder build script, using PPM/pkg can fix any single-user passwd requirements. Apt install would be more correct if the pupxxx.sfs overwriting the add-on multiuser capability was addressed in new Puppy design/build.

No doubt there will be other 'overlaps', for example with /etc and /use/share hierarchy, but fixing the passwd-related clash would probably produce pretty successful/useful results even with tricky packages like Zoneminder.

I might give this a try somtime. BTW, I partly installed dpkg on upupGG+D. See post:
I sort of installed APT, dpkg and pkg on upupGG+D

However, I only updated the status file and not the lists for the package contents. For the file lists puppy unfortunately calls some of these packages by generic puppy names but in my opinion it should instead give separate file lists for each package installed. For instance glibc corresponds to more than one debian package and puppy should supply a file list for each component but it often doesn't.

Anyway, I've thought a bit about how to rectify this after the fact but have got there yet. See thread:

ppm-reduce (Short for Puppy Package Manager. Map Reduce)

s243a wrote: ↑Fri Jan 22, 2021 5:35 am

I might give this a try somtime. BTW, I partly installed dpkg on upupGG+D. See post:
I sort of installed APT, dpkg and pkg on upupGG+D

However, I only updated the status file and not the lists for the package contents. For the file lists puppy unfortunately calls some of these packages by generic puppy names but in my opinion it should instead give separate file lists for each package installed. For instance glibc corresponds to more than one debian package and puppy should supply a file list for each component but it often doesn't.

Anyway, I've thought a bit about how to rectify this after the fact but have got there yet. See thread:

ppm-reduce (Short for Puppy Package Manager. Map Reduce)

Interesting... All the best with that. It's certainly not easy to merge in full apt capability into a distro that was not designed for multiuser operation. PAM and full debian aptuser is a dependency of apt, so all these components need to be accommodated properly for everything concerning dpkg/apt to work for all use-cases (Zoneminder is really a good test case - if you can get dpkg/apt to install that on your upupGG+D, without any dpkg/apt error complaints, that would be something).

The likes of sc0ttman's Pkg program is obviously a lot of work and needs to do all sorts of conversions and manipulations behind the scenes, but at least it is not restricted by dpkg database very strict overall requirements, so simpler in that sense to at least get packages installed (without having to face dpkg complaints ever after). Like I said, the pre and post installation scripts handling, which are part of most debs, is a major issue since deb app developers can call up and need, on the underlying system for pre/post install script configuration purposes, any app that should be installed on any and every properly compatible Debian (or Ubuntu) system. That unfortunately includes PAM/passwd configuration sub-system, and busybox adduser and so on are simply not sufficient - so without full Debian essentials in Puppy (which is far more than just coreutils), Pkg can never be 'perfect' but can be enough for many and maybe even most user requirements. And, as rockedge zoneminder build script for Pups demonstrates, Pkg can be used for the download of zoneminder+dependencies and the script writer (rockedge in this case) can fix/workaround the configuration issues that would otherwise be done by the Debian pre and post installation scripts and since no dpkg/apt involved the problem of satisfying its very precise database needs is removed and not then a problem.

Useful nevertheless to have a dpkg/apt capability that works without issue up to a certain point - but it can't be perfect on an existing Puppy build. As I said, what I'd like to see would be a specially tailored Pup that allows the addon PAM/adduser dependencies (and more) to work correctly - rather than fighting against them - in other words a very basic very stripped down Pup whose filesystem will not overwrite the essential dpkg/apt system PAM (etc) dependency components that the addon can provide (or by merged in to the Puppy filesystem permanently). But maybe more complicated than it would be worth and better just to accept limitations of Pkg solution, which is pretty good anyway. Proper Puppy with full working dpkg/apt system could be made however if designed with that in mind from the outset - would just need to address the single-user limitation of the current woof-ce design. Debian is a multiuser system so dpkg/apt expect that capability when installing certain deb applications (zoneminder by default being one such).

@rockedgeI seem to almost have zoneminder installed via apt (using that very slightly modified puppy_fossapup64_9.5.sfs; The Pup's busybox versions of adduser, addgroup and similar definitely the main problem in non-modified puppy sfs attempt - dpkg post-processing scripts definitely need full versions of pretty much all utils). Only error being with final zoneminder package itself - on other system now, but dpkg error complaint was something about not knowing user:group www-data:root. Unfortunately, after reading something via google I then tried installing nginx since apparently that install creates www-data, but actually problem became worse then...

To be frank, I messed around with adduser and addgroup and accepted lots of changes apt proposed and ended up with rsyslog also installed fine and only final zoneminder package still giving dpkg www-data:root complaint. I did finally get zoneminder install successfully accepted but that flipping nginx-core was still there and giving dpkg errors and I could get rid of the package! Next time I'm trying without the, I'm sure, unnecessary nginx install, but any help re adding user/group www-data:root correctly would be appreciated...

@rockedgeSo looks like I have successfully installed zoneminder, using the slightly modified puppy_fossapup64_9.5.sfs I described in above posts, but of course I now need zoneminder expert to succeed similarly and configure the now installed zoneminder

Anyway, seems to me therefore this dpkg/apt 01firstrib_rootfs.sfs addon can be made to work really quite successfully simply by slight modification to Puppy, though /etc/passwd and /etc/group issues do need addressed properly. Yes, involved a lot of fiddling around so these multiuser passwd config issues need addressed more carefully to avoid the stress!

Basically (may have forgotten some details):

Here is how I undertook the zoneminder install - a bit hairy, but oh well...:

EDIT3: Important not to also include the optional FossaPup64 adrv when doing the following or you will need to modify that too and double the work per my EDIT2 note at foot of this post... (but fine to include that adrv as a ydrv per my later use of a second addon per later descriptions)

[EDIT4 - 01Feb2021: None of this section is needed anymore since all is done by the new double-sfs addons. 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

(Actually, per my later posts, I actually now do the above differently in the sense that I use a new adrv that goes in layer above puppy_focalpup64_9.5.sfs to overwrite the original with these new adduser-related full programs. The original adrv, I rename to use as a ydrv instead - otherwise it would overwrite my alterations since adrv goes in higher layer than ydrv)

As simple as that - didn't change anything else in puppy_fossapup64_9.5.sfs I think (though no doubt some other alterations could also help avoid dpkg/apt issues more generally).

then booted with that new (resquashed via mksquashfs command) puppy_fossapup64_9.5.sfs in place with a new pristine install.

then set up the internet connection for my machine and rebooted and created save file

Just accepted defaults for any questions asked and didn't set any passwords for these users. end-of-EDIT4]

Once rebooted, I used sfs-load to load the 01firstrib_rootfs.sfs (dpkg/apt addon sfs) that I had previously placed in my fossapup64 bootfrom directory.

And then, after importantly checking my timezone and system clock were set up properly I issued command in terminal (I'll do this again after adding new zoneminder repo later too):

apt update

I did get an error about focal-security not valid yet for 1h 13min 7s; maybe better in 1h 13min 7s? (I don't know)

If you want to be able to use the likes of apt-add-repository command you'd need to first apt install the package "software-properties-common", I believe, but that is pretty big so I'm avoiding that for now. However, if repo public key is needed I think something like this is the way without apt-add-repository command (you won't need this if not adding new repo maybe - I'm adding zoneminder repo of issac connor per rockedge's advice):

apt-key adv --keyserver keyserver.ubuntu.com --recv-keys <key> # will check later
(but would first need to install gnupg for that to work anyway) but maybe can tell apt to not bother if no key # again I'll have to check how

EDIT 11Feb2021: The zoneminder related stuff below only seemed to work for amd64 version of zoneminder (i.e. Isaac Connor doesn't seem to have produced a 1386 build recently?).

Okay, I just did:

apt install gnupg

followed by isaac connor (zoneminder) key install with:

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

NOTE: It seems above brings the big common issue of apt installing systemd files over the top of Puppy scripts. I haven't investigated solution to that. I suspect it can't be prevented easily so best might be for 'someone' familiar with Puppy scripts to write a fixitback after using apt shell script, which I haven't done.

At this stage, I now prepared for the zoneminder install by doing the adduser/group stuff required for zoneminder early to avoid most all of the (nevertheless informative) dpkg error messages that otherwise occur during the apt zoneminder install:

addgroup syslog
adduser adm
usermod -a -G syslog adm
adduser www-data

and I also at this stage (important) removed that duplicate tty: x :2 /etc/group original FossaPup apparent misconfiguration, leaving in the tty:109:root,spot,finn line (original FossaPup64 had two tty entries in /etc/group, which seems very wrong and was reported by dpkg/apt in previous install zoneminder attempts). For example can use:

leafpad /etc/group

to remove the tty: x :2

Then, per rockedge's advice I appended the following to /etc/apt/sources.list:

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

Followed by commands:

NOTE: Do make sure the distro system date/time is correct for your timezone before doing this - apt needs that...

apt update

to update the repo data and then:

cat /var/lib/apt/lists/*_Packages >/var/lib/dpkg/available

to create a working dpkg/available file (since seen errors previously when not having that...)

Running command:

apt -f install

suggested all was fine at this stage. Good.

apt install zoneminder

Accepted all the defaults when asked during the install.
Now only got one dpkg error reported, and that just a simple configuration issue that couldn't be done till after, so did:

dpkg --configure -a

and no more errors were reported. All Good. Entering:

apt -f install

said all fine...

Not really relevant any more since I'm now using new adrv and moving old adrv to ydrv but keeping in the following note just as a historical reminder of important issue I came across: EDIT2: Turns out better not to use the adrv because it contains duplicate (but why???! seems unnecessay and problematic here...) of adduser, addgroup etc symlinks to busybox which are overlaying the full versions in the 01firstrib_rootfs.sfs addon and thus messing things up...

As I said, okay to use the adrv now (but as a ydrv) and one of the two dpkg/apt addons becomes new adrv.

Zoneminder is the big test I use on systems, measuring the degree of difficulty and hack steps taken to get the entire ZM and LAMP packages to install using the distro's package manager. Usually in the recent past I had to track down libraries and PERL modules and PHP modules and manually get a mysql server installed and working. Then compile Zoneminder.
Also I installed geany using :

pkg add geany

while ZM was installing in another terminal! Totally worked!

My attempt with the hybrid Fossapup64 to install ZM was very close to success. I had (out of experience dealing with installing users) changed the the symlink names of adduser, addgroup, ect. to adduserBB before I layered in 01firstrib_rootfs.sfs.
Very important difference is I manually added these 2 lines to the bottom of /etc/apt/sources.list

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

I then also did an apt update and the this added the PPA for the master branch of Zoneminder to the repos.
the current master of ZM stands at version 1.35.16 with significant improvements over versions 1.32.+

The errors I am encountering seem to revolve mostly around

 systemd
 systemd-timesyncd

Right now I am comparing what @wiak did to my steps to refine what I'm doing and get to the same point.
Next step will be to check the LAMP and Zoneminder configurations as installed and see what needs to be adjusted for the whole thing to work.

It is really exciting and I feel like it is close to being a solid advancement in knowledge of using multiple package managers in the same OS.

rockedge wrote: ↑Fri Jan 22, 2021 1:50 pm

The errors I am encountering seem to revolve mostly around

Code: Select all

 systemd
 systemd-timesyncd

Ah yes, you are almost there! That's pretty much the last error that needed resolved I think and I managed to fix it (but need to try again to remember the details - that's fine, I plan to try again anyway since want to test something else related).

I've also been thinking about the more general issue involved of having to modify puppy_xxx.sfs. My earlier experiments suggested that adrv and ydrv both end up on top of puppy_xxx.sfs so I should, for example be able to simple create a small second addon that creates the adduserBB alternative and forcing in the full required adduser and so on. If that works won't need to modify puppy_xxx.sfs, which would obviously be a big improvement to the scheme (in fact could make it pretty much 'perfect' with some experience of what needs configured via the ydrv. Only thing I don't know till further test is which is higher in the layering structure - adrv or ydrv. I'm hoping its ydrv, otherwise, in the case of FossaPup64 users would have to not use the current optional adrv (since it also contains the busybox version adduser symlinks as I said). Pity Puppy design didn't allow for more flexible layer arrangements (and more of them) but enough to work with hopefully.

I'll get back with extra help notes re the fix for these systemd-related dpkg errors, which I definitely found answer for in my last attempt.

By the way, I'll want to be moving these posts re the addon for Puppy to the other thread I originally started concerning that special use of the WDLGO_UbuntuFocal64 01firstrib_rootfs since this thread is supposed to concentrate on WDLGO_UbuntuFocal64 itself. It was my fault for pursuing the addon stuff on same thread...

EDIT: First attempt putting the full adduser and so on in a ydrv didn't work, but that seems because ydrv apparently fits in a lower layer than adrv (both being above puppy_xxx.sfs though). Anyway... I'll rename the existing adrv to ydrv and the ydrv to adrv. Easy enough to do that of course but far better if didn't have to... Just a pity that Puppy doesn't have a more flexible layer naming scheme (such as WeeDogLinux 00 to 99, which is so much more useful in practice and particularly for rollback of changes use).

wiak

wiak wrote: ↑Fri Jan 22, 2021 9:45 pm

... Just a pity that Puppy doesn't have a more flexible layer naming scheme (such as WeeDogLinux 00 to 99, which is so much more useful in practice and particularly for rollback of changes use).

wiak

On could write a script to patch initrd of they wanted to use a different layering system. That said one doesn't need to write such a script for this project.

s243a wrote: ↑Fri Jan 22, 2021 11:02 pm

wiak wrote: ↑Fri Jan 22, 2021 9:45 pm

... Just a pity that Puppy doesn't have a more flexible layer naming scheme (such as WeeDogLinux 00 to 99, which is so much more useful in practice and particularly for rollback of changes use).

wiak

On could write a script to patch initrd of they wanted to use a different layering system. That said one doesn't need to write such a script for this project.

Well, I'm not suggesting Puppy 'needs' a different layering system. No Puppy Developer at woof-CE that I know of is wanting to incorporate apt/dpkg officially, so my comments regarding the current layering system is simply from my perspective of trying to add something I'd like to have myself. There may be other reasons why Puppy devs like the adrv, fdrv, ydrv and so-on layering scheme, and that's fine, or perhaps it is just a historical result of original Puppy design, which was revolutionary in many ways so long ago in 2005. It's not necessary to change that layering system if everyone using Puppy is fine with it - it works as intended. My comments, aside from my own needs/interests are also an expression of how I personally would like to see Puppy developed. But since Puppy claims to be a 'do-ocracy' if I really wanted to develop a 'new' Pup design, I should do it, but I'm not planning to so my comments re layering are only concerned with what I am trying to achieve with this addon. It might be interesting to write an alternative initrd/init though, but too many things to do already, and WeeDogLinux initrd/init has already been demonstrated to work with stock Puppy root filesystem anyway should I need that overlayfs layering technique/methodology difference.

The only reason I posted about this addon for FossaPup64 capability is that it struck me that, the way I had made it, the 01firstrib_rootfs.sfs could be used for that purpose (with at least some likely success) so I thought I'd bring that idea to the attention of the Puppy community and try and develop it slightly to make it work for that purpose better. I use WeeDog_Arch64 myself, and various other WeeDogLinux variants now and then, but continue to enjoy providing some Puppy support when I have something that might be of interest to some.

wiak wrote: ↑Fri Jan 22, 2021 11:37 pm

s243a wrote: ↑Fri Jan 22, 2021 11:02 pm

wiak wrote: ↑Fri Jan 22, 2021 9:45 pm

... Just a pity that Puppy doesn't have a more flexible layer naming scheme (such as WeeDogLinux 00 to 99, which is so much more useful in practice and particularly for rollback of changes use).

wiak

On could write a script to patch initrd of they wanted to use a different layering system. That said one doesn't need to write such a script for this project.

Well, I'm not suggesting Puppy 'needs' a different layering system. No Puppy Developer at woof-CE that I know of is wanting to incorporate apt/dpkg officially, so my comments regarding the current layering system is simply from my perspective of trying to add something I'd like to have myself. There may be other reasons why Puppy devs like the adrv, fdrv, ydrv and so-on layering scheme, and that's fine, or perhaps it is just a historical result of original Puppy design, which was revolutionary in many ways so long ago in 2005.

Nostalgia is powerful. We are allowed to like things because of some sacred puppy ritual. If we named the layers your way, then we would need to do more drastic modifications to the original BarryK documentation of "How Puppy Works". That said rituals aren't set in stone if people decide there is a better way. Not everyone likes puppies Layer Naming system. For instance Scottmann wote the following:

And speaking of ADRV etc... I'm just gonna put it out there: "adrv", "zdrv", "fdrv"? ....Really?!

They should be called something helpful, not cryptic and weird..

Like

Code: Select all

puppy-9.5.sfs
kernel-5.4.33.sfs      (?? ..meant be be zdrv)
firmware.sfs
x-puppy-9.5.sfs         (just xinitrc, startx, xlibs, xorg+libs, gtk, PPM/Pkg GUI ... not much else) 

( ^ bear in mind I don't actually know if the zdrv is the actual kernel, or modules for it or what .. but you get the idea)

If x-puppy-9.5.sfs is present, we mount..

..doing it like that also opens up the potential for optional extra SFS files named like:

Code: Select all

x-puppy-9.5-jwm.sfs     (jwm, rox, etc) 
x-puppy-9.5-xfce.sfs
x-puppy-9.5-lxde-1.0.sfs
x-puppy-9.5-lxde-1.1.sfs (a fixed on that comes later, easily swapped in)

...
..if x-puppy-9.5.sfs was mounted, we offer to mount one of the x-puppy-[jwm|xfce|ldxe|mate|etc] at boot..

..and then, if using X, we mount all "x-puppy-apps*" that we find...

Code: Select all

x-puppy-9.5-apps.sfs           # the "adrv" ... small gtk apps, gnumeric etc
x-puppy-9.5-apps-gnome.sfs           # apps that need gnome libs (...libs included in SFS)
x-puppy-9.5-apps-elementary.sfs    # apps that need elementary libs (...libs included in SFS) 

...
This way people

know what each SFS is actually for, at a glance, and without having to trawl through a dozen old forum posts..
can get a CLI only puppy by just NOT using any x-puppy* SFS files
can swap desktop environments simply by changing an SFS and restart X
can update the base system (puppy-9.5.sfs) all on its own, etc
can swap and combine different set or collections of desktop apps very easily
That's how you improve puppy modularity.

The benefit of this is that

we hardly need to touch the PPM or Pkg, mostly updating the init script, and building the relevant SFS files.. Most would of course be optional extras..
sane version numbers and filenames everywhere ... consistent, each file clearly labeled with the pup it's for.
If Pkg built the SFS files, then all packages inside those SFS files with have their own ~/.packages/*.files, and will be counted as an installed package - not some file in the main fs that "comes from god knows where"
Bear in mind you can still swap the word "puppy" in all the above examples with stuff like "fossapup", "dpupbuster" and so on, and it still applies/works..

https://github.com/puppylinux-woof-CE/w ... -729885751

I'm nor saying that Scott's suggestion is better or worse than the approach taken on Weedog. I do like the do-ocracy principle. I would prefer to see people experiment first and see what catches on before an alternative layering system is incorporated into woof-CE by default. Woof-CE could though have separate branches or have parameters that one could specify when building a puppy to use a different (non-default) layering approach.

It's not necessary to change that layering system if everyone using Puppy is fine with it - it works as intended.

agreed

My comments, aside from my own needs/interests are also an expression of how I personally would like to see Puppy developed. But since Puppy claims to be a 'do-ocracy' if I really wanted to develop a 'new' Pup design, I should do it, but I'm not planning to so my comments re layering are only concerned with what I am trying to achieve with this addon.

It might be interesting to write an alternative initrd/init though, but too many things to do already, and WeeDogLinux initrd/init has already been demonstrated to work with stock Puppy root filesystem anyway should I need that overlayfs layering technique/methodology difference.

For sure. We focus on what interests us. An alternative layering system could also be an add-on because all one would need to do is replace initrd. That said, I'm not asking anyone to do this because we all only have time to do so much.

The only reason I posted about this addon for FossaPup64 capability is that it struck me that, the way I had made it, the 01firstrib_rootfs.sfs could be used for that purpose (with at least some likely success) so I thought I'd bring that idea to the attention of the Puppy community and try and develop it slightly to make it work for that purpose better. I use WeeDog_Arch64 myself, and various other WeeDogLinux variants now and then, but continue to enjoy providing some Puppy support when I have something that might be of interest to some.

Lots of people have asked about adding apt/dpkg support to puppy and in many cases pkg suffices but sometimes it doesn't. I was not able to get libreoffice working on UpupGG+D with either pkg or the ppm. The reason likely being that neither of these tools are good at resolving which version of a package to use if there are multiple versions or multiple alternatives. UpupGG+D has the issue of duplication between debain and ubuntu repos with sometimes slightly different veresions. Also the debian/ubuntu build of libreoffice depends on java which has multiple alternatives and the official puppy tools (ppm or pkg) fail at even selecting a consistent version of java.

In some ways this doesn't matter because this forum has lots of helpful members that provide workarounds for popular packages that are often newer than what is available via the repos. For instance I found a pet (see post), which let me install LibreOffice-6.2.8_en-US_xz.pet, which was newer than the version available via the package manager. This pet did not depend on java and as a consequence, I suspect that it is likely missing some java integration features related to scripting. So even though the version available via the package manager is older there still might be some advantages related to it.

More importantly though, the java integration features lets me test how well java is working and official 64bit java binaries are no longer being released even though they are available via the debian repos. I was actually thinking about doing exactly what you did by releasing a apt/dpkg sfs addon for puppy. However, we all only have so much time and I've been focused more on sandboxing lately.

The two things aren't unrelated though. I can base the sfs addon on the sandboxes top layer. I was thinking of building such sfs files for java, libreoffice and apt/dpkg. The layering issues are problematic when important things are being blocked. There are of course workarounds. I will discuss more about this later.

@rockedge: I renamed adrv to ydrv and made a new adrv sfs just with the full adduser-related commands in /usr/sbin and /bin. Then went through the procedure I described up above at:

viewtopic.php?p=15747#p15747

(fixed the usermod command to use -G, which is what I actually used first time of course).

Only difference is that this time I used leafpad to edit /etc/group and left in the tty:109:root,spot,finn line and removed the other one which was tty: x :2 and also I followed your advice and first appended to /etc/apt/sources.list:

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

All went as before (accepted defaults for all apt questions re mime types and so on - I've no idea if that is the optimum but just concentrating on successful install for now since I know nothing about zoneminder needs/setup)

For some reason or other the error re systemd and systemd-timesyncd didn't occur as an error so can't tell you how I fixed that first time... but if no error nothing to fix, so that is good. It might have been this part where, as I say, I accidentally put -g rather than -G in instructions in that earlier post:

adduser adm
usermod -a -G syslog adm

Finally, after the:

adduser www-data
dpkg --configure -a

zoneminder install successfully completed.

Of course, if I had configured these user and groups prior to trying the apt install zoneminder there probably would be no apt/dpkg error reports at all - so apt/dpkg just doing a good job telling me what is missing and preventing it completing the configuration stage of installation (being needed by the post install Debian deb package scripts). Anyway, after fixing such reported errors, the 'dpkg --configure -a' command instructs dpkg to redo all the configurations and thus remove the error reports once satisfied.

What's more is that when I then installed lxterminal with apt install lxterminal, worked first time with no errors. Then I did apt install geany, and again installed no errors. So thus far it seems like it all works pretty fine - only issue being that occasionally the installer has to fix passwd/group additions per apt/dpkg error notices. Most apps don't involve that so they should simply install...

So looks like now have a successful relatively small sfs dpkg/apt addon for FocalPup64 (and will be smaller still when I publish the version of WDLGO_UbuntuFocal64 distro for ethernet connection only - i.e. the FossaPup64 addon doesn't itself need the wpasupplicant and its dependencies and hence will be even smaller). I'll wait to see if anyone needs a Bionic variant - a bit of work to create new version since different distros have some dependency differences for apt/dpkg correct operation, but I have already done some work on WDLGO_UbuntuBionic32 (or 64) so not a large amount of extra work for me at all.

Pity I had to rename adrv to ydrv but needed the full adduser-related passwd stuff to overwrite anything underneath and adrv appears at layer above ydrv.

What I'll do now is publish this addon for general use as two sfs files:

one the new adrv file containing only the /usr/sbin and /bin adduser-related passwd files, and the other the 01firstrib_rootfs.sfs from WDLGO_UbuntuFocal64 (I'll name them differently), which contains the carefully crafted dpkg/apt system and its required dependencies. I'll upload these to usual place and publish the simple fetch script per my usual practice.

One extra thing I'll do is put an overwrite for /etc/group into that new adrv addon, which removes the error duplicate tty in the existing puppy_fossapup64_9.5.sfs. If the mistake gets rectified upstream that overwrite won't be needed but I'll probably leave it in so will work with those that use current FossaPup64 since harmless overwrite anyway. Thereafter, if I find any other improvements during practical use I will modify the new adrv to incorporate any such fixes/improvements. Looking good...

NOTE: I haven't tried rebooting the system yet. I hope I do not find myself now locked out of the system on reboot because of any of the changes I have made. Before rebooting I'm going to have a quick look at the Puppy system files to see if I can see how rebooting and autologin works with it (never having studied it before: inittab, /bin/plogin, /bin/autologin and so on) or maybe I'll just cross my fingers and try it... I will report back with result once I've tried the reboot (my main concern is with that duplicate tty error that I resolved - in case it was there for some weird purpose, which I doubt, but also need to check the new multiuser PAM/passwd system has caused no ill effects; Puppy now a proper multiuser system if all is well...).

wiak

Well, this is looking very promising...

But there is a major hurdle to jump at the moment.

As I feared, the plogin/autologin is not working after installing zoneminder. I don't think it is the dpkg/apt addon itself that causes the issue (might be, but I doubt it). Rather I think it is simply that Debian version of zoneminder installs some systemd files that mess up the underlying Puppy SysVinit system operation (might not be any such systemd files of course, just a suspicion I have (maybe the dbus or rsyslog new scripts in init.d), and likely to be something Puppy-critical getting overwritten by some zoneminder deb installed file anyway). In particular, on reboot I noticed some warning message about systemd not operating (or something - I don't know the detail) and the system refused to shutdown until I did a reboot -f. Thereafter when I rebooted it did not autologin but rather stopped at a login prompt and password 'root' did not work (so ended up locked out of accessing the system).

In summary, I think the dpkg/apt scheme is working well, but I think it is a matter of 'be careful what you install because Debian wants your system to be systemd so its official deb packages post-install scripts can mess up Puppy system...

More testing required to see if there is a way of fixing the Puppy files after the zoneminder install. Of course there also is a way of fixing such matters, but I don't know Puppy system scripts so could well be a difficult one for me to fix. Someone who does know Puppy system script operation inside out, who follow the dpkg/apt sfs zoneminder install instructions might well be able to work out where the problem has occurred and fix it very easily and quickly. I think that is not really something for me to concern myself with, except to say if I do find it myself I will of course address that matter. Otherwise please experiment with the addon as an 'experiment' but I strongly advise you to only do so on a special new install of FossaPup64 made especially for this experimental dpkg/apt purpose, and see if all remains well for apt install of most apps (such as lxterminal, geany, and so on) bearing in mind that larger app installs that bring in systemd components (correctly per Debian's system design) may well break Puppy SysVinit operation and thus need to be avoided - there may be no way to protect Puppy from Debian intended design when using apt, so it is important to be aware of that.

As I said, I will prepare and publish the two addons (substiture adrv and the main dpkg/apt sfs addon for anyone interested in using/experimenting with it. And I will move these posts concerning it to the thread I originally started under 'Puppy Projects' concerning this matter because the thread here is not about it really but rather about WeeDogLinux new distro WDLGO_UbuntuFocal64, which uses the same system, but being a WeeDogLinux is fine to be turned into a normal systemd Ubuntu system (will be some care required doing that too of course, but that is another matter and the one I myself am concerned to address).

Will publish the addons 'As Is' in the next day or two probably following some last checks and tests. If any who experiment with this know or discover the Puppy-related shutdown/re-login issue that that zoneminder install ends up causing (which is not itself probably to do with the addons themselves) that will be good for others using the addon of course. In other words, don't wait on me to 'fix' it - I'm not a Puppy dev (I have not studied its init, or rc.shutdown or rc.sysinit, and I don't even know, any more, what the different PUPMODES are used for) so am unlikely to spend much time looking into that. (I suspect it is a simple issue to resolve, and perhaps I will with luck find its resolution quickly, but... I am concerned to get back to WDLGO_UbuntuFocal64 since this dpkg/apt addon for FossaPup was just a digression for me in terms of WeeDogLinux dev priority; nevertheless, I hope the addon work has and continues to prove useful to those interested in using apt with Puppy).

Clearly, some others have ideas/schemes for implementing dpkg/apt into Puppy (and there have been some who have already done so in the past). It would certainly be interesting if they could try their scheme to install zoneminder - I suspect the result will be the same when installed properly via apt/dpkg because of the systemd components that clearly get included in the install. So my WARNING/DISCLAIMER includes the advice to be careful if using apt to install programs in Puppy - some packages may (by apt correct design) install components that will break Puppy normal operation - best way out of that would be a specially designed Puppy that was happy to accept these install components as part of its normal operation, but that is a different Puppy than that of present design.

wiak

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.

Late though it is, I couldn't resist and did a rebuild and reinstall of zoneminder. That /sbin/init was indeed the issue for reboot. However, mystery... on the rebuild it didn't occur and I have zoneminder successfully installed (assuming it works, which rockedge will have to test), but no shutdown issue and no change to /sbin/init (which is still using Puppy /sbin/init). Don't know why no problem this time... I did one thing different though:

after apt update, but prior to apt install zoneminder, I did the adduser configurations first. That is:

addgroup syslog
adduser adm
usermod -a -G syslog adm
adduser www-data

and I also removed that duplicate tty: x : x /etc/group original FossaPup apparent misconfiguration.

Just accepted defaults for any questions asked and didn't set any passwords for these users.

Just check the original install post for overall details
viewtopic.php?p=15747#p15747
(I was using the standard puppy_fossapup64_9.5.sfs though (not a modified one) but instead using the original adrv as a ydrv and a new sfs with the full adduser-related parts made into an adrv (so no mod to the actual Pup required).

Reason I did these adduser/group items early was to avoid the annoying dpkg errors that otherwise appear during install. Result was that the 'apt install zoneminder' part went very smoothly indeed. One dpkg error at the end and fixing that just needed me to enter: dpkg --configure -a

I will have to retry tomorrow to double check that with that order there really is not shutdown or systemd-related /sbin/init overwrite, but looks 'ALL GOOD' right now...

As for why this all worked including no issues on reboot. Who knows. I can only conjecture at this stage... perhaps by doing the zoneminder-required adduser and so on stuff prior to the actual install the post install scripts did not modify /sbin/init to point to systemd in an attempt to fix something or other(?!). Certainly it happened in previous attempt, but not this time. A bit weird, but I'm fine with that - just hope next rebuilt confirms no further issues.

Once I've confirmed the current All Good status, I just need to package the two addons (main one for layer below puppy_xxx.sfs via sfs-load and one small sfs for layer above it (the new adrv to overwrite the busybox versions of the adduser-related utils and fix the /etc/group duplicate tty error).

EDIT: Just built it again from scratch pristine FossaPup64 and I can confirm the zoneminder install all went fine per the (revised) earlier howto post at: viewtopic.php?p=15747#p15747

Perhaps as, if not more important than the apt/dpkg capability is that this addon brings full PAM multiuser capability to Puppy. That is not important to traditional Puppy users maybe, but it is a hugely important enhancement - personally I was never able to use Puppy much in tertiary education because most Linux instruction for professional use concerned multiuser user/group permission setups and so on for webservers and similar.

So I'm going to go back to my summer holidays very soon!... Do you want a Bionic version by the way - might have time before I put my feet up? Some of the files required to build the apt/dpkg addon for that are very different but I know the differences already.

wiak

Yes! A Bionic version as well! I find Zoneminder runs really well on Bionic and seems a bit more refined running in Bionic as Focal picks up speed.

I also successfully installed ZM! Also found doing the adduser steps early smoothed out the install. I use this tool I picked up along the way with is a ROXAPP called SFS-Edit. Great program that makes editing an SFS file a 2 click function. I can share this tool, I found it long ago on the old forum and now it is really helpful.

@wiak You might find this tool useful as well

Main part now to actually get ZM running.....I have successfully used apt to install the web server Apache2 and PHP7.
Problem now is I can not get the MySQL or mariadb server to start! Errors in the setup which I've run into before (long time ago) are preventing a clean start.

Without the Apache, PHP 7, mysql database Zoneminder will not fully function.

At one time the Zoneminder installation handled installing and configuring the LAMP (or NGINX) automatically but I did not see any of that happening on my attempts with apt. So I restarted and first did the SFS edit, then installed Apache2, PHP7 then the mysql server. Here I am having trouble initializing the mysql tables to finish a proper install.

In woof-next dummy packages are installed to prevent apt/dpkg from installing unwanted packages and to prevent it complaining about missing dependencies.

apt/dpkg might also have options to blacklost packages.

@s243a Good point. Will have to look into that closer.

I am close to having a fully functioning Zoneminder and LAMP all installed via apt into this Fossapup64. I also was able to install geany, viewnior, lxterminal plus mtpaint and mtpaint's screenshot library using apt and all 3 are working as expected!

To begin testing functionality I added a php file in /var/www/html/info.php

<?php
 phpinfo();
?>

and called a page request in palemoon (which I copied over from another frugally installed Fossapup) :

http://localhost/info.php

which shows Apache and PHP 7 are functioning and what modules are installed and configured

I ensured then that the apache2 zoneminder.conf is symlinked in /etc/apache2/conf-enabled

and called a browser page request

http://localhost/zm

But because the mysql server is not starting and running, Zoneminder can't connect to it's all important database (which is not configured!).

So far apt is working well and I actually used Pkg to install another component which worked as well!
The possibilities opening up are astounding

As far as apt installing the mysql-server and getting this running is the current hurdle to overcome.

So close!

I will set up a new Fossa install to keep this one I'm close to success with but do the install procedure again using the latest technology.

Sorry that I can't help with mysql set up since I have no experience with that. But I will build Bionic versions of the dpkg/apt addon (32bit and 64bit) since the facility could be hugely useful to expand Puppy into handling most anything.

You can check what packages apt has installed with the command:

apt list --installed

Thanks for the sfs edit package, by the way; I've actually used it before since Fred includes a version in DebianDog (assuming it is the same program).

Success!!

Was able to finally get the mysql-server initialized and running and was able to install phpmyadmin and create the zm database and import zm_create.sql.
Crazy is I reached a point where I thought I'd just start over on a fresh system so as a last ditch effort I used the PPM to try to install mysql-server. PPM reported most of the dependencies were missing in the repo, then suddenly began to install mysql-server-core and it's components which were missing. I then in a terminal ran:

mysqld --initialize-insecure --user=mysql

which worked!
It seems the first part of mysql-server was installed with apt and finished it with PPM. There are some small modifications to the config files and installed php-mbstring with apt (for phpmyadmin)

I also did:

mkdir -p /var/run/zm
chown -R www-data /etc/zm
chown -R www-data /var/cache/zoneminder
chown -R www-data /var/log/zm
chown -R www-data /var/run/zm

then :

zmupdate.pl -f
zmpkg.pl status
zmpkg.pl start

Here is ZM with a local web camera configured and enabled.

proof of concept of installing a functioning LAMP and Zoneminder package with apt on Puppy Linux Fossa64-9.0.5 provided with a PAM and the apt package manager as an SFS plugin.