TazPuppy 5.0 rc2
-
- Posts: 98
- Joined: Mon 17 Oct 2016, 05:11
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.
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.
- Attachments
-
- screenshot.jpg
- (176.5 KiB) Downloaded 381 times
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.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
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.
-
- Posts: 98
- Joined: Mon 17 Oct 2016, 05:11
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.
I wonder if this is related to the failure to boot when an extra sfs is to be loaded.
- Attachments
-
- sfs_load.jpg
- (31 KiB) Downloaded 264 times
@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.
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.
-
- Posts: 98
- Joined: Mon 17 Oct 2016, 05:11
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.
> 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.
-
- Posts: 98
- Joined: Mon 17 Oct 2016, 05:11
@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.
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.
-
- Posts: 98
- Joined: Mon 17 Oct 2016, 05:11
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.)
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.)
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.
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.
-
- Posts: 98
- Joined: Mon 17 Oct 2016, 05:11
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
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
-
- Posts: 98
- Joined: Mon 17 Oct 2016, 05:11
@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
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
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
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
Code: Select all
make-devx [working folder to creating devx module]
MD5 checksum: afb03b61cd2937bac4a47e7bf71be86f
Build kit: https://drive.google.com/file/d/1h3-En8 ... sp=sharing