Ask your questions here.
Post a reply

Problem with "toram" parameter

Sun Oct 05, 2014 7:39 pm

Dear community!
I've a well working entry for my snapshot without "toram".
But when I active "toram" the snapshot tries to load the whole content of my USB-stick into RAM. :(
Please help, maybe I'm missing something in my destination directory
Kind regards
Peter
Attached my configution:

My environment:
Adopted "Debian Wheezy"
Refracta-Snapshot Version 9.0.9


Filelist of the directory /iso/wartung.AMD64 on my USB-Stick:

filesystem.squashfs
initrd.img
memtest86+.bin
vmlinuz


The problem is the entry where I try to load "menuentry "PCArchiver (amd64, live, toram)".
Contents of the entry "utilities.lst" in my grub2-configuration on my USB-Stick:

set default="1"
set timeout=5

menuentry "Hauptmenue" {
configfile /boot/grub/sel.lst
}

#menuentry "PCArchiver (i386, live)" {
# dir=/iso/wartung.I386
# linux /$dir/vmlinuz live-media-path=$dir boot=live ip=frommedia union=aufs --
# initrd /$dir/initrd.img
#}

############################################################################################
# Works fully ok
menuentry "PCArchiver (amd64, live)" {
dir=/iso/wartung.AMD64
linux /$dir/vmlinuz live-media-path=$dir boot=live ip=frommedia union=aufs --
initrd /$dir/initrd.img
}
# Works fully ok

# Loads everything of the USB-Stick to RAM !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
menuentry "PCArchiver (amd64, live, toram)" {
dir=/iso/wartung.AMD64
linux /$dir/vmlinuz live-media-path=$dir boot=live ip=frommedia union=aufs toram --
initrd /$dir/initrd.img
}
# Loads everything of the USB-Stick to RAM !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
############################################################################################

menuentry "Mini Tool Parted Wizard 8" {
loopback loop /iso/pwhe8.iso
linux (loop)/BOOT/BZIMAGE ramdisk_size=102400 root=/dev/ram0 rw
initrd (loop)/BOOT/tinycore.gz
}

menuentry "SystemRescueCd 32" {
set isofile="/iso/systemrescuecd-x86-4.2.0.iso"
loopback loop $isofile
linux (loop)/isolinux/rescue32 isoloop=$isofile setkmap=de docache dostartx
initrd (loop)/isolinux/initram.igz
}

menuentry "SystemRescueCd 64" {
set isofile="/iso/systemrescuecd-x86-4.2.0.iso"
loopback loop $isofile
linux (loop)/isolinux/rescue64 isoloop=$isofile setkmap=de docache dostartx
initrd (loop)/isolinux/initram.igz
}

menuentry "Neustart vom USB - Stick" {
chainloader +1
}

menuentry "Neustart des Rechners" {
reboot
}

menuentry "Rechner Ausschalten" {
halt
}

Re: Problem with "toram" parameter

Mon Oct 06, 2014 12:55 am

Maybe I'm the one who's confused, but I think it's doing what it's supposed to do. From 'man live-boot':
toram
Adding this parameter, live-boot will try to copy the whole
read-only media to the computer's RAM before mounting the root
filesystem. This could need a lot of ram, according to the space
used by the read-only media.

Re: Problem with "toram" parameter

Mon Oct 06, 2014 4:41 am

I agree -- sounds like toram is performing the intended behavior. What did you expect it to do differently?

Anyhow, toram only provides a noticable benefit if you are booting from (relatively sloooow, compared to USB pendrive) CD-ROM media.

My slowest pendrive (actually it's an older camera miniSD card, now inserted into a USB adapter) is Class 2.
Example difference: launching firefox normally takes 7 seconds, vs 6 seconds within a toram session.
When reading smaller files and when launching most apps, I couldn't detect even a 1 second difference.

When booted from a Class 10 pendrive (via USB2.0 port), I really can't detect a speed difference period (even when opening large apps like OOffice or firefox).

Re: Problem with "toram" parameter

Mon Oct 06, 2014 6:20 pm

Thank you very much for your clarification!
I confess, I didn't read the manual exactly and hoped, that only the portion of the stick which was pointed to by "live-media-path" would be loaded into RAM.

My intention is to start the snapshot on another computer while I'm working on the first computer, because the application may be long lasting (backing up/restoring partitions with "partclone" even over a (wireless) network), but needs no further attention after is has been started. I'm afraid that I cannot remove the media during the running application without getting in trouble.

All parts of the application are already/can be moved to directory "/usr" and its subdirectories. I'm thinking now of "squashing" the directory-tree "/usr" and loading the resulting squashfs into RAM. How can this be achieved and also take a snapshot of the solution?

Any ideas and help are appreciated.
Kind regards
Peter

Re: Problem with "toram" parameter

Mon Oct 06, 2014 6:51 pm

Sorry, but I'm not clear about which computer you want to back up. If you want to back up the hard drive of the other computer, then it makes sense to boot that computer from live media and copy partitions or whole drive while the installed system is not running. If you're trying to back up your main computer while you're using it, that could present some problems. You would be copying the system in its running state, and if you restored that backup, you might not be able to open some programs or even boot the computer.

I also don't understand why you want to put the live system in RAM or why you would want to remove the usb while you're running it.

Re: Problem with "toram" parameter

Tue Oct 07, 2014 3:11 pm

Ok, I think I have to go into detail more. I will call the modified debian partition in whole "the application". A computer is mainly a notebook or a computer consisting of more partitions (Windows, OSX and so on) (and more harddisks) and in my terms one debian partition called "Wartung" (maintenance, I'm German speaking, "the application"), which has to perform the desired tasks.

The application consists of several parts like backup/restore, "gparted" and its own installer. I managed to boot into RAM automatically, if the application is installed already (not using "refracta"). You are right, if I want to backup/restore "the application" too, it has to be booted into RAM, because "partclone" refuses to backup/restore a mounted partition.

Sometimes I stay with friends, who own more than one computer and haven't installed "the application" already, but ask me to do a backup ore restoration. So I've to run the same or different tasks of "the application" simultaneously.

One solution could be, to have more than one identical USB-sticks to do this.

Another solution is to start the desired task(backup/restore) and wait until it's finished and starting over with the next computer then (after a time amount of one or more hours, because Windows-partitions are greater than 100GB often).

The third and of course preferred solution is to boot from one USB-stick into RAM, start the desired long lasting task, plug out the USB-Stick and continue with the next computer immediatly. And that's the point, where booting into RAM is necessary of course.

Kind regards
Peter

Re: Problem with "toram" parameter

Tue Oct 07, 2014 5:28 pm

miraculix, I think it will be helpful if you examine the code within the "refractasnapshot" script and note how it employs rsync.
Afterward, review the rsync manpage and carefully study its many options/switches (copy only changed, delete on destination, etc)

By modifying the refractasnapshot script, with save_work=yes and a convenient (for you) work_dir location...
...you can run a utility script launched from "the application PC" with work_dir pointed to a location on your other PC.
You could use the content of this work_dir (a "mirror" of recent "the application" state) as the source of your on-demand snapshot.

If you perform the rsync often, and "copy only changed", each time it is run it will take only a few seconds to complete
but, to avoid headaches, you really should really suspend/close userspace programs running on "the application PC" prior to performing an rsync operation.
If a web browser is open, for instance, prefs/bookmarks may not written to disk until browser shutdown.

Re: Problem with "toram" parameter

Wed Oct 08, 2014 2:00 pm

Huh. I never thought of removing the live media after booting toram. I just tried it, and it works under certain conditions. I'll get to that in a minute.

If you're going to adapt refractasnapshot to use work_dir as a backup/mirror, pay close attention to the rsync excludes list (/usr/lib/refractasnapshot/snapshot_exclude.list). There may be stuff excluded from the copy that you want to keep for a backup. Some of the things you want to keep might be incompatible with a live system, so the resulting snapshot.iso would be useless, but the copy of the system in $work_dir/myfs would be a more accurate mirror of the system you're backing up.

OK, so toram worked for me when I tried it with a usb stick that has only one live system on it. The first partition on that usb stick is 1.2GB, which is smaller than my 2GB of RAM. When I tried it on a multiboot usb stick that has a 4GB partition, it dropped me to busybox, and in the boot log, it said there was no more space left on the device. During boot, I noticed that it was copying the first system on that partition to ram, even though that was not the system I was trying to boot. Running 'cat /proc/cmdline' showed that it was indeed attempting to boot the system that I had chosen from the boot menu.

So...
The first partition on your usb stick must be smaller than the amount of RAM in the computer on which you are booting it. Maybe you need a dedicated usb stick for that task, or you might put it on a CD.

Re: Problem with "toram" parameter

Wed Oct 08, 2014 4:36 pm

Thank you very much all!

Using a multiboot-usb-stick and "chainload +1" did the trick concerning "toram". But now I'm in trouble with the X-System.

Doing it the way I haved described in my first post ("# Works fully ok") my X-System doesn't get configured by "live-boot".

Now, once I got it running from the chainloaded partition without "live-boot" having configured my X-System, dont remember how. But then not any more.
Is there a way to prevent "live-boot" configuring the X-System or may be everything and how can I do this ?

Thank you in advance again
Peter

Re: Problem with "toram" parameter

Wed Oct 08, 2014 8:55 pm

Hello again!

Strange thing!
My 1st multiboot-usb stick is driven by "grub2". It has the following partitions:
1) Windows7 installer
2) Debian-i386 installer
3) Debian-am64 installer
4) The "boot-menu" (grub on sdb, the general starter)
In its "iso-directory" are 2 subdirectories wartung.I386 and wartung.AMD64. From these directories I've "# It works ok" (please look at my 1st post)

My 2nd multiboot-usb stick is driven by "grub2". It has the following partitions:
1) Utilities (not bootable, Windows-stuff)
2) Wartung (grub on sdb2, i386-variant of "the application"), subdirectory "iso" (now w...I386 under iso)
3) Wartung (grub on sdb3, amd64-variant of "the application"), subdirectory "iso" (now w...AMD64 under iso)
4) The "boot-menu" (grub on sdb, the general starter)

My first attempt on the 2nd stick was to copy the appropriate snapshots simply to the iso-directories. With that configuration I ran into the trouble with the X-System.

In my second attempt on the 2nd stick I created a subdirectory "wartung.I386" on 2nd partition, moved the snapshot and a subdirectory "wartung.AMD64" on the 3rd partition and moved the snapshot to. Additionally I took over the grub-configuration of my 1st stick, 4th partition and changed the configuration on the 2nd stick 2nd and 3rd partitions accordingly.

It looks like, that if I put the snapshot in a subdirectory of a subdirectory under the devices root, live-boot behaves differently. Or maybe the "." in the directory-name, I don't know. I you find out, what's going on here, I would like to hear from you.

But regardless I've achieved what I was looking for. Image

Many thanks for all your help, the discussion with you pointed me in the right direction.
Kind regards
Peter
Post a reply