Page 5 of 7
Posted: Sat 25 Oct 2014, 14:56
by Puppus Dogfellow
mavrothal wrote:Puppus Dogfellow wrote:i upped
precise 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).
Posted: Sat 25 Oct 2014, 18:06
by mavrothal
Puppus Dogfellow wrote:
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?
Posted: Sat 25 Oct 2014, 20:59
by Puppus Dogfellow
mavrothal wrote:
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.
Posted: Sun 26 Oct 2014, 06:34
by mavrothal
Puppus Dogfellow wrote:mavrothal wrote:
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.
Posted: Sun 26 Oct 2014, 11:19
by gyro
mavrothal wrote: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
Posted: Sun 26 Oct 2014, 12:18
by mavrothal
gyro wrote:mavrothal wrote: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.
Posted: Sun 26 Oct 2014, 22:04
by gyro
@mavrothal
Sorry about being picky.
mavrothal wrote: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
Posted: Mon 27 Oct 2014, 01:03
by gyro
@mavrothal
So 'remasterpup2' does not require patching to support this version of savefolder.
Great.
gyro
Posted: Mon 27 Oct 2014, 01:55
by Puppus Dogfellow
mavrothal wrote:gyro wrote:mavrothal wrote: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.
frontend_funcs revisited, original patch incomplete
Posted: Tue 28 Oct 2014, 06:44
by 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
Posted: Tue 28 Oct 2014, 08:26
by mavrothal
pull request ?
![Wink :wink:](./images/smilies/icon_wink.gif)
Posted: Tue 28 Oct 2014, 09:45
by gyro
mavrothal wrote:pull request ?
![Wink :wink:](./images/smilies/icon_wink.gif)
Yes
gyro
Posted: Thu 30 Oct 2014, 21:33
by 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.
Posted: Fri 31 Oct 2014, 05:27
by mavrothal
rg66 wrote:
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?
Posted: Fri 31 Oct 2014, 06:48
by rg66
mavrothal wrote:rg66 wrote:
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.
Posted: Fri 31 Oct 2014, 08:35
by mavrothal
rg66 wrote:
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.
/tmp is tmpfs filesystem which is temporary and is not preserved through reboots.
If you want to mount /tmp in another place and still be "tmp"
checkout this
However, may be simpler to change your build script to build in a folder in your HD.
Posted: Fri 31 Oct 2014, 10:10
by rg66
mavrothal wrote:rg66 wrote:
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.
/tmp is tmpfs filesystem which is temporary and is not preserved through reboots.
If you want to mount /tmp in another place and still be "tmp"
checkout this
However, may be simpler to change your build script to build in a folder in your HD.
I don't need it to be preserved, just use the save partition free space. I think I've sorted it, although /tmp doesn't show as a symlink. /tmp has the same free space as the save partition and is synced to /pathtosavedir/tmp. Making a savefile goes back to tmpfs. The RAM usage is also a little less.
Original init (patched by gyro)
Code: Select all
#df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 74G 17G 54G 24% /initrd/mnt/dev_save
tmpfs 137M 136M 1000K 100% /initrd/mnt/tmpfs
/dev/loop0 136M 136M 0 100% /initrd/pup_ro2
tmpfs 27M 26M 1000K 97% /initrd/mnt/tmpfs4
/dev/loop4 26M 26M 0 100% /initrd/pup_z
tmpfs 1.1M 56K 1000K 6% /initrd/mnt/tmpfs3
/dev/loop3 128K 128K 0 100% /initrd/pup_y
/dev/loop5 30M 30M 0 100% /initrd/pup_ro5
/dev/loop6 132M 132M 0 100% /initrd/pup_ro6
unionfs 74G 17G 54G 24% /
tmpfs 815M 248K 815M 1% /tmp <------------
devtmpfs 1.6G 0 1.6G 0% /dev
shmfs 726M 0 726M 0% /dev/shm
Code: Select all
# free
total used free shared buffers
Mem: 3337224 560364 2776860 0 34896
-/+ buffers: 525468 2811756
Swap: 0 0 0
Modded init
Code: Select all
#df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 74G 17G 54G 24% /initrd/mnt/dev_save
tmpfs 137M 136M 1000K 100% /initrd/mnt/tmpfs
/dev/loop0 136M 136M 0 100% /initrd/pup_ro2
tmpfs 27M 26M 1000K 97% /initrd/mnt/tmpfs4
/dev/loop4 26M 26M 0 100% /initrd/pup_z
tmpfs 1.1M 56K 1000K 6% /initrd/mnt/tmpfs3
/dev/loop3 128K 128K 0 100% /initrd/pup_y
/dev/loop5 30M 30M 0 100% /initrd/pup_ro5
/dev/loop6 132M 132M 0 100% /initrd/pup_ro6
unionfs 74G 17G 54G 24% /
devtmpfs 1.6G 0 1.6G 0% /dev
shmfs 726M 0 726M 0% /dev/shm
Code: Select all
# free
total used free shared buffers
Mem: 3337224 558476 2778748 0 34664
-/+ buffers: 523812 2813412
Swap: 0 0 0
Modded init with savefile
Code: Select all
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 74G 17G 54G 24% /initrd/mnt/dev_save
/dev/loop1 248M 17M 231M 7% /initrd/pup_rw
tmpfs 137M 136M 1000K 100% /initrd/mnt/tmpfs
/dev/loop0 136M 136M 0 100% /initrd/pup_ro2
tmpfs 27M 26M 1000K 97% /initrd/mnt/tmpfs4
/dev/loop4 26M 26M 0 100% /initrd/pup_z
tmpfs 1.1M 56K 1000K 6% /initrd/mnt/tmpfs3
/dev/loop3 128K 128K 0 100% /initrd/pup_y
unionfs 248M 17M 231M 7% /
tmpfs 815M 1.1M 814M 1% /tmp <--------------
devtmpfs 1.6G 0 1.6G 0% /dev
shmfs 727M 0 727M 0% /dev/shm
Posted: Sat 01 Nov 2014, 13:27
by mikeb
Late reply but a tmpfs /tmp is a little mute when using a save partition...just need to remove the bit of code that creates in in rc.sysinit. Not sure if there is still /tmp clearout code in the rc.shutdown... it may need the save folder mode adding to keep it tidy.
Ram usage would vary according to tmpfs//tmp use as its dynamic.
mike
Posted: Sun 02 Nov 2014, 07:10
by rg66
It's not working as well as I'd hoped. It seems to still be using RAM as well as the directory. I'm now looking at rc.sysinit as something is still mounting tmpfs for /tmp. I can successfully boot into RAM, make /tmp symlink to my chosen dir but it disappears on making a save.
Posted: Sun 02 Nov 2014, 09:41
by mikeb
At this point I would do a text search for tmpfs.... will sniff it out...I don't use any recent pups so not 100% where to look though it has to happen early in the boot.
Search with something like searchmonkey unless you want to wait all day
mike