How to unmount thumbdrive after booting Fossapup from it?

[Lee]

I have been running xenialPup64 off of a liveCD for about two years now - no issues. In the interest of security, I typically remove the cd from the drive right after it boots up. This PC does not have a hard drive installed.

Recently I upgraded to fossapup64 running off of a live usb thumb drive. When I try to unmount the drive after it boots(before removing it), it complains that it is in use - so no can do. The PC is primarily used for banking and I'm thinking the less places for any malicious code to find a home while navigating the OS is better. Is this just the nature of the USB beast on Puppy, or is there a way to force it to unmount (and then remove) without damaging the integrity of the data on the drive? The Usb option certainly seems faster and easier to use, so I do hope there is a simple solution.
TIA
Lee

[puddlemoon]

HI

You can add to the boot options: "pfix=ram" if you have no need for a save file/folder Then all drives can be unmounted.

How to add that to the kernel line depends on what boot method you use. It needs to be added to the boot loader config file e.g. menu.lst, grub.cfg etc...

I have been adding this as an extra entry lately to be able to select at boot, so I can unmount the internal drive/s

[Jafadmin]

To expand on what @puddlemoon said, in either the 'syslinux.cfg', the 'grub.cfg', or the 'menu.lst' you are using on the thumbdrive, add to the 'pfix' parameter using a comma: 'pfix=fsck, fsckp, ram'.

You will then notice that the usb drive doesn't mount at boot.

[mikeslr]

You might want to take a look at puli which is designed to boot from a USB-Key that you then unmount. viewtopic.php?p=2551#p2551. In addition to that security feature, the virtual keyboard xvkbd is activated via a task-bar launcher to frustrate 'keyloggers'. Additionally, take note of the security profiles you can choose to counter efforts by hackers.

The latest version is a modification of Bionicpup64.

[Lee]

Thanks all for the quick response! Will try the pfix mod and spend some time reading up on Puli - I am a fan of security. Thanks again!

[mikewalsh]

@Lee/@mikeslr :-

In addition to what the above posters have said, let's not forget that Puppy loads into RAM from compressed, read-only files anyway; if you have no save-file/folder, and are simply using it as a "one-time use" LivePuppy each time you boot, there is absolutely nowhere for malicious code to lodge. Running in a 'virtual' file-system in RAM as it does, under those circumstances everything disappears into cyberspace when you power-down.....

Safe as houses, mate .


Mike.

[mikeslr]

Just a couple of follow-up tips.

In order to use applications after you unplug the USB-Key you booted from, those applications must be entirely within RAM. On bootup Frugally installed Puppy copies into RAM all of the following files from Storage (CD/DVD, Hard-drive, USB-Key): vmlinuz (the kernel), zdrv_your-puppy.sfs (drivers for that kernel & firmware), fdrv_your-puppy.sfs (firmware if packaged separately) and also if there is sufficient RAM all the files in the Puppy_version_number.sfs (the file-manager, window-manager and all applications the Puppy's Dev thought most users would want) and any (a,y or other letter)_your-puppy.sfs. [An "Alphabet.sfs" has additional applications and suites of applications the Puppy's Dev thought some users might want or the user built. These do not sfs-load/unload like an application.sfs. Rather, if present an Alphabet.sfs will always load on bootup and must be removed/renamed before reboot to avoid that. See the Additional Software Section, Utilities for the tools to create any SFS, including Alphabet.SFSes].

Unlike SaveFiles/Folders, an 'alphabet.sfs' and a remastered Puppy_version_number.sfs are READ-ONLY files.. But these will have your settings, customizations and any file you may want/need. Just like with the original files which came in the ISO, you can boot into it, use it, and shut-down without creating a SaveFile/folder and thus NOT preserving anything (including malware you may have picked up which currently resides in RAM: RAM is cleared on Shutdown/Reboot). After bootup, you can literally 'pull the plug.'

Take a look at Puppy's File-Structure, viewtopic.php?f=2&t=180. Note that "everything hangs from /root", i.e, the root at the top, not the folder named root but bearing the symbol "~". When you create a SaveFile/Folder, everything existing in RAM will be written to it except any files "hanging from" /mnt, and files in /root/tmp. The latter are specifically excluded by the application which controls Saving. On bootup the contents of your SaveFile/Folder will also be copied into RAM, if you there is sufficient RAM. But what if there isn't?

Puppies created when computers commonly sold with only 256 Mbs of RAM, and having 512 Mbs was a luxury, were structured to leave about half the available RAM by default available for doing actual work. That is, only essential files were copied into RAM: sufficient to create menu entries. As you used an application, additional files would be copied from storage, and less needed files dropped from memory. You could, however, use a boot argument to compel Puppy to copy all files into RAM; for example:

kernel /fossa64/vmlinuz psubdir=/fossa64 pmedia=usbflash pfix=copy Emphasis supplied.

I know the "copy" command can still be used: doing so doesn't generate any errors. But, I don't know if, or to what extent, it may still be effective. But employing it can't hurt.

When you remaster a Puppy, every application you installed --that became part of your SaveFile/Folder-- is written into your new Puppy_version_number.sfs. Additionally, if you employed a SaveFile (not a SaveFolder) you can use taersh's PaDS, viewtopic.php?p=6355#p6355, to convert it to an "adrv.sfs" or other alphabet.sfs [Currently, by default Puppies can only use adrv and ydrv. IIRC, taersh also published an application which enables more. But I can't find it ].:

1) Create a folder having the "alphabet" name you want, but without the sfs ending, e.g. ydrv_fossapup64_9.5.
2) Boot into your Puppy pfix=ram -- that is so that the SaveFile isn't used. You can't properly copy a SaveFile while it's in use. Or boot into a different Puppy in order to perform next step.
3) Copy your SaveFile into that folder.
4) Reboot into your Puppy, [Actually, you can do this under any Puppy, remembering that the file you build can only be used under the Puppy bearing its name].
5) Install Pads if it is not already installed. If a new install, restart-x in order for Puppy to recognize it's presence.
6) You can copy into the folder you created in step 1 any pet, SFS, and several other package types --see the PaDs thread. But "alphabet" SFSes and portables require special handling.
7) You can include an 'alphabet.sfs', but you may have to change its name, e.g. ydrv_fossapup64_9.5.sfs to something.sfs. IIRC, PaDS has a limitation in that it can not process a file having the same name as the application it is building.
8) Right-click the folder you created and select "combine to sfs". An SFS application with the name of your folder will be created in /root.

You can then move that SFS adjacent to your other 'system files" and after removing your SaveFile boot without a SaveFile. To remove the SaveFile I suggest the follow precaution in case something went wrong and you have to revert. Boot pfix=ram. Create a folder two layers below drive/partition's top. On bootup, Puppy only looks one layer deep for SaveFiles/Folders: e.g., I create /fossa/protect in the /fossa folder then copy the SaveFile into /fossa/protect.

As I mentioned, portables require special handling. They are often packaged as compressed files (e.g. tar.gz) which you can unpack (e.g. UExtract) and locate anywhere. After unpacking they can be used immediately by file browsing into the folder created by unpacking and Left-Clicking the executable. For example, with Mike Walsh's Iron portable, viewtopic.php?p=4865#p4865 you'd file-browse into the Iron-portable folder and Left-Click the script named LAUNCH. Creation of a menu entry is optional. While generally I unpack portables on /mnt/home, to have them available in a Puppy booted from a removable USB-Key, I would locate their folders in /opt --optionally create menu entries-- perform a Save and do that before either Remastering or converting the SaveFile to an 'alphabet.sfs'. Contents of /opt are written to the SaveFile and so would become part of an alphabet.sfs or remastered Puppy_version_number.sfs.

[Lee]

Wow Mikeslr!!!, that was a very through and detailed explanation. The linux community is great. Thank you!!! I have decided that running without some sort of savedfile mods loading, will not work for me. Many of the financial sites I frequent have been complaining about the pale moon browser for a long time. Also, the need to modify any browser with bookmarks(to avoid typos while accessing) and tweaks(to improve security) is another key motivator.

Though I have been using xenial for the past couple of years I never really found the time to get too much into the nuts and bolts of its operation. It just always worked flawlessly for my particular needs. In retrospect, I now see that choosing to boot off of a multi-session liveCD was a bit of dumb luck on my part. I think the original thought was that it would be much harder for anything to attack a cd than a usb-key. Heck, I made just a few coasters myself, trying to get the original setup running correctly. Also, it is very obvious when the cd gets accessed.

When I first read about puppy totally running from ram and then being completely blown away at the end of a session I was sold immediately. I run on an older PC that is ONLY used for financial transactions. Bootup, remove CD, select a bookmark, transact and exit. No email, no general purpose browsing at all. If the url is not in the bookmarks, I don't go there. Very rare is it to save a session, but the need does arise from time to time. Recently, I have been a bit tainted by the faster speed and ease of creation of the usb-key. Also, the access to a virtual keyboard does sound interesting. Still pondering whether the caveats involved will be worth the jump, but I do thank you one more time for the enlightenment.

[baldronicus]

Hi @Lee et all. I don't want to go off-topic but....Another possibility might be to run Fatdog64 in multi-session mode with a modified shutdown that doesn't automatically save. The USB drive can be removed after boot. A save.session icon is placed on the desktop so that you can save when you want to (I presume that you would want to save when off-line), you just have to insert the USB drive and click the icon when you want to save. This would not be a standard configuration (with respect to the shutdown), though.
EDIT- From the post by Rufwoof below, only a configuration change in the standard setup would be needed. Thanks Rufwoof.
If you were interested, it might be best to make a post in the Fatdog section so as not to mess up this thread more than I have.

Thanks.

[user1111]

@Lee/@mikeslr :-

In addition to what the above posters have said, let's not forget that Puppy loads into RAM from compressed, read-only files anyway; if you have no save-file/folder, and are simply using it as a "one-time use" LivePuppy each time you boot, there is absolutely nowhere for malicious code to lodge. Running in a 'virtual' file-system in RAM as it does, under those circumstances everything disappears into cyberspace when you power-down.....

If the sfs is left accessible on rw media (such as HDD) then it can be modified. Fundamentally you can read the sfs header, determine the compression method used, read the inodes and determine the location of the compressed data to which that points ... and could change/replace any files content with something else. 'Better' if the intended action is preserved, so still does what was expected, and where whatever compressed data content is being added still fits within (equal to or less than) the original allocated space. gpartedbin is a 'nice' choice for a dark hat - if for instance the sfs was utilising gzip then instead storing the gpartedbin element as xz with a conversion/control header, then that frees up over 50KB of 'available' gzip'd size space for 'other' functions/purpose. And at that level even less than 1KB is way more enough to compromise a system (a net cat contact remote dark hat server for what command to try next (and feed back the outcome) loop type function can be written in relatively few bytes).

[user1111]

Another possibility might be to run Fatdog64 in multi-session mode with a modified shutdown that doesn't automatically save. The USB drive can be removed after boot. A save.session icon is placed on the desktop so that you can save when you want to (I presume that you would want to save when off-line), you just have to insert the USB drive and click the icon when you want to save. This would not be a standard configuration (with respect to the shutdown), though.

My preferred personal choice Boot from usb, save only on demand to usb, with multi-session save style. Fatdog in multi-session style with Event Manager save interval set to zero will only save whenever you click the desktop save icon. It will throw out a prompt at shutdown as a reminder, but still not save unless you click the save icon. If you set the save to be on removable such as usb, then obviously you have to attach that prior to clicking save. And if its all loaded into ram at startup then the usb can be unplugged as soon as the system has copied into ram/booted. A risk is that in running in ram you may exhaust available space during a session. What I do is adjust the system to use swap space as part of the available save area space (I also set it to use encrypted swap, so any remnants are opaque, due to a unique/random session key being used for that encryption). Pretty much excessively so in my case, with a 26GB swap partition.

Code: Select all

root@fatdog64-d37> df -h
Filesystem      Size  Used Avail Use% Mounted on
devtmpfs        1.7G  4.0K  1.7G   1% /dev
tmpfs           1.7G  6.1M  1.7G   1% /aufs/pup_init
/dev/loop0       74M   74M     0 100% /aufs/kernel-modules
/dev/loop1      516M  516M     0 100% /aufs/pup_ro
tmpfs            26G  521M   26G   2% /aufs/pup_multi
tmpfs            26G   58M   26G   1% /aufs/pup_save
aufs             26G   58M   26G   1% /
tmpfs            26G   18M   26G   1% /dev/shm
tmpfs            26G  436K   26G   1% /tmp

So the amount of "changes" that pup_save area can accommodate is around 26GB before problems occurred. For instance if I downloaded a 8GB file into /root, where otherwise that would use up all of ram space given its a 4GB ram laptop system, then with that setup it will still fully download the file and not crash the system - just it utilises some of swap. When I've done that sort of thing in the past, after it completes downloading I just move the file (to HDD), so its preserved rather than lost - as I infrequently 'save' once I've set the system up as I like it.

A nice factor with multi-session saving is that it creates a save sfs for each individual save action, so you also have a audit trail. It's also relatively simple to merge them (boot - so all of the multi-session save files are in effect overlaid into pup_multi, remove all of the multi-session files from the usb and then click 'save' and fatdog creates a single multi-session save file as a replacement for all of the prior single files. Actually it creates two multi-session files at the first save, multi....base and multi...save, but that's just a technicality i.e. copies of the pup_multi and pup_save contents).

When I last looked, woof-CE based systems came nowhere close to Fatdogs in the boot fully into ram from usb/unplug usb/save on demand type functionality.

[williams2]

mikeslr said: viewtopic.php?p=7761#p7761

On bootup the contents of your SaveFile/Folder will also be copied into RAM, if you there is sufficient RAM

No. The various sfs (squash file system) files will be automatically copied to ram on boot, if there is sufficient RAM. Maybe that's what you meant. When a file system is mounted, the names of the files are added to the Linux virtual file system (VFS). Maybe the contents of the inodes are copied to ram. And a buffer is setup for each mounted file system. None of the actual files are copied to ram, until the file is actually used.

Code: Select all

# ls -lh /initrd/mnt/tmpfs/*sfs
-rwxrwxrwx 1 root root 111M Sep 18 18:47 /initrd/mnt/tmpfs/adrv_bionicpup64_8.0.sfs
-rwxrwxrwx 1 root root 279M Apr 26  2019 /initrd/mnt/tmpfs/puppy_bionicpup64_8.0.sfs
-rwxrwxrwx 1 root root  57M Apr 26  2019 /initrd/mnt/tmpfs/zdrv_bionicpup64_8.0.sfs
#

additional files would be copied from storage, and less needed files dropped from memory.

Not really. Swap does work that way, pushing areas of ram that are not being used into swap.

I run XenialPup64, BionicPup64, and FossaPup64 with an adrv.sfs instead of a save file. The save layer is a ram tmpfs file system. That is, I boot with pfix=ram. No changes persist unless I run my remaster script, which is basically:

Code: Select all

rsync -av /initrd/pup_a/ /tmp/a1
rsync -av --exclude=.wh.* /initrd/pup_rw/ /tmp/a1
mksquashfs a1 out.sfs

pup_a and pup_rw are already mounted, so I don't need to mount anything.

[Lee]

Oh joy, another "simple" solution. JK-thanks for sharing! Definitely some smart fellows in this group. All this rhetoric associated with trying to decide the best method to boot from a usb-key and then unmount in the name of security got me to thinking, I wonder how many folks out there are just like me looking to access a lean mean secure internet machine. I would say most have access to an older machine that could very easily be converted to a "quarantined" high security box. A decent amount of ram, a couple of ubiquitous usb ports and a cd drive if desired(not required). No hard drive. Only base apps included are a well known(chrome,FF,etc) browser, rox file manager(easily export desired data), virtual keyboard and any other files deemed key that I am overlooking out of ignorance. The code would be very light weight which should make the management easier and the loading faster. Any heavy lifting that is desired can be easily offloaded to another box that has a full blown install of the Software and Hardware of your choice. I'm thinking most of you gurus that have a good handle on the nuts and bolts of puppy could gen a first pass of something like this in a few days or less. Seems like a bunch of the pieces are already there, you just need to know how to toss out the extras and then apply the glue to reassemble what's left into the new package. The goal being LEAN & SECURE. As for me, if the volatile feature of the ram getting wiped clean at shutdown did not exist I probably wouldn't be using puppy today. Why not take a good idea, tweak it just a bit and make it impossible to ignore? Am I in the weeds?

[greengeek]

)No hard drive. ...

Hard drive is REALLY useful as a swap partition if you have one available. Makes the system so much faster.

Your concept of a puppy that allows a shutdown that discards all RAM contents (instead of saving them) is an important idea that should be standard in every pup.

Should be as simple as a switch that changes "pupmode" to a special setting.

[rockedge]

doesn't the Puppy distro "Puli" (made for very high security) have the set up to boot, load itself and then umount's the drive / partition it booted from?

One should be able to put pfix=RAM on the kernel command line in the menu.lst and be able to umount the USB drive as long as the pupmode is set for no save file or folder it should be a start point.

Something like the way Puppy Linux works from a CD-ROM in a LiveCD way. Loads, boots and then the CD-ROM can be removed. Same principle.

[Feek]

Hi, I‘ve been using Puppy for a few months. I like this OS very much and I‘m still learning.
Normally I use savefolder. Here and there I read, that one can run without save - and a longing arose in me to have it
I experimented and tried something very simple in Bionicpup64 (frugall on USB stick, ext3):

-boot without savefolder (pfix=ram), then make all the required basic settings and in the end of the session create a new savefolder.
-reboot into the „old” savefolder, then right click on the new created savefolder and choose „dir2sfs” possibility.
-when the sfs file is created, rename it to „adrv_bionicpup64_8.0.sfs”.
-in menu.lst change the parameter „pfix=fsck” to „pfix=ram”.
-after reboot savefolders are ignored and usb stick is not mounted.

I don‘t know if this way is quite correct, but I can say it works on my machine with Bionicpup64.

[greengeek]

-after reboot savefolders are ignored and usb stick is not mounted.
I don‘t know if this way is quite correct, but I can say it works on my machine with Bionicpup64.

Hi Feek, after you boot your puppy using this method could you have a look at the file /etc/rc.d/PUPSTATE and see what the "PUPMODE" number is please?
cheers!

[williams2]

With Feek's method, you should be able to make changes to the save folder and save them to a new adrv.sfs file.

You need a menu.lst entry with pfix=ram for a normal boot,
and a pfix=fsck menu entry for when you want to change something.

You would boot with the save folder, pfix=fsck, make any changes,
reboot using pfix=ram, right click the save folder and make a new sfs with dir2sfs.
You can keep the older adrv.sfs in case you want to go back to the previous setup.

Then boot the pfix=ram menu option which will use the newer adrv.sfs (if it has the correct name, of course)
You would normally boot the pfix=ram option, which will be the exact same system each time you boot.
It would only change if you booted using pfix=fsck and created a new adrv.sfs file.

[Feek]

I would add a note:
When you have "adrv_bionicpup64_8.0.sfs" file already in use and want later something change (as williams2 describes), it would be good either rename it or delete before you boot with the savefolder (pfix=fsck). The reason is that both "adrv_bionicpup64_8.0.sfs" (not renamed) and savefolder contain personal changes and when booted together it could maybe cause chaos somewhere

[Feek]

-after reboot savefolders are ignored and usb stick is not mounted.
I don‘t know if this way is quite correct, but I can say it works on my machine with Bionicpup64.

Hi Feek, after you boot your puppy using this method could you have a look at the file /etc/rc.d/PUPSTATE and see what the "PUPMODE" number is please?
cheers!

Hi greengeek, the file /etc/rc.d/PUPSTATE shows that PUPMODE=5