THINSlacko
Nooby - what method did you use to do the install, and what type/number of partitions did you use?
I have found that the mbr on different usb sticks can be different when you buy them from the shop and this affects the way they boot.
My recommendation is that you backup any vital data on that usb stick and then try this:
Boot a machine from a puppy 4.3.1 Live CD (type pfix=ram at the boot prompt).
Run Gparted and clean out the usb stick you are having problems with, and just make it one FAT32 partition (just for testing purposes anyway...). Set the boot flag for that partition to "on" before you exit Gparted.
Do a frugal install of 4.3.1 and see if that stick now boots.
(there are a whole lot of ways to get around this problem, or work out why it is happening, but I just use puppy 4.3.1 when I am having trouble with a usb stick - there is something "magic" about the way Gparted and syslinux work together in the 4.3.1 install routine)
I have found that the mbr on different usb sticks can be different when you buy them from the shop and this affects the way they boot.
My recommendation is that you backup any vital data on that usb stick and then try this:
Boot a machine from a puppy 4.3.1 Live CD (type pfix=ram at the boot prompt).
Run Gparted and clean out the usb stick you are having problems with, and just make it one FAT32 partition (just for testing purposes anyway...). Set the boot flag for that partition to "on" before you exit Gparted.
Do a frugal install of 4.3.1 and see if that stick now boots.
(there are a whole lot of ways to get around this problem, or work out why it is happening, but I just use puppy 4.3.1 when I am having trouble with a usb stick - there is something "magic" about the way Gparted and syslinux work together in the 4.3.1 install routine)
As far as I remember I let it be the Fat32
as it had been from factory and then I did a totally manual
frugal install of Thinslacko moving the files from the iso.
But I am unsure of where I get the gldr and sometimes
I wonder if Geany add some different sign that are invisible
for us humans but are seen by the computer at boot.
Because the menu.lst looks the same but it boots
on one and not the other.
So you don't think I need to add some delay for the USB flash
to stabilize the address something.
puppy 431 is too old for me. Would not Lupu 528-005 work as well?
as it had been from factory and then I did a totally manual
frugal install of Thinslacko moving the files from the iso.
But I am unsure of where I get the gldr and sometimes
I wonder if Geany add some different sign that are invisible
for us humans but are seen by the computer at boot.
Because the menu.lst looks the same but it boots
on one and not the other.
So you don't think I need to add some delay for the USB flash
to stabilize the address something.
puppy 431 is too old for me. Would not Lupu 528-005 work as well?
I use Google Search on Puppy Forum
not an ideal solution though
not an ideal solution though
The invisible differences are inside the "mbr" (master boot record). Different sticks can have different mbrs when they come out of the shop. This can affect the boot behaviour. Puppy installer does not fix up the mbr unless you specifically tell it to do that (and some puppies do it better than others - it depends on the differences between sticks)nooby wrote: sometimes
I wonder if Geany add some different sign that are invisible
for us humans but are seen by the computer at boot.
Because the menu.lst looks the same but it boots
on one and not the other.
Not until after you have tried the puppy 431 trick. If the 431 trick does not work then you can try other things.So you don't think I need to add some delay for the USB flash
to stabilize the address something.
No. Not for preparing the usb stick. The best idea is that you "prepare" the stick by booting puppy431 into ram, using gparted to clear the partition, doing a puppy431 "universal" install, then if that boots ok you remove the 431 files and replace them with the Lupu or similar files. (but leaving the pup431 mbr in place)puppy 431 is too old for me. Would not Lupu 528-005 work as well?
Other people will be able to tell you other methods to achieve the same thing but this is the method that has worked best for me. I spent months fighting similar problems and the most reliable method by far was to prepare the stick with puppy431, then replace the 3 pup files with the files from your preferred puppy (in this case ThinSlacko)
The script that shuts down the computer when you click menu, shutdown, power off computer is apparently found at /etc/rc.d/rc.shutdown. I want to modify that file in my frugal ThinSlacko install, so I tried clicking on that file to prove it was the right one I need to modify.
The system did not shut down correctly, so that suggests that this script is not the only one that is involved in the shutdown.
I think there might be some other script that gets called first, and does things like unmounting or shutting down x in a way that is beyond the scope of the rc.shutdown script.
Does anyone have any pointers about what runs before rc.shutdown please?
The system did not shut down correctly, so that suggests that this script is not the only one that is involved in the shutdown.
I think there might be some other script that gets called first, and does things like unmounting or shutting down x in a way that is beyond the scope of the rc.shutdown script.
Does anyone have any pointers about what runs before rc.shutdown please?
Hi, greengeek.
I believe there are "wmpoweroff" and "wmreboot" files in /usr/sbin that are activated when you click on menu items "reboot computer" or !shutdown computer". Maybe search for them with pfind (it's not fresh in my memory where they are).
I believe those files do some preliminary "closing" of Puppy stuff and then relay to the /etc/rc.shutdown script.
TWYL.
I believe there are "wmpoweroff" and "wmreboot" files in /usr/sbin that are activated when you click on menu items "reboot computer" or !shutdown computer". Maybe search for them with pfind (it's not fresh in my memory where they are).
I believe those files do some preliminary "closing" of Puppy stuff and then relay to the /etc/rc.shutdown script.
TWYL.
musher0
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)
Thanks Musher0, looks like wmpoweroff is the one I need. It seems to be located at /usr/bin/wmpoweroff. Looks like it writes to /tmp/wmexitmode.txt then links to /usr/sbin/shutdownconfig, which writes to /tmp/shutdown_results which is read after control passes back to /usr/bin/xwin which calls /sbin/poweroff which calls /etc/rc.d/rc.shutdown. Darn it - It looks circular and complex. Maybe I shouldn't fiddle with it.musher0 wrote:I believe those files do some preliminary "closing" of Puppy stuff and then relay to the /etc/rc.shutdown script.
greengeek
What exactly do you want to do? It might be acheivable with a service script which are called with the "stop" parameter from /etc/rc.d/rc.shutdown. A lot easier than fiddling ..
What exactly do you want to do? It might be acheivable with a service script which are called with the "stop" parameter from /etc/rc.d/rc.shutdown. A lot easier than fiddling ..
Puppy Linux Blog - contact me for access
Jasper, open a terminal in the directory that has the ISO.Jasper wrote:
I always make a visual comparison when checking MD5 sums, but, in case it may be of some general interest, perhaps there is an automated method?
Then type md5sum -c [name of the md5 checksum file]
You will be prompted if the files check OK.
I use ThinSlacko in a "dualboot from usb" environment on the Win XP netbook that I use for work, and I'm experimenting with ways of speeding up my day by avoiding having to wait for slow shutdowns caused by slow savefile writes to usb. I think I have found one good solution here:01micko wrote:What exactly do you want to do? It might be acheivable with a service script which are called with the "stop" parameter from /etc/rc.d/rc.shutdown. A lot easier than fiddling ..
http://www.murga-linux.com/puppy/viewtopic.php?t=67084
but I realised I needed to be careful not to jeopardise mounted filesystems (especially my NTFS XP stuff) so I was experimenting with ways of doing a normal "proper" shutdown but without letting snapmergepuppy do it's thing. I read the posts about commenting out the snapmergepuppy lines in rc.shutdown but that became an "all or nothing" solution which took away the "automatic save at shutdown" feature completely.
I wanted to allow shutdown saves 90% of the time, but have a desktop icon for "dump_everything_and_shutdown_superquick" for the other 10% of the time.
(I have also trialled the code that inserts a gtkdialog into the shutdown process, and that works fine as long as I am watching the screen during the shutdown, but I was hoping to find a method that is just "click and run - no questions asked")
I toyed with the idea of having two versions of rc.shutdown - one unmodified, and one modified by removal of snapmergepuppy, but then discovered it wasn't as simple as using a desktop icon to call the modified version. The other processes that exist between calling wmpoweroff and handing control to rc.shutdown make it more complex than I first realised.
I've thought of writing a script to rename my proposed "rc.shutdownMODIFIED" to rc.shutdown, then including a routine to rename things back to how they were - but I have some research to do before I'm going to risk it.
ICK! Skipping rc.shutdown is dangerous!
Why don't you create yourself a nice little shutdown gui with a checkbox called "save session" or something, , have it checked by default, when unchecked it produces a signal and then that can create a flag in /tmp called "No_save" or whatever.
In rc.shutdown, you will see a big "case" statement with quite a few cases. Find the one "13)". Now you test for the condition of whether "/tmp/No_save" exists and if so don't run the snapmerge. Something like:
Something like that will work, and make sure everything gets killed and unmounted cleanly.
Why don't you create yourself a nice little shutdown gui with a checkbox called "save session" or something, , have it checked by default, when unchecked it produces a signal and then that can create a flag in /tmp called "No_save" or whatever.
In rc.shutdown, you will see a big "case" statement with quite a few cases. Find the one "13)". Now you test for the condition of whether "/tmp/No_save" exists and if so don't run the snapmerge. Something like:
Code: Select all
13)
if [ ! -f /tmp/No_save" ];then #start big if
All the snapmerge stuff happens here
fi #end big if
;;
next_case)whatever
Puppy Linux Blog - contact me for access
So if I understand you correctly, you are suggesting something like the following:
1) Modify rc.shutdown section 13 that you have shown, to test for the flag in /tmp (ie, doesnt proceed with snapmergepuppy if flag is set)
2) Write a script that is able to set the flag in /tmp, then calls wmpoweroff and lets it do the rest
3) Add a desktop icon labelled "immediate shutdown without save" or something and symlink it to the script.
Is that the general concept?
1) Modify rc.shutdown section 13 that you have shown, to test for the flag in /tmp (ie, doesnt proceed with snapmergepuppy if flag is set)
2) Write a script that is able to set the flag in /tmp, then calls wmpoweroff and lets it do the rest
3) Add a desktop icon labelled "immediate shutdown without save" or something and symlink it to the script.
Is that the general concept?
Yeah, that ought to do it.greengeek wrote:So if I understand you correctly, you are suggesting something like the following:
1) Modify rc.shutdown section 13 that you have shown, to test for the flag in /tmp (ie, doesnt proceed with snapmergepuppy if flag is set)
2) Write a script that is able to set the flag in /tmp, then calls wmpoweroff and lets it do the rest
3) Add a desktop icon labelled "immediate shutdown without save" or something and symlink it to the script.
Is that the general concept?
Puppy Linux Blog - contact me for access
OK, it's taken me a few hours but I think I've made it to first base. I've got your sample code working now, but I had to add another " (in the end I figured that maybe the leading quote marks were missing from the filename). It seems to work now (just with manual creation of /tmp/No_save) so next I will work on the script to set the flag file and call wmpoweroff.01micko wrote:Something like that will work, and make sure everything gets killed and unmounted cleanly.Code: Select all
13) if [ ! -f /tmp/No_save" ];then #start big if All the snapmerge stuff happens here fi #end big if ;; next_case)whatever
Er.. sorry about the missing quote thing, was in a bit of a rush
Doesn't even need quoting (no spaces ). Glad it seems to be of some use to you anyway.
Doesn't even need quoting (no spaces ). Glad it seems to be of some use to you anyway.
Puppy Linux Blog - contact me for access
.
Thanks micko. I'm very happy with the outcome.
I have modified the /etc/rc.d/rc.shutdown as follows:
then added a script "No_save" into /usr/bin as follows:
and then dragged the script to the desktop and added an icon, so that if I want to do a safe shutdown without waiting for the final save I just click that new icon.
Many thanks for the help!
Thanks micko. I'm very happy with the outcome.
I have modified the /etc/rc.d/rc.shutdown as follows:
Code: Select all
13) #PDEV1 and PUPSFS and PUPSAVE
#/initrd/pup_rw has tmpfs, pup_ro1 has ${DISTRO_FILE_PREFIX}save.2fs file (PUPSAVE), pup_ro2 has PUPSFS file.
#the above are in unionfs at /.
if [ ! -f "/tmp/No_save" ];then
#start big if
#All the snapmerge stuff happens here
echo "`eval_gettext \"Saving session to \\\${SAVEFILE} (\\\${SAVEPART})...\"`" >/dev/console
#echo "Saving session to $SAVEFILE (${SAVEPART})..." >/dev/console
/usr/sbin/snapmergepuppy /initrd/pup_ro1 /initrd/pup_rw
fi #end big if
;;
Code: Select all
#!/bin/sh
echo "test" > /tmp/No_save
/usr/bin/wmpoweroff
Many thanks for the help!
- Attachments
-
- save no_save desktop_.png
- (16.4 KiB) Downloaded 2057 times
-
- Posts: 7
- Joined: Sat 12 Jan 2013, 02:57
Currently running this distro and everything is working well, printing,network, jack, gimp etc. A new candidate for a musicians distro I reckon!
- Attachments
-
- Music2go1.jpg
- (175.85 KiB) Downloaded 743 times