site  contact  subhomenews

Little bugfixes for Woof

October 13, 2010 — BarryK
01micko reported that booting Wary 090 with "pfix=ram", a HD partition remained mounted after bootup. I have done a major rewrite of part of the 'init' script, see my blog posts related to "simplified filenames" or "rationalised filenames", and I was expecting maybe some little issues. This was one of them, fixed.

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.


unique puppy.sfs
Username: 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 and 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.

Another for pupsave
Username: Raffy
"While you are at these "little" fixes, please see what Patriot has suggested [url=]here for pupsave. Thanks, Barry.

Re pupsave shutdown
Username: BarryK
"Raffy, 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.

original post
Username: Raffy
"Sorry, I should have searched your blog first - you have a post about "[url=]clean unmountof save-file". Thanks again.

SFS name
Username: 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.

init script
Username: 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.

re startup msg
Username: BarryK
"Yeah, I have already implemented that in Woof, I just didn't get around to mentioning it on the blog.

Re slower
Username: BarryK
"mavrothal, 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", 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.

Simplified file naming and psubdir
Username: ICPUG
"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?

Boot params
Username: BarryK
"ICPUG, 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.

Username: 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.

Re psubdir
Username: 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.

Notice mavrothal
Username: BarryK
"Mavrothal, 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.

Tags: woof