RAMboot How-To for Debian 8 Jessie
I have refined and updated my RAMboot how-to for Debian 8. Honestly, my previous how-to's still work fine for Debian 8, regardless of the switch to systemd. I have, however, tightened things up.
The basic concept is to boot from a local hard drive or USB drive, using a modified initrd to unpack ramboot/image.tar.gz to a tmpfs ramdisk. From then on, the system runs entirely from ram - uncompressed. This is like running off an extremely fast SSD, but with some important differences:
1) Because tmpfs is purely in RAM, you lose all data on power down. A script can save the current / partition into an updated ramboot/image.tar.gz, but this is a bit slow. See addendum2 for a very fast way to save just your home directory on demand.
2) Boot time is slow due to the need to load the entire image.tar.gz file. A normal SSD just mounts and immediately continues with the boot process.
3) Because the OS partition resides entirely in RAM, less RAM is available for normal use. However, this can be compensated for by using a swapfile or partition. This swapfile may be on another computer, and may even be put on the RAM of another computer (see below).
4) Because / is not a "normal" partition, update-grub will fail when it tries to figure out the canonical path of /. To compensate, we'll rename /boot/grub/grub.cfg so kernel updates do not even attempt to run update-grub. You'll have to manually copy over updated initrd and vmlinuz files to the physical boot drive.
So why RAMboot? If you've got enough RAM, it is blazing fast compared to a normal hard drive, or a slower SSD. Combined with swap on a fast SSD, it will give you the fastest performance you can squeeze out of your computer - if you don't mind the extra boot time.
Also, it costs less to not buy an SSD, and there are situations where an SSD is not a practical option. For example, you might have a laptop with only one drive bay, and you want a spinning hard drive with lots of storage in it. Or you have a Mac Mini where the hardware is purposefully designed to make it difficult to replace the hard drive.
- - - - - 8< - - - - - cute here - - - - - 8< - - - - -
Step 1) MINIMAL DEBIAN 8 INSTALL
Do a minimal Debian 8 install on /dev/sda1 (either a hard drive or USB, typically) and boot to it. Deselect all software suites, unless you're sure you want them.
Step 2) CREATE /tmp RAMDISK, PREPARE /etc/fstab
Log in as root. Edit /etc/fstab and add these lines:
The resulting fstab will look like:
Make a couple copies with:
Edit /etc/fstab.RAMBOOT to uncomment the last line and modify the old / to /mnt/sda1. The result will look like:
Now, make /ramboot, /mnt/sda1 and mount /tmp with:
Step 3) PREPARE CUSTOMIZED /usr/share/initramfs-tools/scripts/local
Make a copies of /usr/share/initramfs-tools/scripts/local with:
Edit local.RAMBOOT by replacing the root mount line from this:
to this:
Step 4) CREATE CUSTOM BOOT FILES
Step 5) CREATE THE IMAGE
We're going to temporarily move the RAMBOOT files in place of the NORMAL files, and also temporarily move grub.cfg. The reason for moving grub.cfg is to prevent the ramboot system from attempting to run update-grub on kernel updates (it would fail, because it can't find the canonical path of /). Later on, you will have to manually copy over the updated vmlinuz and initrd.img files to /mnt/sda1/boot/vmlinuz-ramboot and initrd.img-ramboot.
Reboot, and see if it works! Choose "advanced options" to choose between ramboot and normal mode.
At this point, the / folder will have about 571MB used, and image.tar.gz will be about 220MB in size.
MAINTENANCE
When you want to save a new image, based on the current state, do the following:
If the kernal has been upgraded, manually copy over the new initrd.img and vmlinuz with something like:
To move this RAMBOOT option to another computer/drive that already has a normal install, simply copy over initrd.img-ramboot and vmlinuz-ramboot to the /boot/ and image.tar.gz to /ramboot/ (create /ramboot). Then run "update-grub" and it should detect the new ramboot option. Remember to go into "advanced options" on boot, to choose between ramboot and normal mode.
INSTALLING XFCE4 GUI
Here's an example for installing a GUI. It's not the most stripped down option, but it's easy to specify without being too heavyweight.
After this, / will be about 1084MB and image.tar.gz will be about 428MB. Obviously, adding more software will increase the size of both.
- - - - -
ADDENDUM - USING RAM ON ANOTHER COMPUTER FOR SWAP
RAMboot consumes a good chunk of RAM, but less used files may be offloaded to swap. Thus, RAMboot can greatly benefit from fast swap space. If you've got a local SSD, great! Put a swap partition or swapfile on it, and you can practically eliminate the RAM penalty of RAMboot.
But what if you don't have an SSD? If you have a gigabit ethernet connection, you can use another computer's RAM as a pretty fast swap space. The basic idea is to set up the other computer as an nfs server, serving up a swapfile within a tmpfs nfs share. I detail how to do this in another blog post here:
http://www.linuxquestions.org/questi...omputer-37197/
- - - - -
ADDENDUM2 - "PERSISTENT" HOME ON DISK
One problem with RAMboot is that the snapshot process takes several minutes. This is okay for periodic software updates and the occasional configuration change. But it's annoying for /home, which may update frequently. To account for this, you can set up a taskbar icon to run a save script, along with a script in /etc/rc.local to load /home.
Example script /home/kuo/hsave.sh
You can add a load script to /etc/rc.local, making the end of it look something like this:
This may cause odd behavior if you have auto-login, as the login process fights with this script running like crazy. Thus, you might want to set auto-login to have a bit of a time delay.
The basic concept is to boot from a local hard drive or USB drive, using a modified initrd to unpack ramboot/image.tar.gz to a tmpfs ramdisk. From then on, the system runs entirely from ram - uncompressed. This is like running off an extremely fast SSD, but with some important differences:
1) Because tmpfs is purely in RAM, you lose all data on power down. A script can save the current / partition into an updated ramboot/image.tar.gz, but this is a bit slow. See addendum2 for a very fast way to save just your home directory on demand.
2) Boot time is slow due to the need to load the entire image.tar.gz file. A normal SSD just mounts and immediately continues with the boot process.
3) Because the OS partition resides entirely in RAM, less RAM is available for normal use. However, this can be compensated for by using a swapfile or partition. This swapfile may be on another computer, and may even be put on the RAM of another computer (see below).
4) Because / is not a "normal" partition, update-grub will fail when it tries to figure out the canonical path of /. To compensate, we'll rename /boot/grub/grub.cfg so kernel updates do not even attempt to run update-grub. You'll have to manually copy over updated initrd and vmlinuz files to the physical boot drive.
So why RAMboot? If you've got enough RAM, it is blazing fast compared to a normal hard drive, or a slower SSD. Combined with swap on a fast SSD, it will give you the fastest performance you can squeeze out of your computer - if you don't mind the extra boot time.
Also, it costs less to not buy an SSD, and there are situations where an SSD is not a practical option. For example, you might have a laptop with only one drive bay, and you want a spinning hard drive with lots of storage in it. Or you have a Mac Mini where the hardware is purposefully designed to make it difficult to replace the hard drive.
- - - - - 8< - - - - - cute here - - - - - 8< - - - - -
Step 1) MINIMAL DEBIAN 8 INSTALL
Do a minimal Debian 8 install on /dev/sda1 (either a hard drive or USB, typically) and boot to it. Deselect all software suites, unless you're sure you want them.
Step 2) CREATE /tmp RAMDISK, PREPARE /etc/fstab
Log in as root. Edit /etc/fstab and add these lines:
Code:
none /tmp tmpfs size=95% 0 1 #none / tmpfs size=95% 0 1
Code:
UUID=5129efa8-fd32-58e4-83fd-2e3afdbcdef653 / ext4 error=remount-ro 0 1 none /tmp tmpfs size=95% 0 1 #none / tmpfs size=95% 0 1
Code:
cp /etc/fstab /etc/fstab.NORMAL cp /etc/fstab /etc/fstab.RAMBOOT
Code:
UUID=5129efa8-fd32-58e4-83fd-2e3afdbcdef653 /mnt/sda1 ext4 error=remount-ro 0 1 none /tmp tmpfs size=95% 0 1 none / tmpfs size=95% 0 1
Code:
mkdir /ramboot mkdir /mnt/sda1 mount /tmp
Make a copies of /usr/share/initramfs-tools/scripts/local with:
Code:
cd /usr/share/initramfs-tools/scripts/ cp -vax local local.NORMAL cp -vax local local.RAMBOOT
Code:
mount ${roflag} -t ${FSTYPE} ${ROOTFLAGS} ${ROOT} ${rootmnt}
Code:
###mount ${roflag} -t ${FSTYPE} ${ROOTFLAGS} ${ROOT} ${rootmnt} mkdir /ijkijk mount ${roflag} -t ${FSTYPE} ${ROOTFLAGS} ${ROOT} /ijkijk mount -t tmpfs -o size=95% none ${rootmnt} cd ${rootmnt} echo "Extracting from ramboot/image.tar.gz ..." tar xzf /ijkijk/ramboot/image.tar.gz umount /ijkijk
Code:
cd /usr/share/initramfs-tools/scripts/ cp -vax local.RAMBOOT local mkinitramfs -o /boot/initrd.img-ramboot cp -vax local.NORMAL local cp -vax /boot/vmlinuz-3.16.0-4-686-pae /boot/vmlinuz-ramboot update-grub
Step 5) CREATE THE IMAGE
We're going to temporarily move the RAMBOOT files in place of the NORMAL files, and also temporarily move grub.cfg. The reason for moving grub.cfg is to prevent the ramboot system from attempting to run update-grub on kernel updates (it would fail, because it can't find the canonical path of /). Later on, you will have to manually copy over the updated vmlinuz and initrd.img files to /mnt/sda1/boot/vmlinuz-ramboot and initrd.img-ramboot.
Code:
apt-get clean cd /usr/share/initramfs-tools/scripts/ cp -vax local.RAMBOOT local cp -vax /etc/fstab.RAMBOOT /etc/fstab mv -vi /boot/grub/grub.cfg /boot/grub/grub.cfg.MOVED tar cvzf /tmp/image.tar.gz --one-file-system / cp -vax local.NORMAL local cp -vax /etc/fstab.NORMAL /etc/fstab mv -vi /boot/grub/grub.cfg.MOVED /boot/grub/grub.cfg cp -vax /tmp/image.tar.gz /ramboot/
At this point, the / folder will have about 571MB used, and image.tar.gz will be about 220MB in size.
MAINTENANCE
When you want to save a new image, based on the current state, do the following:
Code:
cd /mnt/sda1/ramboot/ mv -vi image.tar.gz iback tar cvzf /mnt/sda1/ramboot/image.tar.gz --one-file-system /
Code:
cp -vax /boot/initrd.img-3.16.0-4-686-pae /mnt/sda1/boot/initrd.img-ramboot cp -vax /boot/vmlinuz-3.16.0-4-686-pae /mnt/sda1/boot/vmlinuz-ramboot
INSTALLING XFCE4 GUI
Here's an example for installing a GUI. It's not the most stripped down option, but it's easy to specify without being too heavyweight.
Code:
apt-get install xorg xfce4 lightdm apt-get clean
- - - - -
ADDENDUM - USING RAM ON ANOTHER COMPUTER FOR SWAP
RAMboot consumes a good chunk of RAM, but less used files may be offloaded to swap. Thus, RAMboot can greatly benefit from fast swap space. If you've got a local SSD, great! Put a swap partition or swapfile on it, and you can practically eliminate the RAM penalty of RAMboot.
But what if you don't have an SSD? If you have a gigabit ethernet connection, you can use another computer's RAM as a pretty fast swap space. The basic idea is to set up the other computer as an nfs server, serving up a swapfile within a tmpfs nfs share. I detail how to do this in another blog post here:
http://www.linuxquestions.org/questi...omputer-37197/
- - - - -
ADDENDUM2 - "PERSISTENT" HOME ON DISK
One problem with RAMboot is that the snapshot process takes several minutes. This is okay for periodic software updates and the occasional configuration change. But it's annoying for /home, which may update frequently. To account for this, you can set up a taskbar icon to run a save script, along with a script in /etc/rc.local to load /home.
Example script /home/kuo/hsave.sh
Code:
#!/bin/sh rsync -vaxAX --delete /home/kuo/ /mnt/sda1/home/kuo/
Code:
rsync -vaxAX --delete /mnt/sda1/home/kuo/ /home/kuo/ exit 0
Total Comments 4
Comments
-
Note on 2017-05-08
The most recent Debian 8 update (to Debian 8.8, I think) updated /usr/share/initramfs-tools/scripts/local which meant that it overwrites the modifications used to load the root file system into RAM. This will cause the system to boot up to the hard drive instead, possibly a minimal install and also possibly broken if the hard drive architecture is different from the architecture of the tarball (32 bit vs 64 bit).
So, you'll want to redo the modifications to local (and make a convenience copy to local.RAMBOOT) and use something like this to rebuild the init:
Code:mkinitramfs -o /boot/initrd.img-3.16.0-4-amd64 cp -vax /boot/initrd.img-3.16.0-4-amd64 /mnt/sda1/boot/initrd.img-ramboot cp -vax /boot/vmlinuz-3.16.0-4-amd64 /mnt/sda1/boot/vmlinuz-ramboot
Posted 05-08-2017 at 12:04 PM by IsaacKuo -
Notes on Debian 9 Stretch
one quick initial note on Debian 9 Stretch:
When upgrading from Debian 8 to Debian 9, it will want to update grub-pc. It will fail, because it will try to run update-grub even if /boot/grub/grub.cfg does not exist. More generally, my trick of renaming (or erasing) /boot/grub/grub.cfg might not work any more. It seems to try to run update-grub regardless of whether or not grub.cfg exists.
So, instead of using this trick to prevent trying and failing update-grub (fails when it can't find the root canonical path), do this instead:
After booting up into the RAMBOOT install, uninstall grub-pc with:
Code:apt-get remove grub-pc apt-get autoremove --purge
Obviously, do NOT do this while still booted up in the normal hard drive install!
If you don't do this, then it's not really a problem. It's just that every time you do update or install software with apt-get, it will complain that it can't finish installing grub-pc. If you don't mind the annoyance of this every time, you can just leave grub-pc semi-installed.Posted 06-22-2017 at 08:41 AM by IsaacKuo -
I have confirmed that other than removing grub-pc (instead of just moving grub.cfg), everything here works in Debian 9 Stretch.
Posted 06-27-2017 at 04:44 AM by IsaacKuo -
If you have 3GB or less of RAM, and you're looking for places to shave some tmpfs drive space:
1) Move /usr/share/doc onto a local drive or nfs mount, or simply delete it entirely (software updates will tend to put stuff back into it). This can save about 100MB, which is a big deal if space is tight. According to the Debian standards, all software is required to not break if /usr/share/doc is not present.
2) Move /home/<user>/.cache/chromium and other web browser caches onto a local drive or nfs mount. A symlink will work. This can save over 100MB. Even if it's a bit slower than local ram, it's likely you'll never notice since it's still a lot faster than pulling off the internet and web browser speed tends to be limited by the speed of downloading the bits necessary off the internet anyway.
3) Move /home/<user>/.config/chromium and other web browser config onto a local drive or nfs mount. A symlink will work. This actually might not save much space, if you don't use lots of heavy plugins or whatever. But it's nice for you to be able to resume where you left off web browsing in case of power failure. Just make sure to apt to the latest version of the web browser before running it after a power failure. Otherwise, you might lose stuff if you try to run chromium with an older version than what's in the .config save (I learned this the hard way).
Moving the web browser cache/config off to an nfs share is a particularly good fit, because if the network is down you're not doing any web browsing anyway.
With these tricks, you can reduce the size of tmpfs / by well over 200MB.Posted 07-02-2017 at 04:15 AM by IsaacKuo