I am thinking about running Slackware totally from RAM on one of my machines (may be with upgrading to 16GB before).
As far as I understand it the system has to be copied from disk to RAM at boot time, and when it is shutdown the system has to be copied back ( I would rather like it to be asked if that should happen at shutdown).

Has anybody achieved something like that already?
I tried to find information on that topic on the web, but either the information is not available or my Google-Fu is not good enough.
If anyone knows a link to a How-To or knows how to do that and can help me with it I would really appreciate that.

Sidenote: I am (currently) not interested in creating a live-system for that purpose (since it lacks the functionality of saving back changes at shutdown), may be I will look later at that for creating some kiosk systems. I am also at this point not interested in a discussion why I want to do that, at this point I want just to know if it is possible, and how to achieve it, if it is possible.

Thanks for your effort in advance.

As far as I remember, Tiny Core (http://distro.ibiblio.org/tinycorelinux) is able to work in the way described by you.

I've used two distros that run from RAM and allow saving state back to a hard drive.

Puppy Linux at http://puppylinux.org/main/Overview%...%20Started.htm

Slax (based on Slackware) at http://www.slax.org, maintainer's blog at http://www.tomas-m.com/blog/

The google search phrase "linux run from ram" returns quite a few hits. I found various distros and methods to do it there.

I can't find it now, but I know that I've read about some of the tools used to do this. IIRC, some distros use the "toram" boot argument to achieve it for that distro. Adding "toram" to the phrase above, and then telling google I wanted to search for "toram" rather than "to ram", brought up some more hits.

Good luck!

1 members found this post helpful.

It is very possible to do what you want.

A lot of issues and a lot of choices need to be made.

One way is the live cd. It basically doesn't care since it is a live filesystem and it just loads up to ram each time and some options for persistent file someplace.

A way to create your own modified distro that boots to ram but most of the static files remain on hard drive. You may have to choose how much you want moved at boot.

Another is to create and format ramdrive at boot then copy over then chroot.

Look for search terms such as "toram" copy2ram and ramboot.

The best way is to get a revodrive.

Might look at setting up a iscsi target or pxe/gpxe/ipxe an install.


http://www.linuxquestions.org/questi...ilence-662116/

https://wiki.ubuntu.com/BootToRAM

http://www.vanemery.com/Linux/Ramdisk/ramdisk.html

I've been running my slackware from RAM since about mid 2007. So it is certainly possible.
In early attempts I did copy the system back to disk at shutdown. But I've come to prefer the method of having the system packed up in a tarball which I explicitly rebuild when I want to make changes stick across reboots (with the exception of /etc which crond copies from RAM every day, and then the latest backup is copied from disk at boot.) However I don't see any perticular problems with having a "live" system on disk copied to/from RAM at boot/shutdown.

Assuming you have a system installed on sdb1, which you want to run from tmpfs, here is a few things you would want/need to do:
* Create an initrd which fscks and mounts sdb1; mounts tmpfs; copies content of sdb1 to tmpfs; unmount sdb1; swich_root to mountpoint of tmpfs. I think the sample initrd in /usr/share/mkinitrd/initrd-tree.tar.gz is good enough, if you just rewrite the /init script.
* Edit /etc/rc.d/rc.S so that it doesn't whine about / being mounted read-write.
* Make an /etc/rc.d/rc.local_shutdown to copy the system back to disk, something like this would probably suffice:
echo 'Save state? [yes/NO]'
read ans
if [ "x$ans" = "xyes" ];then
rsync --one-file-system --archive --delete / /mnt/sdb1/
fi
* Keeping /var on disk so your log files are (at least somewhat) intact when the system crashes.

With some shell scripting knowledge it shouldn't be too hard to get a proof of concept up and running before trying to figure out all the details.

4 members found this post helpful.

Try Porteus ( http://porteus.org/ )

1 members found this post helpful.

Thanks for your answers.

AFAIK, most live distros do not copy themselves into RAM, otherwise it would not be possible to run a live-system on a machine where the size of the image exceeds the amount of RAM. You can observe this when you have to wait for the CD drive to spin up after issuing a command.

That seems to be exactly what I was looking for, thanks for that. I will try to make my way through that and come back if I have more questions about that.

Marking as solved, at least temporarily.

You need something like unionfs:
http://en.wikipedia.org/wiki/UnionFS

You can reuse the shutdown scripts from Knoppix.

Wouldn't the system still reside on disk instead of in the RAM? I want the whole system to be in RAM, may be except some directories (/var, /home, may be some others).
Currently setting up a VM for experimenting with e5150's suggestions, but not much time left today. Work really can be annoying if one has a project in mind.

Yeah, it works. Thanks again to e5150 for your solution, now I have to fiddle more with that (and get more RAM). Didn't expect it to be so easy, really a straight forward approach.

Can you publish your scripts?

Soon I should have a computer with 128 GB of RAM. So I would like to do the same thing.

After getting a fast SSD I have abandoned this approach, since there is no real benefit anymore. So I don't have any scripts for that, I just have done what e5150 posted in post #5 and it worked. Of course there will be some fine-tuning after that.

Just curious, but what kind of speed increase did you get? I just built a monster and I'm trying to figure out something interesting to do with 32GB of memory.

I didn't make benchmarks on that setup, it just felt fast (almost instant application starts, ...). Of course this also only makes a difference the first time you start an application if you have large amounts of RAM.
But even on a very fast SSD or running from RAM I found out that the real time that is needed to start something depends almost solely on the application itself. KDE will steel need some time to start, so does Firefox. You will get a better performance increase with just changing to lightweight alternatives.

I now have only one mount on my main system as tmpfs, the /tmp directory, where I do all the heavy works. Compilation of a kernel works with -j10 with minimal I/O waits on a six-core CPU.

1 members found this post helpful.