Bug- pinstall.sh runs in frugal but not full install [Fixed]
Hi Perdido.
Going back to your screen cap on page 1, and please correct me if I'm
wrong, I notice that you are trying to create an sfs archive from a pinstall.sh
script in a fully installed Puppy.
Yoo-hoo!!!
Conceptually, that's an extreme sport of sorts for a Puppy distro !!!
Let me explain:
One thing is certain: using sfs's in a full install is iffy. -- If you have a full
install, you go all the way, you install the apps whether through a pet or a
deb or rpm archive and that is it. You try not to use sfs's.
Here's why:
sfs's are meant to be used in frugal installs. IIRC, fully installed Pups do NOT
have the "au" layer-unifying whachamacallit utility, whereas frugally
installed Pups depend on it, it's vital for frugal installs.
Sorry for the "mouse" imagery , but the "au" layer-unifying
whachamacallit utility manages the "gruyere cheese holes" the sfs's fit into.
In a full install, there are no "gruyere cheese holes to fit sfs's into" and no
layers; all programs and libs, etc., are on the same level. So the "au" layer-
unifying whachamacallit utility either is not there or has no" gruyere cheese
layers" to manage.
Look at the PUPSTATE # for a full install and look at BarryK's diagram for it,
it's pretty clear, I think.
~~~~~
2nd point, IMO -- and as I said, I have never done a full install of Puppy.
You may be asking too much of the Puppy system: install a BBIIGG pet
archive AND then immediately afterwards start a squashfs compression?
If you run htop or a similar diagnostics app, and then start the mksquashfs
compression app, you'll see that mksquashfs grabs almost all the computer's
resources for the job it's doing.
I'm not sure if you and rockedge are talking about the same pet file, but if
that pet file is 252 Mg, as rockedge mentions, I would suggest you do one
operation and give the Pup a "bone break" (You can have coffee or tea or
a pop or a beer!) And then, when the Pup is rested, ask it to do the
squashing operation.
But again, AFAIK, sfs's do not play well in full installs. So in the context of
a full install, maybe creating an sfs is not the way to go. Why not provide
another pet, simply?
My 2 ¢, but IHTH.
Going back to your screen cap on page 1, and please correct me if I'm
wrong, I notice that you are trying to create an sfs archive from a pinstall.sh
script in a fully installed Puppy.
Yoo-hoo!!!
Conceptually, that's an extreme sport of sorts for a Puppy distro !!!
Let me explain:
One thing is certain: using sfs's in a full install is iffy. -- If you have a full
install, you go all the way, you install the apps whether through a pet or a
deb or rpm archive and that is it. You try not to use sfs's.
Here's why:
sfs's are meant to be used in frugal installs. IIRC, fully installed Pups do NOT
have the "au" layer-unifying whachamacallit utility, whereas frugally
installed Pups depend on it, it's vital for frugal installs.
Sorry for the "mouse" imagery , but the "au" layer-unifying
whachamacallit utility manages the "gruyere cheese holes" the sfs's fit into.
In a full install, there are no "gruyere cheese holes to fit sfs's into" and no
layers; all programs and libs, etc., are on the same level. So the "au" layer-
unifying whachamacallit utility either is not there or has no" gruyere cheese
layers" to manage.
Look at the PUPSTATE # for a full install and look at BarryK's diagram for it,
it's pretty clear, I think.
~~~~~
2nd point, IMO -- and as I said, I have never done a full install of Puppy.
You may be asking too much of the Puppy system: install a BBIIGG pet
archive AND then immediately afterwards start a squashfs compression?
If you run htop or a similar diagnostics app, and then start the mksquashfs
compression app, you'll see that mksquashfs grabs almost all the computer's
resources for the job it's doing.
I'm not sure if you and rockedge are talking about the same pet file, but if
that pet file is 252 Mg, as rockedge mentions, I would suggest you do one
operation and give the Pup a "bone break" (You can have coffee or tea or
a pop or a beer!) And then, when the Pup is rested, ask it to do the
squashing operation.
But again, AFAIK, sfs's do not play well in full installs. So in the context of
a full install, maybe creating an sfs is not the way to go. Why not provide
another pet, simply?
My 2 ¢, but IHTH.
musher0
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)
- perdido
- Posts: 1528
- Joined: Mon 09 Dec 2013, 16:29
- Location: ¿Altair IV , Just north of Eeyore Junction.?
They are exact copies of the desktop files they are replacing except theybigpup wrote: I wonder if trying to replace core Puppy program .desktop files could be the problem.
icon_switcher.desktop
Desktop-drive-icons.desktop
Both of these are used by several other Puppy programs.
Why are you replacing them?
have NoDisplay-True so they don't get put in the menu.
-------------
They are programs in puppy that are called by the new "Puppy Desktop" GUI that radky has been working on, this is in bionic.These two are not in example: Puppy Xenialpup 7.5
ptheme.desktop
pdesktop.desktop
Are you adding them with the pet install?
I disable the new "Puppy Desktop" from the menu using NoDisplay=True, then add the desktop files to put those two programs
in the jwm mwnu where they used to reside in earlier pups.
--------------
Yes, that works in a script file. It also works in the pinstall.sh that runs ok in a frugal install. That is not the proper format for a pinstall.sh, however.This is what works to change the name:
mv /usr/share/applications/icon_switcher.desktop /usr/share/applications/icon_switcher.desktop.bak
---------------
That dot before the path is explicit in the instructions for pinstall.sh, for reference see this post earlier in the thread.There is no ./usr/share/applications/ directory.
http://www.murga-linux.com/puppy/viewto ... dd#1003152
Code: Select all
It is important to know what the "current directory" is when execution enters the script. In the Unleashed environment,
directory "rootfs-complete" has the just-created complete Puppy filesystem, and rootfs-complete/ is the current directory when the script
is entered.
However, when the package is downloaded and installed with PETget, the current directory is the top of the running Puppy filesystem, that is, "/".
That is why the script has a dot on front of "/usr/local/bin", so that it will work in both cases.
That "dot in front" is the only special thing that you need to remember when creating a "pinstall.sh" script.
----------------
BK explains the reasoning for the .dot before the path in the paragraph above. It makes no difference in my pinstall.shSo that second set of commands for the pinstall.sh should work. Version without "the dot" in front of the absolute paths.
I believe petget is to blame because it is handling the pet differently between a frugal install and a full install.
.
- perdido
- Posts: 1528
- Joined: Mon 09 Dec 2013, 16:29
- Location: ¿Altair IV , Just north of Eeyore Junction.?
Its just a miserly little 188k pet file, petget / ppm are doing all that extra sfs stuff you see. Thanks for looking at that!musher0 wrote:Hi Perdido.
Going back to your screen cap on page 1, and please correct me if I'm
wrong, I notice that you are trying to create an sfs archive from a pinstall.sh
script in a fully installed Puppy.
rockedge is having the same problem with the pet he made.
We are having similar issues with different pets. The pinstall.sh runs and completes in a frugal install but not a full install.
I believe petget is at fault.
.
Well, perdido, believe what you will! Go ahead then, study bash and edit
petget until the cows come home!
I brought to your attention 2 technical reasons why I think that you are
having this problem. Three actually, if one considers that Puppy is designed
for frugal, and that the full install of PuppyLinux was sort of an afterthought.
I also suggested three work-arounds.
What else can I say? Use another distro that offers only full install?
What's the obsession with "full install" anyway?
Best regards.
petget until the cows come home!
I brought to your attention 2 technical reasons why I think that you are
having this problem. Three actually, if one considers that Puppy is designed
for frugal, and that the full install of PuppyLinux was sort of an afterthought.
I also suggested three work-arounds.
What else can I say? Use another distro that offers only full install?
What's the obsession with "full install" anyway?
Best regards.
musher0
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)
- perdido
- Posts: 1528
- Joined: Mon 09 Dec 2013, 16:29
- Location: ¿Altair IV , Just north of Eeyore Junction.?
The whole point of the post was to find out if there is a way to get the pinstall.sh working in a full install.musher0 wrote:Well, perdido, believe what you will! Go ahead then, study bash and edit
petget until the cows come home!
I brought to your attention 2 technical reasons why I think that you are
having this problem. Three actually, if one considers that Puppy is designed
for frugal, and that the full install of PuppyLinux was sort of an afterthought.
I also suggested three work-arounds.
What else can I say? Use another distro that offers only full install?
What's the obsession with "full install" anyway?
Best regards.
I'm not the only person thats noticed this problem. It being a problem because the pinstall.sh is supposed to run in a full install and it does not.
As it stands, the issue is no closer to being resolved than it was on day one of the topic.
Thanks for participating in this discussion.
I believe petget is broken regarding pinstall.sh in a full install.
.
Ditto.
Edit, 10 minutes later.
I just checked and pinstall.sh is not called by petget; you can check for
yourself by opening a console in /usr/local/petget and typing:Easy enough, but nothing shows up.
It is called by script installpkg.sh in the same directory. You do a similar
grep call from console and this is what you get:As you can see, it is further modulated by the "langpack" and the original
LANGuage environment; also pinstall.sh is removed at some point.
So this raises a couple of questions that may give us a lead -- or not:
-- in what language environment have you been working?
-- if you tried installing your pet more than once, perhaps the pinstall.sh
file was erased, and the 2nd time, it could not be found? Can you recall if
this is a possibility? On the other hand, the original pinstall.sh is in the pet
archive, so it should be available every time.
Finally, on line 70 of installpkg.sh, there is a mention of PUPMODEI could not find BarryK's original article, but according to this page by
shinobar, PUPMODE 2 is the full install mode. (It's in Japanese, but the
essentials are in English.) So your instinct may be partially right about
something being different for full install.
I wish I could help more, perdido, but I am not familiar enough with
shinobar's style of coding. Also, I tried to find where his
"$DIRECTSAVEPATH/" variable pointed to and couldn't. Finally, touching up
shinobar's code is sort of taboo in PuppyLand (IMO), because he is such an
excellent coder. I'll leave this in more capable hands, when they show up...
Sorry.
Edit, 10 minutes later.
I just checked and pinstall.sh is not called by petget; you can check for
yourself by opening a console in /usr/local/petget and typing:
Code: Select all
grep pinstall.sh petget
It is called by script installpkg.sh in the same directory. You do a similar
grep call from console and this is what you get:
Code: Select all
[/usr/local/petget]>grep pinstall.sh installpkg.sh
# 20aug10 shinobar: excute [sic] pinstall.sh under original LANG environment
rm -f /pet.specs /pinstall.sh /puninstall.sh /install/doinst.sh
#rm -f $DIRECTSAVEPATH/pet.specs $DIRECTSAVEPATH/pinstall.sh $DIRECTSAVEPATH/puninstall.sh $DIRECTSAVEPATH/install/doinst.sh
for i in pinstall.sh install/doinst.sh DEBIAN/postinst
#120926 if a langpack installed, it will have /usr/share/applications.in (see /usr/sbin/momanager, /usr/share/doc/langpack-template/pinstall.sh).
LANGuage environment; also pinstall.sh is removed at some point.
So this raises a couple of questions that may give us a lead -- or not:
-- in what language environment have you been working?
-- if you tried installing your pet more than once, perhaps the pinstall.sh
file was erased, and the 2nd time, it could not be found? Can you recall if
this is a possibility? On the other hand, the original pinstall.sh is in the pet
archive, so it should be available every time.
Finally, on line 70 of installpkg.sh, there is a mention of PUPMODE
Code: Select all
[ "$PUPMODE" = "2" ] && [ ! -d /audit ] && mkdir -p /audit
shinobar, PUPMODE 2 is the full install mode. (It's in Japanese, but the
essentials are in English.) So your instinct may be partially right about
something being different for full install.
I wish I could help more, perdido, but I am not familiar enough with
shinobar's style of coding. Also, I tried to find where his
"$DIRECTSAVEPATH/" variable pointed to and couldn't. Finally, touching up
shinobar's code is sort of taboo in PuppyLand (IMO), because he is such an
excellent coder. I'll leave this in more capable hands, when they show up...
Sorry.
musher0
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)
- MochiMoppel
- Posts: 2084
- Joined: Wed 26 Jan 2011, 09:06
- Location: Japan
I like "automagically".perdido wrote:Yes and it runs and installs in a frugal just fine.bigpup wrote:Another idea.
Is the pinstall.sh a shell script, so it is exec for permissions
On a full install it does not automagically execute but will run if I mouse click it and finish like it is supposed to.
.
What do you mean by "click it"? It shouldn't exist anymore. It is to be removed immediately after execution by installpks.sh.
- perdido
- Posts: 1528
- Joined: Mon 09 Dec 2013, 16:29
- Location: ¿Altair IV , Just north of Eeyore Junction.?
Hi MochiMoppel,MochiMoppel wrote:I like "automagically".perdido wrote:Yes and it runs and installs in a frugal just fine.bigpup wrote:Another idea.
Is the pinstall.sh a shell script, so it is exec for permissions
On a full install it does not automagically execute but will run if I mouse click it and finish like it is supposed to.
.
What do you mean by "click it"? It shouldn't exist anymore. It is to be removed immediately after execution by installpks.sh.
When using a pinstall.sh in a .pet
It executes and fully runs in a frugal install, there are no relics to click.
However in a full install puppy the pinstall.sh does not run and gets left in the puppy root / along with the puninstall.sh and pet.specs file
The discussion has been about why can't rockedge and I get our pinstall.sh to run in a fully installed puppy when it runs and works in a frugal installed puppy?
.
- perdido
- Posts: 1528
- Joined: Mon 09 Dec 2013, 16:29
- Location: ¿Altair IV , Just north of Eeyore Junction.?
Been using english only, I am no longer fluent in anything else.musher0 wrote:Ditto.
Edit, 10 minutes later.
I just checked and pinstall.sh is not called by petget; you can check for
yourself by opening a console in /usr/local/petget and typing:Easy enough, but nothing shows up.Code: Select all
grep pinstall.sh petget
It is called by script installpkg.sh in the same directory. You do a similar
grep call from console and this is what you get:As you can see, it is further modulated by the "langpack" and the originalCode: Select all
[/usr/local/petget]>grep pinstall.sh installpkg.sh # 20aug10 shinobar: excute [sic] pinstall.sh under original LANG environment rm -f /pet.specs /pinstall.sh /puninstall.sh /install/doinst.sh #rm -f $DIRECTSAVEPATH/pet.specs $DIRECTSAVEPATH/pinstall.sh $DIRECTSAVEPATH/puninstall.sh $DIRECTSAVEPATH/install/doinst.sh for i in pinstall.sh install/doinst.sh DEBIAN/postinst #120926 if a langpack installed, it will have /usr/share/applications.in (see /usr/sbin/momanager, /usr/share/doc/langpack-template/pinstall.sh).
LANGuage environment; also pinstall.sh is removed at some point.
So this raises a couple of questions that may give us a lead -- or not:
-- in what language environment have you been working?
40 years ago the usarmy qualified me as a linguist.
---------------------------
I may have run it like that a few times just thinking the outcome may be different(definition of crazy comes to mind) But I have reinstalled-- if you tried installing your pet more than once, perhaps the pinstall.sh
file was erased, and the 2nd time, it could not be found? Can you recall if
this is a possibility? On the other hand, the original pinstall.sh is in the pet
archive, so it should be available every time.
the full installed test vehicles more times than I can remember and started fresh with each variation of the pinstall.sh, with no different outcome.
-----------------------------
Barry's original article here via archive.org https://web.archive.org/web/20100519032 ... works.htmlFinally, on line 70 of installpkg.sh, there is a mention of PUPMODEI could not find BarryK's original article, but according to this page byCode: Select all
[ "$PUPMODE" = "2" ] && [ ! -d /audit ] && mkdir -p /audit
shinobar, PUPMODE 2 is the full install mode. (It's in Japanese, but the
essentials are in English.) So your instinct may be partially right about
something being different for full install.
I'm not sure it goes into enough detail to be helpful?
--------------------------------------
Thanks for digging around and confirming the problem actually exists.I wish I could help more, perdido, but I am not familiar enough with
shinobar's style of coding. Also, I tried to find where his
"$DIRECTSAVEPATH/" variable pointed to and couldn't. Finally, touching up
shinobar's code is sort of taboo in PuppyLand (IMO), because he is such an
excellent coder. I'll leave this in more capable hands, when they show up...
Sorry.
Perhaps it worked at one time and something was changed
and never got tried on the fully installed puppy since that is not as common as frugal installs.
.
- MochiMoppel
- Posts: 2084
- Joined: Wed 26 Jan 2011, 09:06
- Location: Japan
Mystifies me also. I don't run any of the distros you mentioned and my environment is different, so I have no way to see the effect. Obviously installpkg.sh runs fine as it extracted the file to / and there is little in the way that could prevent it from executing the script. A short test on my system with a simulated full install showed no problems. My pinstall.sh worked fine.perdido wrote:The discussion has been about why can't rockedge and I get our pinstall.sh to run in a fully installed puppy when it runs and works in a frugal installed puppy?
If you like you can send me a PM. I'll try to walk you through the debugging process.
- perdido
- Posts: 1528
- Joined: Mon 09 Dec 2013, 16:29
- Location: ¿Altair IV , Just north of Eeyore Junction.?
Thanks MochiMoppel.MochiMoppel wrote:Mystifies me also. I don't run any of the distros you mentioned and my environment is different, so I have no way to see the effect. Obviously installpkg.sh runs fine as it extracted the file to / and there is little in the way that could prevent it from executing the script. A short test on my system with a simulated full install showed no problems. My pinstall.sh worked fine.perdido wrote:The discussion has been about why can't rockedge and I get our pinstall.sh to run in a fully installed puppy when it runs and works in a frugal installed puppy?
If you like you can send me a PM. I'll try to walk you through the debugging process.
- MochiMoppel
- Posts: 2084
- Joined: Wed 26 Jan 2011, 09:06
- Location: Japan
I don't expect pinstall scripts to work in full installs of any recent puppy (e.g. Dpup Stretch or UPup Bionic Beaver), all puppies that use an updated version of installpkg.sh.
In line 156 it now readswhich IMO is wrong. For PUPMODE 2 I would expect DIRECTSAVEPATH to be empty.
And then only 6 lines later a strange if commandAbsolutely no reason here to check if DIRECTSAVEPATH contains a value. A few lines earlier the author assigned a value. But no harm is done either.
If indeed this is a typo and the author meantto check for the existence of this directory, then also the rest of the code needs fixing.
The real problem with pinstall.sh scripts is that they are now expected in /tmp/petget/directsavepath/ while in fact they sit in / and wait for execution. For the same reason the stuff in / doesn't get deleted. Explains why it can be clicked on. And since the change was made only for PUPMODE 2 it explains why pinstall.sh in frugal installs still works.
Maybe this all makes sense and I'm simply too stupid to understand it ...
In line 156 it now reads
Code: Select all
DIRECTSAVEPATH="/tmp/petget/directsavepath"
And then only 6 lines later a strange if command
Code: Select all
if [ "$DIRECTSAVEPATH" ];then
rm -rf $DIRECTSAVEPATH
mkdir -p $DIRECTSAVEPATH
fi
If indeed this is a typo and the author meant
Code: Select all
[ -d "$DIRECTSAVEPATH" ]
The real problem with pinstall.sh scripts is that they are now expected in /tmp/petget/directsavepath/ while in fact they sit in / and wait for execution. For the same reason the stuff in / doesn't get deleted. Explains why it can be clicked on. And since the change was made only for PUPMODE 2 it explains why pinstall.sh in frugal installs still works.
Maybe this all makes sense and I'm simply too stupid to understand it ...
- perdido
- Posts: 1528
- Joined: Mon 09 Dec 2013, 16:29
- Location: ¿Altair IV , Just north of Eeyore Junction.?
This is both a relief and quite distressing that someone has modified the script and left no notes in it or even tested it for functionality afterMochiMoppel wrote:I don't expect pinstall scripts to work in full installs of any recent puppy (e.g. Dpup Stretch or UPup Bionic Beaver), all puppies that use an updated version of installpkg.sh.
In line 156 it now readswhich IMO is wrong. For PUPMODE 2 I would expect DIRECTSAVEPATH to be empty.Code: Select all
DIRECTSAVEPATH="/tmp/petget/directsavepath"
And then only 6 lines later a strange if commandAbsolutely no reason here to check if DIRECTSAVEPATH contains a value. A few lines earlier the author assigned a value. But no harm is done either.Code: Select all
if [ "$DIRECTSAVEPATH" ];then rm -rf $DIRECTSAVEPATH mkdir -p $DIRECTSAVEPATH fi
If indeed this is a typo and the author meantto check for the existence of this directory, then also the rest of the code needs fixing.Code: Select all
[ -d "$DIRECTSAVEPATH" ]
The real problem with pinstall.sh scripts is that they are now expected in /tmp/petget/directsavepath/ while in fact they sit in / and wait for execution. For the same reason the stuff in / doesn't get deleted. Explains why it can be clicked on. And since the change was made only for PUPMODE 2 it explains why pinstall.sh in frugal installs still works.
Maybe this all makes sense and I'm simply too stupid to understand it ...
modifying it
Much appreciated MM, and everyone else that contributed to this discussion - hopefully someday it will be fixed back to how it once worked.
.
- MochiMoppel
- Posts: 2084
- Joined: Wed 26 Jan 2011, 09:06
- Location: Japan
Test for functionality? Don't expect too much. Your first point is more bothering. Who did this and why?perdido wrote:This is both a relief and quite distressing that someone has modified the script and left no notes in it or even tested it for functionality after
modifying it .
Now look at the bright side: It's a bug, but it's a good bug. Prevents the automatic execution of pinstall scripts which IMO pose an unnecessary security risk. Fortunately you now can inspect the script and decide if you want to execute it or not. Sure you have to clean up, but that's a small price to pay for more security. This bug should become standard for frugal install, seriously
I don't understand that. If you are willing to trust the contents of the PET, why would you not also trust its pinstall script?MochiMoppel wrote:Now look at the bright side: It's a bug, but it's a good bug. Prevents the automatic execution of pinstall scripts which IMO pose an unnecessary security risk.
Supposedly, the PET builder added the script because it is required to make the install work correctly.
- perdido
- Posts: 1528
- Joined: Mon 09 Dec 2013, 16:29
- Location: ¿Altair IV , Just north of Eeyore Junction.?
This is an update to this problem - from woofce
https://github.com/puppylinux-woof-CE/w ... ts/testing
mavrothal is on the ball.
I'm going to try and download the updated installpkg.sh and see how it does.
https://github.com/puppylinux-woof-CE/w ... ts/testing
mavrothal is on the ball.
I'm going to try and download the updated installpkg.sh and see how it does.
- Attachments
-
- 2018-09-15_193053.jpg
- (12.01 KiB) Downloaded 381 times
- perdido
- Posts: 1528
- Joined: Mon 09 Dec 2013, 16:29
- Location: ¿Altair IV , Just north of Eeyore Junction.?
I have downloaded and tried both versions of the proposed new version of installpkg.sh from mavrothal in a full install Upup Bionic 18.05
It ran the pinstall.sh and puninstall.sh and did not leave relics in /
The "simpler fix" was submitted last so it is the latest version.
.
It ran the pinstall.sh and puninstall.sh and did not leave relics in /
The "simpler fix" was submitted last so it is the latest version.
.
Last edited by perdido on Thu 20 Sep 2018, 22:53, edited 2 times in total.
- perdido
- Posts: 1528
- Joined: Mon 09 Dec 2013, 16:29
- Location: ¿Altair IV , Just north of Eeyore Junction.?
These are the two versions of the updated installpgk.sh script available from woofce / commits / testing
for anybody else that is interested.
The script belongs in /usr/local/petget/
Rename to installpkg.sh and make executable.
for anybody else that is interested.
The script belongs in /usr/local/petget/
Rename to installpkg.sh and make executable.
- Attachments
-
- installpkg.sh.02-simpler-fix.gz
- MD5 acd8b88ca2e6d69c8f1d8ff4f79c4563
- (37.23 KiB) Downloaded 258 times
-
- installpkg.sh.01.gz
- MD5 e7a2ddae7f9faff1c62f9a507abbeac4
- (37.29 KiB) Downloaded 237 times