Another thing that was done, which is important if the pup is built to use the simplified filenames, then the main .sfs is now named just 'puppy.sfs' instead of something like 'wary_090.sfs', and if copied to HD from CD will need to be placed in a subdirectory so as not to clash with other 'puppy.sfs' files.
I have modified /etc/rc.d/rc.shutdown to make this subdirectory a name in format 8+3, for example w0901010.083, with enough information to be unique for that build. Previously it was just 8 characters, not unique enough.
Comments:Posted on 13 Oct 2010, 8:25 by BarryK
This unique directory also partially solves a problem when have traditional filename also, ex 'wary_090.sfs'. This problem applies to all previous puppies.
In the case of Wary 090, I released two live-CDs, with 126.96.36.199 and 188.8.131.52 kernels. If you test one of them and at first shutdown it offers to copy 'wary_090.sfs' to the HD -- you accept this. Then you test the other live-CD, but this time at first shutdown the rc.shutdown script sees that wary_090.sfs is already on the HD so doesn't offer to copy it.
Oh dear, at next boot, the incorrect wary_090.sfs gets mounted, and that has the wrong kernel modules in it.
This is a serious problem that has existed with all previous puppies.
With latest changes, the problem still exists, partially. rc.shutdown will now offer to copy the second wary_090.sfs to HD, into a unique subdirectory. That's good, however the 'init' script only searches for 'wary_090.sfs' by its name, and may find the wrong one -- it doesn't look for any particular subdirectory name.
So the problem still exists, for traditional naming. For simplified naming, the 'puppy.sfs' is identified in the 'init' script by it's unique appended id string, so the problem is solved.
Another reason why I will probably build all future puppies, Wary and Quirky anyway, with the simplified filenames.
Posted on 13 Oct 2010, 9:25 by Raffy
Another for pupsave
While you are at these "little" fixes, please see what Patriot has suggested here for pupsave.
Posted on 13 Oct 2010, 10:13 by BarryK
Re pupsave shutdown
You have posted about this at least once before, and I have responded.
Repeating my previous response, Puppy has already implemented patriot's method 1, which was done some time ago.
Posted on 13 Oct 2010, 12:04 by Raffy
Sorry, I should have searched your blog first - you have a post about "clean unmountof save-file".
Posted on 13 Oct 2010, 15:04 by 8-bit
When doing an update to a later Wary, why not just change the DISTROSPECS file to something like wary_091.sfs.
Or would a boot see this as an upgraded version and want to convert the pupsave.2fs file to a new version?
I have enough memory so that I never see the offer to copy the SFS file to the hard drive.
And all my hard drive installs are frugal.
Posted on 13 Oct 2010, 16:59 by Iguleder
Barry, The browser/image viewer needs to fork when it shows the welcome page, otherwise all /root/Startup stuff start only when you close it. No tray icons until you close it and if you go to some website to check your internet connection you don't have any tray icons. It's in /usr/sbin/delayedrun, just add "&" after all the image viewer or browser calls.
Posted on 13 Oct 2010, 18:10 by mavrothal
I do not know if you noticed this post on the bug thread
but just in case,
it would appear that the new init is considerably slower in booting from slow media (USB/SDcard). For a 4GB card and stick with deep folders in it (ext3 formatted) can take more than 2 minutes.
It also needs much more user input defining boot parameters instead of auto detecting, and accepts them even when wrong. Eg defining pmedia=usbhd for a USB stick goes to PUPMODE=12 but the sessions are not saved (this was not the case with the old one).
Finally I have this "select warysave file" bug that 2 warysave files are shown even when there is only one.
The "select warysave file feature" is nice but maybe should be optional as a boot argument. Combined with the long search times (not uncommon is old machines) makes a suboptimal impression compared to other puppies, I would think.
I hope there is a way to combine the robustness and ease of the older scripts with the features of the newer one.
Posted on 13 Oct 2010, 18:37 by BarryK
re startup msg
Yeah, I have already implemented that in Woof, I just didn't get around to mentioning it on the blog.
Posted on 13 Oct 2010, 18:51 by BarryK
It should not be any slower than previous puppies.
You posted about the psavemark=1 boot parameter and you asked about automating this. You can create a file SAVEMARK in the boot partition that does the same job. But, if your save file is in the boot partition, this parameter is not needed.
"More user input defining boot parameters"
...er, no, it is the opposite.
Wary should have very easily been able to determine the boot device. Really all you need is 'pmedia=usbflash' to give a hint to the init script. It should boot fast, 2 minutes indicates something is wrong.
Posted on 13 Oct 2010, 19:09 by ICPUG
Simplified file naming and psubdir
Barry - you say the simplified filenaming solves the problems of locating the sfs files.
Are you saying the use of psubdir is redundant with the simplified file naming and is not used in the new init script?
Isn't the simplified file naming a different way of solving the problem that was already solved by psubdir - or am I missing something?
Posted on 13 Oct 2010, 20:27 by BarryK
I posted about what boot params are acceptable:
The use of psubdir narrows the search, the init script knows that it doesn't have to look anywhere else. So of course it is useful, just as it was before.
Posted on 13 Oct 2010, 23:57 by ICPUG
OK Barry. That's what I thought.
The problem in your first comment can be solved by specifying psubdir.
Admittedly, that requires user interaction, to specify the bootcode, so simplified filenames will help the newbie if they forget.
Posted on 14 Oct 2010, 8:04 by BarryK
It really doesn't matter if psubdir is not specified. It is only a helper, that speeds bootup.
Each 'puppy.sfs' file is unique as each has a unique id-string appended. So, when the init script searches for Puppy files at bootup, it will reject all the "wrong" puppy.sfs files it encounters.
The appended id-string method is superior to just having a filename, ex 'wary_090.sfs', as I pointed out in my first post, as in the case of two builds of Wary 090 with different kernels both having the same name wary_090.sfs.
Posted on 19 Oct 2010, 10:39 by BarryK
A thought has just occurred to me. You posted in the forum about much difficulty booting Wary 0.9 on the XO. You have a modified kernel -- did you append the id-string onto the end of vmlinuz? -- this is essential. This is documented in earlier blog posts.