ram mode is writing to the usb

[je55eah]

I have specified ram mode in my grub.conf file and I changed the time of writing to ram from 30 to 0 so it should only write to the save file when I click the save ram icon. In practice, some things are saved at shutdown , such as the desktop background, and some things are only saved if I click the icon, auch as the fatdog event manager settings. I noticed the usb is still flashing frequently. Out of curiosity I pulled the usb drive out and began launching programs.

The system does not allow me to unmount the sdc2 partition.

The seamonkey webbrowser silently fails to launch.
I began trying applications, beginning from the bottom of the menu.

The games all worked, but pburn complains that /root/my-documents/tmp does not exist.

guvcview doesn't work if the drive is in or out.

puppyphone does not start

pidgin does not start

seamonkey mail, address book, and composer also don't start

mmview doesn't start. edit: it actually does start as the worlds smallest window.

document viewer doesn't start

gnu image manipulation program doesn't start.

engrampa doesn't start.

gslapt package manager doesn't start.

and critically, because this is the only program I cared about:
virtualbox doesn't start.

[jamesbond]

Can you please copy paste your boot stanza here.

Unlike Puppy, Fatdog has multiple "ram" settings which applies to different part of the OS; if you want to have a complete "ram"-only operations then all of these components needs to be specifed to run in "ram".

E.g. You can specify "ram" setting for the savefile, but if your external basesfs or additional SFS are located in the USB and you don't specify the "ram" settings for them, then you can't unmount the USB because the system still need access to those SFS-es.

[je55eah]

That must be the problem.

This is my menuentry:

Code: Select all

menuentry "Start unencrypted Fatdog64 hypervisor" {
	echo Loading ...
	linux /vmlinuz rootfstype=ramfs waitdev=10 coldplug ntfsnoperm savefile=ram:uuid:0284-E81B:/saves/000virtualbox.fd64save.ext4
	initrd /initrd
	echo Booting ...
}

on the usb there is a fd64-devx_813.sfs, kernel-source-5.19.14.sfs, vmlinuz, initrd-nano, and initrd

[jamesbond]

I made a mistake in my previous answer. Apparently I wasn't thinking straight.
My apology for that. I left the wrong answer in the thread so future readers can follow the conversation.

Here is the (hopefully) correct answer:

The "RAM" mode is confusing because it serves two (completely) different purposes.

1. Applied to the "savefile" parameter, it means that a RAM-layer is inserted between the the root volume and the save layer. The idea is to keep your changes in the RAM-layer, and only write them back ("merge down") to the save-layer periodically (or when the user want to). Note that the actual save-layer itself is __NOT__ loaded to RAM.

2. Applied to extrasfs, basesfs, the "ram" parameter means load those files completely into RAM and don't hog the original filesystem (internal disk, USB flash drive) where they came from.

________________________

Now with those two in the clear, here is the catch: you don't use the RAM-layer (in sense (1)) to run completely disk-less. In this mode, you still need to have your save device (internal disk, USB flash drive, whatever) be permanently attached to the system - because you need to be able to "merge down" to it, when you need to (or when the period is up). That's the reason you can't unmount it, and if you forcefully unmount it, the house of cards will go down and you'll see the errors that you saw.

If you want to run completely without a disk, instead of the RAM-layer, you use the "multi-session" mode. It is activated by using "savefile=multi:XXX" parameter, for details please see http://distro.ibiblio.org/fatdog/web/fa ... tions.html . This is the mode where the actual save-layer (stored in read-only SFS) are loaded at boot time; and after that it is never used again - freeing you to actually unmount the disk.

________________________

So where does (2) come into the picture?

Well, (2) is actually orthogonal to (1). (1) is applicable to the save-layer. (2) is applicable when you load base or extra SFS. You can run "multisession" in the sense of (1) from a USB flash drive, and then have an additional extrasfs loaded from the same disk. This is where you need (2): if you want to run a completely diskless operation, then in addition to the multi-session save, you also need to load all your extrasfs into "RAM", so the system never needs to refer to those SFS from the disk again. Of course, if you do this, please mind the size of RAM that you have because you will need to keep in RAM at all time:
- Fatdog OS (size of basesfs + initrd)
- All the extrasfs that you use
- Your save data
- The changes you made during your use of the system.
These can grow big very quickly.

Hopefully that clarifies.

In your particular case, based on the grub stanza you gave me, I see that you don't load any basesfs or extrasfs, so sense (2) isn't used; all you need to do is to use multi-session save. There are plenty of discussions and examples about that around here.

[je55eah]

Thank you. I am booting into a multi-session now with this boot entry:

Code: Select all

menuentry "Fatdog64 with unencrypted USB multisession support" {
	echo Loading ...
	linux /vmlinuz rootfstype=ramfs waitdev=10 coldplug ntfsnoperm savefile=ram:multi:uuid:0284-E81B:/saves/fatdog813save.ext4
	initrd /initrd
	echo Booting ...
}

I haven't tested everything thoroughly, but I appreciate the information you have shared. On my desktop I have two icons, "Save session" and "Save RAM layer" Testing indicates that Save session does not actually save everything, so I started pressing that one followed by second. Can I use "Save RAM layer" only? Is "Save session" redundant?

Now with those two in the clear, here is the catch: you don't use the RAM-layer (in sense (1)) to run completely disk-less. In this mode, you still need to have your save device (internal disk, USB flash drive, whatever) be permanently attached to the system - because you need to be able to "merge down" to it, when you need to (or when the period is up). That's the reason you can't unmount it, and if you forcefully unmount it, the house of cards will go down and you'll see the errors that you saw.

If the RAM save interval is set to 0 in the Fatdog Event Manager, why would that be a problem with a standard save file? The real issue seems to be:

Note that the actual save-layer itself is __NOT__ loaded to RAM.

When specifying ram as a boot option, I don't understand why the save-layer is not loaded to RAM. Can this be changed in future versions?

On that note, can the save interval be set (to zero) reliably with a boot option?

[Clarity]

... If you want to run completely without a disk, instead of the RAM-layer, you use the "multi-session" mode. It is activated by using "savefile=multi:XXX" parameter, for details please see http://distro.ibiblio.org/fatdog/web/fa ... tions.html . This is the mode where the actual save-layer (stored in read-only SFS) are loaded at boot time; and after that it is never used again - freeing you to actually unmount the disk. ...

This Benefit is the primary reason for my use of FATDOGs. It is not limited to use with a CD/DVD.

Further,it affords the ability to skip any session that I find to be a 'bad' session in several different ways. Or to skip, for any reason, a prior session. Although examples of this are not present, this can be a lifesaver as one can not only back up to a prior, but also to remove a prior such that a FD does NOT have to redone or started over.

Thanks for this refresher.

[Feek]

Thank you. I am booting into a multi-session now with this boot entry:

Code: Select all

menuentry "Fatdog64 with unencrypted USB multisession support" {
	echo Loading ...
	linux /vmlinuz rootfstype=ramfs waitdev=10 coldplug ntfsnoperm savefile=ram:multi:uuid:0284-E81B:/saves/fatdog813save.ext4
	initrd /initrd
	echo Booting ...
}

I haven't tested everything thoroughly, but I appreciate the information you have shared. On my desktop I have two icons, "Save session" and "Save RAM layer" Testing indicates that Save session does not actually save everything, so I started pressing that one followed by second. Can I use "Save RAM layer" only? Is "Save session" redundant?

I also use the multisession mode (from hard drive).

I first extracted the base .sfs (fd64.sfs) from initrd and then repacked it. I´m not entirely sure but this is probably required for the multi-session mode, because then you can define how to boot the base .sfs. So then you put the base .sfs in the right place and add the parameter to the kernel (linux) line for it (something like: basesfs=ram:uuid: ....).

I also tried defining the parameter for save using "ram" (savefile=ram:multi: ...), but this "ram" with multisession mode will generate two save buttons as you also found out. So change it to "direct" instead of "ram" and it will show you only one save button. After pressing it, a new .sfs with your changes will be generated and flushed into the defined location.

[je55eah]

I have backed up my old working systems and set up a multisession as mentioned in my previous post. Virtualbox is installed, but it still does not run, even when the USB is still attached. I tried launching it from the terminal as well:

Code: Select all

# virtualbox
/opt/VirtualBox/VirtualBox: error while loading shared libraries: libgssapi_krb5.so.2: cannot open shared object file: No such file or directory

It worked fine in savefile mode, as long as the USB was attached.

I also tried defining the parameter for save using "ram" (savefile=ram:multi: ...), but this "ram" with multisession mode will generate two save buttons as you also found out. So change it to "direct" instead of "ram" and it will show you only one save button. After pressing it, a new .sfs with your changes will be generated and flushed into the defined location.

Will I be able to detach the usb drive despite specifying 'direct' rather than 'ram'? This is not intuitive.

I first extracted the base .sfs (fd64.sfs) from initrd and then repacked it. I´m not entirely sure but this is probably required for the multi-session mode, because then you can define how to boot the base .sfs. So then you put the base .sfs in the right place and add the parameter to the kernel (linux) line for it (something like: basesfs=ram:uuid: ....).

Okay, I will try this too. Thank you @Feek

[step]

Virtualbox is installed, but it still does not run, even when the USB is still attached. I tried launching it from the terminal as well:

Code: Select all

# virtualbox
/opt/VirtualBox/VirtualBox: error while loading shared libraries: libgssapi_krb5.so.2: cannot open shared object file: No such file or directory

That message indicates that at least one dependency package for VirtualBox isn't installed. Specifically, libgssapi_krb5.so.2 is found in package krb5 in the package manager. VirtualBox might have more unsatisfied dependencies, and it won't start until all of them are met.

[je55eah]

@step
I was able to start Virtualbox after installing krb5, but Virtualbox now fails to load virtual machines which were working from the savefile system.

https://ostechnix.com/solve-result-code ... rch-linux/

This link discussing the new error message suggests that some parts of virtualbox need to be upgraded. I reinstalled Virtualbox with the third party software installer in the control panel, but that didn't improve the situation.

Why isn't the multisession mode identical to the savefile mode? I thought the only difference would be the way changes are saved.

[step]

@step
I was able to start Virtualbox after installing krb5, but Virtualbox now fails to load virtual machines which were working from the savefile system.

https://ostechnix.com/solve-result-code ... rch-linux/

This link discussing the new error message suggests that some parts of virtualbox need to be upgraded. I reinstalled Virtualbox with the third party software installer in the control panel, but that didn't improve the situation.

The VirtualBox Linux kernel driver (vboxdrv) is either not loaded or there is a permission problem with /dev/vboxdrv. Please reinstall the kernel module by executing

'/sbin/vboxconfig'

So, two questions are in order when you see that message: 1) is the vboxdrv driver indeed not loaded? 2) does file /dev/vboxdrv have the right owner and permissions? And, by extension, 0) does the vboxdrv even exist prior to starting VB?

Backgrounder: When VB installs itself it compiles vboxdrv (kernel source and devx must be loaded for this to happen). Then it installs the compiled drivers. When you transfer or copy or save a VB installation, the several files resulting from the preceding two actions must be copied too. The VB installer could also modify some existing system files to account for VB's existence and to load the VB drivers when the system starts.

So you see that there can be multiple points of failure in this process, and you could check each one methodically to find out the causes of your VB trouble. Or you could remove the previous installation, then reinstall using the control panel applet, then run VB and confirm everything's OK, then save layers.

I have used VB very little (I prefer QEMU), last time in 2020. So my advice can be wrong.

Removing VirtualBox: VB installs drivers and service and udev rules and symlinks several files. I think the easiest way to uninstall it is to install VB again, then run its uninstall script:

Code: Select all

# coming from a VB full install:
# untested below
mv /sbin/readlink{,-SUSPEND}
cd /opt/VirtualBox && uninstall.sh && ./uninstall.sh
mv /sbin/readlink{-SUSPENDED,}

The two readlink lines above might be unnecessary but they don't hurt. Just make sure that /sbin/readlink still exists in the end.

Verifying if vboxdrv and friends are loaded: Start VB then run lsmod | grep -i vbox in a terminal.

Code: Select all

sandbox# lsmod | grep -i vbox
vboxnetadp             28672  0
vboxnetflt             32768  0
vboxdrv               466944  2 vboxnetadp,vboxnetflt

Why isn't the multisession mode identical to the savefile mode? I thought the only difference would be the way changes are saved.

I don't know. Multisession's intended save target is CD/DVD. I know some people also use it with flash and HDD media but that's their own stretch. I think they do it primarily because they like to be able to "roll back" to a previous session sfs. They may see other benefits, I don't know for sure. I don't need to "roll back" so I don't use multisession. I do use ram layer with save interval zero, and it works for me. Do you really need to use multisession?

[JakeSFR]

I was able to start Virtualbox after installing krb5, but Virtualbox now fails to load virtual machines which were working from the savefile system.

There's something wrong with VBox 7. One of my VMs (FD-813) doesn't boot, but the other (Win XP) does.
For this user nothing boots, unless it's a newly created VM: https://forums.virtualbox.org/viewtopic ... 7&t=107454

I think for now I'll just stick to the 6.1 line, which will remain supported until December 2023.

Greetings!

[je55eah]

@JakeSFR

Nice catch. I loaded my backup which had a working virtualbox and it had virtualbox 6.1, whereas, the new multisession system has 7.0. That update must have come out in the last few days.

@step

Verifying if vboxdrv and friends are loaded: Start VB then run lsmod | grep -i vbox in a terminal.

2) does file /dev/vboxdrv have the right owner and permissions? And, by extension, 0) does the vboxdrv even exist prior to starting VB?

This checks out. The files exist and Virtualbox was installed while the devx and kernel-sources sfs' were loaded. I'm not sure how to check the permissions, but I believe I am running as root.

Code: Select all

mv /sbin/readlink{,-SUSPEND}
cd /opt/VirtualBox && uninstall.sh && ./uninstall.sh
mv /sbin/readlink{-SUSPENDED,}

Before I run this, will you explain what it is supposed to do?
I see that there is a /opt/VirtualBox/uninstall.sh script. Why && ./uninstall.sh?
What do the SUSPEND SUSPENDED things do?

I do use ram layer with save interval zero, and it works for me. Do you really need to use multisession?

I was getting a lot of reading and writing happening, as explained in the op. @jamesbond told me that multisession is the answer. I don't know.

[step]

I'm not sure how to check the permissions

ls -l FILENAME

Code: Select all

mv /sbin/readlink{,-SUSPEND}
cd /opt/VirtualBox && uninstall.sh && ./uninstall.sh
mv /sbin/readlink{-SUSPENDED,}

Before I run this, will you explain what it is supposed to do?
I see that there is a /opt/VirtualBox/uninstall.sh script. Why && ./uninstall.sh?
What do the SUSPEND SUSPENDED things do?

It's supposed to run VB's uninstall script.
Line 1 renames /sbin/readlink to /sbin/readlink-SUSPEND, and line 3 renames it back. The net effect is zero before and after those lines. However, the effect on line 2 is that /sbin/readlink won't be found, if invoked as readlink, and /usr/bin/readlink will be used instead. There used to be a compatibility issue for VB scripts about which of the two readlinks gets used, and lines 1, 3 work around that issue. As I mentioned in my previous post, those two lines may be redundant in recent Fatdog versions but they don't hurt. As regards why uninstall.sh is run twice... maybe because a second pass is needed to really clear VB. I wrote that line originally three years ago; now I can't recall why I wrote it that way.

[jamesbond]

I was curious about this as I have never done it myself. So I decided to give it a try.

1. My settings:
a) fresh setup
b) multisession mode
c) devx and kernel-source SFS loaded to RAM at boot time

2. My grub stanza

Code: Select all

menuentry "Start Fatdog64 Multi Devx RAM" {
	echo Loading ...
	linux /vmlinuz rootfstype=ramfs savefile=direct:multi:uuid:0284e81b-569f-40a6-89c6-de69334c4d9d extrasfs=ram:uuid:0284e81b-569f-40a6-89c6-de69334c4d9d:/fd64-devx.sfs,ram:uuid:0284e81b-569f-40a6-89c6-de69334c4d9d:/kernel-source-5.19.14.sfs
	initrd /initrd
	echo Booting ...
}

Note that those UUIDs (they're all identical because they point to the same drive) are the UUID from my external boot media, which I obtained by running "blkid" from terminal.

3. Once booted, I confirmed that devx and kernel source is indeed loaded (running "gcc" from terminal works, and /usr/src/linux-5.19.14 existed). At this stage I'm running fully with RAM with pristine configuration but with devx and kernel source loaded.

4. I downloaded VirtualBox 6.1.40 to /tmp, and then run "sh VirtualBox-xxxxx.run" to install it. This is all that get-virtualbox.sh actually does. I don't use get-virtualbox because the one in Fatdog 813 will always fetch the latest version. We have a working version that allows us to choose between latest-stable and latest-version but it's not released yet.

5. I confirmed that "lsmod | grep vbox" returns something - it confirmed that the kernel modules for VB were all loaded.

6. Then I clicked "Save Session" to make sure that my session are saved, then I rebooted to confirm that VB is still there after I rebooted. (Actually, I cheated. I did this because the automatic save-session at shutdown fails to work (fails to save the session), so I saved the session manually instead. I have fixed the bug but again it's not in 813 ...).

7. After rebooting, I launched VB, I created a virtual machine called "Test" without any harddisk, and attach Fatdog ISO to it. I allocated 2GB RAM to the VM (this is the default settings apparently). Also important note: there is an important bug in recent versions of VBox that you cannot enable "ALSA Audio", so you will have to go to VM settings --> Audio --> and change the default "ALSA Audio" to "Null audio" (that is, no sound). Thanks to @p310don who spent hours troubleshooting this.

8. Then I "saved session" again, and rebooted once again, to confirm that the "Test" VM is still there.

10. Finally, I launched the "Test" VM, and then took the screenshot of my entire desktop, which is attached.

11. This very post was written using Seamonkey inside the Fatdog VM that was running inside VirtualBox - the one you see in the screenshot.

Final word: this only proves that it works, that it is possible to run VB in multisession mode without any drives mounted (the boot media where I booted from isn't shown in the screenshot, it's actually "sdc1" and "sdc2" which I had unplugged before I took the screenshot).

If it doesn't work on your end, something must have gone wrong; we just need to figure out what it is.

[je55eah]

I can confirm that Virtualbox 6.1 works as expected.

I also retested the apps which failed to run with the usb detached. In multisession mode, all of the applications except guvcview work with no usb attached. This is a success.

Thank you @step @jamesbond @JakeSFR @Feek

Code: Select all

mv /sbin/readlink{,-SUSPEND}
cd /opt/VirtualBox && uninstall.sh && ./uninstall.sh
mv /sbin/readlink{-SUSPENDED,}

Should line 3 be

Code: Select all

mv /sbin/readlink{-SUSPEND,}

I learned some things about how these curly brackets work, but in the end I manually did the following to uninstall version 7:

Code: Select all

cd /opt/VirtualBox
./uninstall.sh

/sbin/readlink doesn't even exist on my system.

After deleting version 7 I downloaded the 6.1 run file and after manually loaing the devx and kernel-sources squash file systems I execute the installer from /temp after moving it there.

I also tested the sfs that step sent me. I loaded it after uninstalling version 7 and before installing 6.1. Despite being loaded no entry for Virtualbox appeared in the menu. Out of curiosity I tried the sfsexec tool, but that also failed to start virtualbox. I probably didn't use it correctly. Maybe I needed to install krb5 again or something, but I didn't have much hope that version 7 would work anyway.

[je55eah]

Also important note: there is an important bug in recent versions of VBox that you cannot enable "ALSA Audio", so you will have to go to VM settings --> Audio --> and change the default "ALSA Audio" to "Null audio" (that is, no sound). Thanks to @p310don who spent hours troubleshooting this.

Alsa audio seems to work for me, but I will keep this in mind in case I encounter issues with audio later.