Ask your questions here.
Post a reply

Re: Load to RAM option at Boot

Fri Jan 27, 2017 10:48 pm

I screwed up the edits. I'll have to try it again later with your version. Eventually, I will work this into refracta2usb.

I had this:
Code:
   # begin copying (or uncompressing)
   mkdir "${copyto}"

You had this (line 81):
Code:
   # begin copying (or uncompressing)
   mkdir -p "${copyto}/${LIVE_MEDIA_PATH}"

Re: Load to RAM option at Boot

Sat Jan 28, 2017 12:15 pm

dzz wrote:miyolinux, it's fine, no can of worms! Some of us actually enjoy hacking this stuff! Keeps me out of the pub. You can help test if you want.


Thanks dzz. To be honest, I'm not much of a code-ologist or code-ographer. :D I'm just a hacker who understands nothing of code, so when I do actually attempt to write even the simplest code, I do it by comparison with other similar codes and trial and error. In other words...when I mess with code, that's usually exactly what I do...mess with it...aka...mess it up. LOL!

I'm still trying to figure out a code/script that fsmithred sent to me just so that I can figure out exactly what it's doing and how it works. I'm afraid that if I start looking at other codes, my brain would probably melt. :lol:

With that said, you guys amaze me. I wish that I did have the knowledge that you guys have.

Re: Load to RAM option at Boot

Sat Jan 28, 2017 1:08 pm

Messing it up is how you figure out what it really does.

Re: Load to RAM option at Boot

Sat Jan 28, 2017 3:36 pm

fsmithred wrote:Messing it up is how you figure out what it really does.


Here's my mind during coding... :D


Image

Re: Load to RAM option at Boot

Sat Jan 28, 2017 4:03 pm

fsmithred wrote:Messing it up is how you figure out what it really does.


Oh the truth in this statement... 8-) :?

Re: Load to RAM option at Boot

Sat Jan 28, 2017 11:46 pm

I t works fine when I do it right. The kernel panics were caused by somehow losing the -print0 on the find command when repacking the initrd. I didn't notice the error message at first: "Cannot stat: File name too long". I looked and couldn't find any long filenames, and then I finally thought about print0.

It also works with the same mods in the version included in patch-initrd. Almost the same mods - I left the first test as -z and kept the 'size=' line in its original place. Was there a reason you re-ordered that section?
Code:
   if [ -z "${MODULETORAM}" ]
   then
      # size the squashfs, not the entire partition
      size=$(fs_size "" ${copyfrom}/${LIVE_MEDIA_PATH}/filesystem.squashfs "used")


Also, if you boot with persistence, it still reads filesystem.squashfs into ram, but the persistent partition gets mounted, so you can't pull out the usb. I didn't try it with loopback or first partition persistence.

Re: Load to RAM option at Boot

Mon Jan 30, 2017 2:01 am

Was there a reason you re-ordered that section?

The original to-disk-to-ram script compares the whole partition to available ram and fails if it doesn't fit . We are only interested in the relevant squashfs (apart from custom hooks, no solution to that yet except maybe including *.sh in the rsync)

Re: Load to RAM option at Boot

Mon Jan 30, 2017 10:07 pm

Couldn't the hooks be treated the same way that .disk is? If it exists, copy it. And while I'm thinking of it, should .disk be copied to ${copyto}/${LIVE_MEDIA_PATH} along with the squashfs?

Also, I got adventurous and tried it with files from the newer live boot (20170112). The toram-todisk mod works, and so does the last patch-initrd you made. I had to use the 4.8-bpo kernel and add nls_ascii to the initramfs, but it works. I also noticed that one mod negates the other - you can have rw media, but since it's only in ram, it doesn't get saved.

Re: Load to RAM option at Boot

Tue Jan 31, 2017 2:51 am

Far as I know .disk is for casper (Ubuntu images) but not used for debian-live.

The rw patch allows a persistence file on the live-media partition. Whether it's still needed toram depends if persistence gets mounted after live-media is copied to ram and umounted, not checked that as yet.

Hooks, probably include *.sh in the rsync line. The power of live-hooks is limited only by your imagination!

More on the latest live-boot when I get time to look, have to take a diff and see if the rw patch needs updating.. http://metadata.ftp-master.debian.org/c ... _changelog .. Says they fixed the FAT problem (nls_ascii missing)

There's probably a case for a bug report here (toram wants to copy an entire partition) but they might not be interested.

Re: Load to RAM option at Boot

Tue Jan 31, 2017 12:50 pm

I used live-boot-2017 for the files in patch-initrd, but I installed live-boot-2016 from backports. That explains why I had to add nls_ascii.

For the hooks, I was thinking something like this. I don't have any hook scripts to test.
Code:
if [ -x /bin/rsync ]
then
   echo " * Copying squashfs to RAM" 1>/dev/console
   mkdir -p "${copyto}/${LIVE_MEDIA_PATH}"
   rsync -a --progress ${copyfrom}/${LIVE_MEDIA_PATH}/*.squashfs ${copyto}/${LIVE_MEDIA_PATH}/ 1>/dev/console
   if [ -d ${copyfrom}/${LIVE_MEDIA_PATH}/hooks
   then
      rsync -a --progress ${copyfrom}/${LIVE_MEDIA_PATH}/hooks ${copyto}/${LIVE_MEDIA_PATH}/ 1>/dev/console
   fi
else
   mkdir -p ${copyto}/${LIVE_MEDIA_PATH}
   cp -a ${copyfrom}/${LIVE_MEDIA_PATH}/* ${copyto}/${LIVE_MEDIA_PATH}
   if [ -d ${copyfrom}/${LIVE_MEDIA_PATH}/hooks
   then
      cp -a ${copyfrom}/${LIVE_MEDIA_PATH}/hooks ${copyto}/${LIVE_MEDIA_PATH}/
   fi
   if [ -e ${copyfrom}/${LIVE_MEDIA_PATH}/.disk ]
   then
      cp -a ${copyfrom}/${LIVE_MEDIA_PATH}/.disk ${copyto}
   fi
fi
Post a reply