Puppy Linux Discussion Forum Forum Index Puppy Linux Discussion Forum
Puppy HOME page : puppylinux.com
"THE" alternative forum : puppylinux.info
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

The time now is Wed 26 Nov 2014, 06:23
All times are UTC - 4
 Forum index » Advanced Topics » Puppy Projects
slacko-6.0 beta 2
Moderators: Flash, JohnMurga
Post_new_topic   Reply_to_topic View_previous_topic :: View_next_topic
Page 25 of 49 Posts_count   Goto page: Previous 1, 2, 3, ..., 23, 24, 25, 26, 27, ..., 47, 48, 49 Next
Author Message
gyro

Joined: 28 Oct 2008
Posts: 522
Location: Brisbane, Australia

PostPosted: Thu 03 Jul 2014, 14:29    Post_subject:  

SFR wrote:
Hmm, problem with disappearing whiteout files again?
Yes, I tracked it down to /usr/sbin/sfs_load removing whiteout files. My proof of concept was much simpler, I simply commented out the line in /usr/sbin/sfs_load that calls "cleanwhite".

This is bit of a problem, because if you add an extra sfs, all whiteout files are removed every time, sfs_load loads the sfs, which is every boot.
If you delete a file that requires a whiteout file, then re-boot, the file comes back again. Not good.
When extra sfs's were loaded in init, at least the "cleanup" only mucked things up when the extra list was changed, not every boot.

It also confuses "Boot Manager"->"Startup apps", because you end up with both a ".desktop.bak" file and the old ".desktop" file in /root/.config/autostart.

I'm intend to stick with no whiteout file cleaning, for a while.

I wonder if we would be better off if sfs_load did not do any whiteout file cleaning, and we had a utility that would remove any whiteout files that correspond to files in the specified sfs?

Or, sfs_load becomes even more sophisticated:
1) Only does a whiteout file cleanup when the list of sfs's changes, or ideally only the first time an sfs is loaded.
2) Only removes whiteout files that correspond to files that exist in the sfs being loaded.

Puppy should not make it impossible to "delete" a file that exists in an sfs.

gyro
Back to top
View user's profile Send_private_message 
SFR


Joined: 26 Oct 2011
Posts: 1101

PostPosted: Thu 03 Jul 2014, 15:53    Post_subject:  

@Gyro: Yeah, I wish sfs_load did nothing to other layers than pup_rw.
The idea to backup and restore .wh files is perhaps a bit unusual, but plain and simple, no need to manually process all the whiteouts and remove them thereafter.
But like I said elsewhere, I don't know sfs_load enough; the most qualified person in this matter is Shinobar himself. Cool

Billtoo wrote:
After just over 1 hour the warning screen popped up.

Did it happen when FIrefox was up and running, like it was the previous time?
Have you been actively browsing at the same time when saving took place?
And finally, I assume it was again just a false alarm?

Hmm, could you please try the attached, modified version of snapmergepuppy (copy it to /usr/sbin/ and save the session)?
The idea behind the modification is that if copying a file failed, it tries once more and only then reports an error.

Not sure if this will work, because I have suspicions that only re-evaluating of all the layers (what takes place after copying) fixes anomalies responsible for those false errors and makes that the next save is error-free.
On the other hand it might be just a matter of bad timing (an app is doing something with a file that is being processed by snapmerge at the same moment), so it's worth a try, I believe.

You're quite "lucky", btw. Wink It happens to me no more than 1-2 times a month...and I'm saving a lot!

Does anyone else have this problem too?

Greetings!
snapmergepuppy_billtoo.tar.gz
Description  Unpack and copy to /usr/sbin
gz

 Download 
Filename  snapmergepuppy_billtoo.tar.gz 
Filesize  4.24 KB 
Downloaded  22 Time(s) 

_________________
[O]bdurate [R]ules [D]estroy [E]nthusiastic [R]ebels => [C]reative [H]umans [A]lways [O]pen [S]ource
Omnia mea mecum porto.
Back to top
View user's profile Send_private_message 
Billtoo


Joined: 07 Apr 2009
Posts: 2156
Location: Ontario Canada

PostPosted: Thu 03 Jul 2014, 16:04    Post_subject:  

SFR wrote:


Billtoo wrote:
After just over 1 hour the warning screen popped up.

Did it happen when FIrefox was up and running, like it was the previous time?
Have you been actively browsing at the same time when saving took place?
And finally, I assume it was again just a false alarm?

Hmm, could you please try the attached, modified version of snapmergepuppy (copy it to /usr/sbin/ and save the session)?
The idea behind the modification is that if copying a file failed, it tries once more and only then reports an error.

Greetings!


I forget whether or not firefox was active, I usually have it going but I think I was playing a game and listening to music.

I didn't check the error file at the time, I shut down for an hour or so and just booted up a few minutes ago, the /tmp/snapmergepuppy-error file is empty now.

I'll try your modified version and report back if the popup continues.

Thanks.
Back to top
View user's profile Send_private_message 
shinobar


Joined: 28 May 2009
Posts: 2631
Location: Japan

PostPosted: Thu 03 Jul 2014, 16:10    Post_subject: whiteout  

sfs_load lone 52-57 has some options, it'll be useful for testing:
Code:
#some options the puplet builder can choose
WIPEWHITEONLOAD="true"   # true/false
WIPEWHITEUNLOAD="true"   # recommend 'true'
WIPEMASKONLOAD="false" # recommend 'false'
DISSOSIATE="true"   # excute'losetup -d', some 3.2.x kernel may hung up
WIDESEARCH="false"   #v2.0: search sfs other than /mnt/home and /mnt/home/PSUBDIR


But WIPEWHITEONLOAD/WIPEWHITEUNLOAD works only when the extra sfs is load/unload by sfs_load. I forgot to implement dealing with the whiteout when extra sfs are handled by the bootmanager.

Removing the extra sfs function from the bootmanager is one option we can take.

But an issue remained with zdrv/adrv/ydrv. Both sfs_load and bootmanager cannot handle zdrv/adrv/ydrv. Only the way is to add/remove using a filer by hand with RAM mode... Sad

_________________
Google Chrome portable
Downloads for Puppy Linux http://shino.pos.to/linux/downloads.html
Back to top
View user's profile Send_private_message Visit_website 
shinobar


Joined: 28 May 2009
Posts: 2631
Location: Japan

PostPosted: Thu 03 Jul 2014, 16:56    Post_subject: whiteout patch  

Add one line against sfs_load-2.0.11:
Code:
--- sfs_load-11   2014-07-03 04:23:32.826584625 +0900
+++ sfs_load   2014-07-04 05:53:02.526655485 +0900
@@ -2063,6 +2063,7 @@
   #v1.9.2: skip fixmenus, hope done before
   #v2.0: see the LASTUNIONRECORD backup
   if [ "$LASTUNIONRECORD" != "$PREVUNIONRECORD" ]; then
+   [ "$WIPEWHITEONLOAD"  = "true" -o "$WIPEWHITEUNLOAD"  = "true" ] && cleanwhite && touch $MYTMPDIR/CLEANWHITE
    [ "$NEED_FIXMENUS" ] || SKIP_FIXMENUS="y"
    if [ "SKIP_HAS_FIXMENUS" ]; then
      #not checked, force all on

_________________
Google Chrome portable
Downloads for Puppy Linux http://shino.pos.to/linux/downloads.html
Back to top
View user's profile Send_private_message Visit_website 
gyro

Joined: 28 Oct 2008
Posts: 522
Location: Brisbane, Australia

PostPosted: Thu 03 Jul 2014, 17:39    Post_subject: Re: whiteout  

shinobar wrote:
sfs_load lone 52-57 has some options, it'll be useful for testing:
Thanks for this information.
I've currently set:
Code:
WIPEWHITEONLOAD="false"   # true/false
WIPEWHITEUNLOAD="false"   # recommend 'true'
and since no whiteout file processing is being done by sfs_load, all is well with /root/.config/autostart.
I also have not encountered any problems caused by unwanted whiteout files.
gyro
Back to top
View user's profile Send_private_message 
SFR


Joined: 26 Oct 2011
Posts: 1101

PostPosted: Thu 03 Jul 2014, 18:15    Post_subject:  

shinobar wrote:
Code:
WIPEWHITEONLOAD="true"   # true/false
WIPEWHITEUNLOAD="true"   # recommend 'true'

Thanks! Setting the above to 'false' seems to fix also my old problem in PUPMODE=13 & SAVEINTERVAL=0, without the need of 'tar' workaround.
So, why it is recommended to have them set to 'true'? What are possible drawbacks of 'false' state?

Greetings!

_________________
[O]bdurate [R]ules [D]estroy [E]nthusiastic [R]ebels => [C]reative [H]umans [A]lways [O]pen [S]ource
Omnia mea mecum porto.
Back to top
View user's profile Send_private_message 
gyro

Joined: 28 Oct 2008
Posts: 522
Location: Brisbane, Australia

PostPosted: Thu 03 Jul 2014, 18:19    Post_subject: Re: whiteout patch  

shinobar wrote:
Add one line against sfs_load-2.0.11:
I edited sfs_load with your patch, set the whiteout options back to "true".
Loaded the devx sfs using sfs_load.
Rebooted and the whiteout files in /root/.config/autostart had been removed. (expected)
I fixed the files in /root/.config/autostart.
Rebooted and the whiteout files in /root/.config/autostart had been removed. (not expected)
I unloaded the devx sfs using sfs_load.
I fixed the files in /root/.config/autostart.
Rebooted and the whiteout files in /root/.config/autostart had been removed. (expected)

So it seems that the patch makes no difference to the problem, whereas setting the whiteout options to "false" does.

gyro
Back to top
View user's profile Send_private_message 
shinobar


Joined: 28 May 2009
Posts: 2631
Location: Japan

PostPosted: Thu 03 Jul 2014, 19:31    Post_subject: wh  

How. About ONLOAD false/UNLOAD true?
Back to top
View user's profile Send_private_message Visit_website 
gyro

Joined: 28 Oct 2008
Posts: 522
Location: Brisbane, Australia

PostPosted: Thu 03 Jul 2014, 23:41    Post_subject: Re: wh  

shinobar wrote:
How. About ONLOAD false/UNLOAD true?
That's probably a reasonable compromise with the current sfs_load.
Edit: Did that, works as expected, but it's a compromise, I now have whiteout cleanup, but I still get annoyed on the next boot after interactively unloading an sfs, because it removes ALL whiteout files.

So, I'm suggesting 3 changes to sfs_load:
1) On load, only remove whiteout files that correspond to files that exist in the sfs being loaded.
2) Don't ever run cleanwhite if called during startup or shutdown.
3) On unload, only remove whiteout files corresponding to files in the sfs being removed.

I want any whiteout files that correspond to files that exist in an sfs to be removed the first time I load it, so that all it's files get exposed by aufs, none get hidden by some ancient whiteout file. But I then want to be able to "delete" files in this sfs and not have them restored at the next boot.

Then change BootManager to use sfs_load to handle all extra sfs processing.

Note: I will attempt to create some bash code that removes whiteout files that correspond to files in a specified sfs. And report back.

gyro
Back to top
View user's profile Send_private_message 
01micko


Joined: 11 Oct 2008
Posts: 7841
Location: qld

PostPosted: Fri 04 Jul 2014, 00:57    Post_subject:  

I've made a few changes to PUI.

I think I will go with shinobar's dotpup and also include the frugal-installer - both patched for new woof icons. Only a few lines. PUI is covered by shinobar's dotpup.

PUI itself:

Changes (a brief list, see the diff attached)
  • deleted the ispupfunc() - didn't work
  • added the hunks of shinobar's patch for ext4 extlinux bug
  • added a new function linux_func() which attempts to identify puppy installs, linux installs and windows.
  • added a test for other linux versions loosely based on shinobar's patch (actually that is used as a fallback) based on the existence of /etc/os-release, tested working with fedora and slackware. Will work with recent ubuntu/debian also.
  • changed many gui to gtkdialog and cleaned up the appearance of some of the existing gtkdialog.
  • fixed numerous bugs mostly dated with a recent date so searching for '#140' (yymmdd) should reveal them.
  • bold big warning before you commit to install (full installs)
  • completed the partial removal of ZIP/LS120 disk support for installation. This has been crippled for over 3 years anyway.
  • all icons calls are to new woof icons
  • disabled installing to windows partitions from PUI. Support for installing to windows partitions by other methods are unaffected by this change
  • hard coded version to 0.0 so rc.update runs in full installs. It did anyway but since the test was broken there were 'integer expected' errors
  • partial code cleanup so in most cases you don't need a nine foot wide monitor.
  • made full installs (all sfs) a loop through the various sfs files which may exist.
  • added 64 bit support, tested working.


I limited my wording changes to probably 10 words (in GUI) so hopefully translations are not too broken. This is why I didn't do a full rewrite. Possibly deletions will have a bad effect on translations. IDK. I'll release the code for testing soon but in the meantime, those interested go over the diff (it should apply cleanly to most recent woof versions of PUI) and pick it apart. There is always room for improvement. Smile
Screenshot(1).jpg
 Description   
 Filesize   86.67 KB
 Viewed   350 Time(s)

Screenshot(1).jpg

puppyinstaller-wce-140704.diff.gz
Description 
gz

 Download 
Filename  puppyinstaller-wce-140704.diff.gz 
Filesize  17.49 KB 
Downloaded  28 Time(s) 

_________________
Woof Mailing List | keep the faith Cool |
Back to top
View user's profile Send_private_message Visit_website 
gyro

Joined: 28 Oct 2008
Posts: 522
Location: Brisbane, Australia

PostPosted: Fri 04 Jul 2014, 04:00    Post_subject:  

I've done a crude edit to /usr/sbin/sfs_load so it only removes whiteout files that correspond to files in the sfs file being loaded, and it dosen't run 'cleanwhite' when called during startup.
And it works, well at least in my very limited test.
In the function 'append_sfs', I replaced
Code:
[ "$WIPEWHITEONLOAD"  = "true" ] && [ ! -f $MYTMPDIR/CLEANWHITE ] && cleanwhite && touch $MYTMPDIR/CLEANWHITE
with
Code:
[ "$WIPEWHITEONLOAD"  = "true" ] && [ "$STARTSCRIPT" = "" ] && [ ! -f $MYTMPDIR/CLEANWHITE ] && cleanwhite $MNTPNT && touch $MYTMPDIR/CLEANWHITE

In the function 'make_cleanup_script', I replaced
Code:
S=$(ls /initrd/pup_ro{?,??}/"$D/$B" /initrd/pup_[az]/"$D/$B" 2>/dev/null| grep -vw "^$PREM"| head -n 1)
[ "$S" ] || rm -f "$BASE$W"
with
Code:
S=$(ls "$PREM/$D/$B"  2>/dev/null)
[ "$S" ] && rm -f "$BASE$W"

I certainly do not suggest that this is an appropriate patch for sfs_load, but just a proof of concept.

Very limited test in pupmode=12:
1) Used interactive sfs_load to load the devx sfs.
2) In ROX-filer I deleted /usr/dietlibc/, a directory that exists only in the devx sfs.
3) After reboot, /usr/dietlibc/ is still deleted, whiteout file /usr/.wh.dietlibc was not removed from pup_rw.
4) Used interactive sfs_load to unload the devx sfs.
5) The file /usr/.wh.dietlibc is now removed from pup_rw.
The whiteout files in /root/.config/autostart remained in tact throughout the whole test.

Note: In pupmode=13 probably need to remove whiteout files from pup_ro1 as well.

gyro
Back to top
View user's profile Send_private_message 
SFR


Joined: 26 Oct 2011
Posts: 1101

PostPosted: Fri 04 Jul 2014, 05:43    Post_subject:  

01micko wrote:
I've made a few changes to PUI.

Looks pretty nice. Smile

But I can't get the same results as on your screenshot - I have Win7_x64 + Slacko-5.7.0 (Noryb's installer) on sda2.
I'm getting "Unknown Linux" instead.
The log:
Code:
# ./puppyinstaller
/mnt/sda1
no pups found
no distro
no distro
OLINUX=
no distro
no distro
/mnt/sda1
is windows?
/initrd/mnt/dev_save
found 1 pups
name is /initrd/mnt/dev_save/Puppy_Slacko_5.7.0/puppy_slacko_5.7.0.sfs
continuing search
no distro
no distro
no distro
OLINUX=
no distro
distro is Unknown Linux
/mnt/sda3
no pups found
no distro
no distro
OLINUX=
no distro
no distro
/mnt/sda3
is windows?
./puppyinstaller: line 742:  9656 Killed                  gtkdialog-splash -bg yellow -close box -text "$SPLSHMSG"
#

So, I set DISTRO variable (linux_func) to null right after checking for vmlinuz and indeed I got the expected "sda2: ntfs, size 111.5 GiB, Windows 64 bit and Puppy Slacko 5.7.0 installed".

Btw, I tried to apply the patch against the puppyinstaller from woof, but there were 9 rejects, so I did it against the one from Slacko-5.7 and ended up with only 2 (applied them manually).

Greetings!

_________________
[O]bdurate [R]ules [D]estroy [E]nthusiastic [R]ebels => [C]reative [H]umans [A]lways [O]pen [S]ource
Omnia mea mecum porto.
Back to top
View user's profile Send_private_message 
Jades

Joined: 07 Aug 2010
Posts: 451
Location: Somewhere in Blighty.

PostPosted: Fri 04 Jul 2014, 06:21    Post_subject:  

01micko wrote:
[*]disabled installing to windows partitions from PUI. Support for installing to windows partitions by other methods are unaffected by this change.


To clarify, does this mean that PUI is no longer able to automatically create a new Frugal on any NTFS partition or just one where it finds an actual Windows install? Would I be correct in assuming that "other methods" includes creating a directory and manually copying the various bits and bobs from the CD to it?

_________________
Zhaan - AMD K6 2 500, 512MB RAM, ATI Rage 128 VR. Full install Wary 5.5 HardInfo Report
Merlin - Core i5-4590, 8GB RAM, Radeon R9 270X. Slacko 5.7.0
Back to top
View user's profile Send_private_message Visit_website 
01micko


Joined: 11 Oct 2008
Posts: 7841
Location: qld

PostPosted: Fri 04 Jul 2014, 08:12    Post_subject:  

Jades wrote:
01micko wrote:
[*]disabled installing to windows partitions from PUI. Support for installing to windows partitions by other methods are unaffected by this change.


To clarify, does this mean that PUI is no longer able to automatically create a new Frugal on any NTFS partition or just one where it finds an actual Windows install? Would I be correct in assuming that "other methods" includes creating a directory and manually copying the various bits and bobs from the CD to it?


Any from PUI.

You can do it manually, or with NoryB's installer but 'officially' from PUI I say it is unsupported. Still doesn't stop save from CD. That's fine.

I am dead against installing to NTFS on a hard drive. I know nooby would not have been too happy, but there is a reason. You can completely screw up a hibernated windows install. Windows 8+ hibernates by default at "shutdown" (which really is not shut down) and thus windows can be rendered unbootable and warranty voided. It must be discouraged to install to NTFS in my opinion.

That said, it is still doable. I should add a bold warning somewhere about windows 8.

I may reconsider allowing installation (from PUI) to an NTFS partition that does not contain windows OS.. but is there any point in that? Most noobs are going to have 1 NTFS partiton (plus all the hidden garbage for EFI if on a new computer).

----

SFR wrote:
But I can't get the same results as on your screenshot - I have Win7_x64 + Slacko-5.7.0 (Noryb's installer) on sda2.
I'm getting "Unknown Linux" instead.


My bad for using a 'dummy' install. Anyway, I added a search for a frugal in that block in case this happens.
Code:
if [ ! "$DISTRO" ];then
     KERNELS=$(find -L "$ISPUPMNTPT" -maxdepth 2 -type f -iname 'vmlinuz*' 2>/dev/null) #shinobar, but reduced depth to 2
     [ "$KERNELS" ] && DISTRO="Unknown Linux"
     # could be a frugal pup though
     FRUGPUP=`find "$ISPUPMNTPT" -type f -name '*up*[0-9]*.sfs' -maxdepth 2 2>/dev/null`
     [ "$FRUGPUP" ] && DISTRO=''
     #echo 5 ##debug
     [ "$DISTRO" ] && echo "distro is $DISTRO" || echo "no distro"
   fi


I'll attach the whole script, also with mods to the windows search, tested with XP, Fista, 7 and server 2008R2 installed (bare metal). I'm not too worried if the versions are reported wrong (they are only a generic guess anyway) but there existence must be confirmed.

EDIT: updated windows test in script
puppyinstaller.gz
Description 
gz

 Download 
Filename  puppyinstaller.gz 
Filesize  25.69 KB 
Downloaded  22 Time(s) 

_________________
Woof Mailing List | keep the faith Cool |

Edited_time_total
Back to top
View user's profile Send_private_message Visit_website 
Display_posts:   Sort by:   
Page 25 of 49 Posts_count   Goto page: Previous 1, 2, 3, ..., 23, 24, 25, 26, 27, ..., 47, 48, 49 Next
Post_new_topic   Reply_to_topic View_previous_topic :: View_next_topic
 Forum index » Advanced Topics » Puppy Projects
Jump to:  

Rules_post_cannot
Rules_reply_cannot
Rules_edit_cannot
Rules_delete_cannot
Rules_vote_cannot
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001, 2005 phpBB Group
[ Time: 0.1397s ][ Queries: 12 (0.0104s) ][ GZIP on ]