MochiMoppel wrote: ↑Wed Jun 05, 2024 3:50 pm
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:
HairyWill, Oct 2007 wrote: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:
Puppylinux 3.0 release wrote: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 804 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.
Ignores the sfs files on USB and loads main sfs and zdrv from HDD
