Making Ubuntu Fast using RAM (updated and simplified)

[terminator14]

Ok, the problems seems to be mount --uuid . It wants to be mount -U uuid . But after i successfully mounted to /mnt/Original_OS the "redit" and "rupdate" give me

"Failed to mount RAM Session. Is it already mounted?"

Well, yes. It is already mounted. It needs to be or not? The command as far as i unterstood, is to update the image, after modifying any settings in the RAM session, am i right?

The redit command lets you modify the image because any modifications in the RAM Session do not get written to the image.
If this is unclear, check out the video if you haven't seen it:

https://www.youtube.com/watch?v=pmqx...ature=youtu.be

As for the problem you've been running into:

The 14.10_ng script was written for Ubuntu 14.10, where the mount command man page looks like this:

-U, --uuid uuid

I just noticed that Ubuntu 14.04's man page looks like this:

-U uuid

Apparently, the version change of the mount command between Ubuntu 14.04 and Ubuntu 14.10 added the --uuid argument, which I use in my scripts.
I just changed all my scripts to use -U instead of --uuid.
If you run:

sudo rupgrade

in the RAM Session, it should complain about failing to mount the Original OS, then update itself to a version that uses -U, then automatically run the new version and update all the other scripts.
If that doesn't work, let me know.
Thanks for helping me catch that.

[robert144]

rupgrade
A script for Ubuntu 14.04.1 LTS could not be found in the github RAM Booster repo

[terminator14]

rupgrade
A script for Ubuntu 14.04.1 LTS could not be found in the github RAM Booster repo

It's fixed. Sort of.
You should now be able to run "sudo rupgrade" to update the scripts, but after fixing the above problem, I noticed more trouble. Ubuntu 14.04's umount command also doesn't have the -R argument that Ubuntu 14.10 uses.
This prevents redit from exiting properly, causing it to spit out errors. It probably effects the other scripts too, but I haven't tried those yet.
Unfortunately, this is a bigger problem than --uuid, since there's no equivalent in Ubuntu 14.04 to -R. I'm going to need to write some code to get duplicate the functionality.
I guess my assumption that the script would probably work on 14.04 without any problems was just wishful thinking.
It's 2am here, so I'm going to have to do that tomorrow. After that, I'll probably actually try my script on 14.04 to see if I run into any more problems.
I might not test every option, but at least I can make sure that the basics work.

[robert144]

alright. Thanks for your help.

rupgrade
Failed to mount RAM Session. Is it already mounted?

I think the best is to get some sleep and try it again

[terminator14]

rupgrade
Failed to mount RAM Session. Is it already mounted?

The script doesn't check what you already have mounted - even if it's what's supposed to be mounted.
If something is already mounted, it exits. This is by design.
If you have something mounted there from earlier, either unmount it manually, or reboot. Then try "sudo rupgrade".
I made some more changes, and the umount problem I mentioned earlier should now be fixed in the new versions of the scripts (which get installed by rupgrade).

[cigtoxdoc]

There are several less than friendly issues with this software. First, if you use SpiderOak or PDFStudioPro, you DO NOT want to use separate directories for /home. Both of the programs I mentioned consider the second /home to be another unique PC. Second, if the program is uninstalled or exits without completion (see attachments), it can leave a mess. When I realized the first installation of RAM_booster_Ubuntu_14.10_ng.sh resulted in "Ubuntu_to_RAM" left out SpiderOak and PDFStudioPro, I installed the program using the dialog that says you need to unistall before beginning a second installation. I did that only to have the second installation (no separate /home) fail and leave a mess. I have attached a copy of the latest log file.

How should one recover from this situation so that everything was like it would have been before the first time trying to install the script?

Thank you

John

[terminator14]

There are several less than friendly issues with this software. First, if you use SpiderOak or PDFStudioPro, you DO NOT want to use separate directories for /home. Both of the programs I mentioned consider the second /home to be another unique PC. Second, if the program is uninstalled or exits without completion (see attachments), it can leave a mess. When I realized the first installation of RAM_booster_Ubuntu_14.10_ng.sh resulted in "Ubuntu_to_RAM" left out SpiderOak and PDFStudioPro, I installed the program using the dialog that says you need to unistall before beginning a second installation. I did that only to have the second installation (no separate /home) fail and leave a mess. I have attached a copy of the latest log file.

How should one recover from this situation so that everything was like it would have been before the first time trying to install the script?

Thank you

John

when_things_go_wrong_Making_Ubuntu_Fast_using_RAM (updated and simplified).pdf

All I see there is the regular install process, which fails to complete because your root partition ran out of space in the middle of creating /live/filesystem.squashfs
Sure, it didn't automatically remove everything at that point, but running the script again will detect that it ran and offer to remove everything

GParted after failed Fast RAM install.pdf

The only thing I see there is that /mnt/root is mounted, which the script did
To fix it, you would either:

1. unmount /mnt/root and delete the folder
   OR
2. reboot and delete the folder
   OR
3. just run the RAM_Booster script again, which will offer to uninstall RAM Booster, which will unmount and delete the folder automatically, and clean up everything else

I don't really see any of these as issues, as the script can't write data to a hard drive that's full, and uninstalling is as simple as it gets, which is covered both in the original post, and the video.
The script didn't break because the code malfunctioned - it broke because the partition ran out of space.
Even the "mess" that you are left with before you uninstall should let you boot your Original OS with no problems - the only thing you can't do is boot the RAM Session.

Edit: Since the script doesn't uninstall itself when squashfs fails to be created, I added a note to the new version that tells users that they should probably uninstall it to remove the partially installed files and stuff.
Uninstalling RAM_Booster cleans up everything the script does, no matter if the script finished running or broke somewhere in the middle.

Edit 2: Forgot to mention - I've never heard of SpiderOak or PDFStudioPro so I'm not sure how they effect the RAM Session

[adambond]

Subscribed

[claudiocapobianchi]

Hi! first of all, an entire post should be written only to thank you for the incredible work you did and keeping up. Having an OS loaded on ram is something absolutely astonishing, just imaging all its advantage blows my mind!!! Thank you again
I installed the Ubuntu 14.04_ng_BETA on a EXT4 / sharing the /home partition and all worked fine. On RAM session, I get the information window that suggest me to rupdate to install updates, so after

sudo upgrade

it hits all repositories, then reports;

Failed to unmount chroot
Scanning for processes holding it up...

None found

There was an error unmounting /mnt/Original_OS/
A reboot should fix that
After the reboot, you will need to save your changes by recreating
the squashfs image if there was an update. Just run "sudo redit -s"

I rebooted and logged in RAM session, typed

sudo redit -s

and pressed Y

"squashfs image created successfully
reboot to use it"

after the reboot,

sudo rupgrade

"No updates available"

sudo rupdate

same output about unmounting chroot, and if intstead of rebooting I write

sudo rupgrade

I get

"Failed to mount RAM Session. Is it already mounted?"

looks like a loop, how can I fix it? here you have the log file ram_booster.log.txt

Thank you very much.

[terminator14]

Hi! first of all, an entire post should be written only to thank you for the incredible work you did and keeping up. Having an OS loaded on ram is something absolutely astonishing, just imaging all its advantage blows my mind!!! Thank you again

Always nice to be appreciated

I'm not sure how familiar you are with Linux basics, so hopefully you can follow this, but it sounds like this is what's happening:

after the reboot,

sudo rupgrade

"No updates available"

This checks for updates to my scripts from github. As it didn't complain, it seems to have exited and run cleanly.

sudo rupdate

same output about unmounting chroot

It didn't show an error with mounting, so at that point everything seems fine.
After it is done running, it tries to unmount and fails, which gives you the error.
This means that at this point, /mnt/Original_OS, and filesystems underneath it are still mounted.

and if intstead of rebooting I write

sudo rupgrade

I get

"Failed to mount RAM Session. Is it already mounted?"

This seems accurate, because from the last error, we can tell that the RAM Session is still mounted.
It prevents it from running when it did not unmount cleanly by design.

The only problem I see is the fact that it couldn't unmount after checking for updates (after rupdate ran), which is a real problem, but a reboot should still be a workaround - it just fails to unmount all over again after a reboot when you run it again, but does actually do its primary function of checking for and installing updates before it fails.

Unfortunately, while a simple mount of like a flash drive or something will almost always unmount without problems, there are many reasons a mounted system with bind mounts of /sys, /dev, /dev/pts, /proc, etc. can fail to unmount. When I was writing the scripts, I spent many days tracking down as many reasons as I could and writing code to handle it, but clearly, there are still things unaccounted for. I'll see if I can reproduce the problem by installing Ubuntu 14.04, but this is one of the hardest problems in the project. The plan was to make this never be a problem again by switch to LXC to make the RAM Session more isolated when it gets mounted, to make it easier to unmount, but I've been busy and haven't gotten around to it.

I'll do some testing and post back.