How to exit a frozen Puppy...and bring up a terminal in CLI mode?

[mikewalsh]

Quick query for y'all, guys. Not something I've ever given much thought to, but:-

Question:- If Puppy freezes - for whatever reason - how do we kill 'X', then bring up a terminal outside of 'X'? (So that we can then use that terminal to search for PIDs, etc, and kill processes that might be the culprits, and could be jamming things up..?)

In other words, how do we exit 'X' using the keyboard only?

A discussion in the Linux & Unix section over at BleepingComputer has prompted this. One of the guys over there has done a tutorial on how to get out of this conundrum in a 'mainstream' distro, and it got me thinking; I know there was some discussion around this over at the old forum, but as always, it wasn't a subject thread all on its own.....another unrelated thread ended up 'morphing' into a discussion about this, so it's buried away in the middle of something else.

Puppy works somewhat differently to mainstream distros; we don't use very many of the 'standard' commands since
Busybox, as I understand it, uses a reduced Bash sub-set, so.....what procedure would WE follow to get a terminal up in a 'frozen' Puppy?

Some of you are rather better at this kind of stuff than yours truly..!!

Mike.

[MochiMoppel]

In other words, how do we exit 'X' using the keyboard only?

Ctrl+Alt+Backspace
However with a frozen system your keyboard would be frozen too...

[mikewalsh]

@MochiMoppel :-

Ah, thanks, Mochi. I couldn't remember what the key combination was. I have used it in the past, but not for a long time; the old grey matter's not as sharp as it once was.

It always amuses ME that most of these tutorials seem to assume that although your system may be 'frozen', your keyboard is still functional....

Okay. Assuming that part works, how would WE bring up a terminal from outside 'X'? That's not something I've ever needed to do; I want to post in the BC tutorial thread, and clarify the differences for any Puppians who may be reading it, y'see.

Cheers.

Mike.

[gyrog]

In a running Xenialpup, "Ctrl+Alt+Backspace", followed by "reboot" at the console prompt, gave me a clean shutdown and normal boot.

[MochiMoppel]

how would WE bring up a terminal from outside 'X'?

When you are outside of X then you are already in a terminal.

[some1]

#date
#help
#startx
...
#poweroff
-might be good for the health

[mikewalsh]

how would WE bring up a terminal from outside 'X'?

When you are outside of X then you are already in a terminal.

Aah. Makes sense, now I think about it. You've shut-down "X", but of course Puppy is still running.....in theory.

Clarification appreciated. Right; so.... Okay, how about this one? Puppy is 'frozen'; GUI immobile; keyboard unresponsive. I don't suppose there IS any way to get a terminal running, if that's the case.....no?

(This is all theoretical, but I'm just trying to cover all the bases; it's stuff I've never really experimented with before. Hope y'all understand that. As a mod at BC, it just doesn't DO to profess ignorance.....you're expected to be all-seeing, all-knowing..! )

-------------------------

In a running Xenialpup, "Ctrl+Alt+Backspace", followed by "reboot" at the console prompt, gave me a clean shutdown and normal boot.

Yah, again that makes sense. D'you think it would work from a frozen-up, unresponsive Puppy? I don't really know how I could approximate such conditions, simply to try such a thing out.... Like I said, this is all pure theory; "what if" type of stuff, y'know?

Has anybody else actually found themselves in this kind of situation, and successfully recovered without a hard power-down? That's what I'd be curious to know.

Mike.

[rockedge]

@mikewalsh I have been in this situation often. I have never been able to recover when keyboard is also frozen, only hard stop works.

[amethyst]

@mikewalsh I have been in this situation often. I have never been able to recover when keyboard is also frozen, only hard stop works.

Agreed, once your mouse and keyboard are stuck you are f..cked. Turn off machine and hope for better next time.

[rockedge]

@amethyst I figure if one's managed to totally crash a Linux distro, it might be best to turn off the machine for a minute or so, and re-access what your doing...

[amethyst]

@amethyst I figure if one's managed to totally crash a Linux distro, it might be best to turn off the machine for a minute or so, and re-access what your doing...

I have a strange thing going with my laptop. It does not happen often but somnetimes when I boot different Puppy's in quick succession I may encounter some display issues (like screen dimming, some other screen issues, etc.). Actually - switching off the machine for a few minutes normally fixes things. On very rare occasions the plug has to be pulled.

[mikewalsh]

@amethyst I figure if one's managed to totally crash a Linux distro, it might be best to turn off the machine for a minute or so, and re-access what your doing...

I have a strange thing going with my laptop. It does not happen often but somnetimes when I boot different Puppy's in quick succession I may encounter some display issues (like screen dimming, some other screen issues, etc.). Actually - switching off the machine for a few minutes normally fixes things. On very rare occasions the plug has to be pulled.

@amethyst :-

Nic;

This IS only an (educated?) guess, like. I know even less about circuit design than I do about the 1001 things that keep a Linux OS ticking-over in the background, but.....power caps tend to hold current for a few minutes - sometimes, quite a while - before it gradually drains away in the normal course of things, yes..? (This is why "power-cycling" works; holding the power button down for 30-60 seconds speeds-up that draining process.)

I wouldn't be at all surprised if the RAM sticks also draw power from the caps, so THAT could be why leaving the machine for a few minutes allows things to start behaving themselves. It lets residual current disappear from the caps, so the RAM sticks truly DO lose any data they may have been holding onto. This IS all speculation, mind you; I don't profess to be any kind of an expert with hardware, but the theory does (kinda) make sense to me.....

If I want to power-cycle, I always pull the plug, then hold the power button down for at least 60 seconds. This usually does the trick; more important for Puppy operation, since frugals always run entirely in RAM anyway.

Myself, I've got an odd issue, too. For some strange reason, if I've been in 32-bit Xenialpup 7.5, then re-boot straight into jrb's 'lite' spin on Quirky64 April 7.0.1 - my usual 'daily driver' - I lose network access. The only way to get it back is to shut Quirky down, re-boot the router, then boot Quirky again; problem solved. Out of all the Pups in the kennel, this only occurs between these two Puppies.....and ONLY in that direction. Re-booting from Quirky into Xenial32, everything is tickety-boo.....

(*shrug*)

Mike.

[TerryH]

@mikewalsh I have been in this situation often. I have never been able to recover when keyboard is also frozen, only hard stop works.

One of the benefits of not writing directly to the save file/folder, is that when shutdowns like this are required, it doesn't stuff up your saves.

[gyrog]

since frugals always run entirely in RAM anyway.

Sorry, but I have to disagree.
There are only 3 pupmodes in the current Puppy that actually do this, 5, 77, and the new 66.
If you are running a frugal Puppy with a savefolder, the directory on disk that is the savefolder is directly mounted into the / aufs stack, so the partition that contains it is mounted rw, always,
if you are using a savefile, the mount point of the savefile on disk is directly mounted into the / aufs stack, when you write it goes directly to disk, so again the partition that contains it is mounted rw, always.
That is why on pupmode=12, rc.shutdown says that there is no saving to do, the data is already on disk.
To run entirely in RAM the savefolder/savefile would need to have their contents copied to RAM in 'init', and then copied from RAM to the savefolder/savefile in 'r.shutdown'.
Normal Puppy does not do that.

So, back to the topic with the above explanation in mind:
I use savefolders on an ext4 partition in pupmode=12.
To give myself a chance of not loosing it all, should I have to hit the hardware "reset" button, (and it does happen sometimes),
I always boot my Puppies with "pfix=fsckp", and FrugalPup utilities always produce Puppy boot entries wih "pfix=fsck,fsckp", just to be sure.
This automatic fsck of the partition in 'init', before the first mount of the partition, has allowed me to survive every hard "reset" so far, (fingers crossed).
I choose to use ext4 because it's fsck is always very fast on a healthy partition, even with large partitions on modern large HD's, so doing the fsck on every boot has a minimal time penality.

[taersh]

@gyrog
What is that fsckp option/command?

[gyrog]

@gyrog
What is that fsckp option/command?

Before Puppy supported savefolder, all frugals used a savefile.
There was a "pfix=fsck" boot parameter to get 'init' to fsck the linux filesystem in the pseudo partition that is the savefile, before it is mounted.

When savefolder was introduced, there was no linux filesystem inside the savefolder, it's just an ordinary directory.
So a new pfix boot parameter was introduced, "pfix=fsckp", the "p" is to indicate "partition".
This tells 'init' to fsck the real linux partition that contains the savefolder directory, before the partition is mounted.
Actually if "pfix=fsckp" is defined, 'init' does an fsck on every linux partition before it mounts it,
since it can't workout which partition contains the savefolder without mounting them.
It is significant that the fsck is done before a partition is mounted.

Having 2 "pfix=" boot parameters, makes particular sense if the install directory is on a real linux partition, but a savefile is used.
The user can choose to fsck the savefile only (pfix=fsck), or the partition it resides in only (pfix=fsckp), or both (pfix=fsck,fsckp).

[williams2]

To be explicit, if the keyboard and the mouse are not working, you can shut down the machine by pressing the power button and holding it for at least 5 seconds, it's a good idea to wait 20 or 30 seconds before starting it again.

If any file systems are mounted read/write, it is possible for those file systems to be corrupted, especially if the file system is being written to. Doing a file system repair after a forced shut down is usually a good idea.

Sometimes, running out of memory can cause the system to freeze. The kernel has a built in Out Of Memory killer, but it does not seem to work well in some (many) kernels. EarlyOOM seems to work reasonably well.
See viewtopic.php?f=105&t=2980

[gyrog]

Sometimes, running out of memory can cause the system to freeze. The kernel has a built in Out Of Memory killer, but it does not seem to work well in some (many) kernels. EarlyOOM seems to work reasonably well.
See viewtopic.php?f=105&t=2980

My strategy is to place a swap partition in the slowest possible location, i.e. on the tail end of the slowest HD.
My idea is that I will notice the system going very slowly, and realise it is swaping, so reboot.
Under normal usage, my machine never even looks like doing any swaping.

[bigpup]

#date
#help
#startx
...
#poweroff
-might be good for the health

These are not the commands used in Puppy Linux.
In Puppy Linux.

power off:
wmpoweroff

To start x server:
xwin

[Feek]

When savefolder was introduced, there was no linux filesystem inside the savefolder, it's just an ordinary directory.
So a new pfix boot parameter was introduced, "pfix=fsckp", the "p" is to indicate "partition".
This tells 'init' to fsck the real linux partition that contains the savefolder directory, before the partition is mounted.
Actually if "pfix=fsckp" is defined, 'init' does an fsck on every linux partition before it mounts it,
since it can't workout which partition contains the savefolder without mounting them.
It is significant that the fsck is done before a partition is mounted.

Hello, I boot puppy from ext3 partition and the savefolder resides in the same place, pupmode=13. Until now I used pfix=fsck. If I understand correctly, it would be better to change it to pfix=fsckp. Am I right?

[gyrog]

Hello, I boot puppy from ext3 partition and the savefolder resides in the same place, pupmode=13. Until now I used pfix=fsck. If I understand correctly, it would be better to change it to pfix=fsckp. Am I right?

Yes, "pfix=fsck" does nothing for a savefolder.
I haven't tried "pfix=fsckp" with ext3, only ext4, so I hope it works well for you.

[mikewalsh]

Hello, I boot puppy from ext3 partition and the savefolder resides in the same place, pupmode=13. Until now I used pfix=fsck. If I understand correctly, it would be better to change it to pfix=fsckp. Am I right?

Yes, "pfix=fsck" does nothing for a savefolder.
I haven't tried "pfix=fsckp" with ext3, only ext4, so I hope it works well for you.

I'm using ext3 throughout the kennels. I edited my boot entries, last night, to add "p" to the end of each 'pfix=fsck'. It appears to be working fine. Haven't noticed any adverse effects yet.....

Mike.

[Grey]

Well, okay, after the crash it's clear. And if another case with a hard drive.
Does anyone have experience in recovering overwritten files on a hard drive? I will repeat again, not deleted, but overwritten.
The QEMU GUI shell is good, but when trying to create a new disk image, it can overwrite the old one if you are distracted a little from what is happening on the screen. This happened to me yesterday.
The grep and dd commands failed to fix. My favorite TestDisk & PhotoRec didn't do it either. So it goes.
I have an ext4 file system, and the file is large enough that I already said goodbye to it

[step]

While Magic SysRq key can't get you from a frozen X to a CLI, it can help you shutdown a frozen Linux system in an orderly manner - unmounting filesystems and so on. Note that you need to plan ahead and enable this kernel feature before it can be used. For Fatdog64 811 users: the default kernel supports this feature, then you need to write 1 to /proc/sys/kernel/sysrq to enable magic sysrq. The actual keyboard sequence that invokes the magic is a bit cumbersome to type but with some exercise it can be done.

[jrb]

since frugals always run entirely in RAM anyway.

Sorry, but I have to disagree.
There are only 3 pupmodes in the current Puppy that actually do this, 5, 77, and the new 66.
If you are running a frugal Puppy with a savefolder, the directory on disk that is the savefolder is directly mounted into the / aufs stack, so the partition that contains it is mounted rw, always,

I seem to have found a way around this with savefolders in frugal install on ext3 drives. I have no explanation but here is what I do:

A) Set boot paramater pmedia=ataflash (pupmode=13)

B) I run a script, /etc/init.d/00pupmode12 at bootup
sed -i 's/PUPMODE=13/PUPMODE=12/g' /etc/rc.d/PUPSTATE > /dev/null 2>&1

This allows my savefolder to load before the script is run but after that there are no changes in the folder. When I want to make changes to my savefolder, I do it manually by copying in files, or deleting files.

When, while running puppy, I compare the contents of my savefolder with the contents of /initrd/mnt/tmpfs/pup_rw there is no change in the savefolder but all the normal changes associated with running puppy are in /initrd/mnt/tmpfs/pup_rw. They are not saved at shutdown and there is no request to do so. The save button that comes with pupmode=13 is present on the desktop but not functional.

As I say I have no explanation, I would certainly welcome one, but I use this with all my puppies and it has consistently worked.

Cheers, J

[jrb]

While Magic SysRq key can't get you from a frozen X to a CLI, it can help you shutdown a frozen Linux system in an orderly manner - unmounting filesystems and so on. Note that you need to plan ahead and enable this kernel feature before it can be used. For Fatdog64 811 users: the default kernel supports this feature, then you need to write 1 to /proc/sys/kernel/sysrq to enable magic sysrq. The actual keyboard sequence that invokes the magic is a bit cumbersome to type but with some exercise it can be done.

I had forgotten this feature, thanks for reminding me. I use to use this with Debian but Puppy kernels never seem to be configured for it.

[mikeslr]

since frugals always run entirely in RAM anyway.

Sorry, but I have to disagree.
There are only 3 pupmodes in the current Puppy that actually do this, 5, 77, and the new 66.... if you are using a savefile, the mount point of the savefile on disk is directly mounted into the / aufs stack, when you write it goes directly to disk, so again the partition that contains it is mounted rw, always.
That is why on pupmode=12, rc.shutdown says that there is no saving to do, the data is already on disk.
To run entirely in RAM the savefolder/savefile would need to have their contents copied to RAM in 'init', and then copied from RAM to the savefolder/savefile in 'r.shutdown'.
Normal Puppy does not do that.

Sorry I have to disagree. That's not how I understand pupmode 13. See, https://bkhome.org/archive/puppylinux/d ... works.html. ... "ramdisk: This is the tmpfs filesystem running in RAM, with new and changed files"...Under pupmode 13, "In the above diagram, the top layer is a tmpfs ramdisk, into which all new and modified directories go. It is the working area, and has the potential limitation of the amount of RAM available...".
That post was written some 15 years ago. But as far as I know, the only significant changes are (1) puppys then used a unionfs (union file-system) while today they use aufs (another union file-system) and (2) jpeps published the information that the use of the boot command 'pmedia=ataflash' (together with the installation of a newer grub4dos config to some then old Puppies) puppys booted from a hard-drive could be tricked into functioning under pupmode 13. [Menu>System>Puppy Event Manager, Save Session Interval still has to be changed to 'Never, ask at shutdown' to prevent automatic writing of the contents of the ramdisk to media at that time].

[ozsouth]

Both @peebee & my kernels have CONFIG_MAGIC_SYSRQ available but not enabled on startup. Writing 1 to /proc/sys/kernel/sysrq would enable it.

[Feek]

since frugals always run entirely in RAM anyway.

Sorry, but I have to disagree.
There are only 3 pupmodes in the current Puppy that actually do this, 5, 77, and the new 66.... if you are using a savefile, the mount point of the savefile on disk is directly mounted into the / aufs stack, when you write it goes directly to disk, so again the partition that contains it is mounted rw, always.
That is why on pupmode=12, rc.shutdown says that there is no saving to do, the data is already on disk.
To run entirely in RAM the savefolder/savefile would need to have their contents copied to RAM in 'init', and then copied from RAM to the savefolder/savefile in 'r.shutdown'.
Normal Puppy does not do that.

Sorry I have to disagree. That's not how I understand pupmode 13. See, https://bkhome.org/archive/puppylinux/d ... works.html. ... "ramdisk: This is the tmpfs filesystem running in RAM, with new and changed files"...Under pupmode 13, "In the above diagram, the top layer is a tmpfs ramdisk, into which all new and modified directories go. It is the working area, and has the potential limitation of the amount of RAM available...".
That post was written some 15 years ago. But as far as I know, the only significant changes are (1) puppys then used a unionfs (union file-system) while today they use aufs (another union file-system) and (2) jpeps published the information that the use of the boot command 'pmedia=ataflash' (together with the installation of a newer grub4dos config to some then old Puppies) puppys booted from a hard-drive could be tricked into functioning under pupmode 13. [Menu>System>Puppy Event Manager, Save Session Interval still has to be changed to 'Never, ask at shutdown' to prevent automatic writing of the contents of the ramdisk to media at that time].

It seems to be only a question of therminology.

"entirely in RAM" means something like boot from cd (pupmode 77 or 5), so not a single partition is mounted after boot by default.

In pupmode 13 is a partition with savefolder/file mounted during the whole session. The content of the save is not coppied into RAM during boot.
The savefolder on the mounted partition is ready to read from it (e.g. launching an app installed as .pet saved in previous sessions) and write to it (if we decide to save session).
If we decide NOT to save, the savefolder should remain unchanged for the next boot (so it can be said, that "the processes in puppy ran entirely in RAM for this session" )

[tallboy]

This was a theme in the old forum.
I have no number for all the times my Puppys have frozen! All possible suggestions about how to restart it by entering certain key sequences etcetra, is bullsh..., because X is frozen, keyboard is frozen, mouse is frozen, there are no input devices that work, you cannot communicate with the PC!
When Puppy freezes like that, there are two possibilities:
1) Power off by pressing the on/off button for more than 4 seconds, until it shuts down.
2) Wait! Just WAIT! There are some mysterious processes that seem to freeze everything, but in reality, your CPU is still active, it only needs some time to figure out what to do, while it barely crawls along, one tiny step at the time. So, you just wait, until it comes out of it's temporary trance!
Just leave the machine when you realize that the freeze is on, without making any panic key presses, or any other silly attempts to start it again. Just leave it alone, to figure out by itself how to get out of these 'frozen' processes. Leave it overnight, maybe even for a couple of days, and it just may be acting normal again, as if nothing happened, when you wake it up from the screen saver.
If you are one of the clever ones, you may find out what caused the freeze, the rest of us just have to accept it sometime happens.