I would also like to mention another problem I am having with Saluki, as it might remotely be related to these shutdown issues (but probably not). Again, I have this problem with Saluki, but not with NOP 5.2.2 which is based on the same racy.

DISCLAIMER: this will sound a bit spooky-tunes. You will think I am going mad. Maybe I am. Anyway, here is my problem:

When I try to boot from the usb stick I have loaded Saluki onto (regardless of whether I selected "save to file" or "save to partition") the system will not boot on the first attempt. It will hang forever showing:

If I force a poweroff by holding the power button for 10 seconds, then power on again within 20 seconds, Saluki will boot up correctly. If I leave it longer than 20 seconds, the next power on will go back to the SYSLINUX prompt and hang there forever. (actually - it is not a prompt, it is just like the machine stopped in mid sentence)

I also notice that if I remove and reinsert the usb stick during the initial 20 seconds after a poweroff, it will not reboot - just goes to SYSLINUX message again. This suggests to me that perhaps my machine maintains some portion of usb power for approx 20 seconds after poweroff? And that this affects whether or not Saluki boots correctly.

Or maybe the netbook power management system has something that still exists in memory or BIOS for 20 seconds after a power off? I just don't know. Anyway, it is repeatable and happens every time, and I have tried reinstalling about 10 times on two (identical) usb sticks, and now a third, different, higher quality stick, without being able to get rid of the problem. NOP 5.2.2 does not show this behaviour.Edited_times_total

Just in case it helps to narrow down the problem I thought I would mention the following:

If I install Gray's Racy 5.2.2 NOP in the same way as I have been installing Saluki, I do not have any shutdown problems at all.

NOP 5.2.2 seems to use a different routine for specifying the locale - I can choose en_Aus on the first stage - it does not require me to go to a second screen to select en-Aus, Also, it does not offer the "Legacy" prompt ro do the install to partition. I have now tried both the "save to file" and "save to partition" with NOP 5.2.2 and they both work fine.

Just to be precise : I think you refer to en_AU because you are located in NZ (en_NZ) OR en_US ?

When I try to boot from the usb stick I have loaded Saluki onto (regardless of whether I selected "save to file" or "save to partition") the system will not boot on the first attempt. It will hang forever showing:

(One note about thunar : Thunar uses a trash dir , so i was having problems deleting files larger than the remaining free space in the pupsave-file)

Yes, I've had that problem with a usb install also, if a file is deleted in /mnt/home then it creates /mnt/home/.Trash-0 which can not be emptied if there isn't sufficient free space,
this results in having to reformat the drive, I now don't delete files in /mnt/home
It might be an idea to be able to select a percentage of free space for the trash like that other OS.

(One note about thunar : Thunar uses a trash dir , so i was having problems deleting files larger than the remaining free space in the pupsave-file)

Yes, I've had that problem with a usb install also, if a file is deleted in /mnt/home then it creates /mnt/home/.Trash-0 which can not be emptied if there isn't sufficient free space,
this results in having to reformat the drive, I now don't delete files in /mnt/home
It might be an idea to be able to select a percentage of free space for the trash like that other OS.

Hi Karl, I have now edited my previous posts to clarify that I was selecting Australian English (ok I am in NZ but I figured that Puppy is an Aussie creation so was hoping I would have less problems by selecting their locale... )

I have attached pics of the locale outputs (sorry I don't know how to save data from a terminal yet..

I have absolutely no idea about the different en_EN differences, just had heard there are different scottish dialects in australia ..

and that the neccessary and necessary programms programs ..

If you are running on USB with save to entire partition, could you post the output of the

Code:

mount

command ?

(you could use the mouse left clicking holding the button and move the cursor over the output of the console, release the left button, and middle click to paste it into an empty sheet of an editor and do the same to copy from editor to the inputbox of the browser)

Version 21 gives me a slightly different result. It does not reboot into X, but just reverts to a command prompt after the saving process. However, I still have to do a hard shutdown to get out of this state.

If you are running on USB with save to entire partition, could you post the output of the

Code:

mount

command ?

OK, I have taken a shot of the mount command in the "fresh boot" state (first boot after hard reset) and also the "loop boot" state (when the shutdown procedure has auto rebooted in error).
(Sorry I couldn't do the middleclick trick till I get a mouse attached)

Version 21 gives me a slightly different result. It does not reboot into X, but just reverts to a command prompt after the saving process. However, I still have to do a hard shutdown to get out of this state.

Yeah, I could reproduce your problem under the locale 'en_US' (left as the default). I think the locale does not affect.
I think your problem is the saving to the partition specific. Or, saving to the partition on the flash, that is PUPMODE=7. Maybe recent woof bug.
I suspect the shutdown problem occurs every PUPMODE, but with different appearance.

Attached the rc.shutdown for debugging for whom the shutdown problem concern. Install the PET. You are warned because it will replace the existing /etc/rc.d/rc.shutdown, but proceed. Shutdown or reboot. The console gives prompt with '?'. Press [Enter]-key to proceed.
As for the PUPMODE=7, greengeek's case,press [S]-key at only one place where you are offered to skip.

The only reason it would restart X that I can think of, is if it's killing the shell (or logging off) on tty1. If that shell dies, mingetty will respawn it, and rerun /etc/profile.

Short exercise:
Go down to the console, type:

Code:

kill -KILL $$

Its killing myself. logging out and auto login.

Code:

rm -fr /tmp/*
kill -KILL $$

Coming back the desktop because the flag '/tmp/bootcnt.txt' was cleared.
Reasonable.

Test with the debugging tool:
Well, I reproduced the greengeek's case (USB flash install, save the session to the partition). Used the firstrun-debug-shutdown, and foud that the rc.shutdown kills its parent 'reboot'(or 'poweroff') and itself at the last stage. I don't know why, but maybe woof bug. It occurs PUPMODE=7 on saluki-21 but maybe all recent Puppies. I don't know about PUPMODE=6 (save the session in the internal HDD partition). I am not sure if it is related with PUPMODE=2 (Sage's case).
I also suspect that similar case can occur under PUPMODE=5 and/or under other cases, somewhere in the script rc.shutdown.

Anyone interested in comparing a copy of rc.shutdown with rc.shutdown.pupdev ? Who instigated the latter? Is it self-generating? Although I do not follow the above detail concerning code, I did find what works and what does not work, at least for a FULL - seems that it must contain the audit trail for the coding fault?

Anyone interested in comparing a copy of rc.shutdown with rc.shutdown.pupdev ? Who instigated the latter?

The rc.shutdown.pupdev is a document text. It does nothing as a script. Nothing do results hard-shutdown in some meaning.
I am very interesting if you report the result of the firstrun-debug-shutdown-2.2.1.pet. We can see, by the test, where it fails._________________Google Chrome portable
Downloads for Puppy Linux http://shino.pos.to/linux/downloads.html

(One note about thunar : Thunar uses a trash dir , so i was having problems deleting files larger than the remaining free space in the pupsave-file)

Yes, I've had that problem with a usb install also, if a file is deleted in /mnt/home then it creates /mnt/home/.Trash-0 which can not be emptied if there isn't sufficient free space,
this results in having to reformat the drive, I now don't delete files in /mnt/home
It might be an idea to be able to select a percentage of free space for the trash like that other OS.

I finally opened a terminal in these trash directories and did a

Code:

rm *
rm .*
cd ..
rmdir *
rmdir .*

to solve this manually

In order not to clutter up the trash "rubbish", use the delete missing trash. The right mouse button (in the paragraph the cursor is positioned). Recover deleted in this case is impossible.

The rc.shutdown.pupdev is a document text. It does nothing as a script. Nothing do results hard-shutdown in some meaning.
I am very interesting if you report the result of the firstrun-debug-shutdown-2.2.1.pet. We can see, by the test, where it fails.

As I explained, I don't do coding. I swapped rc.shutdown for rc.shutdown.pupdev and the shutdown failure/desktop looping stopped. If you tell me where to find firstrun-debug-shutdown-2.2.1.pet I will look for it, but presume I would have to invert the swap because shutdown works with the -.-.pupdev.

Yes, I double checked. It may be just a text file but swapping rc.shutdown with ditto.pupdev and back again reproducibly causes and rectifies the shutdown problem. No idea why, but it does. You're the expert, shino....