Stats

I was going to fork Woof so as to develop this new idea, however I don't really have the time to maintain two Woof projects. So, I devised a very nice solution...

There will continue to be only the one Woof project, that is able to build a distro using either the traditional or the simplified filenames. There is a question in script '3builddistro' that asks this, or via a checkbox in the GUI.

Scripts in Puppy can read these variables to determine the filenames. So far I have modified 'init' (in the initramfs) and rc.shutdown. So, the names can now be anything. In fact, the naming is now totally irrelevant, and a developer can choose anything they want (for example if you want wary_071.sfs instead of wary-071.sfs, no problem!).

The Woof build script 3builddistro generates a unique 16-byte id-string, "w071100912163021" in the above example. This is stored in /etc/DISTRO_SPECS and also in /DISTRO_SPECS in the initramfs -- so, the 'init' script in the initrd.gz file can read the id-string and then search for the files.

3builddistro appends the id-string onto the end of vmlinuz, puppy.sfs, zdrv.sfs and devx.sfs (or whatever they are named). It is this id-string that enables the init script to find the exact required files, regardless of their names.

This works extremely well, and results in very simple code in the 'init' script to find the Puppy files. I have already mentioned a significant reduction in the number of lines of code in init.

So, Woof can continue to build puppies with the traditional names, and many scripts that are designed to work with these names will continue to function. However, any scripts that rebuild an .sfs file, such as CD-remaster applications, will need to add a line to append the id-string. Which is simple -- after building a new .sfs, just do this (for example):

echo -n "$DISTRO_IDSTRING" >> pup-431.sfs

Ultimately, a CD-remaster program should read those variables in file DISTRO_SPECS, so as to be totally compatible with this new system.

I intend to release Quirky 1.3 with this new system, and built with the simplified names. This will enable some hands-on and will hopefully put people at ease with this system. After a period of feedback I will decide whether it will remain in Woof.

Posted on 13 Sep 2010, 20:56 by perthiePsubdir not needed?What happens if I have more than one install of the same version? For example, a regular setup and a separate devx setup.

Or does the path for vmlinuz also get used to find the sfs file?

Posted on 13 Sep 2010, 22:54 by BarryKRe psubdirThe 'init' script now locates vmlinuz therefore knows the subdirectory. Previously, if there were vmlinuz files all over the place, the init script could not tell them apart, but now that they have an id-string appended, the init script is able to locate the exact one that Puppy has booted off.

Posted on 13 Sep 2010, 23:01 by BarryKRe psubdirYou can still specify it as a kernel boot parameter -- it will prevent the init script from probing other partitions.

Posted on 13 Sep 2010, 24:25 by TerryphiRe psubdirBarryK wrote:

Re psubdir
You can still specify it as a kernel boot parameter -- it will prevent the init script from probing other partitions.

Excellent news!

Posted on 13 Sep 2010, 24:42 by perthieSub-sub folders?Does that mean that you can now put your frugal install in a folder several levels down?

Posted on 13 Sep 2010, 24:51 by perthieMore QuestionsWill the pdev1 argument also be unnecessary?

Also, what happens if I boot off the Live CD, but then want to launch a USB install? Currently the "pmedia=usbflash" option handles that situation.

Posted on 14 Sep 2010, 9:45 by BarryKRe sub-sub foldersSub-sub folders: no, because I only set the 'find' command to search with '-maxdepth 2'. I did this for speed. The thing is, would there be noticeable slowdown at booting if the init script searched '-maxdepth 3' or even more?

usbflash: pmedia should not be needed. The init script searches the sr devices (optical) last, so if there is a vmlinuz found with the correct id-string, that will be treated as the boot partition (and sub-directory). So, even though it started booting from CD, it should automatically flip over to the usb drive.
...so, we could have very simple "it just works" situation.

Posted on 14 Sep 2010, 10:02 by BarryKpsavemark boot paramIntroducing a new kernel boot parameter. If you have this kernel boot param:

psavemark=2

And say that you are booting off a usb flash drive with two partitions. You have vmlinuz, initrd.gz and puppy.sfs in the first partition.

A typical scenario with large flash drives is that you might create a vfat first partition, quite small, as some PCs need that to boot the flash device.

But, you would like the save file to be in the second partition. Or if the second partition is a Linux f.s. you can save the session to the entire partition.

Now, by passing 'psavemark=2' you tell the init script the partition number in the boot drive in which the save file is located (or to be located).

Note that file 'SAVEMARK' in the first partition can also have the value "2" in it and this will override the boot param. The 'SAVEMARK' file is already implemented in recent Woof-built puppies (including Lucid). But now I have added the boot param.

Posted on 14 Sep 2010, 10:35 by BarryKRationalised Puppy filenamesI will in future refer to this initiative as "Rationalised Puppy filenames", as the key development is that now they can be anything. The names are stored in /etc/DISTRO_SPECS and the 'init' script no longer depends on the name of the file to decide if it is the right one, instead reads an id-string appended to the file.

Posted on 14 Sep 2010, 11:28 by Raffysavemark overrideQuote: Note that file 'SAVEMARK' in the first partition can also have the value "2" in it and this will override the boot param.

Do you mean that SAVEMARK will be a file in the saved-to partition, which will override a psavemark parameter (that directs Puppy to save to the psavemark partition)? And will the user have control over SAVEMARK?

Posted on 14 Sep 2010, 16:49 by BarryKRe psubdirRe psubdir
You can still specify it as a kernel boot parameter -- it will prevent the init script from probing other partitions.

Sorry, my brain was getting fuzzy. I meant that 'pdev1' can prevent probing of other partitions. 'psubdir' can also be specified and it narrows down the search a bit more, but doesn't in itself prevent probing of all partitions.

Posted on 14 Sep 2010, 16:53 by BarryKRe SAVEMARK fileRaffy,
No, file SAVEMARK has to be in the boot partition, where you have vmlinuz. Yes, you can create it yourself.

The SAVEMARK file is a feature in the BootFlash utility, where one of the USB installation modes creates two partitions on the USB drive. That has been around for awhile.

Posted on 15 Sep 2010, 22:40 by BarryKSAVEMARK improvedIf you are booting off the first partition of a USB drive and you want the session to be saved in say the second partition, the SAVEMARK file or psavemark boot parameter did not work if the session was saved to the entire partition. I have fixed that, theoretically anyway.