Recent developement of the BootFlash USB install option

[perdido]

The latest BionicPup32 19.03 now has the built-in capability of writing a hybrid .iso to USB stick/thumb drive and recovering the unused space on the stick as an added partition.
How cool is that? Some additional background info here.

One improvement to this process would be to have the newly created partition of the recovered drive space on the USB-stick be available to be used for a save directory or save file.
So far I have been able to create a save directory on the USB-stick at shutdown but the system hangs while creating a save file.
.
Currently the session will save to the partition on the USB-stick but does not recognize the save folder on the Live USB-stick while booting and the folder does not get loaded.
Having the additional space available for storage on the USB-stick is great and convenient but having the capability to boot from a save created on the stick would be marvelous

Hopefully using the recovered storage/partition on the USB-stick for a puppy savefile/directory is already on the drawing board
"Taking the puppy out for a walk" is being redefined.

My thanks to the puppy developers for this new variation of install that is taking puppy to the next level in portability and security.

.

[rufwoof]

Have you ever tried Fatdog and its multi-session usb save style choice perdido?

http://murga-linux.com/puppy/viewtopic.php?t=116147

Once you have a bootable usb so the mbr, bootloader, kernel (vmlinuz), initrd, main sfs and save files are all on that, with the system totally loaded into ram after bootup, then you can physically unplug the usb once booted, so no potential for it to be cracked.

Keep data separate, only use saves for configuration changes and only after booting clean, making changes, saving. Keeping data on a removable storage device means you can boot clean, edit data, shutdown. Or otherwise (more usually) just boot without the data device attached, browse/whatever, shutdown. If you also set up a encrypted swap partition, and use that for your work area, then after shutdown there's no residual trace of data (easily) visible.

Such a setup is impervious to virus attacks, ransomware ...etc. Only a single session might be cracked and provided you reboot between doing sensitive activities such as online banking/data editing, then even then the risk is low-value. Pretty much invalidates the need for the laptops integral HDD, other than for use as a encrypted swap file/partition.

Typically, once initially set up and configured as I like, I rarely save. Just reboot the exact same system time after time. The exception is for chrome updates, where I boot, install the latest chrome version, save. Multi-session usb saving is very similar to multi-session CD/DVD saves, another save file is created for each separate save - so you have a audit trail. That's also nice as you can roll back to earlier save versions, such as if you decide that you' rather not have saved the last session.

[perdido]

Hi rufwoof,

I have not used fatdog but I see a variation of what you wrote here http://murga-linux.com/puppy/viewtopic. ... 56#1028256 that may be useful for my immediate requirements.

My goal is to run a remastered hybrid .iso that has been dd to the USB stick and has the unused space reclaimed as a partition. Then use the reclaimed space on that USB partition to mount a save file or directory.
I see a possibility of doing that using some variation of

Code: Select all

savefile=direct:multi:sda1::

on the kernel line and sticking it into the isolinux.cfg before remastering, having one of the menu options during boot to be boot using a save from a particular partition or other variations, etc.

I will report back with my findings trying that, could be a workaround there just looking for a place to happen.
Thanks for the interesting links

.

[perdido]

Did some experimenting with the isolinux.cfg kernel line and the upupbb32 19.03.iso that was dd installed to usb stick.
Had no success with any variant of parameters to get it to find a savefile on the usb stick the system was booting from.
---------------------------
Now the good stuff.
Burned (dd) a virgin Fatdog64-802.iso to USB using the upupbb32 19.03 install tools, saved a session to the usb sdb3 partition as a savefile and Fatdog will load the savefile at boot
from the same usb it boots from by using the "Start Fatdog with savefile in USB device" boot option, easy to do and no monkeying around with boot parameters. Nice.

The kernel line used for that boot in the Fatdog64-802 isolinux.cfg is

Code: Select all

append=rootfstype=ramfs waitdev=5

Notice that it does not contain a

Code: Select all

savefile=direct:

parameter as referenced in this post http://murga-linux.com/puppy/viewtopic. ... 56#1028256, though the post was referencing menu.lst and not isolinux.cfg.
I would think most every parameter available in isolinux.cfg is also available in syslinux.cfg - for whatever anyone might wish to imagine doing there.

The dd to usb of the fatdog64-802 hybrid .iso is one route to take if all other methods with the upupbb32 .iso fail, I have yet to try the isolinux.cfg kernel line that works for fatdog64-802
in the upupbb32 experiment but will do another round of testing upupbb32 before giving up.
-----------------------------------
One item I did not try in the kernel line in isolinux.cfg using the same dd to usb install method of the upupbb32 19.03 hybrid .iso was adding a

Code: Select all

waitdev=5

I'm not sure if that parameter is available outside of Fatdog, I also ran into some other parameters for the kernel line that are Fatdog specific and do not seem to do anything in upupbb32

.

[bigpup]

Fatdog is not a normal Puppy.
It uses boot options that normal Puppy does not use.
Normal Puppy uses boot options that Fatdog does not use.

[mikeslr]

Bigdog is correct. However, Puppy [that is boot-loaders for Puppy] may have equivalent options. You can find commonly used Fatdog boot options here, https://distro.ibiblio.org/fatdog/web/f ... tions.html

As I read the instructions regarding waitdev it delays the boot process by the number of seconds that follow the = sign, e.g. waitdev=5 means wait 5 seconds.

The equivalent argument when using grub4dos would be to place the following at the top of the file, that is above the first menu listing: timeout 5.

A reasonable hypothesis is that every boot-loader will provide an argument to accomplish anything every other boot-loader provides. But the commands and syntax are likely to differ.

Essentially, you stand in the position of translator.

[rcrsn51]

As I read the instructions regarding waitdev it delays the boot process by the number of seconds that follow the = sign, e.g. waitdev=5 means wait 5 seconds.

The equivalent argument when using grub4dos would be to place the following at the top of the file, that is above the first menu listing: timeout 5.

They are completely different things.

[bigpup]

They sure are.
Grub4dos uses timeout to control how long it waits before the default boot entry is executed.
Thus gives you time to see the boot menu and select another entry.

Fatdog uses waitdev to delay the search for devices.
I have had to use that to give a USB drive time to fully power-up, so it is found and can be read by the boot process.

Puppies boot process has waiting for stuff to fully activate in it's code. Different places, it holds/delays for a few seconds and then proceeds to the next step.