(old)Puppy Linux Discussion Forum

@Terry H since Tazpuppy is now fully modular you can use the fdrv file of other puppies if you hardware does not support with the shipped fdrv on tazpuppy. To load it on boot automatically, rename the fdrv file as fdrv_tazpup_5.0.sfs

I am experiencing a strange error at boot.

It is a frugal install onto a hard drive (ntfs). I tried various types of tazpupsave (ext2/3/4), but all resulted in the same error.

I am loading an extra sfs (firefox) which I made myself. I've used the sfs with recent releases of tazpuppy without any problem.

I attach the screenshot.

Edit
I booted another Puppy and moved the sfs to another drive. Tazpuppy booted successfully. I am adding this line with Midori.

mistfire wrote:@Terry H since Tazpuppy is now fully modular you can use the fdrv file of other puppies if you hardware does not support with the shipped fdrv on tazpuppy. To load it on boot automatically, rename the fdrv file as fdrv_tazpup_5.0.sfs

I'm not sure you followed my intent with the fdrv details I posted. I don't use an fdrv in any puppy, I am aware of how to rename and load an *drv sfs. I only loaded your fdrv to test it.

With such an old fdrv you will get many people reporting wifi and ethenet nic connection failures. It would be advisable to use a more up to date version.

I noticed fdrv is listed in sfs_load. It is my understanding that fdrv is not counted as an extra sfs.

I wonder if this is related to the failure to boot when an extra sfs is to be loaded.

@thinkpadfreak beta 8 was kernel related update, the main sfs and init was untouched.

The kernel modules is now on zdrv, the zdrv on beta 7 is contains only firmware driver. When I decided to make modular the former zdrv was now renamed as fdrv. By the way i will try to investigate also the fdrv in sfs_load. But based on your screenshot, it is likely the culprit because the filename contains whitespaces

Also the kernel was recompiled and it has some tweaks. I cannot no longer push beyond 4.17.6 because it cannot compiled by my host puppy X-Slacko Slim. So I will resort to the latest 4.9.x backport, If the linux kernel source code has builitin aufs that will be no problem.

Can you help me to find the download link for linux kernel source code 4.9.136 with aufs patched?

@Terry H thanks for your advise however expect the increase of file size.

mistfire wrote:
> By the way i will try to investigate also the fdrv in sfs_load. But based on your screenshot, it is likely the culprit because the filename contains whitespaces

As for the spaces of the filename, I think the font is responsible. I added a Japanese font set, and strangely there are cases where underscores are invisible.
There are at least several people in the Puppy Linux Japanese Forum who confirm the failure to boot: when fdrv sfs and an extra sfs exist, beta 8 is unable to boot.

As a test, I joined the contents of fdrv and zdrv, and made a new zdrv. Since there doesn't exsist fdrv, beta 8 boots successfully. It seems that fdrv and an extra sfs conflict, and the layers cannot be configured. Please do investigate this issue.


> I cannot no longer push beyond 4.17.6 because it cannot compiled by my host puppy X-Slacko Slim. So I will resort to the latest 4.9.x backport, If the linux kernel source code has builitin aufs that will be no problem.

Unfortunately, I do not know much about kernel compilation. 4.17.6 kernel seems good in itself, though it is too new for my machine.

@thinkpadfreak what sfs file did you load aside the fdrv that was loaded. Can you try to rename that fdrv as ydrv_tazpup_5.0.sfs then boot it to see what happens whether it will boot sucessfully or not?

@mistfire
The following is a summary of what I have tried so far.

main sfs + fdrv + zdrv ... OK
main sfs + fdrv + zdrv + an extra sfs (firefox) .... failure
main sfs + zdrv (the content is fdrv and zdrv merged) + an extra sfs ... OK


> Can you try to rename that fdrv as ydrv_tazpup_5.0.sfs then boot it to see what happens whether it will boot sucessfully or not?

I will try later.

I tried renaming fdrv to ydrv.

main sfs + ydrv + zdrv + extra sfs ... OK

ydrv is not listed in sfs_load. The mount point of ydrv is /dev/loop3, while the mount point of fdrv is /dev/loop5, which seems to conflict with that of an extra sfs.

In case of UpupBB, for example, the configuration of the layers is very different. I wonder if the init script defines the configuration. (I am just an ordinary user, and don't know in detail.)

@thinkpadfreak I finally found the bug on loop5. It is the big flaw in the init script code upon loading extra sfs. It is now fixed. I made some revisions on sfs_load script.

To mitigate this problem on beta 8 or below rename the fdrv_tazpup_5.0.sfs to ydrv_tazpup_5.0.sfs

Hi Mistfire and all,

Congrats on keeping this going for so long now? Especially since a novice like me can finally play it and get somewhere.

Can I ask a question of anyone here?

What is the exact order, when booting occurs, that the various *drv sfses are loaded?

I assume the main.sfs always comes, at the first layer so-to-speak, but what comes or is "officially" loaded next? An adrv? A zdrv? A fdrv? A ydrv?? (assuming we have these when we are booting up)

I guess what I am asking, what is the official order that puppy loads all these *drv sfses??

Reason I am asking because it seems if you are not careful, like when I started renaming *drv files, some stuff I had modded in one *drv was getting written over by a later *drv and messing up stuff.

Thanks for any response(s) explaining this.

@belham2 based on boot observation, loading sequence are here as follows:
main sfs
zdrv sfs
adrv sfs
ydrv sfs
fdrv sfs

only loading fdrv was the problem due to /dev/loop5 assignment which was used also by zdrv sfs. That problem is now fixed

@mistfire

I am glad that the cause of the problem has been identified.

I posted to the Japanese Forum about the workaround.

I made an update on firmware drivers, the result was the fdrv file size was increased by 10Mb so it is now 20Mb.

TazPuppy Beta 9 released

Changes:
* Linux kernel 4.9.124
* A bug on initrd which both zdrv and fdrv failed to load is fixed
* Autoconfig also work if the kernel version changes
* Some fixes on boot scripts

Download: https://drive.google.com/file/d/1DszXd7 ... sp=sharing
MD5 Checksum: 851882385a390eb0a88712970e29a918

Build Kit: https://drive.google.com/file/d/1zDoX3X ... sp=sharing

I have installed beta 9. (It is a frugal installation and the save file is newly created.)

Auto-configuration of sound cards worked at first boot.
Kernel 4.9 seems to be more suitable for my machine, though I did not expect that the kernel would be changed.

Thanks a lot!

@thinkpadfreak youre welcome

Right now I'm attempting to make the tazpup-builder architecture independent. It means it can easily to build tazpuppy either 32 or 64-bit. At present, tazpup builder builds 32-bit only. I gradually remove binary files in the core folder. In the future it was all bash scripts which is my ultimate goal.

vercmp and cddetect is now bash script, elspci is now removed (with a cost of modifying the script). Next to remove was dc command as well as freememtray_applet and will be replaced by yad and bash

I succesfully created the freememtray_applet using bash and yad. dc command is now dropped. On my latest experiment it now works nicely.

TazPuppy Beta 10 released:

Changes:
* busybox is now upgradable on tazpkg
* freememtray_applet is now bash script
* builtin make-devx script to make devx module from slitaz packages (experimental)

NOTE: To use make-devx script to create devx module, type this command to terminal Download: https://drive.google.com/file/d/1eXdzGh ... sp=sharing
MD5 checksum: afb03b61cd2937bac4a47e7bf71be86f

Build kit: https://drive.google.com/file/d/1h3-En8 ... sp=sharing

I suggest that the password for tazpuppy be listed in the first post.
______________________________________________________