Continued Success with apt_sfs_load_fossa_amd64 SFS Plugin

[rockedge]

@wiak As shown in the screenshot attachment the add on apt_sfs_load_fossa_amd64.sfs continues to operate error free. The system was just completely upgraded with

Code: Select all

apt update
apt upgrade

which also upgraded the ZoneMinder installation to the latest master build version 1.37.13 and is shown running in zmNinja which is a mobile/desktop interface application for ZM.

Screenshot(13).png (204 KiB) Viewed 1513 times

This SFS plugin is developed for experimentation by wiak that brings APT package manager capabilities to Fossapup64 and adds PAM support.

With careful juggling I am able to use 3 different package managers in this Fossapup64. APT, PKG and PPM will all successfully install packages, APT and either of the other Puppy Linux package managers DO NOT communicate. That is APT does not "know" what PPM or PKG-cli have installed or uninstalled and vise versa.

Zoneminder, Apache2, MySQL and PHP 7.4 were all installed and are maintained with APT. The system upgrades are done with APT but this may change some key Puppy Linux components that reboot or shutdown the system properly using busybox. A small script and a symlink need to be restored to the Puppy versions with a script. Although this is only on those occasions after full system upgrades which the systemd mechanism is effected.

The systemd mechanism is NOT implemented but some components exist to make a pseudo systemd that assists in making APT operate smoothly in some cases. (a spoof)

Most of the time I am only doing pinpoint update/upgrades to the system, which has now been working steadily for over a year stable and supporting one of the best functioning and latest version of ZoneMinder I have at this time available.

I would say the apt_sfs_load_fossa_amd64.sfs (and it's accompanying adrv_fossapup64_9.0.5.sfs). add-on despite not really being a production ready offering, that it's performance is outstanding. Really makes this Fossapup64 a fun system to work with and play on.

[dimkr]

apt in Puppy is great! woof-CE support for apt is in very good shape now, and it's so much better than PPM and pkg (IMHO).

And https://github.com/puppylinux-woof-CE/woof-CE/pull/3044 will make Puppy even more Ubuntu-compatible, enough to make podman work (for spot too). A working container runtime means you can always podman run -p an Alpine/Debian/Ubuntu/whatever container with servers like Apache, and don't have to convert a Puppy installation into a server.

[mikewalsh]

@rockedge :-

Erik, where do we find these 'add-ons' for Fossapup64? Do you have a link, please?

Mike.

[rockedge]

@dimkr There looks to be huge advancements with the work you've done on bringing the package management to a new level of compatibility with the upstream Ubuntu / Debian repos by adding the full functioning APT.

I am looking forward to building such a woof-CE Puppy Linux very soon. I just need a bit of guidance to insure I am building correctly with all the new and other improved features included!

I have traditionally used fresh builds made with woof-CE, with either Bionic or Fossa and calling them for example like this: Bionic64-CE or Fossapup64-CE with the "CE" of course denoting the "community edition" concatenation.

@mikewalsh In a short time I'll post a link so you can get both SFS files.
The trick is replace the stock adrv SFS with the customized version and boot the fresh Fossapup64. Then using SFS-Load-on-the-fly mechanism load the apt_sfs_load_fossa_amd64 SFS and then in a terminal try : apt update

There is the issue of on certain upgrades that 2 changes are made that replace the Puppy Linux symlink and script that need busybox with a script and symlink pointing to systemd. To solve this I made and added to the rootfs of Fossapup64 backup copies of those like this:
/sbin/poweroff-puppy which is a script using busybox
/sbin/reboot-puppy which is a symlink to the Puppy version of poweroff

the script restore-puppy-boot.sh:

Code: Select all

#!/bin/sh
rm /sbin/init
cp /sbin/init-puppy /sbin/init

rm /sbin/poweroff
cp /sbin/poweroff-puppy /sbin/poweroff

rm /sbin/reboot
ln -s /sbin/poweroff /sbin/reboot
gxmessage Set for Puppy Poweroff -font 16 -center -timeout 4

Then when it looks like the command apt upgrade will run better thinking systemd is in charge:

Code: Select all

#!/bin/sh
rm /sbin/init
cp /sbin/init-systemd /sbin/init

rm /sbin/poweroff
cp /sbin/poweroff-systemd /sbin/poweroff

rm /sbin/reboot
cp /sbin/rebooy-systemd /sbin/reboot

I then run the apt update then the apt upgrade commands then again use the first script to restore the Puppy versions.

If the Puppy Linux poweroff script and reboot sysmlink are not in place, the system will not shutdown or reboot.
As soon as the Puppy stuff is again in place the normal operation resumes.

Sounds a bit crazy but it is more of a proof of concept which @dimkr has now made into a reality.

One gets spoiled quickly when it works.

[dimkr]

I just need a bit of guidance to insure I am building correctly with all the new and other improved features included!

Try these two:

https://github.com/puppylinux-woof-CE/w ... -on-GitHub
https://github.com/puppylinux-woof-CE/w ... ibutor-101

The woof-distro/x86_64/ubuntu/jammy64 is a good place to start, it has all the goodies. The bionic64 and focal64 configurations are mostly static, they receive only vital woof-CE features (for example, PulseAudio support). But it shouldn't be super hard to clean up these two and build something very similar to the jammy64 configuration, but without anything Wayland-related, without PipeWire, etc'.

[mikeslr]

@rockedge :-

Erik, where do we find these 'add-ons' for Fossapup64? Do you have a link, please?

Mike.

Mike, I think this is what you're looking for, viewtopic.php?p=49341#p49341.

I haven't tried to make use of those yet. The state of my ignorance would only lead to confusion; my own and perhaps others. I'll wait for someone to 'paint the fence.'

A couple of thoughts, however. If apt proves to be as good as dimkr feels and rockedge's experience suggests, (a) it should be built into future 'ubuntu' & 'debian' Puppys*/** -- a woof project. And (b) Even before that should be the primary means to supplement such Puppys' applications.
pkg-cli and PPM can still be used. The problem that apt will not know what those applications have installed can be over-come as I suggested under Voidpup: (a) easiest, only use pkg-cli and PPM to create 'alphabet' and 'application' SFSes; or (b) modifications so that all package installers write records to and read records from /var. [IINM, Fossapup already writes to /var with /root/.packages being a symlink].

If apt is going to be Ubuntu/devian Puppys' principal package manager, someone will have to create applications enabling the easy creation of 'debs' and SFSes, ala dir2pet and dir2sfs.

--=-=-=-=--
* perhaps reach out to 666philb and/or peebee who I suspect are already contemplating a 64-bit version of Ubuntu 22.04 (jammy jellyfish) now that it has finalized.

** Slackware, hence Slacko puppys, employ either pkgtool , installpkg which I suspect are 'variations on a theme'. AFAIK, the main structural difference between Slackware and debian/Ubuntu is where they locate 64-bit packages. A Slacko version of Puppys' apt should not be impossible to devise.

[mikewalsh]

@rockedge / @mikeslr :-

Hm. Okay. Well, call me dense if you want, but I fail to see how this is supposed to work.

I followed mikeslr's link to the older thread - I'll be honest, I forgot I'd asked about these before! - and the adrv I downloaded from there is less than 7 MB in size. The original 'stock' adrv is almost 230MB.....and as I understand it, contains the bulk of Fossapup's software!

So; correct me if I'm wrong. The procedure involves gutting Fossapup to a 'bare-bones' Puppy.....simply to benefit from 'apt'? Where's the point in that?

Or is the adrv on the older thread that Mike linked me to NOT the correct one..? I'm really confused here...

Perhaps I need the facts driving into my thick skull with a maul and a wedge!

Mike.

[dimkr]

So; correct me if I'm wrong. The procedure involves gutting Fossapup to a 'bare-bones' Puppy.....simply to benefit from 'apt'? Where's the point in that?

woof-CE can easily build a "fat" Puppy with Xfce and working apt

[mikeslr]

Mike, rename Fossapup64's adrv.sfs to ydrv.sfs. It's the first thing I do*. Later, you can use Amethyst's nicOS-Utility-Suite's Save2SFS module, viewtopic.php?t=1694 to do any of the following:
include the adrv.sfs in a rebuilt/created ydrv.sfs
create a new adrv.sfs
create a new ydrv.sfs.
include your SaveFile/Folder and/or** any installed but not-as-yet Saved applications in either an adrv.sfs or a ydrv.sfs.
Caution: Before running Save2SFS, to not include your SaveFile/Folder boot pfix=ram.

Both adrv.sfs and ydrv.sfs will be used if Puppy finds them (i.e., located adjacent to the 'Core/Base'.sfs). The difference is that the contents of an adrv.sfs have priority over everything other than the contents of a SaveFile/Folder.
-=-=--=
* My only criticism of how 666philb structured Fossapup64: too many applications were assigned to the adrv.sfs.

** My approach is, if possible, anything which is not going to change goes in the ydrv.sfs. Applications likely to have up-dates (e.g., still being developed) goes in the adrv.sfs. Applications frequently changed/updated, (e.g. web-browsers) are assigned to the SaveFile/Folder either by installation (pets), SFS-load or linked such as with portables and AppImages. On my desktop and yours rebuilding either an adrv.sfs or a ydrv.sfs only takes a minute or two. I worked out this approach while exploring Voidpup: applications unique to Puppys are included in its ydrv.sfs: Void's package manager didn't have to know about them.

Eventually, I may remaster to include the current ydrv.sfs in the core/base sfs.

[rockedge]

@mikewalsh,
If I remember there was a reason for those components for APT to be in the adrv because of the layer order. It would be possible to rename the stock adrv to ydrv or merge those 2. Then import the small adrv.

That way Fossapup64 remains full featured.

[mikewalsh]

Mm. O-kay. I think I've got it.

- Rename the stock adrv to ydrv.
- Add the new adrv to /mnt/home in its place.
- Load the apt-whatever.sfs on the fly, once up-and-running...

Sound about right? (And then tiffle about with those scripts & commands in /sbin....)

(I'll boot up with pfix=ram first, and create a new save-folder for trying this stuff out. It'll give me the option of running 'stock' Fossa if I don't want to play with it, or the 'test' Fossa if I do....)

Mike.

[rockedge]

@mikewalsh that sounds like you've got the hang of it now!

Let us know how you make out.......

[puddlemoon]

It is almost working with jackalpup (: Had to clean up my sources a bit first (the kx repos were old) but I am hitting an error.

Code: Select all

root# apt update
Hit:1 http://archive.ubuntu.com/ubuntu focal InRelease
Hit:2 http://archive.ubuntu.com/ubuntu focal-updates InRelease                
Hit:3 http://security.ubuntu.com/ubuntu focal-security InRelease              
Hit:4 http://archive.ubuntu.com/ubuntu focal-backports InRelease              
Hit:5 http://archive.canonical.com/ubuntu focal InRelease                     
Hit:6 http://ppa.launchpad.net/kxstudio-debian/libs/ubuntu focal InRelease
Hit:7 http://ppa.launchpad.net/kxstudio-debian/plugins/ubuntu focal InRelease
Hit:8 http://ppa.launchpad.net/kxstudio-debian/apps/ubuntu focal InRelease
Hit:9 http://ppa.launchpad.net/kxstudio-debian/kxstudio/ubuntu focal InRelease
Hit:10 http://ppa.launchpad.net/kxstudio-debian/libs/ubuntu bionic InRelease
Hit:11 http://ppa.launchpad.net/kxstudio-debian/music/ubuntu bionic InRelease
Hit:12 http://ppa.launchpad.net/kxstudio-debian/plugins/ubuntu bionic InRelease
Hit:13 http://ppa.launchpad.net/kxstudio-debian/apps/ubuntu bionic InRelease
Hit:14 http://ppa.launchpad.net/kxstudio-debian/kxstudio/ubuntu bionic InRelease
Reading package lists... Done
Building dependency tree       
Reading state information... Done
23 packages can be upgraded. Run 'apt list --upgradable' to see them.
root# 
root# apt upgrade
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Calculating upgrade... Done
The following packages will be upgraded:
  ca-certificates gpgv libc-bin libc6 libgcrypt20 libgnutls30 libhogweed5
  liblz4-1 liblzma5 libnettle7 libpam-modules libpam-modules-bin
  libpam-runtime libpam0g libseccomp2 libssl1.1 libsystemd0 libudev1 libzstd1
  openssl passwd ubuntu-keyring zlib1g
23 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/9,180 kB of archives.
After this operation, 174 kB disk space will be freed.
Do you want to continue? [Y/n] y
Preconfiguring packages ...
(Reading database ... 3510 files and directories currently installed.)
Preparing to unpack .../libc6_2.31-0ubuntu9.7_amd64.deb ...

LD_LIBRARY_PATH contains the traditional /lib directory,
but not the multiarch directory /lib/x86_64-linux-gnu.
It is not safe to upgrade the C library in this situation;
please remove the /lib/directory from LD_LIBRARY_PATH and
try again.

dpkg: error processing archive /var/cache/apt/archives/libc6_2.31-0ubuntu9.7_am
d64.deb (--unpack):
 new libc6:amd64 package pre-installation script subprocess returned error exit
 status 1
Errors were encountered while processing:
 /var/cache/apt/archives/libc6_2.31-0ubuntu9.7_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)

I did have to mess with the ld.so.cache recently so I am guessing that has something to do with it. But unsure about removing the /lib dir from the path...

I was also getting a warning about no sandbox which went away after installing apt-utils

Code: Select all

root# apt install apt-utils
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following additional packages will be installed:
  apt libapt-pkg6.0
Suggested packages:
  apt-doc aptitude | synaptic | wajig dpkg-dev gnupg | gnupg2 | gnupg1
  powermgmt-base
The following NEW packages will be installed:
  apt-utils
The following packages will be upgraded:
  apt libapt-pkg6.0
2 upgraded, 1 newly installed, 0 to remove and 23 not upgraded.
Need to get 216 kB/2,347 kB of archives.
After this operation, 891 kB of additional disk space will be used.
Do you want to continue? [Y/n] y
Get:1 http://archive.ubuntu.com/ubuntu focal-updates/main amd64 apt-utils amd64 2.0.6 [216 kB]
Fetched 216 kB in 1s (344 kB/s)    
debconf: delaying package configuration, since apt-utils is not installed
(Reading database ... 3472 files and directories currently installed.)
Preparing to unpack .../libapt-pkg6.0_2.0.6_amd64.deb ...
Unpacking libapt-pkg6.0:amd64 (2.0.6) over (2.0.4) ...
Setting up libapt-pkg6.0:amd64 (2.0.6) ...
(Reading database ... 3472 files and directories currently installed.)
Preparing to unpack .../archives/apt_2.0.6_amd64.deb ...
Unpacking apt (2.0.6) over (2.0.4) ...
Setting up apt (2.0.6) ...
Selecting previously unselected package apt-utils.
(Reading database ... 3472 files and directories currently installed.)
Preparing to unpack .../apt-utils_2.0.6_amd64.deb ...
Unpacking apt-utils (2.0.6) ...
Setting up apt-utils (2.0.6) ...
Processing triggers for libc-bin (2.31-0ubuntu9.2) ...
/sbin/ldconfig.real: /usr/lib/x86_64-linux-gnu/libgthread-2.0.so.0 is not a sym
bolic link

/sbin/ldconfig.real: /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 is not a sym
bolic link

/sbin/ldconfig.real: /usr/lib/x86_64-linux-gnu/libgmodule-2.0.so.0 is not a sym
bolic link

/sbin/ldconfig.real: /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 is not a symbol
ic link

/sbin/ldconfig.real: /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0 is not a symboli
c link

W: No sandbox user '_apt' on the system, can not drop privileges

[fredx181]

What you can try first is setting the LD_LIBRARY_PATH to empty before any apt command, e.g.:
export LD_LIBRARY_PATH= (untested)
If that doesn't work, it could be needed to set all e.g. export LD_LIBRARY_PATH=/lib/:/usr/lib:/lib/x86_64-linux-gnu:/usr/lib/x86_64-linux-gnu

[dimkr]

https://github.com/dimkr/woof-CE/releas ... p-22.04.32 is based on Ubuntu 22.04, it's pretty barebones and apt works very well. The menu is updated automatically after apt install, Synaptic works, gdebi is registered as the handler for .deb files, and so on. I also rebuilt fossa64 with apt support and it was slightly broken (the Synaptic menu entry is broken) but it shouldn't be hard to fix it the package conflicts and other small issues.

[puddlemoon]

Thanks for the response @fredx181 ... export LD_LIBRARY_PATH= did the trick. Got the upgrade to go thru. (only got that warning when attempting the upgrade) Installed LMMS and another synth plugin to test. working so far.
I could see where things could get crazy when I tried to remove the plugin... But cool to test, could try again at some point with another fresh save and maybe be a bit more methodical, but it seems jammy with apt is right around the corner so leaving it to the experts is my best bet (;