As you already know, everyday there are hundreds of new additions to the GitHub repository. But, many good projects go unnoticed, and never receive the attention they deserve. Today, I stumbled upon a cool project named Ramroot. Using Ramroot, we can run Arch Linux entirely from RAM! Yes, you read that right.
Ramroot loads the entire root filesystem into RAM at system boot. It is specially designed for Arch Linux. I tried it in Ubuntu, but It didn't work. I hope the developer will make it to work on other Linux distributions as well.
Table of Contents
Run Arch Linux From RAM Using Ramroot
Ramroot is available in AUR, so you can install it using any AUR helper programs, for example Paru or Yay.
$ Paru -S ramroot
Or,
$ yay -S ramroot
Then, enable Ramroot using command:
$ ramroot enable
Sample output:
:: Detected root UUID: 6517af02-68e9-484e-9dae-f0ed61822ad3 :: No /boot UUID detected. :: zram added to mkinitcpio.conf MODULES :: ext4 added to mkinitcpio.conf MODULES :: vfat added to mkinitcpio.conf MODULES :: ramroot added to mkinitcpio.conf HOOKS :: Enabling ramroot... [sudo] password for sk: ==> Building image from preset: /etc/mkinitcpio.d/linux.preset: 'default' -> -k /boot/vmlinuz-linux -c /etc/mkinitcpio.conf -g /boot/initramfs-linux.img ==> Starting build: 4.17.6-1-ARCH -> Running build hook: [base] -> Running build hook: [udev] -> Running build hook: [ramroot] -> Running build hook: [autodetect] -> Running build hook: [modconf] -> Running build hook: [block] -> Running build hook: [filesystems] -> Running build hook: [keyboard] -> Running build hook: [fsck] ==> Generating module dependencies ==> Creating gzip-compressed initcpio image: /boot/initramfs-linux.img ==> Image generation successful ==> Building image from preset: /etc/mkinitcpio.d/linux.preset: 'fallback' -> -k /boot/vmlinuz-linux -c /etc/mkinitcpio.conf -g /boot/initramfs-linux-fallback.img -S autodetect ==> Starting build: 4.17.6-1-ARCH -> Running build hook: [base] -> Running build hook: [udev] -> Running build hook: [ramroot] -> Running build hook: [modconf] -> Running build hook: [block] ==> WARNING: Possibly missing firmware for module: wd719x ==> WARNING: Possibly missing firmware for module: aic94xx -> Running build hook: [filesystems] -> Running build hook: [keyboard] -> Running build hook: [fsck] ==> Generating module dependencies ==> Creating gzip-compressed initcpio image: /boot/initramfs-linux-fallback.img ==> Image generation successful :: ramroot enabled.
If it doesn't work for any reason, grab the Ramroot binary from GitHub repository and run it as described below.
Git clone the Ramroot repository using command:
$ git clone https://github.com/arcmags/ramroot.git Cloning into 'ramroot'... remote: Counting objects: 94, done. remote: Compressing objects: 100% (52/52), done. remote: Total 94 (delta 41), reused 82 (delta 32), pack-reused 0 Unpacking objects: 100% (94/94), done.
The above command will create a folder named "ramroot" in the current working directory and save all contents of Ramroot project in it.
Then, go to the Ramroot bin directory:
$ cd ramroot/bin/
Make the following files a executable:
$ chmod +x ramroot-build $ chmod +x ramroot-enable
Finally, run the following command to enable the Ramroot.
$ ./ramroot-enable
Enter your sudo or root password when prompted.
Now, reboot the system. At boot process, you will be prompted to load the filesystem into RAM. Type "Yes" to proceed.
Load root filesystem to RAM
Please note that this prompt (y/N) defaults to yes with a 15 second timeout if 4G or more of RAM is detected. Since, I have 2GiB RAM, I had to type "Y" to continue.
Wait for a while to finish the loading process. It will take several minutes to load the entire root filesystem into RAM. Make sure you have sufficient RAM installed on your system.
If you want to maintain faster RAM sync times, try to keep a clean and trimmed down system. Remove old and unnecessary packages, and keep your package cache folder clean.
Update:
If you use the most recent Ramroot version, the installed RAM size should be at least 500MB more than the size of root filesystem. If there is at least 500MB more RAM than the size of the filesystem, the user will be prompted to load the root filesystem to RAM. If the size of the root filesystem is less than the installed memory, the latest Ramroot version won't load the Root filesystem in your RAM. It won't even prompt you whether it should load filesystem into RAM or not. The filesystem will be mounted in your local disk automatically and the Arch Linux will boot normally.
Once root filesystem is loaded into the RAM, you will be landed into rootfs prompt. Please note that nothing will be saved after reboot. Because our Arch Linux is entirely loading from RAM, not from the local disk.
Root filesystem loaded into RAM
Display Ramroot help
To display Ramroot help section, run:
$ ramroot --help
Sample output:
NAME ramroot - load root (and /boot) filesystem entirely to RAM during boot SYNOPSIS ramroot <ACTION> [OPTIONS] ACTIONS disable Remove ramroot from /etc/mkinitcpio.conf HOOKS. Remove ext4, vfat, and zram from /etc/mkinitcpio.conf MODULES. Rebuild linux cpio boot image. enable Rebuild build and runtime hooks in /usr/lib/initcpio. Add ramroot to /etc/mkinitcpio.conf HOOKS. Add ext4, vfat, and zram to /etc/mkinitcpio.conf MODULES. Rebuild linux cpio boot image. remove Disable ramroot. Remove build and runtime hooks from /usr/lib/initcpio. status Print ramroot and root filesystem status to screen. Return exit status 0 if enabled and currently loaded to RAM. Return exit status 1 if enabled and not loaded RAM. Return exit status 2 if disabled. OPTIONS -b, --boot <UUID> Specify /boot partition UUID to use when building hooks. -D, --dryrun Execute ACTION without making any changes. -F, --fstab Mount all other partitions in /etc/fstab normally. -H, --help Display help text and exit. -K, --keep Keep copies of new build and runtime hooks in ~/.cache/ramroot. -M, --message Print 'Arch on RAM' message at tty login by using custom /etc/issue. -N, --no Change startup prompt default to not load filesystem to RAM. -r, --root <UUID> Specify root partition UUID to use when building hooks. -t, --timeout <SECONDS> Set RAM boot prompt timeout (default=15).
Remove Ramroot
Reboot your system, and type "n" when it asks to load the filesystem to RAM to login normally to your Arch Linux system. Go to the ramroot/bin folder and make the following files as executable.
$ cd ramroot/bin/ $ chmod +x ramroot-disable $ chmod +x ramroot-remove
Finally, remove Ramroot from your Arch Linux system using commands:
$ ./ramroot-disable $ ./ramroot-remove
If you have installed Ramroot from AUR, remove it using commands:
$ ramroot disable
$ ramroot remove
And, finally remove the Ramroot package:
$ sudo pacman -Rns ramroot
Conclusion
Ramroot might be helpful for those who wants to do some testing on their Arch Linux box. Also, if you want a private session to learn Linux commands, Ramroot is definitely helpful. Give it a try, and don't forget to share your thoughts about this project in the comment section below.
Resource:
9 comments
Questions:
Does it CREATE or REPLACE the GRUB entry?
Can you setup a user session?
Can you mount HDD and SDD drives? so then save things
Question 1 – No, it doesn’t change anything. It simply loads the filesystem into RAM
Question 2 – You can set user session and switch to the new user.
Question 3 – I haven’t tested this yet. I suppose it should work.
The logic dictates that any Linux that can mount a filesystem on read & write can do changes to such filesystem.
Since your question 3 is ambiguos (what thigs to be saved?) i answer with what i thing it could be… actually i will investigate this “ramroot” as soon as i can… it seems to be just what i am most interested upon years (be able to run a full distro on my 64GiB Ryzen 7 2700X fully from RAM), yes i did not recieve yet all pieces of my new computer but i was searching for howto since years, prior to buy the hardware, even prior than the hardware even exists… other main goal i was looking for was loading VirtualBOX from RAM with Winodws10 virtual disk image file on RAM (more than 32GiB).
Answering to your question 3: Yes and No.
If you mount a filesystem you can save files, so downloaded PDFs can be saved to such filesystem, etc… just DATA.
But if you pretend to save applications configuration changes, or new installed apps, i am afraid will NOT be saved upon reboot, this does not seem like some LiveCD that uses a special file to save your session among reboots.
This must be much more powerfull from what i can thing of its uses:
1.- Boot with all your system on ram is equivalent to make system inmutable, so you can intentionally infect your system with a VIRUS (just the concept as a drastic example, i know how impossible is for a Linux to be infected) and on next boot no change persist, it will boot as it did, nothing had changed since all changes where done on RAM… except what you change by mounting filesystem in read & write mode… for example you can work with Gimp, Blender, LibreOffice or whatever, your work will be saved, but changes on such programs configurations will not persist upon a reboot (like historical opened/saved files, etc.)
2.You can chroot to system on real storage and there make changes, like install packages, etc… very usefull because you can prepare an install script, tested (see what fail, fix it, etc) on your RAM root, once you have it working (you can use reboots to test it multiple times) then you can chroot and run it there with the confidence it will do the same as when on RAM root… so you can failsafe install things on your system because you can try them on inmutable copy of your system (without the need to clone/restore since on boot it copies all to ram)… great use, since some installs can ruin a system; warning: anything that needs reboot will void this idea until a persistent next boot could be implemented.
3.-Also copy to ram VirtualBOX machines and run them enterly from ram, after shutdown just be sure to copy back to physical media from ram drive or you loose all changes… again one more extra use of this, no need to make inmutable disk image on VirtualBOX and loose disk speed, since if you want it to be inmutable, you just do not save the modified image… very usefull for Windows guest updates that fails and ruin Windows system, not to mention the disk speed, it will be RAM speed, not such very slow NVMe that can write 5Gib/s, yes RAM is a lot more fast than the fastest NVMe.
4.-Also if you want to make changes to installed apps, etc, there is the option to boot normal, without copy to ram.
I want to test it as soon as i can, it will help me a lot… if it does what it say it does… copy the whole root onto RAM and run from there.
Extra: Some motherboards let you how-swap SATA drives, some has SIX ports, imagine SIX fast SSD in LVM2 Striped (i know cost is arround 500 €), at each boot you only read from them and at speeds near best NVMe gives, but after boot you can put out them from your PC (with NVMe you can not, at least actually i do not know of any hot-swapable NVMe motherboard), so after that no matter what command is run, such SSD will not be able to be written (since they are not connect to the PC anymore), so you can do whatever ‘dd’ you want being sure you will not damage the data on them, as opposite if you ‘dd’ your NVMe you can ruin it.
SuperExtra: Imagine you boot fully to RAM and then have no storage space available (no storage connected), you can let your son or an extranger to use your PC, you know whatever do will got lost or not saaved to your storage, since tour storage is far away and off-line… it is similar to use a LiveCD without any storage drive on the system, but tons faster.
I can not wait to put my hands on this piece of softare, it is does such ‘copy root to ram’ and ‘continue to boot from ram’ it would be my best day ever.
Sorry to be so detailed and so happy that finally something like this exists, but most people do not image what the concept of this piece of software allows… i had only commented the top most usefull/importatn ones… like: makeing your system inmutable, ensure no write go to your disks after eject sata drives (if sata ports are hot-swapable) after copy to ram ends, probe new updates / installs prior to deploy them on the real system, etc.
P.D.: I know this piece exists just today… but i was preparing my self for a day like this one since more than ten years… wishing i have money on time (for 4x16GiB=64GiB DDR4 3200MHz) and all knownledge to reach it…. till today i was trying with Grub2 ISO files Boot, like SystemRescueCD but with my own made distro… this aproach is much more easy, just install a package and at boot time select yes… luckly anyone could find how to make ‘yes’ as default.
OMG, thanks for your detailed comment Mr.Anonymous. Your comment is much more clear than my article. This should be added in the Ramroot official wiki page.
Hi, I am running arch linux from a couple of weeks now, having used other distros over a long time, i will be trying this implementation of ramroot, i have tried out similar stuff in windows in previous years, also for anonymous above there are a no of linux distros already available that run entirely from ram, google for distros that run from ram and u will find them, I think this should allow one to still give access to disk and not be fully virtual. Very good site and lots of good info on arch linux by sk. thanks.
You’re welcome.
:: ramroot status: enabled
:: root filesystem not loaded to RAM
how would i go about fixing this ?
hI this project is still on?
Last commit on GitHub page is November, 2019. So I think the project is still alive.