Thanks, I fixed it.
The forum also has a link to another fix by DaveS, however that only applies to other remaster scripts.
Note, in remasterpup2, a new id-string is calculated, IDSTRING, which is placed in variable DISTRO_IDSTRING in file /etc/DISTRO_SPECS and DISTRO_SPECS in the initrd, and appended to 'vmlinuz' and the sfs files.
The reason for generating a new id-string is because this is a new distinct build of Puppy, and avoids the earlier (wrong) files being found at bootup.
Note, if traditional filenames are used, not the simplified 'puppy.sfs' and 'zdrv.sfs' (as in Wary 094), then these sfs files do not need the appended id-string as they are detected at bootup purely by their filenames. However, 'vmlinuz' must always have the id-string.
Comments:Posted on 7 Nov 2010, 8:19 by zygo
remaster fails to copy essential files
Barry, thanks for fixing the "too old" bug and giving the sfs an id so it can boot.
What about the bug I reported in my following post on the forum (Quirky 1.3 feedback thread http://www.murga-linux.com/puppy/viewtopic.php?t=60163&start=45 ) which has existed since at least Puppy 431.
Judging by the 33kB size of the remaster script it's a complicated business. But it fails to copy essential files. The workaround is simply to copy (almost) everything. Could you not incorporate this and warn at the beginning that browser caches etc will be copied to the live-cd?