It is evident that this forum is littered with posts relating to boot issues with typically either:
1. The main SFS or save-file not being found or
2. The incorrect sfs or save-file being loaded.
These issues generally crop up when multiple pups are in use or more advanced boot techniques are being used where the component parts of puppy are being held on different drives, sub-directories and partitions.
I am aware that BK's philosophy, with which I totally agree, is that Puppy should in the main (with the possible exception of pmedia=) be capable of booting without other boot codes & be clever enough to work things out for itself.
In addition new users should not have to concern themselves with complex boot codes.
Currently the additional codes are intended by him to provide hints/help to Puppy when more complex arrangements are deployed.
This is fine for non-advanced use as probably 90% of users will have all the puppy files together in one directory.
The current problem with advanced use seems to be that the boot codes can sometimes conflict with or undermine the search logic that hunts down the location of firstly the save-file(s) and then the main sfs & any additional sfs files that the selected save-file calls for to be loaded. Often removing a boot code can help but more often than not one has to hit on the right combination of codes by a process of trial and error.
A couple of real world working examples:
CASE 1: Kernel on 16 MEG Smartmedia with main sfs & savefile on NTFS HDD (sda1)
Code: Select all
LABEL 5332
MENU LABEL Slacko 5.3.3.2 05/07/12
KERNEL /p5332/vmlinuz
APPEND initrd=/p5332/initrd.gz pmedia=atahd pupsfs=sda1:/p5332/puppy_slacko_5.3.3.2.sfs pdev1=sda1
CASE 2: Kernel on first Fat32 partition of USB2 flash main sfs & save file on 2nd ext4 partition of stick.
Code: Select all
LABEL 5332
MENU LABEL Slacko 5.3.3.2 05/07/12
KERNEL /p5332/vmlinuz
APPEND initrd=/p5332/initrd.gz pmedia=usbflash pupsfs=sdb2:/p5332/puppy_slacko_5.3.3.2.sfs psavemark=2
Both of the above were a nightmare to get right. It is of course a matter for BK, but what I propose is a new boot code (say SEARCH=NO) that would totally override the search logic and codes to allow for the precise location of the following to be specified:
A: The location of vmlinuz & initrd
B: The drive, partition & directory containing the main sfs and any additional sfs files.
C: The drive, partition & directory containing the save-file(s)
This would, I believe, eliminate the uncertainty and knock this thorny issue on the head once and for all.
If UUIDs could also be adopted so much the better.