Savefolder without 'mount -o bind' - works

[gyro]

I'm happy to merge these patches

I haven't had a complete success with git yet, but I'll have one more try. So, thank you very much for the offer.

666philb reckons it's too close to release for him, so as soon as he does I say merge.

There are documented problems with pcmanfm, spacefm (peebee I believe) and thunar (rg66) with the bind mount method. Not to mention all the other issues.

Understood, and agree.

gyro

[gyro]

The double entries in the sidebar of the file managers do not go away as I would have hoped. Could be something else though I did not really looked any careful.

That's odd; I still use Dpup Exprimo Squeeze, and it has pcmanfm on the desktop. I have ported this implementation of savefolder to it, and the unpatched pcmanfm works as expected.

gyro

[Puppus Dogfellow]

do you happen to know if autosaving can be disabled in savefolder setups?

Theoretically, it should work just as well as savefile, but I'm not aware of anyone having tested it yet.
Good luck.

gyro

cool, that's what i was hoping to hear, and i think i'll try out booting from disc to a savefolder on a different machine as well.

@Puppus_Dogfellow: my latest f2fs-installer (posted somewhere here ) supports hacking the initrd to run in pupmode = 12 so it writes directly to the save - this is what f2fs is all about. Its wear levelling prolongs the life of the drive (theoretically) so frugal writes are not a problem. I'll get back later (tomorrow maybe) about where the latest is posted, or maybe you were a part of that thread?

i'm not sure i've got your latest--last time i was involved in an f2fs thread i was recommending outdated versions. that the thread you remember?

anyway, i've seen with quirky tahr that f2fs works remarkably well with flash, but those writes to that usb 2.0 drive are something i'd rather be in control of in the end. the added speed of the new file system and the greater manageability (how i see it, anyway) of the savefolder would really make the upgrade from 5.5 seem like one. i'm used to the idiotproofing of disabled autosaves and the speed of running purely in ram except for when i'm leaving the room, etc. i want to avoid having an upgrade that feels at any time relatively slow or delicate.


does the devx have to be renamed to be usable with 5.7.2? is there going to be some trickery needed to gain control of the save intervals in a savefile installation?

[gyro]

The double entries in the sidebar of the file managers do not go away as I would have hoped. Could be something else though I did not really looked any careful.

I can't reproduce this.
I've never used LxPup before, but I just did a fresh manual frugal install of LxPupPrecise-14.10.02-retro.iso, and pcmanfm seemed to work fine for me.

gyro

[mavrothal]

The double entries in the sidebar of the file managers do not go away as I would have hoped. Could be something else though I did not really looked any careful.

I can't reproduce this.
I've never used LxPup before, but I just did a fresh manual frugal install of LxPupPrecise-14.10.02-retro.iso, and pcmanfm seemed to work fine for me.

Installing on a different VM I do not see it anymore.
(I still see double entries on removables but not the boot/save volume).

[Puppus Dogfellow]

i uppedprecise 5.7.2, which is 5.7.1 with your patches. curious as to whether or not it works correctly

and...?

works perfectly. i remastered the 5.7.2 into p573-no_abi.iso, which is 5.7.1, your and gyro's updates, and the removal of abiword, osmo, rubix, and xemeraldia. the save to folder function worked correctly (booted off a cd > first shutdown > save to folder option), and it's running very well. firefox 31 esr (not included--runs out of its own folder) is also surprisingly quick.

i gave it the 573 moniker because i had intended to finish the remaster after the reboot (little more pruning plus adding about 30 mb of stuff), but the remaster cd program began to pull in seemingly everything on the partition, so i aborted it and deleted the 15 gig dev folder, or whatever the enormous folder in the remaster cd working directory was called.

anyway, it's working well and i'm very pleased. it seems even faster and less resource hungry than i remember. i haven't as yet tried it out on flash media/tried to see if disabling autosaves works for the save folder (i see no point in trying it on actual spinning hard drives--they're plenty fast for what they're asked to do).

[mavrothal]

i gave it the 573 moniker because i had intended to finish the remaster after the reboot (little more pruning plus adding about 30 mb of stuff), but the remaster cd program began to pull in seemingly everything on the partition, so i aborted it and deleted the 15 gig dev folder, or whatever the enormous folder in the remaster cd working directory was called.

Did this happen (pull in seemingly everything on the partition) while trying to remaster while using a savefolder ?
Did you use the built in remaster script or from some other (which?) pet?

[Puppus Dogfellow]

Did this happen (pull in seemingly everything on the partition) while trying to remaster while using a savefolder ?
Did you use the built in remaster script or from some other (which?) pet?

the pull-in happened after the first shutdown/initial setup. the remastering was done with the built-in script and was successful in making the 573 iso mentioned. after a reboot (save folder now in use), i tried to remaster the remaster and that was when the problem occurred.

[mavrothal]

Did this happen (pull in seemingly everything on the partition) while trying to remaster while using a savefolder ?
Did you use the built in remaster script or from some other (which?) pet?

the pull-in happened after the first shutdown/initial setup. the remastering was done with the built-in script and was successful in making the 573 iso mentioned. after a reboot (save folder now in use), i tried to remaster the remaster and that was when the problem occurred.

remasterpup2 also looks for info in /initrd/pup_rw. So this is probably why is doing this. It shouldn't but you never know...
See if the attached pet fixes the problem (worked OK for me on precise5.7.2 with a savefolder).
It contains the following change

Code: Select all

--- a/usr/sbin/remasterpup2	2013-05-27 17:41:04.000000000 +0300
+++ b/usr/sbin/remasterpup2	2014-10-26 11:24:16.000000000 +0200
@@ -271,11 +271,19 @@
  SCHOICES="`cat /tmp/schoices.txt`"
 
 #add tmpfs ramdisk choice...
-SIZETMPFSM="`df -m | grep '^tmpfs' | grep '/initrd/pup_rw' | tr -s " " | cut -f 4 -d " "`"
+if [ -L /initrd/pup_rw ]; then
+ SIZETMPFSM="`df -m | grep '^tmpfs' | grep ' /initrd/mnt/dev_save$' | tr -s " " | cut -f 4 -d " "`"
+else
+ SIZETMPFSM="`df -m | grep '^tmpfs' | grep '/initrd/pup_rw' | tr -s " " | cut -f 4 -d " "`"
+fi
 TMPFSMSG=''
 
 if [ "$SIZETMPFSM" != "" ];then
- TOTALTMPFSM="`df -m | grep '^tmpfs' | grep '/initrd/pup_rw' | tr -s " " | cut -f 2 -d " "`"
+ if [ -L /initrd/pup_rw ]; then
+  TOTALTMPFSM="`df -m | grep '^tmpfs' | grep ' /initrd/mnt/dev_save$' | tr -s " " | cut -f 2 -d " "`"
+ else
+  TOTALTMPFSM="`df -m | grep '^tmpfs' | grep '/initrd/pup_rw' | tr -s " " | cut -f 2 -d " "`"
+ fi
  if [ "$SCHOICES" = "" ];then #v3.01
   SCHOICES="ramdisk "$m_09: tmpfs  $m_10: ${TOTALTMPFSM}M  $m_11: ${SIZETMPFSM}M ($m_07)" \"
  else

Edit: Please see below before you use this.

[gyro]

remasterpup2 also looks for info in /initrd/pup_rw. So this is probably why is doing this. It shouldn't but you never know...

Sorry if I seem a bit picky, But just looking at the code in your patch, remasterpup2 isn't looking for info in /initrd/pup_rw, it's looking for information about the size of /initrd/pup_rw in the output from df.
So with a savefolder it should not work correctly since there is no entry for /initrd/pup_rw in the output of df, because it is not a mountpoint. So your patch is necessary, even if it doesn't fix Puppus Dogfellow's problem.
If it were just reading the contents of /initrd/pup_rw, there should be no problem.

gyro

[mavrothal]

remasterpup2 also looks for info in /initrd/pup_rw. So this is probably why is doing this. It shouldn't but you never know...

Sorry if I seem a bit picky, But just looking at the code in your patch, remasterpup2 isn't looking for info in /initrd/pup_rw, it's looking for information about the size of /initrd/pup_rw in the output from df.

You are picky. Looking for info is generic in this case does not specify what info or where exactly.
However, I still do not see why it is working since in either case unless pup_rw is in RAM (PUPMODE 5, 7, 13) $SIZETMPFSM and $TOTALTMPFSM should be empty.
Actually thinking of it the patch is wrong because in pupmode 13 you can still have a savefolder but pup_rw is there and is mounted on tempfs.

Latter: I actually used the original remasterpup2 script on precise5.7.2 with savefolder and it works fine producing an identical (to the modified script) ISO.
I do not really know why it did not work for Puppus Dogfellow
Maybe something vital for remasterpup2 was removed in his first remaster.

[gyro]

@mavrothal
Sorry about being picky.

However, I still do not see why it is working since in either case unless pup_rw is in RAM (PUPMODE 5, 7, 13) $SIZETMPFSM and $TOTALTMPFSM should be empty.
Actually thinking of it the patch is wrong because in pupmode 13 you can still have a savefolder but pup_rw is there and is mounted on tempfs.

Yes, in pupmode=13 'initrd/pup_rw' is a mountpoint. 'initrdrd/pup_ro1' is the symbolic link to the savefolder.

gyro

[gyro]

@mavrothal
So 'remasterpup2' does not require patching to support this version of savefolder.
Great.

gyro

[Puppus Dogfellow]

remasterpup2 also looks for info in /initrd/pup_rw. So this is probably why is doing this. It shouldn't but you never know...

Sorry if I seem a bit picky, But just looking at the code in your patch, remasterpup2 isn't looking for info in /initrd/pup_rw, it's looking for information about the size of /initrd/pup_rw in the output from df.

You are picky. Looking for info is generic in this case does not specify what info or where exactly.
However, I still do not see why it is working since in either case unless pup_rw is in RAM (PUPMODE 5, 7, 13) $SIZETMPFSM and $TOTALTMPFSM should be empty.
Actually thinking of it the patch is wrong because in pupmode 13 you can still have a savefolder but pup_rw is there and is mounted on tempfs.

Latter: I actually used the original remasterpup2 script on precise5.7.2 with savefolder and it works fine producing an identical (to the modified script) ISO.
I do not really know why it did not work for Puppus Dogfellow
Maybe something vital for remasterpup2 was removed in his first remaster.

i wonder if it's related to that particular machine or something about the way i have files (symlinks?) on it. an earlier installation of precise 5.6.1. necessitated a huge save file because everything went into it, whether it was downloaded to root, home, or even the partition home was on--i made it 25 gb at one point just to safeguard against the problems such weirdness can cause. by the time i upgraded, free space was whittled down to less than 5 (downloads folder from two other installations are also on that partition). also, i'm not sure sure the remaster of the remaster was actually reading the main sfs file from the hard drive--the original boot cd (precise 572) was still in the bay and the third reboot restored all the things i had deleted, which leaves the matter in doubt. if it read from the cd on reboot two, it was probably/possibly doing so after the first reboot.

thanks for trying to get it sorted out though. at this point, i've added so much stuff to it, that it's not something i would want to make a remaster of. i'd use woofy, but the iso's seem to come out too large and abi doesn't ever really seem to get removed. anyway, thanks again.

[gyro]

Unfortunately the original patch to '/usr/local/pup_event/frontend_funcs' was incomplete. It covered pupmode=6,12.
Here is the patch to cover pupmode=3,7,13.

Code: Select all

--- frontend_funcs.orig	2014-10-28 16:01:55.523845354 +1000
+++ frontend_funcs	2014-10-28 14:47:32.577411196 +1000
@@ -370,7 +370,11 @@
 
 free_flash_func() { #PUPMODE 3,7,13. called every 4 seconds.
  WARNMSG=""
- SIZEFREEM=`df -m | grep ' /initrd/pup_ro1$' | tr -s ' ' | cut -f 4 -d ' '`
+ if [ -L /initrd/pup_ro1 ]; then
+  SIZEFREEM=`df -m | grep ' /initrd/mnt/dev_save$' | tr -s ' ' | cut -f 4 -d ' '`
+ else
+  SIZEFREEM=`df -m | grep ' /initrd/pup_ro1$' | tr -s ' ' | cut -f 4 -d ' '`
+ fi
  SIZETMPM=`df -m | grep ' /initrd/pup_rw$' | tr -s ' ' | cut -f 4 -d ' '`
  [ -s /tmp/pup_event_sizefreem ] && PREVSIZEFREEM=`cat /tmp/pup_event_sizefreem`
  [ -s /tmp/pup_event_sizetmpm ] && PREVSIZETMPM=`cat /tmp/pup_event_sizetmpm`

This is in addition to the original patch, so is a patch to an already patched file.

I've no idea how significant these functions in 'frontend_funcs' are, or even if they are still used. But this patch is for completeness.

gyro

[mavrothal]

pull request ?

[gyro]

pull request ?

Yes
gyro

[rg66]

This is probably not the right place to post this but it's the only thread I could find on save folders.

I was getting dir2sfs errors saying not enough space in /tmp where I was building. I looked at /tmp properties and it's max 854.3 MB. Is /tmp in RAM, and if I'm using a save folder couldn't it use the save partition instead? I'm assuming this is all in the init script but wouldn't know where to start.

[mavrothal]

I was getting dir2sfs errors saying not enough space in /tmp where I was building. I looked at /tmp properties and it's max 854.3 MB. Is /tmp in RAM, and if I'm using a save folder couldn't it use the save partition instead?

Not sure what is the question.
Do you want to mount /tmp outside RAM (say /mnt/home/tmp) or to somehow increase tmpsf size while in RAM?

[rg66]

I was getting dir2sfs errors saying not enough space in /tmp where I was building. I looked at /tmp properties and it's max 854.3 MB. Is /tmp in RAM, and if I'm using a save folder couldn't it use the save partition instead?

Not sure what is the question.
Do you want to mount /tmp outside RAM (say /mnt/home/tmp) or to somehow increase tmpsf size while in RAM?

Yes, I want /tmp to be a symlink to /mnt/home/tmp so it can use the full partition free space. If my save dir is outside RAM, not sure of the point of using RAM for /tmp other than speed maybe.