Simplified Puppy filenames

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.

The simplified names are:
vmlinuz, initrd.gz, puppy.sfs, zdrv.sfs, devx.sfs

The traditional names have distro/version information in some of the names. For example, Wary version 071, kernel 2.6.33.5:
vmlinuz, initrd.gz, wary-071.sfs, zw071335.sfs, wary_devx_071.sfs

You can see that vmlinuz and initrd.gz are unchanged. Whatever names are chosen, they are recorded in /etc/DISTRO_SPECS in the built Puppy. For example:

DISTRO_IDSTRING='w071100912163021'
DISTRO_PUPPYSFS='puppy.sfs'
DISTRO_ZDRVSFS='zdrv.sfs'
DISTRO_DEVXSFS='devx.sfs'

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.

---

Comments

Scripts upgraded
Username: BarryK
This morning I upgraded /usr/sbin/puppyinstaller (Universal Installer), /usr/sbin/bootmanager, /usr/sbin/bootflash (BootFlash USB installer), /etc/rc.d/rc.update and /etc/rc.d/functions4puppy, to handle the new generic filenames system. There are only two other scripts that I need to upgrade in Woof, /usr/sbin/remasterpup2 and resizepfile.sh, will do those this afternoon.

pmedia, psubdir boot params
Username: BarryK
"The new streamlined 'init' script does not really need 'pmedia' kernel boot parameter anymore. 'psubdir' is not needed either, but you will still need to specify the sub-directory in Grub or Lilo to tell them where to find the vmlinuz and initrd.gz files in the case of frugal installation.

Code to extract id-string
Username: BarryK
"For the record, this is how my scripts read the id-string off the end of the Puppy files, vmlinuz for example: [code]FULLSIZE=`stat -c %s vmlinuz` ORIGSIZE=`expr $FULLSIZE - 16` IDSTRING="`dd if=vmlinuz bs=1 skip=$ORIGSIZE 2>/dev/null`"[/code]

Format of id-string
Username: BarryK
"Oh yeah, also for the record, the format of the 16-byte id-string is, each byte is an ASCII character: [code]BYTE DESCRIPTION 15 First letter of DISTRO_FILE_PREFIX (ex: 'w' for wary) 14,13,12 Three digit version number of Puppy. 11,10 Year 9,8 Month 7,6 Day 5,4 Hour 3,2 Minute 1,0 Second[/code] Where byte-0 would be on the very end of the file.

CD-remaster script updated
Username: BarryK
"Ok, /usr/sbin/remasterpup2 updated.

Psubdir not needed?
Username: perthie
"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?

Re psubdir
Username: BarryK
"The '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.

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

Re psubdir
Username: Terryphi
"[i]BarryK wrote: Re psubdir You can still specify it as a kernel boot parameter -- it will prevent the init script from probing other partitions.[/i] Excellent news!

More Questions
Username: perthie
"Will 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.

Re sub-sub folders
Username: BarryK
"Sub-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.

psavemark boot param
Username: BarryK
"Introducing a new kernel boot parameter. If you have this kernel boot param: [i]psavemark=2[/i] 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.

Rationalised Puppy filenames
Username: BarryK
"I 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.

savemark override
Username: Raffy
"Quote: 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?

Re psubdir
Username: BarryK
"[i]Re psubdir You can still specify it as a kernel boot parameter -- it will prevent the init script from probing other partitions. [/i] 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.

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

SAVEMARK improved
Username: BarryK
"If 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.

Tags: woof