Taking into consideration that an fdrv.sfs is required (which peebee has also made available) and that not all Puppies are "fdrv aware", can these be used in Puppies other than LxPup?

mikesLr

Hi Mike

Short answer=yes. Longer answer - if fdrv is not automatically loaded by init (only likely in very old pups) then you could try explicitly loading it as an .sfs assuming that it isn't needed on the very first boot to get a basic system running.....as always in pupland - try it and see

Probably could have used your first suggestion, but your second method worked fine with Xenialpup64.

Ally, changing the "pfs" ending to "sfs" does, in fact, enable their contents to be viewed and perhaps used with non-Russian-built Puppies. However, I have some doubts about the later. An examination of the included files revealed several with suffixes I'm not familiar with from my dissection of other Puppies and applications.

I didn't test, nor expend the time which would have been necessary to ascertain how those files functioned within their system.

I've made a 64bit Slacko compatible 4.9.94 kernel via Puppy kernel-kit, with the cutdown firmware option. Is Spectre/Meltdown mitigated.
Adding needed firmware to (or using another) fdrv will be helpful. Uses performance cpu governor by default (max speed).
Have swapped it into Slacko64 6.9.9.9 and LxpupSc64 18.03. Works ok in both. As usual, use at own risk.

Taking into consideration that an fdrv.sfs is required (which peebee has also made available) and that not all Puppies are "fdrv aware", can these be used in Puppies other than LxPup?

mikesLr

Hi Mike

Short answer=yes. Longer answer - if fdrv is not automatically loaded by init (only likely in very old pups) then you could try explicitly loading it as an .sfs assuming that it isn't needed on the very first boot to get a basic system running.....as always in pupland - try it and see

Otherwise the zdrv and fdrv would need to be "combined"....

Cheers
peebee

Hello, peebee, mikeslr and all.

It used to be (around the time of jrb's Puppy 4.12 / 4.21) that Puppy
would load automatically any sfs with its version number in it. (E.g.
something like openoffice_4.12.sfs, gimp_4.12.sfs, etc.) Has that capacity
been removed from the init in new Puppies?

(This is a real question, not a rhetorical one: if that capacity is still there,
it could be put to good use. Also, if this capacity is still present, combining
the fdrv with the zdrv would not be necessary.)

I've made a 64bit Slacko compatible 4.14.35 kernel via Puppy kernel-kit, with the no firmware option. Is Spectre/Meltdown mitigated.
Needs firmware by making own (or using another) fdrv . Uses performance cpu governor by default (max speed). As usual, use at own risk.

I made a 64bit Slacko compatible 4.14.47 kernel via Puppy kernel-kit, with the no firmware option. Need firmware by making (or using another) fdrv.
Is Spectre/Meltdown mitigated. Uses performance cpu governor by default (max speed).
Have swapped it into Slacko64 6.9.9.9 and LxpupSc64 18.03. Works ok in both. As usual, use at own risk.

I've made a 64bit Slacko compatible 4.14.69 kernel via Puppy kernel-kit, with the no firmware option.
Is Spectre/Meltdown mitigated - except microcode update is needed for spectre 3a, for some processors.

Needs firmware by making own (or using another) fdrv . Uses performance cpu governor by default (max speed).
Have swapped it into Slacko64 6.9.9.9 and LxpupSc64 18.03. Works ok in both. As usual, use at own risk.

Kernels are not directly interchangeable between slacko & ubuntu derivatives. Problem is /usr/lib64. In slacko it is a physical directory; in ubuntu it is a symlink to /usr/lib. In bionic64, zdrv uses /usr/lib64 as a physical directory, which contains the libau.* files (that would be correct for a slacko derivative). They should be in /usr/lib and /usr/lib64 should be a symlink of that. This was the case in xenial64. Loading .pets in the wrong base often causes the same problem. For those with issues in ubuntu derivatives, try moving /usr/lib64 files into /usr/lib, deleting /usr/lib64, then symlinking /usr/lib to /usr/lib64.Last edited by ozsouth on Thu 08 Nov 2018, 23:19; edited 1 time in total

Although the workaround he suggested should work, I'm not sure ozsouth is entirely correct. I've been employing kernel version 4.15.0-lxpup64 in Xenialpup64 for several months now without a problem running any application: originally under Xenialpup64-7.0.8, the last week or two under Xenialpup64-7.5. Tahrpup64 also uses that kernel.

Slackos, which are binary-compatible with Slackware, use of /lib64 folders to hold 64-bit libraries. The problem with the "Ubuntu-Pups" is that they are binary-compatible with either Ubuntu Trusty Tahr or Ubuntu Xenial Xerus with access to their respective Ubuntu repos. Ubuntu published those to locate 64-bit libraries in folders bearing the names x86_64-linux-gnu*. I think its a 'woof' problem, but neither Tahrpup64 nor Xenialpup64 have ever been able to recognize the existence of those folders. Applications created for Ubuntu when used under "Ubuntu-Pups" are unable to find the libraries located in such folders. So, the 'work-around' was to move libs from them into /lib and create symbolic links named x86_64-linux-gnu to /lib.

It should be noted that Tahrpup and Xenialpup will recognize /lib64 folders and find files placed in them. As a result applications built for 64-bit Slackos which placed libraries in /lib64 can be used in "Ubuntu-Pups" without having to move such libs ['though they may require other libs and some tweaking].

I think only with Xenialpup64-7.5 were the symlinks named x86_64-linux-gnu built into the structure of puppy_xenialpup64-7.5.sfs. This may cause a problem with packages obtained by accessing Ubuntu repos directly using a web-browser or via PPM: those packages may not be able to follow the symbolic link to place libs in /lib. [That's not the case if PaDS is used to create SFSes or Pets, as it is constructed to move such libs 'behind the scenes' during the build process].

The real solution would be to modify woof and pet-get so that “Ubuntu Pups” were consistent with Slacko Pups: use /lib64 for 64-bit libraries, and automatically –behind the scene-- relocate libs from x86_64-linux-gnu to /lib64. [My suggestion to modify woof so that 'Ubuntu-Pups' handle multi-arch the same way as Ubuntu either having fallen on deaf ears or been 'cries in the wilderness'. But on reflection, providing consistency among Puppies would, in fact, be the better course].

* There are actually several folders bearing that name: at least one under /lib, one under /usr/lib, and another under /usr/local/lib. I’m not sure about “sbin” folders. Although Ubuntu uses three folders, it would probably suffice if Ubuntu-Pups use one, perhaps /usr/lib64.

I've made a 64bit Xenial/Bionic compatible 4.14.79 kernel via Puppy kernel-kit, with the no firmware option. Is Spectre/Meltdown mitigated (except 3a). Needs firmware by making own (or using another) fdrv . Uses performance cpu governor by default (max speed). Tested OK in Xenialpup64-7.5. As usual, use at own risk.

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou cannot attach files in this forumYou can download files in this forum