Puppy Linux Discussion Forum

So fatdog let's you use a savefile or a save directory .... why not allow a save partition! Currently I have a need for this especially integrated in the new usb-boot images provided, having priority during boot. This will prevent accidental deletion of savefile or directory (or renaming). I am tryinǵ to create as failsafe as possible an sdcard setup for a novice user! So currently the disk image has two partitions plus free space, OEM and OS. So I need the image to have a third partition named SAVEP or whatever. The init script would need to be reworked to mount SAVEP as working ram layer (i guess).

Any instructions to do this myself appreciated.

stemsee

stemsee wrote: Mon Apr 25, 2022 9:10 am

So fatdog let's you use a savefile or a save directory .... why not allow a save partition! Currently I have a need for this especially integrated in the new usb-boot images provided, having priority during boot. This will prevent accidental deletion of savefile or directory (or renaming). I am tryinǵ to create as failsafe as possible an sdcard setup for a novice user! So currently the disk image has two partitions plus free space, OEM and OS. So I need the image to have a third partition named SAVEP or whatever. The init script would need to be reworked to mount SAVEP as working ram layer (i guess).

Any instructions to do this myself appreciated.

stemsee

From Fatdog help (fatdog-help.sh), savefile section

savefile=direct:device:sda1

There is also amongst others save to NBD (a networked device (available on host port)). Personally I use multi, which is the old multi-session CD style, where a new additional sfs of that save are created/stored, so you have a audit trail (all of the sfs's get loaded/layered in sequence at bootup), so if the last save screws things up, remove that multi..save...sfs file and you're back to booting to the saved version immediately prior to that. There is also a switch option to boot and exclude n number of prior saves. Boot files (main fd64.sfs) can also be booted multiple ways, including pulling it down across the net.

All very flexible Fatdog team.

One of my boots is a 7MB vmlinux with integral rootfs.cpio, just busybox and dropbear (ssh), both statically compiled. With that I can boot, tether my android phone for network access and ssh or scp to anywhere i.e. pull down other boot choices. In the past I did compile in kexec ... which enables you to boot other vmlinuz directly rather than having to physically reboot the machine/device.

So probably using uuid would be more reliable.
In that case I just need recreate the USB images with modified grub.cfg
Cheers

rufwoof wrote: Mon Apr 25, 2022 12:43 pm

From Fatdog help (fatdog-help.sh), savefile section

savefile=direct:device:sda1

This is actually incorrect! The help states;

Some examples:
savefile=direct:device:sda1
savefile named fd64save.ext4 located in root directory of /dev/sda1, save directly to it

that means the device sda1 is not the save to device, rather it is the location of a savefile fd64save.ext4 ... in fact fatdog puts its icon on the desktop drive icon, but nothing gets saved, and savefile creator script fires up on shutdown.

So my first feature request is still valid. It's almost the same as just having a savefolder fd64save, but that could be deleted or moved or renamed, that's why i want to be able to specify the device for direct saving.

cheers
stemsee

I have found that symlinking /mnt/mmcblk0p3 to /mnt/mmcblk0p3/fd64save.ext does the trick! Where fd64save.ext4 is the symlink and not a savefile.