(old)Puppy Linux Discussion Forum

shinobar wrote:I remember old persisting bug in finding the main sfs.
It may occur when you have multiple puppy_slacko_5.3.5.3.sfs in your PC...

It's not that. But I moved the sfs file to the root of a different partition than the boot partition and it WORKED!

I will have to set up some other machines to test this more.

@rcrsn51, 01micko
Don't you have another full installed slacko in the same PC?

Does using the UUID help?

shinobar wrote:@rcrsn51, 01micko
Don't you have another full installed slacko in the same PC?

Mines an old spup, that I keep updating

01micko wrote:Does using the UUID help?

Legacy GRUB doesn't use UUID's.

shinobar wrote:@rcrsn51, 01micko
Don't you have another full installed slacko in the same PC?

No. I have a frugal install of 533 in another partition. But deleting it didn't change anything.

@rcrsn51, 01micko
I have made some tests. And i made another frugal install on sda3/slacko-pae.
In this case, booted off from the sdc2 but the puppy took the sfs from sda3/slacko-pae.

Next, i removed the main sfs from sda3/slacko-pae but left the vmlinuz and initrd.gz there.
That is, there are two vmlinuz, sdc2 and sda3/slacko-pae, but the sfs is only at sdc2.
In this case, same booting off from the sdc2, the puppy maybe found the vmlinuz at sda3/slacko-pae, but failed to find the sfs.
I got 'puppy_slacko-5.3.5.3.sfs not found!'.

shinobar wrote:Next, i removed the main sfs from sda3/slacko-pae but left the vmlinuz and initrd.gz there. That is, there are two vmlinuz, sdc2 and sda3/slacko-pae, but the sfs is only at sdc2.In this case, same booting off from the sdc2, the puppy maybe found the vmlinuz at sda3/slacko-pae, but failed to find the sfs.I got 'puppy_slacko-5.3.5.3.sfs not found!'.

Exactly! I just found the same thing in my setup. I routinely have subfolders with backup copies of vmlinuz and initrd.gz. Their presence is keeping 5353 from finding its sfs file. If I delete them so the only copies are at the root, it works.

But this is the only Puppy I have ever seen that works this way. Even the latest Precise doesn't care about the extra copies.

rcrsn51 wrote:

shinobar wrote:Next, i removed the main sfs from sda3/slacko-pae but left the vmlinuz and initrd.gz there. That is, there are two vmlinuz, sdc2 and sda3/slacko-pae, but the sfs is only at sdc2.In this case, same booting off from the sdc2, the puppy maybe found the vmlinuz at sda3/slacko-pae, but failed to find the sfs.I got 'puppy_slacko-5.3.5.3.sfs not found!'.

Exactly! I just found the same thing in my setup. I routinely have subfolders with backup copies of vmlinuz and initrd.gz. Their presence is keeping 5353 from finding its sfs file. If I delete them so the only copies are at the root, it works.

But this is the only Puppy I have ever seen that works this way. Even the latest Precise doesn't care about the extra copies.

It occurs when you have a copy of the vmlinuz in a subfolder sdxn/foo/vmlinz, where x is the drive number and n as the partition number, and only if the sdxn is earlier than the one of the booting partition. I am not sure it occurs or not even if you specify the 'psubdir'.

For example, suppose a full install on sda3, which has sda3/boot/vmlinuz but no main sfs.
No problem with another frugal install on sda2. But a frugal install on sda5 will fail.

The bug is in the function 'search_func' in the initrd introduced on 2011-04-25 and persists still now. I don't know about the older woof.

I stand corrected about Slacko 533 - it has the same bug. If the three core files are at the root and the first two files are also in a subfolder, it fails.

But if you move everything one level deeper, it works, ie. the three core files are in a subfolder and the backups are in a sub-sub-folder. But in that case, there would be a psubdir argument.

I'm guessing that the search logic goes like this:

If no psubdir argument is used, start looking in subfolders FIRST.

If you find vmlinuz and initrd.gz in a subfolder, then expect to find the sfs file there too. If it's not, quit with an error.

If you can't find the two files in any subfolders, then go back to the root and look there next.

Maybe there are other Puppies that work this way, I just never had that particular setup.

rcrsn51 wrote:If you find vmlinuz and initrd.gz in a subfolder, then expect to find the sfs file there too. If it's not, quit with an error.

In exact, if puppy finds vmlinuz in a subfolder, it sets the subfolder name as the PSUBDIR, then expect to find the sfs file in a subfolder with the same name.

It likely occurs when one has a full install, which has /boot/vmlinuz, and another frugal install at later partitions. Frugal install at earlier partitions than the full have no problem.

This is more common that I realized. Wary 522 does the same thing - looks in subfolders before it looks at the root.

At the moment, Precise is the only one that does it in the "right" order.

rcrsn51 wrote:At the moment, Precise is the only one that does it in the "right" order.

I think the precise beta has the same initrd dated 2012-03-28 and the same issue as the slacko beta has.

I checked Precise 5393 again and it does it right. If there is no psubdir argument, it finds the three files at the root and is not confused by other files in subfolders.

rcrsn51 wrote:I checked Precise 5393 again and it does it right. If there is no psubdir argument, it finds the three files at the root and is not confused by other files in subfolders.

Confirm the copy of the vmlinuz is the same.

I tested the Precise 5393.
Note that the presice is installed in a subfolder, not at the root in my case.
'pmedia=ataflash' because the sda is a SSD. The uuid is that of sda3. I copied sda3/precise/vmlinuz to sda2/Backups/vmlinuz.
Booted off with the above parameter got success.

Next, i removed the 'psubdir' parameter. Booted off and failed... 'puppy_presice_5.3.93.sfs not found.'

In this case, the puppy found the sda2/Backups/vmlinuz and set the PSUBDIR to 'Backups' and failed to find the sda3/presice/puppy_presice_5.3.93.sfs.
The result may be the same if the frugal install was at root.

At the risk of beating this little exercise to death, I tried "psubdir=/". It worked! It picked the files at the root of the partition before looking in subfolders.

Which makes sense, except that psubdir doesn't usually need a leading slash.

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)
CASE 2: Kernel on first Fat32 partition of USB2 flash main sfs & save file on 2nd ext4 partition of stick.
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.

I made a frugal install, put the .sfs file in both the root and subfolder where the other files were (slackobeta). Still, on boot the program can't find the meaty .sfs file.

The psubdir trick did it. I copies the file to the root and then directed the boot to that. I think my post was a bit premature, before I had carefully read the previous posts -- sorry.

I should have read all pages.

Some of you refer to Precise but the thread is about slacko
so both of them then search same way and thus get confused?

Would be helpful if you guys took it up with Barry then
so we get an official way to solve this once for all.
Just my sloppy suggestion

Some Homebank icons are missing and I have made i18n-ed firewallstate.