Bug- pinstall.sh runs in frugal but not full install [Fixed]

Please post any bugs you have found
Message
Author
musher0
Posts: 14629
Joined: Mon 05 Jan 2009, 00:54
Location: Gatineau (Qc), Canada

#21 Post by musher0 »

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 !!! :lol:
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)

User avatar
perdido
Posts: 1528
Joined: Mon 09 Dec 2013, 16:29
Location: ¿Altair IV , Just north of Eeyore Junction.?

#22 Post by perdido »

bigpup wrote: I wonder if trying to replace core Puppy program .desktop files could be the problem. :idea:
icon_switcher.desktop
Desktop-drive-icons.desktop
Both of these are used by several other Puppy programs.
Why are you replacing them?
They are exact copies of the desktop files they are replacing except they
have NoDisplay-True so they don't get put in the menu.
-------------
These two are not in example: Puppy Xenialpup 7.5
ptheme.desktop
pdesktop.desktop
Are you adding them with the pet install?
They are programs in puppy that are called by the new "Puppy Desktop" GUI that radky has been working on, this is in bionic.
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.
--------------
This is what works to change the name:
mv /usr/share/applications/icon_switcher.desktop /usr/share/applications/icon_switcher.desktop.bak
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.
---------------
There is no ./usr/share/applications/ directory.
That dot before the path is explicit in the instructions for pinstall.sh, for reference see this post earlier in the thread.
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.

----------------
So that second set of commands for the pinstall.sh should work. Version without "the dot" in front of the absolute paths.
BK explains the reasoning for the .dot before the path in the paragraph above. It makes no difference in my pinstall.sh

I believe petget is to blame because it is handling the pet differently between a frugal install and a full install.

.

User avatar
perdido
Posts: 1528
Joined: Mon 09 Dec 2013, 16:29
Location: ¿Altair IV , Just north of Eeyore Junction.?

#23 Post by perdido »

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.
Its just a miserly little 188k pet file, petget / ppm are doing all that extra sfs stuff you see. Thanks for looking at that!

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.

.

musher0
Posts: 14629
Joined: Mon 05 Jan 2009, 00:54
Location: Gatineau (Qc), Canada

#24 Post by musher0 »

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.
musher0
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)

User avatar
perdido
Posts: 1528
Joined: Mon 09 Dec 2013, 16:29
Location: ¿Altair IV , Just north of Eeyore Junction.?

#25 Post by perdido »

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.
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.
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.

.

musher0
Posts: 14629
Joined: Mon 05 Jan 2009, 00:54
Location: Gatineau (Qc), Canada

#26 Post by musher0 »

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:

Code: Select all

grep pinstall.sh petget
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:

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).
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 PUPMODE

Code: Select all

[ "$PUPMODE" = "2" ] && [ ! -d /audit ] && mkdir -p /audit
I 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.
musher0
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)

User avatar
MochiMoppel
Posts: 2084
Joined: Wed 26 Jan 2011, 09:06
Location: Japan

#27 Post by MochiMoppel »

perdido wrote:
bigpup wrote:Another idea.
Is the pinstall.sh a shell script, so it is exec for permissions :idea:
Yes and it runs and installs in a frugal just fine.
On a full install it does not automagically execute but will run if I mouse click it and finish like it is supposed to.
.
I like "automagically". :lol:
What do you mean by "click it"? It shouldn't exist anymore. It is to be removed immediately after execution by installpks.sh.

User avatar
perdido
Posts: 1528
Joined: Mon 09 Dec 2013, 16:29
Location: ¿Altair IV , Just north of Eeyore Junction.?

#28 Post by perdido »

MochiMoppel wrote:
perdido wrote:
bigpup wrote:Another idea.
Is the pinstall.sh a shell script, so it is exec for permissions :idea:
Yes and it runs and installs in a frugal just fine.
On a full install it does not automagically execute but will run if I mouse click it and finish like it is supposed to.
.
I like "automagically". :lol:
What do you mean by "click it"? It shouldn't exist anymore. It is to be removed immediately after execution by installpks.sh.
Hi MochiMoppel,

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?

.

User avatar
perdido
Posts: 1528
Joined: Mon 09 Dec 2013, 16:29
Location: ¿Altair IV , Just north of Eeyore Junction.?

#29 Post by perdido »

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:

Code: Select all

grep pinstall.sh petget
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:

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).
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?
Been using english only, I am no longer fluent in anything else. :oops:
40 years ago the usarmy qualified me as a linguist. :shock:
---------------------------
-- 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.
I may have run it like that a few times just thinking the outcome may be different(definition of crazy comes to mind) :lol: But I have reinstalled
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.
-----------------------------
Finally, on line 70 of installpkg.sh, there is a mention of PUPMODE

Code: Select all

[ "$PUPMODE" = "2" ] && [ ! -d /audit ] && mkdir -p /audit
I 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.
Barry's original article here via archive.org https://web.archive.org/web/20100519032 ... works.html
I'm not sure it goes into enough detail to be helpful?
--------------------------------------
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.
Thanks for digging around and confirming the problem actually exists.
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.

.

User avatar
MochiMoppel
Posts: 2084
Joined: Wed 26 Jan 2011, 09:06
Location: Japan

#30 Post by MochiMoppel »

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?
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.

If you like you can send me a PM. I'll try to walk you through the debugging process.

User avatar
perdido
Posts: 1528
Joined: Mon 09 Dec 2013, 16:29
Location: ¿Altair IV , Just north of Eeyore Junction.?

#31 Post by perdido »

MochiMoppel wrote:
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?
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.

If you like you can send me a PM. I'll try to walk you through the debugging process.
Thanks MochiMoppel. :)

User avatar
MochiMoppel
Posts: 2084
Joined: Wed 26 Jan 2011, 09:06
Location: Japan

#32 Post by MochiMoppel »

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 reads

Code: Select all

DIRECTSAVEPATH="/tmp/petget/directsavepath"
which IMO is wrong. For PUPMODE 2 I would expect DIRECTSAVEPATH to be empty.

And then only 6 lines later a strange if command

Code: Select all

if [ "$DIRECTSAVEPATH" ];then
 rm -rf $DIRECTSAVEPATH
 mkdir -p $DIRECTSAVEPATH
fi
Absolutely 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 meant

Code: Select all

[ -d "$DIRECTSAVEPATH" ]
to 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 ...

User avatar
rockedge
Posts: 1864
Joined: Wed 11 Apr 2012, 13:32
Location: Connecticut, United States
Contact:

#33 Post by rockedge »

MochiMoppel that is an interesting find. what you say makes sense...time to look at the code closer.

User avatar
perdido
Posts: 1528
Joined: Mon 09 Dec 2013, 16:29
Location: ¿Altair IV , Just north of Eeyore Junction.?

#34 Post by perdido »

MochiMoppel 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 reads

Code: Select all

DIRECTSAVEPATH="/tmp/petget/directsavepath"
which IMO is wrong. For PUPMODE 2 I would expect DIRECTSAVEPATH to be empty.

And then only 6 lines later a strange if command

Code: Select all

if [ "$DIRECTSAVEPATH" ];then
 rm -rf $DIRECTSAVEPATH
 mkdir -p $DIRECTSAVEPATH
fi
Absolutely 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 meant

Code: Select all

[ -d "$DIRECTSAVEPATH" ]
to 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 ...
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 :shock:

Much appreciated MM, and everyone else that contributed to this discussion - hopefully someday it will be fixed back to how it once worked.

.

User avatar
MochiMoppel
Posts: 2084
Joined: Wed 26 Jan 2011, 09:06
Location: Japan

#35 Post by MochiMoppel »

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 :shock: .
Test for functionality? Don't expect too much. Your first point is more bothering. Who did this and why?

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 :lol:

User avatar
rcrsn51
Posts: 13096
Joined: Tue 05 Sep 2006, 13:50
Location: Stratford, Ontario

#36 Post by rcrsn51 »

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.
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?

Supposedly, the PET builder added the script because it is required to make the install work correctly.

User avatar
perdido
Posts: 1528
Joined: Mon 09 Dec 2013, 16:29
Location: ¿Altair IV , Just north of Eeyore Junction.?

#37 Post by perdido »

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.
Attachments
2018-09-15_193053.jpg
(12.01 KiB) Downloaded 381 times

User avatar
perdido
Posts: 1528
Joined: Mon 09 Dec 2013, 16:29
Location: ¿Altair IV , Just north of Eeyore Junction.?

#38 Post by perdido »

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.

.
Last edited by perdido on Thu 20 Sep 2018, 22:53, edited 2 times in total.

User avatar
perdido
Posts: 1528
Joined: Mon 09 Dec 2013, 16:29
Location: ¿Altair IV , Just north of Eeyore Junction.?

#39 Post by perdido »

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.
Attachments
installpkg.sh.02-simpler-fix.gz
MD5 acd8b88ca2e6d69c8f1d8ff4f79c4563
(37.23 KiB) Downloaded 253 times
installpkg.sh.01.gz
MD5 e7a2ddae7f9faff1c62f9a507abbeac4
(37.29 KiB) Downloaded 233 times

Post Reply