Bug- pinstall.sh runs in frugal but not full install [Fixed]
- perdido
- Posts: 1528
- Joined: Mon 09 Dec 2013, 16:29
- Location: ¿Altair IV , Just north of Eeyore Junction.?
Bug- pinstall.sh runs in frugal but not full install [Fixed]
Created a small pet file. I used dir2pet to create pet
I can only get the pinstall.sh & puninstall.sh scripts to run in a frugal install.
The full install ignores them, making the pet unusable for the full install.
The scripts are not touched in the full install.
I tried adding sleep wait states to scripts with no effect. Thats why I believe the scripts are not touched.
Tried it in bionic and xenial just to see if the scripts did anything in a full install, they did not.
I can't be the only person this has happened to.
.
I can only get the pinstall.sh & puninstall.sh scripts to run in a frugal install.
The full install ignores them, making the pet unusable for the full install.
The scripts are not touched in the full install.
I tried adding sleep wait states to scripts with no effect. Thats why I believe the scripts are not touched.
Tried it in bionic and xenial just to see if the scripts did anything in a full install, they did not.
I can't be the only person this has happened to.
.
Last edited by perdido on Wed 24 Oct 2018, 18:01, edited 5 times in total.
- perdido
- Posts: 1528
- Joined: Mon 09 Dec 2013, 16:29
- Location: ¿Altair IV , Just north of Eeyore Junction.?
A little more, when running petget from terminal to install the pet the screens are different and the frugal install does not complete, but the full install does.
There is no reference to "nohup.out" in the full install.
It is my understanding there should be a "nohup.out" generated after the pinstall.sh initiates, it just catches the output from the pinstall script?
This is strange because both installs complete with just a mouse click on the pet using Rox but the full install will not run the pinstall script either way
Top pic is full install completing in terminal
Bottom pic is frugal install hanging in terminal at "nohup.out"
Please read the descriptions at top of pics for additional info
There is no reference to "nohup.out" in the full install.
It is my understanding there should be a "nohup.out" generated after the pinstall.sh initiates, it just catches the output from the pinstall script?
This is strange because both installs complete with just a mouse click on the pet using Rox but the full install will not run the pinstall script either way
Top pic is full install completing in terminal
Bottom pic is frugal install hanging in terminal at "nohup.out"
Please read the descriptions at top of pics for additional info
- Attachments
-
- full-install1.png
- Full install completing in terminal but not running pinstall script
Full install also completes with just a mouse click on pet using Rox
Neither of these installs run the pinstall script in the pet - (94.13 KiB) Downloaded 446 times
-
- frugal-install.jpg
- Frugal install hanging in terminal on nohup.out file see pic but runs pinstall script, nohup.out file contains "Generating /root/.jwmrc..."
Frugal install fully installs with mouse click using Rox and runs pinstall script in the pet - (42.58 KiB) Downloaded 448 times
- perdido
- Posts: 1528
- Joined: Mon 09 Dec 2013, 16:29
- Location: ¿Altair IV , Just north of Eeyore Junction.?
Maybe someone can answer me this:
1.Why can't the pinstall.sh in a pet file run the command jwm -restart
2.Why can't the pinstall.sh in a pet file run the command wmrestart
3.Is there a way to disable fixmenus from automatically running atfter a pet gets installed?
I would be looking for some way of doing this from inside the .pet pinstall.sh
I havn't found diddly-squat about those issues though I can guess the window manager and
server are not allowed a restart to keep the puppy package manager running--- maybe.
Anyways, any insight provided will be appreciated.
.
1.Why can't the pinstall.sh in a pet file run the command jwm -restart
2.Why can't the pinstall.sh in a pet file run the command wmrestart
3.Is there a way to disable fixmenus from automatically running atfter a pet gets installed?
I would be looking for some way of doing this from inside the .pet pinstall.sh
I havn't found diddly-squat about those issues though I can guess the window manager and
server are not allowed a restart to keep the puppy package manager running--- maybe.
Anyways, any insight provided will be appreciated.
.
Last edited by perdido on Wed 05 Sep 2018, 17:18, edited 1 time in total.
3.Is there a way to disable fixmenus from automatically running after a pet gets installed?
Why do you care?
If the pet package is a program.
If you put the required files, in the pet package, to make a menu entry for the program. Running fixmenus completes the install by updating the menu.
The program now has a menu entry.
If the pet package is not something that needs a menu entry and does not have required files to make a menu entry. Running fixmenus does nothing. and takes very little time to do nothing.
Basically it hurts nothing to run it.
The things they do not tell you, are usually the clue to solving the problem.
When I was a kid I wanted to be older.... This is not what I expected
YaPI(any iso installer)
When I was a kid I wanted to be older.... This is not what I expected
YaPI(any iso installer)
- perdido
- Posts: 1528
- Joined: Mon 09 Dec 2013, 16:29
- Location: ¿Altair IV , Just north of Eeyore Junction.?
bigpup wrote:3.Is there a way to disable fixmenus from automatically running after a pet gets installed?
Why do you care?
If the pet package is a program.
If you put the required files, in the pet package, to make a menu entry for the program. Running fixmenus completes the install by updating the menu.
The program now has a menu entry.
If the pet package is not something that needs a menu entry and does not have required files to make a menu entry. Running fixmenus does nothing. and takes very little time to do nothing.
Basically it hurts nothing to run it.
Pet package has desktop files, looking for a way to get the pinstall.sh and puninstall.sh running to completion in the full install. pinstall.sh hangs and when fixmenus runs it
throws stuff into the jwm menu that would not be there if pinstall.sh did not hang (the pinstall.sh rearranges some desktop files). But I don't think disabling fixmenus
can be done like that....
I wish you would have brought a bucket of information and dumped it in here
If the pinstall.sh & puninstall.sh would run to completion in the full install like they do in the frugal install I would not have the fixmenus running problem. I've been to
the puppy graveyards looking for info LOL, pretty much gave up on the pet working in a full install. You would be suprised how little info there is about pinstall.sh
Thats my story and I'm sticking to it <g>
I have also encountered strange things happening with full installs and PET packages loading.
I also found very little on the pinstall.sh scripts....my PET packages depend heavily on the pinstall.sh script to import sql files to a mariadb or mysql server and create users for apache to stay in line with the programs I am making the PET's from.
I need something similar with loading sfs packages. Someone did tell me once a way to do this in an sfs ...I will need to dive into the forum to find it.
I also found very little on the pinstall.sh scripts....my PET packages depend heavily on the pinstall.sh script to import sql files to a mariadb or mysql server and create users for apache to stay in line with the programs I am making the PET's from.
I need something similar with loading sfs packages. Someone did tell me once a way to do this in an sfs ...I will need to dive into the forum to find it.
- perdido
- Posts: 1528
- Joined: Mon 09 Dec 2013, 16:29
- Location: ¿Altair IV , Just north of Eeyore Junction.?
Makes it impossible to manufacture a pet that does anything but copy files when installing to a full install.rockedge wrote:I have also encountered strange things happening with full installs and PET packages loading.
I also found very little on the pinstall.sh scripts....my PET packages depend heavily on the pinstall.sh script to import sql files to a mariadb or mysql server and create users for apache to stay in line with the programs I am making the PET's from.
I need something similar with loading sfs packages. Someone did tell me once a way to do this in an sfs ...I will need to dive into the forum to find it.
I would like to see a way to run a pinstall.sh in either a pet or sfs when running a full install.
I guess that they are not used much and so are not missed at the user level.
I wonder if it is a bug or a feature?
.
Hi guys.
Why do a full install of a distro that was designed for a frugal install? Why
don't you stick to the type of install PuppyLinux was designed for? Problem
solved, if you ask me.
Why do you want a Puppy to meow? It's a Puppy, for God's sake: it barks.
Let it be.
Why do a full install of a distro that was designed for a frugal install? Why
don't you stick to the type of install PuppyLinux was designed for? Problem
solved, if you ask me.
Why do you want a Puppy to meow? It's a Puppy, for God's sake: it barks.
Let it be.
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.?
Do you use pinstall.sh in pet packages you manufacture? Tell me the secret of how to make them run in a full install puppy linux?musher0 wrote:Hi guys.
Why do a full install of a distro that was designed for a frugal install? Why
don't you stick to the type of install PuppyLinux was designed for? Problem
solved, if you ask me.
Why do you want a Puppy to meow? It's a Puppy, for God's sake: it barks.
Let it be.
What is the reason a pinstall.sh in a pet file runs in a frugal install but not in a full install?
.
Hi perdido.
I have used a pinstall.sh script on occasion in a pet archive, e.g. to install
and register a TTF font with fc-cache. Or to download a needed lib through
PPM on the tail of another prog.
But I never had your problem since I have never done a full instal of a
Puppy.
I don't which country this proverb is from, but here goes: "If you can't
move the boulder off the road, go around it."
If pinstall.sh can't do what you want in a full install, don't buck? It's not
worth redoing the entire petget for just one particular case.
Just suggesting:
-- Tell your user to run the pinstall.sh manually if the user has installed
Puppy as full install?
OR
-- Store pinstall.sh under a different name in /root/my-applications/bin or
/opt/local/bin, and inform the user to finish the install of your program
from there?
OR
-- Maybe the following is better, because it is a universal solution, not
dependent at all on pinstall.sh:
use a "first run" feature in a wrapper, so that the first time it is run, it
finishes the install? Something like
BTW, does your app install properly on a frugally installed Pup?
IHTH.
I have used a pinstall.sh script on occasion in a pet archive, e.g. to install
and register a TTF font with fc-cache. Or to download a needed lib through
PPM on the tail of another prog.
But I never had your problem since I have never done a full instal of a
Puppy.
I don't which country this proverb is from, but here goes: "If you can't
move the boulder off the road, go around it."
If pinstall.sh can't do what you want in a full install, don't buck? It's not
worth redoing the entire petget for just one particular case.
Just suggesting:
-- Tell your user to run the pinstall.sh manually if the user has installed
Puppy as full install?
OR
-- Store pinstall.sh under a different name in /root/my-applications/bin or
/opt/local/bin, and inform the user to finish the install of your program
from there?
OR
-- Maybe the following is better, because it is a universal solution, not
dependent at all on pinstall.sh:
use a "first run" feature in a wrapper, so that the first time it is run, it
finishes the install? Something like
Code: Select all
#!/bin/bash
if [ ! -f needed-file ];then
finish-install.sh
# Meaning: if the needed file is not found, fetch and install it.
# Maybe here you can add an info box telling the user why the wait on
# 1st run.
fi
# Once the file is there, the section above is skipped on any run
# afterwards. And the app is run with no delay:
blabla-prog
IHTH.
musher0
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)
Maybe the question should be what exactly is in the pinstall.sh?
Post the contents.
Could be something in it that is trying to do something wrong for a full install Puppy.
Post the contents.
Could be something in it that is trying to do something wrong for a full install Puppy.
The things they do not tell you, are usually the clue to solving the problem.
When I was a kid I wanted to be older.... This is not what I expected
YaPI(any iso installer)
When I was a kid I wanted to be older.... This is not what I expected
YaPI(any iso installer)
Adding my 2 Cents
Hi All,
Like musher0, I only run frugal installs. Musher0, however, asked "Why do a full install of a distro that was designed for a frugal install?" I thought the only exception to the general recommendation to use Frugal installs to be if you had a RAM-challenged computer, e.g. 256 Mbs or less. But recently someone --perdido perhaps-- suggested that Full installs present a better environment for compiling. Knowing nothing about compiling I have no reason to doubt that. But I don't see how that relates to the current problem of Full installs not ever executing pinstall.sh.
I discovered the lack of documentation/explanations regarding pinstall.sh under another circumstance when they cease to function. If you convert a pet to an SFS, a pinstall.sh of the pet will be copied to the into the SFS but, as far I know, isn't executed when the SFS is loaded or ever.
When I discovered that, I thought perhaps it would be necessary to write some type of "run-once" script to be placed in /root/Startup: check to see if the commands in the script had already be executed, and if not execute them. Way beyond my scripting skills. Fortunately, I don't recall any converted-SFS that failed to function as expected. Which left me wondering under what circumstances are pinstall.shs actually necessary.
mikesLr
Like musher0, I only run frugal installs. Musher0, however, asked "Why do a full install of a distro that was designed for a frugal install?" I thought the only exception to the general recommendation to use Frugal installs to be if you had a RAM-challenged computer, e.g. 256 Mbs or less. But recently someone --perdido perhaps-- suggested that Full installs present a better environment for compiling. Knowing nothing about compiling I have no reason to doubt that. But I don't see how that relates to the current problem of Full installs not ever executing pinstall.sh.
I discovered the lack of documentation/explanations regarding pinstall.sh under another circumstance when they cease to function. If you convert a pet to an SFS, a pinstall.sh of the pet will be copied to the into the SFS but, as far I know, isn't executed when the SFS is loaded or ever.
When I discovered that, I thought perhaps it would be necessary to write some type of "run-once" script to be placed in /root/Startup: check to see if the commands in the script had already be executed, and if not execute them. Way beyond my scripting skills. Fortunately, I don't recall any converted-SFS that failed to function as expected. Which left me wondering under what circumstances are pinstall.shs actually necessary.
mikesLr
Which left me wondering under what circumstances are pinstall.shs actually necessary.
the PET being installed contains Apache (or updated Hiawatha), mariaDB, PHP (either 5 or 7) and ZoneMinder
to get all of this ready to actually run after installation 2 users must be created. (there is a way to use webuser:webgroup that is already present)
www-data and mysql. MariaDB needs extra steps to be installed which includes creating the database tables for the mysql server to run AND the zoneminder database zm_create.sql needs to be loaded. and a mysql user for zoneminder needs to be created. then the sql is imported. the mariaDB need a script "mysql_install_db to run, a root user and password need to be set, the mysqld daemon must be started for of the further configuration to happen. then several directories must be created and permissions for 5 directories must be changed to the web server user created earlier. All in all there are about 20 lines (which I have shortened) in the zoneminder-130.4.pet pinstall.sh script that without it you're on your own getting it started....defeats the pupose of the PET in the first place.
I could post a copy of the pinstall.sh for this PET which the PET itself is around 262 megs in size.
Last edited by rockedge on Tue 28 Aug 2018, 15:26, edited 2 times in total.
- perdido
- Posts: 1528
- Joined: Mon 09 Dec 2013, 16:29
- Location: ¿Altair IV , Just north of Eeyore Junction.?
Hi musher0,
First off, I'm not a coder. I don't write programs but I can change configuration files to get programs set up. I would not know where to put your wrapper.
Thanks for taking this issue more seriously, seems there is something broken somewhere in the full install concerning petget & pinstall.sh
There are examples posted of installing the pet in terminal using petget in the 2nd post, whole bunch of verbosity
going on in the full install until it fully completes and leaves the pinstall.sh & puninstall.sh & pet.specs in the root directory(they should not get left there)
The problem is only that the pinstall.sh does not run in a full install.
A full install is supposed to run it, as far as I can tell by what little documemtation there is about the pinstall.sh
The best documentation I have found is this little snippit from Barry Kauler
That is from the puppy graveyard of things lost & forgotten. Luckily archive.org bot traversed that page and saved it.Whole page here PET packages
That was last updated - PAGE UPDATED: Feb 17, 2007, for Puppy v2.14+ only, when pet packages were a new concept and had replaced .pup packages in puppy 2.14
.
First off, I'm not a coder. I don't write programs but I can change configuration files to get programs set up. I would not know where to put your wrapper.
Thanks for taking this issue more seriously, seems there is something broken somewhere in the full install concerning petget & pinstall.sh
Well yes it does, it has been mentioned several times in this thread.musher0 wrote: BTW, does your app install properly on a frugally installed Pup?
IHTH.
There are examples posted of installing the pet in terminal using petget in the 2nd post, whole bunch of verbosity
going on in the full install until it fully completes and leaves the pinstall.sh & puninstall.sh & pet.specs in the root directory(they should not get left there)
The problem is only that the pinstall.sh does not run in a full install.
A full install is supposed to run it, as far as I can tell by what little documemtation there is about the pinstall.sh
The best documentation I have found is this little snippit from Barry Kauler
Code: Select all
The post-install script
This is an optional script that you would have to create yourself. Very few PET packages need this. Ditto for the post-uninstall script.
But, if you did need to create a "pinstall.sh" script, here are some notes:
The post-install script needs further clarification. There is no difference between a standalone PET package and a PET package in the Unleashed suite, except for where they are used. Unleashed packages are used to create a Puppy live-CD ISO file, whereas standalone PET packages are are available on the Internet for individual download and installation by the PETget package manager.
In both cases, the post-install script will be executed after the package has been installed.
Here is the basic format, taken from the Dillo web browser package:
#!/bin/sh
#post-install script.
#creatuppy: current directory is rootfs-complete, which has the final filesystem.
#pupget: current directory is /.
#dillo is by default the default internal html viewer.
#if no other browser, then dillo will also have to be the default web browser...
if [ "`ls -1 ./usr/local/bin/ | grep --extended-regexp "opera|mozstart|links|hv3"`" = "" ];then
echo "Configuring Dillo as the default web browser..."
echo '#!/bin/sh' > ./usr/local/bin/defaultbrowser
echo 'exec dillo "$@"' >> ./usr/local/bin/defaultbrowser
echo -n "dillo" > /tmp/rightbrwsr.txt
fi
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.
That was last updated - PAGE UPDATED: Feb 17, 2007, for Puppy v2.14+ only, when pet packages were a new concept and had replaced .pup packages in puppy 2.14
.
- perdido
- Posts: 1528
- Joined: Mon 09 Dec 2013, 16:29
- Location: ¿Altair IV , Just north of Eeyore Junction.?
Sure, here is one versionper instructions from BKbigpup wrote:Maybe the question should be what exactly is in the pinstall.sh?
Post the contents.
Could be something in it that is trying to do something wrong for a full install Puppy.
Code: Select all
#!/bin/sh
mv ./usr/share/applications/icon_switcher.desktop ./usr/share/applications/icon_switcher.desktop.bak
mv ./usr/share/applications/icon_switcher.desktop.new ./usr/share/applications/icon_switcher.desktop
mv ./usr/share/applications/Desktop-drive-icons.desktop ./usr/share/applications/Desktop-drive-icons.desktop.bak
mv ./usr/share/applications/Desktop-drive-icons.desktop.new ./usr/share/applications/Desktop-drive-icons.desktop
mv ./usr/share/applications/pdesktop.desktop ./usr/share/applications/pdesktop.desktop.bak
mv ./usr/share/applications/ptheme.desktop ./usr/share/applications/ptheme.desktop.bak
Code: Select all
#!/bin/sh
mv /usr/share/applications/icon_switcher.desktop /usr/share/applications/icon_switcher.desktop.bak
mv /usr/share/applications/icon_switcher.desktop.new /usr/share/applications/icon_switcher.desktop
mv /usr/share/applications/Desktop-drive-icons.desktop /usr/share/applications/Desktop-drive-icons.desktop.bak
mv /usr/share/applications/Desktop-drive-icons.desktop.new /usr/share/applications/Desktop-drive-icons.desktop
mv /usr/share/applications/pdesktop.desktop /usr/share/applications/pdesktop.desktop.bak
mv /usr/share/applications/ptheme.desktop /usr/share/applications/ptheme.desktop.bak
The script changes the existing similarily named desktop files to the extension ".bak" and
replaces them with the desktop files with the "new" extension by removing the .new using "mv" to change the names.
Now you can see why fixmenus is an issue if the pinstall.sh does not run, it leaves non-working programs in the menu.
.
- perdido
- Posts: 1528
- Joined: Mon 09 Dec 2013, 16:29
- Location: ¿Altair IV , Just north of Eeyore Junction.?
Re: Adding my 2 Cents
Hi mikeslr,mikeslr wrote:Hi All,
Like musher0, I only run frugal installs. Musher0, however, asked "Why do a full install of a distro that was designed for a frugal install?" I thought the only exception to the general recommendation to use Frugal installs to be if you had a RAM-challenged computer, e.g. 256 Mbs or less. But recently someone --perdido perhaps-- suggested that Full installs present a better environment for compiling. Knowing nothing about compiling I have no reason to doubt that. But I don't see how that relates to the current problem of Full installs not ever executing pinstall.sh.
I discovered the lack of documentation/explanations regarding pinstall.sh under another circumstance when they cease to function. If you convert a pet to an SFS, a pinstall.sh of the pet will be copied to the into the SFS but, as far I know, isn't executed when the SFS is loaded or ever.
When I discovered that, I thought perhaps it would be necessary to write some type of "run-once" script to be placed in /root/Startup: check to see if the commands in the script had already be executed, and if not execute them. Way beyond my scripting skills. Fortunately, I don't recall any converted-SFS that failed to function as expected. Which left me wondering under what circumstances are pinstall.shs actually necessary.
mikesLr
You present an interesting potential workaround using the /root/startup/ directory.
I have borrowed a script from shinobar that did something similar when installing the nvidia driver,
the script resides in /root/startup/ after the pet installs and runs on reboot. Here is the start of the script, the whole script is attached as nvidia.tar.gz so unzip to view.
Code: Select all
#!/bin/sh
# watch and make the nvidia graphic driver ready
# 22jun2012 shinobar
# 23jun2012: fatdog64
# 25jun2012: lhp64
#10oct2012: vdpau
#3may2013: try to avoid the depmod bug found in Puppy 4.3.1
# 23may2012: fix disablenouveau (thanks to peebee)
# 24may2012: improve disablenouveau keeping compatibility with Barry's xorgwizard-cli, welcome message
# 25may2013: can be called from rc.nvidia
# 26may2013: never use nvidia-xconfig
# 4sep2013: [Meeki] Must check xconfig file with nvidia-xconfig -t (see line(s) 255-258 & 296-304)
# 6sep2013: [Meeki] added LH64 to the skip of msg to run xorg after reboot (see line 286)
# 6sep2013: [Meeki] -a changed to -o meeki (see line 280)
# 6sep2013: [Meeki] tons of edits (see line 284 to 290)
# avoid multiple run
PSRESULT=$(ps)
N=$(echo "$PSRESULT"| grep -w "$0"| grep -w 'sh'| wc -l)
if [ $N -gt 1 ] ; then
echo "$0 seems already running."
exit 0
fi
- Attachments
-
- nvidia.tar.gz
- This is an auto run script that resides in /root/startup/ after installing an nvidia pet from shinobar,
it runs automatically when the system is rebooted after the pet is installed and then removes itself - (4.61 KiB) Downloaded 201 times
Last edited by perdido on Tue 28 Aug 2018, 16:09, edited 2 times in total.
I have not tried it on a full install.....which I will soon.
pinstall.sh
pinstall.sh
Code: Select all
#!/bin/sh
DATABASE_PASS="admin"
chown -R webuser /var/run/mysqld
chown -R webuser /var/cache/zoneminder
/usr/bin/mysql_install_db
sleep 7
mysqld &
sleep 7
mysqladmin -u root password "$DATABASE_PASS"
mysql -u root -p"$DATABASE_PASS" -e "UPDATE mysql.user SET Password=PASSWORD('$DATABASE_PASS') WHERE User='root'"
mysql -u root -p"$DATABASE_PASS" -e "DELETE FROM mysql.user WHERE User='root' AND Host NOT IN ('localhost', '127.0.0.1', '::1')"
mysql -u root -p"$DATABASE_PASS" -e "DELETE FROM mysql.user WHERE User=''"
mysql -u root -p"$DATABASE_PASS" -e "DELETE FROM mysql.db WHERE Db='test' OR Db='test\_%'"
mysql -u root -p"$DATABASE_PASS" -e "FLUSH PRIVILEGES"
mysql -u root -p"$DATABASE_PASS" -e "CREATE USER 'pma'@'localhost' IDENTIFIED BY 'admin';"
mysql -u root -p"$DATABASE_PASS" -e "GRANT ALL PRIVILEGES ON * . * TO 'pma'@'localhost'"
mysql -u root -p"$DATABASE_PASS" -e "CREATE USER 'zmuser'@'localhost' IDENTIFIED BY 'zmpass';"
mysql -u root -p"$DATABASE_PASS" -e "GRANT ALL PRIVILEGES ON * . * TO 'zmuser'@'localhost'"
mysql -u root -p"$DATABASE_PASS" < /usr/share/phpmyadmin/sql/create_tables.sql
sleep 2
mysql -u root -p"$DATABASE_PASS" < /usr/share/zoneminder/db/zm_create.sql
ln -s /etc/init.d/zoneminder /root/my-applications/bin
hiawatha
zoneminder start
I wonder if trying to replace core Puppy program .desktop files could be the problem.perdido wrote:Sure, here is one versionper instructions from BKbigpup wrote:Maybe the question should be what exactly is in the pinstall.sh?
Post the contents.
Could be something in it that is trying to do something wrong for a full install Puppy.The pet installs a couple desktop files with the extension "new"Code: Select all
#!/bin/sh mv ./usr/share/applications/icon_switcher.desktop ./usr/share/applications/icon_switcher.desktop.bak mv ./usr/share/applications/icon_switcher.desktop.new ./usr/share/applications/icon_switcher.desktop mv ./usr/share/applications/Desktop-drive-icons.desktop ./usr/share/applications/Desktop-drive-icons.desktop.bak mv ./usr/share/applications/Desktop-drive-icons.desktop.new ./usr/share/applications/Desktop-drive-icons.desktop mv ./usr/share/applications/pdesktop.desktop ./usr/share/applications/pdesktop.desktop.bak mv ./usr/share/applications/ptheme.desktop ./usr/share/applications/ptheme.desktop.bak
The script changes the existing similarily named desktop files to the extension ".bak" and
replaces them with the desktop files with the "new" extension by removing the .new using "mv" to change the names.
icon_switcher.desktop
Desktop-drive-icons.desktop
Both of these are used by several other Puppy programs.
Why are you replacing them?
These two are not in example: Puppy Xenialpup 7.5
ptheme.desktop
pdesktop.desktop
Are you adding them with the pet install?
This is what works to change the name:
mv /usr/share/applications/icon_switcher.desktop /usr/share/applications/icon_switcher.desktop.bak
There is no ./usr/share/applications/ directory.
So that second set of commands for the pinstall.sh should work. Version without "the dot" in front of the absolute paths.
The things they do not tell you, are usually the clue to solving the problem.
When I was a kid I wanted to be older.... This is not what I expected
YaPI(any iso installer)
When I was a kid I wanted to be older.... This is not what I expected
YaPI(any iso installer)
Another idea.
Is the pinstall.sh a shell script, so it is exec for permissions
Is the pinstall.sh a shell script, so it is exec for permissions
The things they do not tell you, are usually the clue to solving the problem.
When I was a kid I wanted to be older.... This is not what I expected
YaPI(any iso installer)
When I was a kid I wanted to be older.... This is not what I expected
YaPI(any iso installer)
- perdido
- Posts: 1528
- Joined: Mon 09 Dec 2013, 16:29
- Location: ¿Altair IV , Just north of Eeyore Junction.?
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.
I think petget is broken, maybe I should full install a bunch of pups and see if any of them will run a pinstall.sh
.