Puppy 107 LiveCD will not boot with less than 64MB and no swap space. The copy to new_root at the end of the init script fails (out of space in new_root) which causes an endless loop later on, in rc.sysinit.
The cause seems to be that the tmpfs size SIZEFILLK of 12288 used in this case is no longer quite big enough. Please increase this parameter in future releases. (Derived from /root0/.etc/ramdiskfssize etc via all that complex logic that makes up the bulk of the init script?)
However, the whole approach appears to be some sort of legacy-holdover, since tmpfs only takes what it really needs, anyway -- so why not make the size parameter effectively infinite? I guess, the default is half RAM, but I'd rather it were bigger, so the parameter would have to be provided. 500m? 999m? 100% of ram? 80% of ram? (Does something blow up if you specify a size parameter larger than ram?)
Maybe making this parameter always "very large" would simplify the rest of init, and whatever elsewhere cares about these related paramters?
This is all based on one day of agonizing debugging on a DOS-boot-based CF-IDE, using Gujin and Linld. I was trying to find out why Linld was failing to boot (in 32 or 48MB), but it turned out the reason was that Gujin was "cheating" -- my Gujin 1.2 boot is failing to get the full /lib when copying to new_root, getting 5.7M instead of 7.4M due to some glitch, so it does not bump into the 12288 limit. (And for some reason I've never missed the 1.7M of lib contents, never took the error messages seriously -- now I need to track them down.)
I won't be sure of all this until someone remasters the CD and tries it out...
Question/discussion:
The whole process of copying over most all of <image? - 13MB> to make a new root seems unfortunate, wasteful in theory... Why? Why can't the old stuff just be edited?
It looks like everything is being done in ram, but not truly a direct copy -- it looks like the copy is passing through "cached memory" so we actually have transiently at least three copies of most everything (if you have plenty of ram)?
Would it be feasible/more efficient for some or all of those copies to new_root be moves instead?
increase tmpfs size in init
I experimented just now with setting the SIZEFILLK to 999999k when the tmpfs is made before the init filesystem copies. Everything seemed to work fine, through to the desktop GUI.
But even though that is fine for messing around, it probably is not a serious option. You get a persistent tmpfs that claims to be 1GB. There are bound to be troubles and complaints...
So I guess the agressive option would be to set it to something like swapspace + (90% of physcial ram size). Then in almost all cases people would run out of ram before they filled up the tmpfs, but the tmpfs free space would not be too too misleading.
But even though that is fine for messing around, it probably is not a serious option. You get a persistent tmpfs that claims to be 1GB. There are bound to be troubles and complaints...
So I guess the agressive option would be to set it to something like swapspace + (90% of physcial ram size). Then in almost all cases people would run out of ram before they filled up the tmpfs, but the tmpfs free space would not be too too misleading.