Gyro I compiled zarfy which works fine but the changes are not persistent. As soon as I run zarfy again the monitors are swapped back but on next restart all reverts to original wrong way round._________________Software <-> Distros <-> Tips <-> Newsletters

Just to start on the same page, could you please do test booting with the following configuration:
Do a non uefi boot of a frugal install on an ext partition containing only these 4 files, initrd.gz, puppy_slacko64_6.9.5.sfs, vmlinuz, zdrv_slacko64_6.9.5.sfs.
With these boot paramaters "pmedia=atahd", "pfix=fsckp", and appropriate "pdev1=" and "psubdir=".

Note: the pfix=fsckp, this tells the new init to fsck every ext partition before just before mounting it. The important thing for testing is that it displays the output of e2fsck on the console, so it should be obvious if the "pdev1=" parameter is not being honoured.

We need to try to reduce the variation, in order to pinpoint the significant difference.

Oh, by all means use the debug version produced by jlist.

If this does not provide a resolution, then I can produce a series of init scripts that sinply stop and display significant variables, (then reboot with ctrl+alt+del, it's ok no partitions are mounted when it stops).
The first version would do this very early to establish that the boot parameters have been correctly interpreted, and then subquent versions move this further down the code, until we find something that is not right.
Quite tedious, but it's pretty much the method I used to build the thing.

I'm working on an init which has several breakout points, controled by "pdebug=n" boot parameter.
"pdebug=0" will dropout very early, "debug=1" will dropout later, and so on...
So downloading a single initrd.gz will provide many testing points.
Even just seeing which debug point you get to before a problem occurs, will give us a starting clue.
gyro

I have atached a debgug init for this slacko64, as init.gz.
It's also available as an updated initrd.gz from http://www.fishprogs.software/puppy/slacko64/initrd.gz.
This init accepts "pdebug=" boot parameters.
"pdebug=0" drops out to the console just after intepreting boot parameters.
"pdebug=3" drops out just before getting the no puppy...sfs message.
1,2 are in between. There is no "pdebug=4".
At each pdebug point it displays a message showing significant init variables at that point. The different pdebug points show different messages.
At the console you can run commands like "mount" to confirm that no partitions are still mounted.
Use ctrl+alt+del keys to reboot.

How to use:
Start by booting with "pdebug=0", and then "pdebug=1" etc.. noting the last pdebug point that was successful.
Please report what was the last successful pdebug point number and the contents of the line above showing the init variables.

Edit: This version has been replaced, see later post

gyroLast edited by gyro on Tue 30 Aug 2016, 12:44; edited 1 time in total

This a a slightly refined version, in that the debug messages are always written if any value of pdebug is set. i.e. if you boot with "pdebug=y" all debug messages will be appended to bootinit.log.
If "pdebug=" is set to 0,1,2,3 init will drop out as per previous version.

So, for initial testing boot "pdebug=y". If the boot works, there's a few extra lines in "/initrd/tmp/bootinit.log". If it fails, all the messages should appear on the screen following the "bootinit.log" line.

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