PeasyScale has disappeared from the right-click menu in Rox file manager

[rockedge]

We'll need to examine the boot stanza options that are included in the ISO/CD-ROM. I believe this is the place to start to look at what has been directed for the system start.

Going to attempt to reproduce the bug on some QEMU virtual machines using different Fossapup64's and F96's

UPDATE: I tested a F96-CE_4 ISO booting on a QEMU vm as a CD-ROM. I have a 10 G QEMU HDD split into two ext4 partitions.
I have a small save folder "B" and a puppy_fossapup64_9.6.sfs on /mnt/sda1 and on /mnt/sda2 is another save folder named "A".

When booting the CD-ROM the save folder "B" and the puppy_fossapup64_9.6.sfs on /mnt/sda1 were used in the layered file system when selecting the very first (default) boot option in the Grub4Dos menu.lst on the CD-ROM

@MochiMoppel, @Governor The next test would be selecting to boot with no save file and RAM only and check if the search for the puppy_fossapup64_9.6.sfs is limited to the CD-ROM (ISO) version and not on the partitions.

Further test is to remove all the files for F96-CE_4 in /mnt/sda1 and see how the search goes through /mnt/sda2

UPDATE #2: Tested now with two save folders (A and B) on /mnt/sda1 and puppy_fossapup64_9.6.sfs on /mnt/sda2 and I was given an option to select the save folder (A or B) and the puppy_fossapup64_9.6.sfs on /mnt/sda2 was the one used!

The fdrv, ydrv and zdrv are not loaded when the rootfs SFS is in a different partition that is found during the boot cycle and hardware devices will not work.
To do this it must be declared on the boot stanza kernel command line.

So it is what we've been saying. Puppy Linux is designed to look on the primary root of each partition for usable files that will take precedence over those on the CD-ROM.

The location of the save folder becomes /mnt/home

When the puppy rootfs SFS is removed into a sub-directory like a frugal installation would have, the CD-ROM version is used.

The important fact here is only if Puppy Linux SFS files or save folders/files are in the partition(s) root will they be used with precedence over the CD-ROM versions.

Once the SFS is in a sub-directory it is handled like a frugal install and only SFS files from the CD-ROM will be used

All these tests are using the first boot option on the CD-ROM.

[williwaw]

And it is crazy that I couldn't boot from my CD and actually load the Puppy files on the CD, until I deleted all Puppy files on all partitions

But have you actually deleted all the puppy files on all partitions? Or removed all the devices which could contain puppy files from the machine when you boot the CD?
If so, Fossapup and peasyscale and rightclick should be working now.

If Fossapup CD boot does not work correctly, report back what happens (lots of pics please)

[jamesbond]

I tried to reproduce his problems and now I'm as puzzled as he is.
I burned the ISO and closed the CD as he did.
He reported that he had related files scattered on his internal and external drives and that these files prevented the proper booting of the CD, so I placed a copy of the main sfs and a zdrv on my harddisk:
/mnt/sda5/puppy_fossapup64_9.5.sfs
/mnt/sda5/zdrv_fossapup64_9.5.sfs
No other files, no external devices connected

The CD booted as expected and showed its boot menu. The default seems to be "copy to RAM" and this is what it did, but the boot messages showed that only the main sfs and the zdrv was copied ... suspiciously fast. No adrv and fdrv. As it turns out the CD booted but ignored the sfs files on the CD but loaded the 2 files from the HD instead.

As I said earlier. This is how Puppy behaves, and has behaved, for the longest time.

That's not what I expect from a CD boot.

Your expectation is incorrect when it comes to Puppy.

There is no reason for the CD to poke around in my HD.

There is. As I said earlier, because CD boot is slow, Puppy tries to find its SFS files on harddisk first, and if it finds one, it will load it and use it.

This is not an accident. This is not a bug. It is __BY DESIGN__.

When I booted with "Do not copy to RAM" the SDA5 partition is mounted and - because it's in use - can't be unmounted.

It is expected, because the files from the sda5 are used, not from the CD.

Only when I remove the copy of the main sfs from SDA5 the CD boots correctly with all its sfs files.

Because Puppy cannot find SFS files from harddisk, then it is forced to use the file from the __SLOW__ CD.

Sorry, but I agree with Governor that this is a bug.

You're entitled to your opinion, but others don't think of it that way.
It is in fact a known feature.

Here is a post from 2007, about installing Puppy 3.0.
Please note the second post, from HairyWill.
https://oldforum.puppylinux.com/viewtopic.php?t=23072

I quote:

By all means copy the two .sfs files fom the root of your CD onto the root of the hard disk partition where you have saved your pup_save.2fs file. This will speed up your boot. Apart from that you often won't gain much by installing.

Here's the release notes from Barry for Puppy 3.0:
https://bkhome.org/archive/puppylinux/d ... e-3.01.htm
Of special note, read the section "Boot Parameters".

I quote:

Boot parameters. The 'init' script should now correctly handle the boot parameters 'psubdir', 'pdev1'.
The 'init' bootup script now has rigorous handling of 'psubdir', so a frugal install of vmlinuz, initrd.gz, pup_301.sfs and zdrv_301.sfs in a folder, say 'puppy301', will be recognised. Puppy will automatically search partitions one-deep, however the 'psubdir=puppy301' boot parameter can be given to prevent Puppy from searching anywhere else.

But of course you don't to take my word for it. You can run Puppy 3.0 yourself, it's here: http://distro.ibiblio.org/puppylinux/pu ... monkey.iso

Code: Select all

# truncate -s 1G disk.img
# mkfs.vfat disk.img
# mount -o loop disk.img /mnt/data
# mount -o loop puppy3.0.iso /mnt/cd
# cp /mnt/cd/*.sfs /mnt/data
# umount /mnt/data /mnt/cd
# qemu-system-x86_64 -enable-kvm -m 128 -hda disk.img -cdrom puppy3.0.iso -boot d

And when you're booted up, do "mount" in a terminal and tell me what is mounted in /initrd/mnt/dev_ro2.

xscreenshot-20240606T102146.png (49.8 KiB) Viewed 802 times

--------

Puppy has always been designed to be booted from external storage (CD and USB) but make use of the available internal storage (harddisk) for persistence ("pupsave", as it was known before, before we change it to "savefile"), and for optimisation (loading the SFS files from faster media).

It's a legacy that is still carried until today, as @rockedge has shown in the two post above this one.

It's fine if anybody dislike this feature, or even disagree with the design, and you can take it up with the relevant puppy developer of the day (or, you can roll up your sleeves and make your own pup that does it the way you want it to be).

But to call it is a bug is a stretch, since features like these don't happen by itself. In fact, if you try the same experiment with Puppy 2.14, which is still available here: https://archive.org/details/Puppy_Linux_Series2, you will find that it will behave as you expect: it will boot using files on the CD regardless of the presence of the files on the harddisk.

So why the difference? Because this feature was explicitly added to Puppy 3.0 to improve boot time, and it has stayed there ever since. To be clear, the feature and ability of using SFS files from harddisk was even already there in 2.14, but it was "fenced" so it wasn't activated for CD boot. Puppy 3.0 removed this fence.

Line 995 of /sbin/init, Puppy 2.14. Please note the comment at the top.

Code: Select all

 *) #ransack the entire PC looking for puppy!
  ALLDRIVES="`probedisk 2> /dev/null | grep '^/dev/' | cut -f 1 -d '|' | cut -f 3 -d '/' | tr "\n" " "`"
  findpupfunc $ALLDRIVES
  #...return with PDEV1=hdc FSTYPE=iso9660 PUPSFS=pup_001.sfs (for example)
  guesspmediafunc
  [ ! "$PUPSAVE" ] && searchsavefunc #search for PUPSAVE.
  ;;

----------

I remember this feature very well, as I used it myself, and I was grateful that this feature was there. I had a computer with 64MB of RAM (=so not enough to copy the SFS into RAM), and a very slow CD. Without this feature, when I boot from CD, I'm stuck to using SFS from CD, which is horribly slow to the point of being almost unusable. Each time I opened an app, puppy had to load it from the CD (because not enough RAM for disk cache, remember?). By copying the SFS to the disk and having Puppy boot from CD but used the SFS from the disk (which is about 100 times faster than the CD) automatically, the experience became a lot more bearable; and it made that 64MB RAM PC usable again.

That was (and still is) what Puppy is all about.

[MochiMoppel]

We'll need to examine the boot stanza options that are included in the ISO/CD-ROM. I believe this is the place to start to look at what has been directed for the system start.

Here we go:

Code: Select all

title fossapup64 9.5
  kernel /vmlinuz    pfix=fsck pmedia=cd
  initrd /initrd.gz

title fossapup64 9.5 - Copy SFS files to RAM\n
  kernel /vmlinuz    pmedia=cd pfix=fsck,copy
  initrd /initrd.gz

title fossapup64 9.5 - Don't copy SFS files to RAM\nIf you want more RAM available
  kernel /vmlinuz    pmedia=cd pfix=fsck,nocopy
  initrd /initrd.gz

Looks OK to me.
After failing with the CD boot I was curious to see if I can replicate the bug without booting from CD, i.e. booting from USB.
I can

I have multiple distros on the USB stick, each in its own subfolder. In order to simulate the CD boot as close as possible I copied the fossapup files to the USB root and made a new menu.lst entry:

Code: Select all

kernel /vmlinuz pmedia=usbflash  pfix=nocopy
initrd /initrd.gz

Works perfectly. All sfs files loaded

Now let's try a lie:

Code: Select all

kernel /vmlinuz pmedia=cd  pfix=nocopy
initrd /initrd.gz

Ignores the sfs files on USB and loads main sfs and zdrv from HDD

If Puppy can be confused by a "wrong" pmedia declaration, what happens if there is no pmedia declaration at all? Let's have Puppy figure out the type of boot device by itself:

Code: Select all

kernel /vmlinuz pfix=nocopy
initrd /initrd.gz

This was the biggest shock. Same result as with pmedia=cd
In practical terms it means that a person who has the distro installed on USB and on HDD, he may boot from USB, but with the wrong sfs files. I don't like this.

This can even happen when booting from a distro in a USB subfolder.
In my case this still worked:

Code: Select all

kernel /pup_fossa64_9.5/vmlinuz pmedia=cd  psubdir=/pup_fossa64_9.5 pfix=nocopy
initrd /pup_fossa64_9.5/initrd.gz

This doesn't. Loads sfs from HDD:

Code: Select all

kernel /pup_fossa64_9.5/vmlinuz pmedia=cd  pfix=nocopy
initrd /pup_fossa64_9.5/initrd.gz

[rockedge]

@MochiMoppel that's what I am saying. If the SFS files are on a HDD in any partition's root, so one level deep in the directory structure, that puppy_rootfs SFS will be used.
From any partition it first finds one in.

If the puppy SFS is in any sub-directory on the partition two levels deep (or more) for example in /mnt/sda1/F96_spare_sfs the SFS packages on the CD-ROM will be used.
So if the puppy_rootfs SFS is in a sub-directory it is handled like a frugal install of a Puppy and that SFS will NOT load during a CD-ROM boot.

On some of my machines if USB drives are connected a F9-CE_4 CD-ROM/ISO will search those as well for the puppy_rootfs SFS

[jamesbond]

In practical terms it means that a person who has the distro installed on USB and on HDD, he may boot from USB, but with the wrong sfs files.

In practical terms nothing bad will happen.
1. Most people will only have one puppy installed.
2. Puppy SFS files are versioned, one version of Puppy will not accidentally load other version's files.

[rockedge]

From another post -> https://forum.puppylinux.com/viewtopic. ... 27#p121927

Boot parameters:
pmedia=<atahd|ataflash|usbhd|usbflash|cd>
Indicates the type of boot device.
If it's "cd" then the partitions are searched for a save layer file, the only situation that triggers such a search.*
If the first 3 characters are "usb", then any searching is restricted to only usb devices.
If the last 5 characters are "flash" the top layer in the stack remains the tmpfs in memory, otherwise any found save layer becomes the top layer in the stack.
This boot parameter should always be provided.

* concerning CD boots......
its not a bug, its a documented feature!

[williwaw]

Now let's try a lie:

Code: Select all

kernel /vmlinuz pmedia=cd  pfix=nocopy
initrd /initrd.gz

:shock: Ignores the sfs files on USB and loads main sfs and zdrv from HDD

If Puppy can be confused by a "wrong" pmedia declaration, what happens if there is no pmedia declaration at all? Let's have Puppy figure out the type of boot device by itself:

Code: Select all

kernel /vmlinuz pfix=nocopy
initrd /initrd.gz

:shock: This was the biggest shock. Same result as with pmedia=cd
In practical terms it means that a person who has the distro installed on USB and on HDD, he may boot from USB, but with the wrong sfs files. I don't like this.

Mochi-

and if a person misconfigured the pmedia declaration with a typo? ex. pmedia=ubsflash

[Governor]

@jamesbond @rockedge @geo_c
It appears that everybody thinks that @Governor did some stupid things and just needs to learn how Puppy works.
But what if he is right?

I tried to reproduce his problems and now I'm as puzzled as he is.
I burned the ISO and closed the CD as he did.
He reported that he had related files scattered on his internal and external drives and that these files prevented the proper booting of the CD, so I placed a copy of the main sfs and a zdrv on my harddisk:
/mnt/sda5/puppy_fossapup64_9.5.sfs
/mnt/sda5/zdrv_fossapup64_9.5.sfs
No other files, no external devices connected

The CD booted as expected and showed its boot menu. The default seems to be "copy to RAM" and this is what it did, but the boot messages showed that only the main sfs and the zdrv was copied ... suspiciously fast. No adrv and fdrv. As it turns out the CD booted but ignored the sfs files on the CD but loaded the 2 files from the HD instead. That's not what I expect from a CD boot. There is no reason for the CD to poke around in my HD. When I booted with "Do not copy to RAM" the SDA5 partition is mounted and - because it's in use - can't be unmounted. Only when I remove the copy of the main sfs from SDA5 the CD boots correctly with all its sfs files.

Sorry, but I agree with Governor that this is a bug.

That is the point I have been trying to make. Thank you.
One man's feature is another man's bug.

[Governor]

One man's feature is another man's bug. IMO it is a design flaw, but apparently, it is the Puppy "Holy Grail", and no one is inclined to do anything about it, so there is no point in mentioning it. It is what it is. Geez.
(*shrug...*)

I tried to reproduce his problems and now I'm as puzzled as he is.
I burned the ISO and closed the CD as he did.
He reported that he had related files scattered on his internal and external drives and that these files prevented the proper booting of the CD, so I placed a copy of the main sfs and a zdrv on my harddisk:
/mnt/sda5/puppy_fossapup64_9.5.sfs
/mnt/sda5/zdrv_fossapup64_9.5.sfs
No other files, no external devices connected

The CD booted as expected and showed its boot menu. The default seems to be "copy to RAM" and this is what it did, but the boot messages showed that only the main sfs and the zdrv was copied ... suspiciously fast. No adrv and fdrv. As it turns out the CD booted but ignored the sfs files on the CD but loaded the 2 files from the HD instead.

As I said earlier. This is how Puppy behaves, and has behaved, for the longest time.

That's not what I expect from a CD boot.

Your expectation is incorrect when it comes to Puppy.

There is no reason for the CD to poke around in my HD.

There is. As I said earlier, because CD boot is slow, Puppy tries to find its SFS files on harddisk first, and if it finds one, it will load it and use it.

This is not an accident. This is not a bug. It is __BY DESIGN__.

When I booted with "Do not copy to RAM" the SDA5 partition is mounted and - because it's in use - can't be unmounted.

It is expected, because the files from the sda5 are used, not from the CD.

Only when I remove the copy of the main sfs from SDA5 the CD boots correctly with all its sfs files.

Because Puppy cannot find SFS files from harddisk, then it is forced to use the file from the __SLOW__ CD.

Sorry, but I agree with Governor that this is a bug.

You're entitled to your opinion, but others don't think of it that way.
It is in fact a known feature.

Here is a post from 2007, about installing Puppy 3.0.
Please note the second post, from HairyWill.
https://oldforum.puppylinux.com/viewtopic.php?t=23072

I quote:

By all means copy the two .sfs files fom the root of your CD onto the root of the hard disk partition where you have saved your pup_save.2fs file. This will speed up your boot. Apart from that you often won't gain much by installing.

Here's the release notes from Barry for Puppy 3.0:
https://bkhome.org/archive/puppylinux/d ... e-3.01.htm
Of special note, read the section "Boot Parameters".

I quote:

Boot parameters. The 'init' script should now correctly handle the boot parameters 'psubdir', 'pdev1'.
The 'init' bootup script now has rigorous handling of 'psubdir', so a frugal install of vmlinuz, initrd.gz, pup_301.sfs and zdrv_301.sfs in a folder, say 'puppy301', will be recognised. Puppy will automatically search partitions one-deep, however the 'psubdir=puppy301' boot parameter can be given to prevent Puppy from searching anywhere else.

But of course you don't to take my word for it. You can run Puppy 3.0 yourself, it's here: http://distro.ibiblio.org/puppylinux/pu ... monkey.iso

Code: Select all

# truncate -s 1G disk.img
# mkfs.vfat disk.img
# mount -o loop disk.img /mnt/data
# mount -o loop puppy3.0.iso /mnt/cd
# cp /mnt/cd/*.sfs /mnt/data
# umount /mnt/data /mnt/cd
# qemu-system-x86_64 -enable-kvm -m 128 -hda disk.img -cdrom puppy3.0.iso -boot d

And when you're booted up, do "mount" in a terminal and tell me what is mounted in /initrd/mnt/dev_ro2.

xscreenshot-20240606T102146.png

--------

Puppy has always been designed to be booted from external storage (CD and USB) but make use of the available internal storage (harddisk) for persistence ("pupsave", as it was known before, before we change it to "savefile"), and for optimisation (loading the SFS files from faster media).

It's a legacy that is still carried until today, as @rockedge has shown in the two post above this one.

It's fine if anybody dislike this feature, or even disagree with the design, and you can take it up with the relevant puppy developer of the day (or, you can roll up your sleeves and make your own pup that does it the way you want it to be).

But to call it is a bug is a stretch, since features like these don't happen by itself. In fact, if you try the same experiment with Puppy 2.14, which is still available here: https://archive.org/details/Puppy_Linux_Series2, you will find that it will behave as you expect: it will boot using files on the CD regardless of the presence of the files on the harddisk.

So why the difference? Because this feature was explicitly added to Puppy 3.0 to improve boot time, and it has stayed there ever since. To be clear, the feature and ability of using SFS files from harddisk was even already there in 2.14, but it was "fenced" so it wasn't activated for CD boot. Puppy 3.0 removed this fence.

Line 995 of /sbin/init, Puppy 2.14. Please note the comment at the top.

Code: Select all

 *) #ransack the entire PC looking for puppy!
  ALLDRIVES="`probedisk 2> /dev/null | grep '^/dev/' | cut -f 1 -d '|' | cut -f 3 -d '/' | tr "\n" " "`"
  findpupfunc $ALLDRIVES
  #...return with PDEV1=hdc FSTYPE=iso9660 PUPSFS=pup_001.sfs (for example)
  guesspmediafunc
  [ ! "$PUPSAVE" ] && searchsavefunc #search for PUPSAVE.
  ;;

----------

I remember this feature very well, as I used it myself, and I was grateful that this feature was there. I had a computer with 64MB of RAM (=so not enough to copy the SFS into RAM), and a very slow CD. Without this feature, when I boot from CD, I'm stuck to using SFS from CD, which is horribly slow to the point of being almost unusable. Each time I opened an app, puppy had to load it from the CD (because not enough RAM for disk cache, remember?). By copying the SFS to the disk and having Puppy boot from CD but used the SFS from the disk (which is about 100 times faster than the CD) automatically, the experience became a lot more bearable; and it made that 64MB RAM PC usable again.

That was (and still is) what Puppy is all about.

[geo_c]

Sorry, but I agree with Governor that this is a bug.

That is what I have been trying to tell everyone. Thank you.

Selective reader.

@jamesbond and @rockedge have clearly laid out why this is by design and always has been part of a CD rom boot.

@MochiMoppel had to put the pmedia=cd parameter in the boot stanzas to get the same behavior from a USB boot, which only loads from the hard drive because the boot stanza he inserted informs the initrd that it's booting from a CD. That's a lie, and a computer is a bad judge of character. It does what you tell it, even if it's wrong.

In the second example he doesn't even tell the USB boot where to look for files or what type of media it's located on. It goes looking for them and loads from any attached media. It's what puppy's were designed to do, boot from anywhere and load it's files from anywhere.

The search for system layers on the attached storage media is by design and not a bug.

@MochiMoppel doesn't like it, and neither do you.

But why were you booting from a CD anyway?

I boot from USB all the time with other installs of the same pup on my other attached drives, but probably because all my boot stanzas state the location of the install, I have never experienced a puppy using the sfs files of those installs from other drives.

The information included in my boot stanza is the drive UUID, the path of the kernel location, the drive to find the pdrv, the subdirectory that the install is located, the location of the initrd which builds the filesystem from the sfs files, and the kind of drive it's booting from:

Code: Select all

title fossapup64 9.6 (sda1/fossapup64_9.6)
  find --set-root uuid () a230772e-1e96-xxxxxxxxxx-cde60d1c
  kernel /fossapup64_9.6/vmlinuz  pdrv=a230772e-1e96-xxxxxxxxxx-cde60d1c  psubdir=/fossapup64_9.6 pmedia=atahd pfix=fsck
  initrd /fossapup64_9.6/initrd.gz
  

It's pretty amazing to me that @MochiMoppel could boot a puppy and tell it nothing like that, and it still finds enough files in different place to try and cobble together a system.

But the result is you'll get a unintended locked drive somewhere because the system is using files from it.

[williwaw]

...no one is inclined to do anything about it

WTF

[Governor]

@MochiMoppel that's what I am saying. If the SFS files are on a HDD in any partition's root, so one level deep in the directory structure, that puppy_rootfs SFS will be used.
From any partition it first finds one in.

If the puppy SFS is in any sub-directory on the partition two levels deep (or more) for example in /mnt/sda1/F96_spare_sfs the SFS packages on the CD-ROM will be used.
So if the puppy_rootfs SFS is in a sub-directory it is handled like a frugal install of a Puppy and that SFS will NOT load during a CD-ROM boot.

On some of my machines if USB drives are connected a F9-CE_4 CD-ROM/ISO will search those as well for the puppy_rootfs SFS

This is helpful. Thank you.

[jamesbond]

One man's feature is another man's bug.

A bug is something that is not supposed to happen.
A feature is something that is deliberately put in, with effort, to make it happen.

If you choose to ignore that despite our repeated explanations, and still intent on calling everything that you don't like or don't understand as "bugs", then please go ahead, no one's going to stop you.

The one who loses the most is yourself.

If you admit that this is a feature that you previously didn't understand (or missed), it will motivate you to spend more time, reading documentations, asking questions, etc to learn about Puppy; and one day, you will become a Puppy expert and is able to bend Puppy to do your will. Or at least, have enough arguments to convince Puppy developers to "fix" what you perceive to be a "deficiency".

If on the other hand you continue to refuse to accept the fact that you didn't understand Puppy, then you have not learnt anything. Nothing we say here will matter to you since you reject and argue instead - and that being the case, I see no reason why we should waste our time responding to someone who deliberately chooses not to listen

IMO it is a design flaw,

You don't like the design, I understand that. That's fine; we just have to agree to disagree on this, because there are others who like it.

but apparently, it is the Puppy "Holy Grail"

Your words. No one else said that this is "holy grail" or anything like that. We only said that it is a feature, and a feature that has existed for a very long time.

and no one is inclined to do anything about it,

Obvious, isn't it? Because it is __NOT__ a problem to anyone else. This forum (and the old forum) is full of bugs reports, and they would eventually got fixed if those were genuine bugs. I don't ever recall anyone ever raising this particular feature as "bug", until now.

Well if you want to get someone to fix it, then you have to convince the developers that this is indeed a "bug" that needs fixing. You've already convinced @MochiMoppel, perhaps he can help you

so there is no point in mentioning it. It is what it is. Geez.

Of course there is point in mentioning it. At least now you know that this is a __DESIGNED-IN__ feature, that it is not an "accident".

-----

On the side note, how did those SFS files get into your harddisk in the first place?
Files don't move themselves from USB or CD to harddisks

-----

It's pretty amazing to me that @MochiMoppel could boot a puppy and tell it nothing like that, and it still finds enough files in different place to try and cobble together a system.

Indeed!

[Governor]

One man's feature is another man's bug.

Technically, not a bug, even though it may feel like one or give that impression.
IMHO:
A bug is when an intended action or outcome is unexpectedly prevented from happening.

A design flaw is when a function or feature has an unexpected adverse outcome or side effect. IMHO, this would apply, in this case (except for Puppy insiders who can take steps beforehand to avoid the pitfall).

If your bootloader configuration says to "search for files and use the first one you can find", well, then exactly which files will be used would be ... rather random

Ordinary computer users expect that when they boot a CD, the system files on the CD are what are actually loaded, and not "random" system files on a hdd. AFAIK, only Puppy insiders would know that this could happen. When an ordinary (no Puppy insider) computer user sets the BIOS to boot from the CD and boots up, they expect and naturally assume that they have actually booted from the CD.

If I understand the explanation correctly, when booting from a CD, if there are 'system files' in the root of any hdd partition, the first instance found will be loaded.

Suppose a problem has developed when booting my hdd installation which the bootmenu points to. If I boot my Puppy boot CD, I may be loading the same problematic installation as before, or quite possibly a different set of 'system files' on the hdd. And if the boot CD is closed, there is no way to change the boot menu. Then what?

If you choose to ignore that despite our repeated explanations, and still intent on calling everything that you don't like or don't understand as "bugs", then please go ahead, no one's going to stop you.

I am neither hopeless nor an idiot, ok. Even though I have years of computer experience, I realize I would not even reach the knees of most people in this forum, and I would not reach the ankles of many others. I am not ignoring suggestions or explanations.

The one who loses the most is yourself.

If you admit that this is a feature that you previously didn't understand (or missed), it will motivate you to spend more time, reading documentations, asking questions, etc to learn about Puppy; and one day, you will become a Puppy expert and is able to bend Puppy to do your will. Or at least, have enough arguments to convince Puppy developers to "fix" what you perceive to be a "deficiency".

I can see that Puppy insiders could find this a useful feature, but most other people who boot from a CD actually want to load the system files on the CD and not another media.

If on the other hand you continue to refuse to accept the fact that you didn't understand Puppy, then you have not learnt anything. Nothing we say here will matter to you since you reject and argue instead - and that being the case, I see no reason why we should waste our time responding to someone who deliberately chooses not to listen

I think things have taken a turn for the better. It looks like I have both a fossapup and an Airedale bootable thumb drive with persistence.

IMO it is a design flaw,

You don't like the design, I understand that. That's fine; we just have to agree to disagree on this, because there are others who like it.

Excluding the “CD boots your hdd” feature, I have uncovered several design flaws in the GUI which hinder my working efficiently, but apparently nobody cares about these, and nobody is working on the OS itself (so I’ve been told). I find it all very frustrating. At link below is an example of such a design feature in the GUI. Why it is a feature to intentionally have virtually unreadable menu titles is a mystery to me. Can you explain this? Can anyone?
download/file.php?mode=view&id=23858

On the side note, how did those SFS files get into your harddisk in the first place?
Files don't move themselves from USB or CD to harddisks

Not funny, considering it was Puppy who did it!! I was asked if I wanted to create savefolders or savefiles several times. And since the computer never used the saves on bootup, I kept trying to save in different locations hoping that it might work on the next boot, but it never did. And I know this because on re-boot all settings were set to the default.
Thanks!

[rockedge]

Not funny, considering it was Puppy who did it!!

I'll say it one more time......you did it when you made those "saves"....you had to go through the query that asks to save some components to the partition or not to speed up the boot times or not.

I was asked if I wanted to create savefolders or savefiles several times

You did go through this step without really understanding all of the options (reading the question fully) what choosing "yes" meant. Because each time the make a save mechanism is in motion you are asked whether or not to copy those files.

That is how those files got there.

[Governor]

Not funny, considering it was Puppy who did it!!

I'll say it one more time......you did it when you made those "saves"....you had to go through the query that asks to save some components to the partition or not to speed up the boot times or not.

I was asked if I wanted to create savefolders or savefiles several times

You did go through this step without really understanding all of the options (reading the question fully) what choosing "yes" meant. Because each time the make a save mechanism is in motion you are asked whether or not to copy those files.

That is how those files got there.

My understanding was that the save would be used on the next boot. That did not happen, but I did not stop trying. Now I know why it did not work. Because I was booting from the CD and, as explained, the system files being used on boot were the first system files found on the hdd, and not the more recent saves, and not the system files on the CD either.

[rockedge]

@Governor This will really drive you nuts.....the searching for and finding of which save folder to use is a another story, different than the SFS files.

I still don't understand why all those save files or folders couldn't be used or were not found. I mean over the course of time I have tried out a big variety of ways to run a Puppy Linux and hit walls with some really experimental installations but can't say I've had any trouble like this when I first started using Puppy Linux.

[mikewalsh]

I well remember my own early days with Puppy.

Since I wasn't at all clued-up with the USB install option in those days, I of course opted for the CD method for trying Puppy out (this was in late 2014, just after Tahrpup 6.0 CE had been released).

In my case, I was so pleased to find a version of Linux that booted straight to a fully-functional desktop - which also correctly filled the screen! - that after a couple of hours I had already determined that Puppy would fit my requirements. Within a couple more hours, Windoze was but an already-receding memory, and Tahrpup had taken its place on both the anciente Dell laptop AND the big Compaq desktop rig. I've not looked-back since.

Because I installed Puppy to hard drive so soon - due to just wanting MyCrudSoft out of my life, ASAP - I never discovered the business of placing the save on faster, internal media while still booting from CD. Didn't have any need to.....Tahrpup did everything I wanted, so it went straight onto the re-partitioned internal drive, and, following advice, into its own sub-directory (where everything just "worked").

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

But, er, yes; CD booting IS slow. I still have a CD of Fossapup set-up, along with a flash drive populated with a save-folder and a bunch of 'portable' apps, & my trusty wireless 'hot-spot', for the occasions when I go and see an elderly mate a few miles away. He describes himself as a 'tech dinosaur'; he bought himself a Dell desktop many years ago with Vista pre-installed, although he never really used it very much. The updates got so far behind, it reached the stage where it was no longer ABLE to update. I introduced him to Puppy some years ago (though he couldn't understand how Puppy works), but the issue is that the BIOS on his machine - the last update made for it - no longer recognises USB drives to boot from, because the firmware on modern USB drives now declares them to be USB-HDDs.....and his BIOS doesn't understand that. Which gels neatly with the following point:-

He didn't want me to wipe the internal drive and install Puppy - always had some vague notion about "resurrecting" Vista, though I told him it would never happen! - so I respected his wishes, and our Pup always ran from external media.....and Vista just sits there, mouldering away, and completely useless.

When I go and see him now, I plug the flash-drive in, boot Fossapup from CD - it finds the 'save' on the flash drive because I've told it to do so - and use the portable browsers & apps to do stuff. For occasional usage, it all works very nicely......but I, personally, wouldn't want to run it like that all the time.

Our Pup's nothing if not versatile...

Mike.