Although this howto still works for the main part, an updated version of it in the form of a script (greatly simplified) can be found here:
http://ubuntuforums.org/showthread.php?t=1594694
What this guide will try to accomplish
I will try to update and expand upon the guide written by capink here back in 2008. The guide basically explains how to create a squashfs image out of your existing Ubuntu installation and copy the entire image to RAM upon boot to speed up your OS. I will also go into some detail of how to make your /home mount from a regular hard drive thereby making sure the important information one would wish to save on their machine would remain untouched between boots.
A little history
I have always been fascinated with the idea of speeding up an OS by the non-conventional way of providing a faster medium from which it runs. I call this non-conventional because I use to think (and I believe many people still do) that just by buying faster and faster processors that my computer would keep speeding up more and more. Although this is the case to some degree, after purchasing my QX9650 a few years back and not seeing as much of a difference as I would have hoped, I realized there had to be something else that was slowing my computer down.
That's when I found out about SSDs. I've read much about them, and finally a few months ago got my first SSD - an X25-M 160GB Intel SSD. Installing my Windows 7 on it, I realized how insanely fast this made it run. Everything just seemed to open instantly. All my games loaded instantly. This was what I had been looking for to speed up my OS.
Unfortunately the downside of this was that the speed of my Windows 7 now made my Ubuntu 10.04 feel slow. The first thought that came to mind was of course to create another partition on the large, 160GB SSD and move my Ubuntu there. In order to maintain the SSD's fast speeds however, TRIM was required. TRIM is something that keeps an SSD running at its top speed. Without it, an SSD will slowly slow down while being used. TRIM is built into Windows 7, so I had no problems with my SSD in Windows, but, from what I've read, TRIM did not make it into the kernel Lucid uses by 1 day.
I had a choice here. I could either find the patched kernel that included TRIM support, and replace my existing kernel with it (messing with the kernel is something I've never done as I've never had the need to), or I could take the opportunity to make my Ubuntu work even faster than the SSD could allow.
One of the first Linux distributions I tried was knoppix. Knoppix had (and probably still does) an amazing feature called "toram". The way you would use this is simply add the string "toram" to the boot line when knoppix was starting from the cd and the entire knoppix CD would be copied into your RAM before being run. Now even though this took a while (about a minute in most cases), the advantage to this was that this made knoppix run insanely fast. Which brings me to the reason why you would want to do this:
Why do this?
Looking at the DDR2 page of wiki, it is clear the advantage RAM has over regular hard drives. Something as cheap as DDR2-533, something you could easily obtain an extra 1 GB of for about $30, has roughly a speed of 4266 MB/s. Compared to a regular 100MB/s hard drive, that's 42 times faster. If you have a slightly more expensive system that supports faster RAM (I have 6GB of DDR2-1066 RAM), the speed of the RAM can be up to 8533 MB/s. Imagine every file your operating system requests to read or write being served up at that speed!
Who should do this?
What this will do is basically remove (or at least significantly decrease) the conventional hard drive as a bottleneck for computing. That means your processor will likely be the next in line to be the bottleneck. If you have a slow processor (anything below dual core I would imagine) than this will likely not help you as your processor won't be fast enough to take advantage of the speed increase and the trouble of setting this up and maintaining it would not be worth the slight (if any) increase in performance.
You also need enough RAM to pull this off. I would guess that you would need at least 2GB 3.5GB to fit the entire Ubuntu Lucid 10.04 OS into your RAM and have RAM left over to work with. As RAM is cheap these days, this should not be too much of a problem for most people. I have 6GB so I've had no problems running out so far and do not plan to have any in the future. You could of course use less RAM (eg 2GB), but that would require you to keep a close eye on your free space, or remove packages from Ubuntu that you do not use to decrease its size (like Open Office). If you are curious why the sudden change from my initial estimates, this is mainly due to the recently discovered inaccuracy of System Monitor in telling the used/free RAM. See the "Possible Reason for Slowdown" section of this howto at the bottom for more info.
You will also need at least an intermediate knowledge of linux. A beginner might be able to do this with a little reading into the concepts being used here but will more than likely get lost.
Lets Begin
The following is an almost word for word copy and paste of capink's original post (link above). This is because many of the steps he wrote about in 2008 are still relevant today. To keep this from being half quotes and half not quotes, effectively destroying formatting, I will not put the sections that came from him in quotes. I will however make them red, while my additions will be black.
The main idea and the general principles are similar to the original wiki on how to boot Ubuntu to RAM. But this guide has some differences to the original wiki:
1. Rather than using a live CD, we will use the system installed on your harddisk as the basis of the image we will create.
2. This guide uses live-initramfs instead of casper. This is because live-initramfs is present in both Ubuntu and Debian so that guide can serve wider audience. For those who want to use casper instead it should work the same but I have not tested it, you will just need to replace live-initramfs with casper and /live with /casper.
3. No editing of the boot scripts as live-initramfs introduced an option to boot from ram automatically.
4. Unlike the method of the original wiki, using this method all your partitions are going to be mounted automatically exactly as they are mounted when you boot your normal system, with the exception of the root partition.
Note: Since the system is going to be copied to RAM, the boot process takes slightly longer time. For those of you with an SSD, I will explain how to copy the image to a partition on the SSD to speed this up a bit.
N.B This guide works only for Ubuntu gutsy and Debian lenny or later. I have tested this only with Ubuntu Lucid 10.04. You may need to modify a few things to get it to work with other versions of Ubuntu.
NOTE: Although I will cover a way to make the data on your desktop and in your home folder (the entire /home) remain after a reboot, anything you install or configure (with a few exceptions) will be lost after a reboot! This guide also deals with partitioning your disks and formatting them. This can also destroy data if not done carefully. Proceed with caution.
Requirements
Enough RAM. How much depends on the size of the squashfs image we are going to create from the installed system. A system that is 1.5 G in size will create roughly a 500 M squashfs. Since this 500 M is going to be copied to RAM, your RAM must be larger than 500 M, at least by an additional 256 M of RAM (Amount of RAM required = squashfs size + at least 256 M). But to work comfortably in the previous scenario it is recommended to have 1 G or more of RAM.
If you have a swap partition (which you should since you already have a copy of Ubuntu installed), The system will fall back to it when the RAM gets full. But this will severely limit the speed of the system which defeats the purpose of this guide.
You also need enough harddisk space. At least double the amount taken up by your system.
Note: A command to know how much space is taken up by your system:
Code:
sudo du -hcs --one-file-system / --exclude=/dev/* --exclude=/tmp/* --exclude=/sys/* --exclude=/proc/* --exclude=/home/*
The process:
1. Install some essential packages:
live-initramfs is present in the universe section of the repository. You must first enable universe repository before attempting to install the package. Here is guides to enable universe (Ubuntu GUI, Kubuntu GUI, CLI).
Code:
sudo apt-get update
Code:
sudo apt-get install live-initramfs squashfs-tools
Note: the 'linux-ubuntu-modules-$(uname -r)' from capink's guide can no longer be found in the Lucid repos and is not necessary, so it has been removed.
Also, if you have casper installed, you may have to remove it for live-initramfs to install properly (thanks to CarloMagno for the tip).
If you run into problems (especially in Jaunty) where apt exits with a message similar to:
Code:
update-initramfs: Generating /boot/initrd.img-2.6.28-19-generic
cpio: ./bin/udevinfo: Cannot stat: No such file or directory
update-initramfs: failed for /boot/initrd.img-2.6.28-19-generic
dpkg: subprocess post-installation script returned error exit status 1
E: Sub-process /usr/bin/dpkg returned an error code (2)
run:
Code:
gksudo gedit /usr/share/initramfs-tools/hooks/live
and change the line that reads:
copy_exec /usr/bin/udevinfo /bin
to
copy_exec /sbin/udevadm /bin
also add the line:
copy_exec /usr/bin/du /bin
to the file. Save and exit gedit.
then run:
Code:
sudo dpkg --configure -a
Thanks to happyhamster for the tip.
2. Update the kernel modules dependencies:
3. Update the initramfs
Code:
sudo update-initramfs -u
4. Copy your filesystem to temporary directory (go get yourself a cup of coffee once you do this since this could take a few minutes)
Code:
sudo mkdir -p ${DEST}
Code:
sudo rsync -av --delete / ${DEST} --one-file-system \
--exclude=/proc/* --exclude=/tmp/* --exclude=/dev/* \
--exclude=/sys/* --exclude=/boot/* \
--exclude=/home/* --exclude=/etc/mtab \
--exclude=/live --exclude=${DEST}
Note: You can replace /var/squashfs with any path you wish. Just make sure that it have enough space.
5. The home directory
The home directory is the location where your Desktop, Music, Pictures, and user specific settings are kept. The main idea behind this guide is that in linux, the home directory is modified frequently, such as when you save files to your desktop, add mp3s to your collection or even modify programs like firefox, evolution, pidgin, or the like which creates files to store those settings in your home directory. The rest of the system however is rarely modified where the modifications are vital. This is why keeping the /home directory on a non-volatile storage medium will in most cases keep your files and settings between reboots, while the speed of the RAM which the rest of the system will reside upon will give you a much needed boost. Of course this means that things like system updates, log files, and settings stored in /etc will not survive a reboot, but I will show you how to deal with this below.
To move the home directory, you must first create a new partition where it will reside:
Code:
sudo apt-get install gparted
gksudo gparted
Note: Be careful with this tool as you can seriously damage your system by wiping out Linux or Windows completely if you start formatting things you shouldn't be.
Using gparted, create a new partition using some free space somewhere on your hard drives. In most cases, you will not have any unallocated space to create such a partition. In this case, you will first have to find your linux partition, and resize it by taking some space from the end of it. Because you are working from within the linux located on this partition, you may first have to boot into a live cd and launch gparted from there in order to resize your linux partition. You can also use a usb drive to store your /home partition but you would need to remember to always have it pluged in when booting into your Ubuntu.
You will need this partition to be as big as you expect to use up with the files that will be on your desktop, your music folder, pictures, and anything else in your home directory. I recommend at least 5GB.
You will also be asked which file system to use for this partition. I recommend ext4 as it is the latest and greatest, or ext3 if you would rather have stability and peace of mind (ext4 originally had some issues that kept people from adopting it - I think they have been worked out since then though).
Take note of the device this partition is using (eg. /dev/sda3). You will need this later.
Once you have created the new partition, mount the device:
Code:
sudo mkdir -p /mnt/home
sudo mount /dev/sda3 /mnt/home
Change /dev/sda3 to the one in your case. Then run:
Code:
sudo cp -a /home/* /mnt/home/
to copy everything you have in your /home to the new partition that will contain your /home. The -a will preserve the file permissions and ownership.
6. Modify fstab of the copied filesystem
Code:
gksudo gedit ${DEST}/etc/fstab
delete the entry of the root directory. It should look like this:
Code:
UUID=..... / ext3 defaults,.... 0 1
To use the partition that we created in step 5 as our /home, add a line similar to the following:
Code:
/dev/sda3 /home ext4 auto 0 0
Change /dev/sda3 to the device you took note of in step 5, and ext4 to the type of filesystem you created in step 5 (likely either ext4 as above, or ext3).
After finishing with that, save the file and close gedit.
7. Clean some unnecessary files
Delete some files under ${DEST}/var
Code:
[ -n "$DEST" ] && sudo find ${DEST}/var/run ${DEST}/var/mail ${DEST}/var/spool ${DEST}/var/lock ${DEST}/var/backups ${DEST}/var/tmp -type f -exec rm {} \;
Delete only OLD log files:
Code:
[ -n "$DEST" ] && sudo find ${DEST}/var/log -type f -iregex '.*\.[0-9].*' -exec rm -v {} \;
Code:
[ -n "$DEST" ] && sudo find ${DEST}/var/log -type f -iname '*.gz' -exec rm -v {} \;
Clean current log files:
Code:
[ -n "$DEST" ] && sudo find ${DEST}/var/log -type f | while read file; do echo -n '' | sudo tee $file; done
Note the small difference from the original command by capink which prevents the extra newline created in log files.
Clean Pakcage cache:
Code:
[ -n "$DEST" ] && sudo rm -v ${DEST}/var/cache/apt/archives/*.deb
8. Create the squashfs image
The squashfs image must reside in /live
Code:
sudo mksquashfs ${DEST} /live/filesystem.squashfs -noappend -always-use-fragments
Examine the size of the image and make sure it is less than the size of your RAM.
Code:
sudo du -h /live/filesystem.squashfs
9. Add a new entry to Grub
If you are using regular grub (the old grub), than capink's instructions will probably work for you. If however you are using Grub2, which comes default in Lucid, skip to the grub2 section.
Grub:
Add a new entry to /boot/grub/menu.lst of your main system
Code:
gksudo gedit /boot/grub/menu.lst
Copy the entry of your main system and modify it to look exactly like this:
Code:
title RAM Session
root (hd0,2)
kernel /boot/vmlinuz-$(uname -r) BOOT=LIVE boot=live toram username=user nosudo noxautoconfig noautologin quickreboot ro quiet splash
initrd /boot/initrd.img-$(uname -r)
The text highlighted in blue should match the corresponding parts of your main system entry.
Replace user with your account username.
The parts highlighted in Red are essential.
Grub2:
This is probably the biggest change since capink's guide. Since 2008, Grub2 has become Ubuntu's default, and it works a little differently from Grub. To create the menu entry for your RAM session using grub2 do the following:
Create a file called 50_RAMSESS in your /etc/grub.d/ folder.
Code:
gksudo gedit /etc/grub.d/50_RAMSESS
The file should read something very similar to:
Code:
#!/bin/sh -e
cat << EOF
menuentry "Ubuntu, Linux $(uname -r) to RAM" {
set root='(hd0,1)'
linux /boot/vmlinuz-$(uname -r) boot=live toram=filesystem.squashfs apparmor=0 security=""
initrd /boot/initrd.img-$(uname -r)
}
EOF
Where (hd0,1) is the location of your Ubuntu installation.
Save the file and exit gedit. Run:
Code:
sudo chmod a+x /etc/grub.d/50_RAMSESS
to make the script executable and:
to update the grub menu.
10. Reboot and choose the RAM Session from your boot menu.
It will take a few seconds or minutes to copy the squashfs image into your RAM, after which, the system will boot and you will be able to use it at incredible speeds.
Speeding up boot using an SSD
If you are fortunate enough to have an SSD (for your Windows 7 for example because this obviously can't be done in Windows), you can speed up the boot process by copying the squashfs image onto a partition on the SSD. Since the SSD is faster than a regular hard drive, your system will copy the image into RAM during boot at far greater speeds (with an X25-M, I can copy the ~1.5GB image in about 10 seconds at 160MB/s, about 3 times faster than from my regular 7200RPM WD hard drive at about 50MB/s).
To do this, resize whatever partition is currently on your SSD. If it's Windows, you may want to do the resize with Windows tools such as those provided by Paragon or Acronis as they will properly inform Windows of the change, something I don't think gparted does - though I could be wrong. All you need is a partition big enough to fit your squashfs image. If you have plenty of space on your SSD, a 5GB partition should do. If not, try 3GB.
I formated my partition as ext4 but you could probably get away with ext3 if you like.
Make a folder on the newly created partition on your SSD in the root of the drive (don't make it in any subfolders) and call the folder "live".
Copy your /live/filesystem.squashfs to this folder. You will need to repeat this whenever you update /live/filesystem.squashfs.
Modify your /etc/grub.d/50_RAMSESS on your Lucid (NOT ON THE RAM IMAGE OR /var/squashfs) to read:
Code:
#!/bin/sh -e
cat << EOF
menuentry "Ubuntu, Linux $(uname -r) to RAM" {
set root='(hd0,2)'
linux (hd0,1)/boot/vmlinuz-$(uname -r) boot=live toram=filesystem.squashfs apparmor=0 security=""
initrd (hd0,1)/boot/initrd.img-$(uname -r)
}
EOF
Where (hd0,2) should now point to your newly created 5GB partition on your SSD, while (hd0,1) should point to your regular Ubuntu Lucid partition.
Once this is done, run:
and your image should now be copied from your SSD during boot.
Issues once you boot from RAM
The first time I did this, as soon as I booted from RAM I noticed that my Internet was not working. It turns out as stated here by jesbecker:
apparmor does not work well with stacked and read only files systems. A work around for this bug is to either disable for remove apparmor.
Disable:
You can disable by adding apparmor=0 and security="" as kernel options in your grub boot configuration.
Remove:
You can also choose to remove apparmor by executing: sudo apt-get remove apparmor
This issue seems to affect any program that is protected/enforced by apparmor.
As you may have noticed, this is the reason I added apparmor=0 and security="" to the end of the 50_RAMSESS. This fixes the internet. I also tried "sudo apt-get remove apparmor" as suggested by jesbecker before I made those additions to my 50_RAMSESS and that works too.
Broken time
If your time is wrong every time you boot into your RAM session, run:
Code:
gksudo gedit /var/squashfs/etc/rc.local
from your regular Lucid and add the line:
Code:
dpkg-reconfigure --frontend noninteractive tzdata
just before the "exit 0" line that is already there. Save and exit. You will have to recreate your filesystem.squashfs image with:
Code:
sudo mksquashfs /var/squashfs /live/filesystem.squashfs -noappend -always-use-fragments
and move it to your SSD if necessary.
Broken applets
You may also find that some of your items from the Panel (top right) have disappeared, or moved around. I'm not sure why this happens but once you restore them once, and arrange them the way you want, they should be fine. The way these items are arranged is saved within the /home folder as settings so in theory they should remain the way you set them up despite reboots. They do get jumbled around sometimes after a reboot for some reason.
For those adventurous enough to test something that has yet to be properly tested, try this to fix the panel:
Organize the panel the way you want it to be. Then run:
Code:
mkdir -p ~/.settings/
gconftool-2 --dump /apps/panel > ~/.settings/saved_panel_settings.entries
Boot into or mount and chroot into your regular lucid, and open your /var/squashfs/etc/rc.local with a text editor as root:
Code:
gksudo gedit /etc/rc.local
and above the "exit 0" line, add:
Code:
gconftool-2 --dump /apps/panel > /tmp/saved_panel_settings.entries
if [[ `md5sum /tmp/saved_panel_settings.entries | cut -d ' ' -f 1` != `md5sum ~/.settings/saved_panel_settings.entries | cut -d ' ' -f 1` ]]
then
rm /tmp/saved_panel_settings.entries
gconftool-2 --load ~/.settings/saved_panel_settings.entries
killall gnome-panel
fi
The code above works better as a script for some reason. Try saving it to your ~/Documents/ folder, making it executable with:
Code:
sudo chmod a+x panelfix.sh
and in the RAM session, go to System --> Preferences --> Startup Applications. Create a new startup program, call it anything, and for command, browse to or type the entire path including the file name of panelfix.sh.
Because fixing the panel involves reloading gnome-panel, which for a second makes the panel disappear and may be annoying every time you boot, this will check if the panel layout has changes since you saved it. If there has been a change, it will reload the panel to restore the save file. If not, it will not bug you.
After you have edited /var/squashfs/etc/rc.local, recreate your squashfs image with:
Code:
sudo mksquashfs /var/squashfs /live/filesystem.squashfs -noappend -always-use-fragments
Move it to the SSD if you need to.
If after a while you decide to change the panel again and want to save it again, just rerun:
Code:
gconftool-2 --dump /apps/panel > ~/.settings/saved_panel_settings.entries
This method of saving/loading the panel seems to work manually, but above is my attempt to make the process automated. I'm not sure if it will work. Let me know if there's a problem with it.
Performing System Updates/Changes
Although you may not need to modify your system other than your /home folder for quite a while, eventually you will need to perform updates or will want to install packages that will modify the system. This will be overwritten on next reboot unless you do the following (from within the RAM Session):
Code:
sudo mkdir -p /mnt/lucid
sudo mount /dev/sdc1 /mnt/lucid/
sudo mount -o bind /proc /mnt/lucid/var/squashfs/proc
sudo mount -o bind /dev /mnt/lucid/var/squashfs/dev
sudo mount -o bind /dev/pts /mnt/lucid/var/squashfs/dev/pts
sudo mount -o bind /sys /mnt/lucid/var/squashfs/sys
sudo cp /etc/resolv.conf /mnt/lucid/var/squashfs/etc/resolve.conf
sudo chroot /mnt/lucid/var/squashfs /bin/bash
change /dev/sdc1 to the device of your partition where Lucid was installed. You are now modifying the image you boot from (not directly - you will need to recreate it). To do updates run:
Code:
sudo apt-get update
sudo apt-get upgrade
and to install packages run
Code:
sudo apt-get install vlc
change vlc for the package you wish to install. Once you are done this, you will need to unmount the RAM disk and mount the regular lucid install to recreate the image. Type:
and
Code:
sudo umount /mnt/lucid/var/squashfs/proc
sudo umount /mnt/lucid/var/squashfs/dev/pts
sudo umount /mnt/lucid/var/squashfs/dev
sudo umount /mnt/lucid/var/squashfs/sys
to unmount the previously mounted partitions. Then run:
Code:
sudo mount -o bind /proc /mnt/lucid/proc
sudo mount -o bind /dev /mnt/lucid/dev
sudo mount -o bind /dev/pts /mnt/lucid/dev/pts
sudo mount -o bind /sys /mnt/lucid/sys
sudo cp /etc/resolv.conf /mnt/lucid/etc/resolve.conf
sudo chroot /mnt/lucid /bin/bash
rerun:
Code:
sudo mksquashfs /var/squashfs /live/filesystem.squashfs -noappend -always-use-fragments
to recreate the image. This will create a new /live/filesystem.squashfs with the changes you made. If you moved your filesystem.squashfs to an SSD as mentioned earlier, copy the new filesystem.squashfs from /live to the SSD.
Now Reboot.
To simplify the steps above, I have created a script to mount either the lucid installation or the RAMDISK. I keep this script in my /home/Documents folder and launch it from within the RAM session when I need to do updates or want to install a new program. It seems to work ok. See the file attached for the script.
Edit: Sorry, I forgot to mention that the script has the device hardcoded as /dev/sdc1, which for me it is. I made it easier to change by only making it necessary to modify a single variable at the top, but you will still have to open the file with a text editor such as gedit and change the $DEVICE at the top to the proper device for your setup.
Possible Reason for Slowdown
As I keep using my RAM session and notice things about it, I update this article as much as I can. The thing I recently noticed was that when you use a program (VMware in my case) that takes up your entire RAM, your swap begins to fill up. Now that's not unusual, but it does mean that your system may become ridiculously slow if this happens (in my case so much so that even the music I had playing started to lag a lot). This is why you should keep an eye on your RAM and swap space if you know you are going to be using programs that eat up RAM.
In order to see how much RAM is used up by your system, DO NOT use the System Monitor. The System Monitor seems to show how much RAM your OS (Ubuntu) is using, but does not tell you how much RAM is actually in use. As RAM is normally only used by your OS, this works fine most of the time, but since in our case we initially copied an image into RAM that the OS does not account for, the System Monitor ends up showing that you have much more free RAM than you actually have. To display a proper reading of how much RAM and SWAP space you are using (in MB), use:
One other problem that I noticed was that if you already started using a program that eats RAM and your swap fills up, simply turning off that program frees up RAM but your OS still continues to use that SWAP space, keeping it slow when it doesn't have to be. To solve this, you can either reboot, or run:
Code:
sudo swapoff -a && sudo swapon -a
to dump your swap and make the system use RAM again.
Conclusion
I'm no Linux expert, and this is pretty much my first howto but if anyone has any questions I'll try to help you out with them. Also if those more wise than myself see any problems or corrections with what I wrote, let me know so I can fix them.
Adv Reply
Originally Posted by terminator14
Bookmarks