Puppy linux has a recurring problem about not finding the sfs file during the boot process. Have you also seen the error “sfs not found. Dropping out to initial ramdisk console….” ? Here’s an out-of-band hard-fix to that problem: use netcat to preposition the file on hard disk instead of having the OS configuration script fail to read the file off disk.
The sfs file is a “squished file system” that is needed to run puppy. For some reason, although the boot CDROM has the file, certain hardware combinations make it impossible to read this file only during the boot sequence.
In my case, none of the available fixes out on the Internet worked. My problem occurred booting v7.5.1 Xenial puppy an older (2002) Dell X200 laptop computer. If you read the various forums, you’ll see the problem and various boot or puppy configuration parameter changes that seem to work some times to fix the problem. Or sometimes, it’s about the CDROM files recorded with in all-capital filenames verus case-sensitive names that Linux needs, or Rock Ridge (linux-ish) vs. Joliet (Microsoft-ish) CDROM filename extensions.
- http://www.murga-linux.com/puppy/viewtopic.php?p=428108 (Jun 2010, v5.0.1)
- https://www.linuxquestions.org/questions/puppy-71/5-1-2-sfs-not-found-890873 (July 2011 v5.1.2)
- http://www.murga-linux.com/puppy/viewtopic.php?t=84558 (Feb 2012 several versions)
- https://www.howtogeek.com/forum/topic/formatted-ext-3-intalled-linux-lupu-501sfs-not-found-cant-access-tty (Jun 2013 v5.0.1)
- https://superuser.com/questions/1280162/sfs-file-not-found-error-when-booting-live-puppy-linux (Dec 2017 v6.0.5)
- https://www.reddit.com/r/puppylinux/comments/7521lm/puppy_linux_cannot_find_the_sfs_file (Jun 2018 v5.7.1)
These are all “in band” solutions – using Puppy to mitigate the problem. Because none of them worked for me, I needed an “out of band” solution that didn’t use Puppy or linux itself.
It was clear that the .sfs file was not readable from my computer CDROM during the boot sequence. The same CDROM booted up Xenial Puppy fine on other computers and I noted that the other computers had an .sfs file available on the associated hard drive in the computer. So I decided to skip the solutions of getting some configuration correct. Instead, rather than fix the CDROM read, I’d simply stop ~trying~ to read the sfs file off the CROM. I manually put a copy of the sfs file onto a virgin hard drive I had recently put into the target system.
Here’s the plan:
1) ready a new hard drive to hold an sfs file
2) put a copy of sfs onto the hard drive
3) boot successfully when Puppy finds the hard drive copy of the sfs file instead of the CDROM copy.
Without any other OS to boot, I booted up a 3.5″ floppy 1.77 MB linux distribution tomsrtbt v2.103.0 (http://www.toms.net/rb). The BIOS boot screen showed that the new hard drive was available, so here’s how I prepped it:
fdisk /dev/hda mkdosfs -v -F 32 -n 80GBX200 /dev/hda1 mkdir test mount -t vfat /dev/hda1 test
I used fdisk menus to make a single partition of type 0x0B W95 FAT32. I also set the bootable flag intending to eventually boot from the new hard drive. When mounting the partition, be sure to specify the vfat because that will allow long filenames. If you allow mount to chose the filetype, it will choose type “msdos”, which allows only 8-character filenames.
I couldn’t figure out which /dev tomsrtbt might access the CDROM at (later Puppy linux showed it mounted as /dev/sr0). But in any case, I didn’t think tomrtbt was going to be able to read it, so the plan is to read the sfs file off the Puppy CDROM on a different Windows computer and then move a copy to the target system using my local ethernet. In order to connect tomsrtbt to my local network behind a router, here’s what I used:
ifconfig eth0 10.0.0.130 ifconfig eth0 netmask 255.255.255.0 route add default gw 10.0.0.1 echo "name server 10.0.0.1" > /etc/resolv.conf ping www.google.com
BTW, the ethernet access worked flawlessly for tomsrtbt. When I eventual was able to boot up under Puppy v7.5.1, it doesn’t even see the ethernet hardware. This is not wireless. It is good old fashioned wired ethernet, and that version of Puppy can’t find it. I can’t fix the problem because it’s not a configuration or network configuration problem. It won’t even find the motherboard ethernet port. That’s a foul – unacceptable. Puppy should be more capable than a single 1.77 MB distribution of Linux!
I used a spare Windows computer to read the sfs file off the Puppy CDROM, and then used netcat to get a copy over on the target computer new hard drive. I used the netcat for Windows from https://joncraton.org/blog/46/netcat-for-windows, which offers a clean simple exectable and source code.
On the tomsrtbt machine,
nc -v -l -p22222 > /dev/hda/puppy_xenialpup_7.5.sfs
On the windows machine,
type puppy_xenialpup_7.5.sfs | nc -w3 10.0.0.103 22222
nc -w3 10.0.0.103 22222 < puppy_xenialpup_7.5.sfs
-v means be verbose
-l listens for someone to call
> redirects from stdout to a file
| pipes stdout of type to stdin of nc
< redirects from a file to stdin
-w3 times out after 3 seconds of inactivity
The transfer took longer than I would have expected. If you want to check on the progress, Alt-F2 to the second of tomsrtbt four console screens, log in again, and cd over to the destination directory and ls -l to see a snapshot of how much has been downloaded.
When the transfer is complete, use the md5sum program to confirm that it transferred with no errors. Use tomsrtbt to put a copy of the file in the root hard drive directory.
At this point, I tried to again boot up the Puppy CDROM and it worked fine.