Make Puppy recover automatically from improper shutdowns

How to do things, solutions, recipes, tutorials
Message
Author
User avatar
SilverPuppy
Posts: 143
Joined: Fri 29 May 2009, 02:21

Make Puppy recover automatically from improper shutdowns

#1 Post by SilverPuppy »

I do computers for a living, and using Puppy to make computers usable that most people think are landfill anchors is very fun to me. I started on that kick last winter (I live in a seasonal area and winter is really dead....) and I continue with it to this day. This posting is coming to you from a computer running Puppy 4.1.2 using Firefox 3.5.3.....all on a Pentium II-350mhz w/ 160mb RAM. It's a full HD installation. It runs so well that once I get on it, I'm just zipping along, doing this, clicking that, and I often forget that it's actually not my main computer until the internet hangs up, since it comes through my main computer and is shared from there.

Anyway, I get these computers all snazzed up and ready to play ball, and then pawn them off on old people who want in on this computer thing. More often than not, sooner or later, something doesn't go as expected and they freak out and just turn them off. Stock, Puppy doesn't recover from this well. It'll hem and haw in the driver initialization phase, then end at a # bash prompt and await user intervention. Invariably that user intervention is a phone call to me. :shock: I wanted to put an end to that little problem.

Actually, under 4.1.2 (my all-time favorite Puppy so far) this creates several problems. First of all, it leaves them X-less, and computer-illiterate people don't like the absence of a GUI so well. Second, if you type "startx" to coax X back to life, some things won't work right until it's rebooted again, such as USB. Third, it would be a good idea to do a "fsck" to make sure that nothing got its feathers ruffled by being dumped in a pile, but that's not easy to do safely without a LiveCD.

Here are modified startup and shutdown scripts that fix that. This is for full-HD installations, and I don't know what, if anything, it would do to frugal or CD-based installations. You may have to just copy what I did into your startup scripts, depending on what version of Puppy you're using, but the changes I made should work in all versions of Puppy. These scripts are drop-in ready for Puppy 4.1.2 RETRO, which is what they were created for. To find my additions, search for my username "silverpuppy" as I denoted the pieces I added that way.

Notice where these have been added in, as they work correctly there. As far as I know, some of these could move around a little and still work fine, but the addition that calls e2fsck MUST be in the exact same place as it is in mine or it likely won't work. This is well explained in the comments within the script.

Credit where credit is due: I couldn't have done this without the genius of Puppy forum user mikeb, who contributed so much to my understanding of how this could work, and even directed me to some almost ready-to-implement code that saved me a lot of time scratching out my own. (I'm actually fairly new to Linux, though I've been computing for 20 years.) The forum in which we hashed this all out is here.

My files are attached, ready to drop into place on 4.1.2 Retro full HD installs on hda1. Slight revision to the fsck line will be necessary for the non-retro kernel or SATA installations to reflect the nomenclature change. Also, if Puppy is not installed to the first partition or the first hard drive, appropriate changes will have to be made. Everything else should work no matter what with no revisions. Hope this helps someone!

EDIT: I have just attached a new archive (made in Windoze, sorry, but should open in PupZip OK) that includes ready-to-use files for not only 4.1.2, but also 4.3.1, which I am actually considering liking. :D (Those of you who know me know that I despise 4.2......)

Do be aware that 4.3 supports timezones, and this creates an odd problem: when you write the superblock, it gets written in GMT, so if you install 4.3.1 and set the timezone to anything WEST of Greenwich (such as anywhere in the States) fsck will freak out if it is run from the rc.sysinit because it's not allowed to automatically fix the "superblock last write time is in the future" error. If anyone has ideas on how to fix this without having the timezone set wrong, let me know. (Here, not by PM.)
Attachments
rc.sysinit&shutdown-4.1.2-4.3.1.zip
(41 KiB) Downloaded 1329 times
Last edited by SilverPuppy on Mon 07 Dec 2009, 14:53, edited 1 time in total.

Sylvander
Posts: 4416
Joined: Mon 15 Dec 2008, 11:06
Location: West Lothian, Scotland, UK

#2 Post by Sylvander »

1. "if Puppy is not installed to the first partition or the first hard drive, appropriate changes will have to be made"
I've used your files, and my BoxPup installation is on sda3.
Could you explain what changes would need to be made?

User avatar
SilverPuppy
Posts: 143
Joined: Fri 29 May 2009, 02:21

Good to see, now here we go........

#3 Post by SilverPuppy »

Thanks for trying my files. Glad to see someone getting some mileage out of them. I really like them......

The change you MUST make is in the insertion that calls e2fsck to check the hard drive. By default, it instructs e2fsck to check /dev/hda1, which is the proper name and location for the Puppy installation on my boxes. In your case, you'd just change the partition to /dev/sda3 and everything will be happy.

If you don't change it, it will still appear to recover properly, and mostly will, but no fsck will ever take place, although the "Checking...." message will still appear, since it is only a text line, not the output from fsck.

I'm not sure what kernel and/or Puppy BoxPup is based on; it might be better to just take my revisions from my files and insert them into yours. But if mine work on your puplet, then don't worry about it. I guess I'd suggest trying mine intact first to see if they work, but keep a backup of your original ones in case they don't so you can then go back and customize and use your original ones.

That help?

Sylvander
Posts: 4416
Joined: Mon 15 Dec 2008, 11:06
Location: West Lothian, Scotland, UK

#4 Post by Sylvander »

1. I'm a Linux & Puppy newbie.

2. In folder /etc/rc.d and files rc.shutdown & rc.sysinit I can find no examples of:
e2fsck
/dev/hda1
/dev/sda3

3. I think I'm going to be forced to restore the original files.

4. Something of possible interest:
I right-clicked on the new rc.sysinit and clicked "Open"...
The screen went all kinds of strange colored patterns, then black then back into the desktop.
But once there things were not working quite right, so I rebooted, and then all seemed OK.

User avatar
SilverPuppy
Posts: 143
Joined: Fri 29 May 2009, 02:21

Ok then.....

#5 Post by SilverPuppy »

Well, for a newbie you sure are talkative! 487 posts or what was it......

Anyway, you're correct, the ORIGINAL files don't contain any reference to /dev/hda1 or any of the other stuff you mentioned. My files do contain that in the section that performs the fsck on the Puppy partition.

If you just drop in the files, I don't know what will happen on BoxPup because I don't know what it's based on. I guess I could look it up......it will likely work, but you'll have to change the fsck section to reflect your configuration. Change /dev/hda1 to /dev/sda3 and you should be in good shape on that.

The best approach if you're not using Puppy 4.1.2 would be to simply search my files for silverpuppy, my username, which I put in the comment header and footer around all the stuff I added. I even put in the header --silverpuppy-- and in the footer --end silverpuppy-- so there can be no mistake about what I have added and what was there before. Just look at what's before and after in my files and put them in the same places in yours. There are 2 sections in each with additions from me. The ones in rc.shutdown are very brief, the ones in rc.sysinit are longer. Just be SURE you get the first insertion in rc.sysinit in the right place or it won't work. Full details on exactly where it must go are in the comments within the file itself.

If you really get stuck, upload your original files and I'll put my code into it and re-upload them so you can have a ready-to-go set, and hopefully you and maybe others can see what I did and understand it better with a second example.

Sylvander
Posts: 4416
Joined: Mon 15 Dec 2008, 11:06
Location: West Lothian, Scotland, UK

#6 Post by Sylvander »

1. I had put your files in place and BoxPup wouldn't boot, so I used another Puppy to put back the originals.
I've been incorrectly searching those for your changes.

2. Re-downloaded your files.
(a) Found 1 reference to /dev/hda1 in file rc.sysinit, and changed that reference to read /dev/sda3
(b) Replaced my original files with yours, and will now try rebooting.
That worked OK.

3. Uploaded my original copies in an archive file.
Attachments
originals.tar.gz
(17.87 KiB) Downloaded 885 times

User avatar
SilverPuppy
Posts: 143
Joined: Fri 29 May 2009, 02:21

OK, here you go

#7 Post by SilverPuppy »

Sorry it took me so long to get around to it. Here's my code injected into your original files. Looking at the files, I think that my original files are probably interchangeable with yours. It appears that yours is based on 4.1.1, and using my files based on 4.1.2 should work fine, if not better.

But nonetheless, here are your files modified by moi.
Attachments
boxpup-sda3-rc.files.tar.gz
(18.53 KiB) Downloaded 875 times

Sylvander
Posts: 4416
Joined: Mon 15 Dec 2008, 11:06
Location: West Lothian, Scotland, UK

#8 Post by Sylvander »

The altered files are now in place, then rebooted without incident. :D

Thank you SilverPuppy. 8)

User avatar
SilverPuppy
Posts: 143
Joined: Fri 29 May 2009, 02:21

Hee hee hee......[rubs hands evilly]

#9 Post by SilverPuppy »

Good, so the files boot properly (knew they would :D ) but now you need to MAKE an incident so you can observe their behavior under the conditions they are designed to compensate.

Boot 'er up, and just when Puppy thinks you're about to check your email, unplug it! That's the "improper shutdown" these modifications compensate for.

Expected behavior:

Upon restoring power, Puppy will boot through "Loading Kernel Modules" after which the message will be shown "Cleaning up after improper shutdown........" then almost immediately after it "Rebooting to finish......." after which Puppy will indeed go through its normal shutdown routine and reboot. Upon reboot, it will progress to "Making Filesystem Usable" and then immediately issue the message "Checking Filesystem after improper shutdown........" which should take a few seconds or more, followed by a summarial output from fsck, and the boot sequence should continue to a normal X window manager just like always.

This seems to take a bit longer then the previous behavior, if you don't think about it, but it's ultimately much faster because a) before, it would dump you at a # prompt and you had to do something, b) you have to reboot anyway after an improper shutdown to restore USB and....something else, I forget, and c) it is absolutely, positively NOT SAFE to fsck a mounted filesystem, so you have to reboot with a LIVECD to do it any other way. THAT'S SLOW.

In short, this fix is the cleverest thing I've done in a long time, which doesn't really say much to me having a life or a brain, since I basically just pieced together stuff from other people and packaged it. But hey, if it helps someone, that's the idea.

Frankly, I'd like to see this behavior included automatically in the future, but I'm not sure how that would be possible, since it only applies to full HD installations, and Puppy is really geared toward frugal and livecd operation. I guess we'll just have to keep patching it it. Not a big deal.

Sylvander
Posts: 4416
Joined: Mon 15 Dec 2008, 11:06
Location: West Lothian, Scotland, UK

#10 Post by Sylvander »

That worked a treat! :D

1. With BoxPup running and 3 Firefox windows open...
Switched off the power at the power socket at the wall.
All PC hardware is powered by connecting to a couple of daisy-chained 6-socket power strips, so that powered off EVERYTHING PC related.

2. Flicked the wall-switch to ON, and pressed the on-button on the desktop unit.

3. Startup proceeded normally to the point where GRUB offers its choices [part1 on the HDD MBR, part2 in the Ubuntu files on the Ubuntu partition on the internal HDD].

4. Chose to boot BoxPup.

5. First part was too quick for me...
Began rebooting before I knew it.
The remainder of the sequence went pretty quick too.
Booted into BoxPup as per normal.

6. I think this is BRILLIANT! :D
And as you say, aught to be included as standard in all Puppies/puplets.

PupGeek
Posts: 353
Joined: Sun 06 Sep 2009, 11:30

#11 Post by PupGeek »

I had a power outage while using a full HD install of puppy 2.15 and i never got it working quite right.... now it always starts x with the "woof woof" help page.... (It plays the sound file that I made for it and set it to play). I haven't really been persuing this issue as I simply frugalled puppy 4.2.1 instead.

I do, however, like the full HD install of 2.15 as it boots in only about 90 seconds from pushing the on button to X (400 MHz PII dinosaur). and plus, I have a full Debian set (yep, all 23 cds) of binaries for that kernel (2.6.18.1).

sindi
Posts: 1087
Joined: Sun 16 Aug 2009, 13:30
Location: Ann Arbor MI USA

Puppy 4.3.1 improper shutdown not fixable

#12 Post by sindi »

A friend returned a Puppy installation that booted to a black screen. xwin/Xvesa fixed it once, but then to try to duplicate the problem I booted and hit the power button. Now it boots to an endless series of the same messages, and e2fsck run from live CD fixes a lot of stuff but then it boots to X with only two icons (fd and sda on top of each other). Full install. Has anyone tried these replacement files with 4.3.1? The fix I had to use was to spend 10 hours setting up XP on a faster computer instead. Maybe frugal install would recover better but it takes 3-5 sec to respond to a mouse click and people end up loading the program 3-4 times.

PupGeek
Posts: 353
Joined: Sun 06 Sep 2009, 11:30

#13 Post by PupGeek »

with frugal installs and liveCD sessions, full installs really don't make much sense to me anymore. its just so much easier to recover from a screwed up system with a frugal install or liveCD session. you just start off a new pup_save file and that's it. Got documents on the old one you wanna keep? Simply rename the old pup_save file instead of deleting it, so you can mount it later and retrieve those documents.

User avatar
SilverPuppy
Posts: 143
Joined: Fri 29 May 2009, 02:21

That's why we love it

#14 Post by SilverPuppy »

Yes, Puppy is flexible.....it embodies the Burger King slogan: "Have it your way." (Don't sue us, BK: we know you own that line. :D )

Personally, I think that just dumping your savefile if something goes wrong is a cheap-and-lazy way to AVOID having to actually fix problems. For example, when sindi had his issues, the pinboard file got corrupted, then deleted by fsck. Simply replacing it from the disc would have fixed the problem. It only takes 30 seconds, and there's instructions in the forum for how to do it. I found said instructions, read them, and fixed my problem in less than 10 minutes after a poorly made PET borked mine.

I've gotten pretty familiar with the way Puppy works, and I think that, done properly, Full HD installs can be VERY reliable, but there are a few things that need to be done to make it really solid:

1. Embrace progress. Ditch EXT2. The journaled nature of EXT3 makes it much more solid and much LESS subject to corruption than EXT2. True, you lose some usable space to the journal, and in a perfect world, keeping that space would make sense, but this isn't a perfect world, so there's Walgreens XD

2. Insert the pertinent code from my startup files into yours. Invariably, sooner or later, you'll get some goof that just hits the button, or the electricity to your house will fail, or whatever. Having it immediately perform clean-up AND an FSCK minimizes both the need to mess around with stuff AND the risk of losing stuff.

3. Use a stable build and find the little fixes for it. I use 4.1.2 with several patches, including CUPS, and it's solid and fast.

4. Don't freak out if something acts weird. There's usually a simple fix for it. Search the forum--virtually all of the problems have been fixed before.

Hope that helps a Puppian along the way somewhere!

PupGeek
Posts: 353
Joined: Sun 06 Sep 2009, 11:30

#15 Post by PupGeek »

I like dumping the save files better because most of the problems I have stem from something or other that i did to tweak the system. Rather than spend a bunch of time trying to recover, I just start anew and keep in mind not to try that tweak again. But then again, I have learned that if I want to tweak my system, I should boot up with a pfix=ram so that my pup_save file does not get corrupted.

I do not believe that it has so much to do with laziness as it does with the fact that recovering your system is all to often, the absolute last thing anyone wants to do at any given moment.... When you want to get something done, you just want to do it, not sit there all day trying to configure your system to accomplish the task, or try to recover from your last attempt to. That happens to be one of the main reasons why Windoze remains at the top of the heap despite its increased vulnerability to viruses and its cost.

I have been spending a lot of time configuring software packages as roxapps, with some even using squashfs to keep the size down. At this point the AppRun script can even be written to execute a roxapp that unzips a tarball and functions exactly like a windows installer. Given that I do that, I benefit in two ways by running a livecd environment (or frugal install) without using a pup_save file. For starters, I do not worry about screwing up the installation that i use just to get stuff done. The second way I benefit is more important, as I can ensure that the app i configured contains all the files it depends on, even if the end user is just using a plain puppy with nothing added on.

User avatar
SilverPuppy
Posts: 143
Joined: Fri 29 May 2009, 02:21

As I said before......

#16 Post by SilverPuppy »

Have it your way! :D We love Puppy!

While I won't ever use Puppy the way you do, I respect that your uses for Puppy are quite as legitimate as mine, and if it works best for you that way, so be it!

That's the joy of Linux--make it what you want it to be, not what M$ thinks you should have!

PupGeek
Posts: 353
Joined: Sun 06 Sep 2009, 11:30

#17 Post by PupGeek »

exactly

Puppyt
Posts: 907
Joined: Fri 09 May 2008, 23:37
Location: Moorooka, Queensland
Contact:

#18 Post by Puppyt »

Bloody Brilliant, SilverPuppy.

Love this - just skimmed your posts with Sylvander and co (and have kinda been hovering around mikeb's posts on various other threads, taking notes etc - glad to see his hand in this). Your methods here appear to be just the the tonic for another related scenario - old hardware and a shortage of RAM causing problems with incomplete shutdowns. I've gone "Full" with my installations in a sub-64Mb setup, barebones 4.1.2, Ext2, but the 'structure' keeps unraveling and it bogs down after a few shutdowns... Thought I'd be noobie-smart and take the shortcut with "pfix=fsck" in the Grub menu.lst, but apparently that argument has been functionally removed from the 4.1 series and I don't have the patience now to spend on the other recommended workarounds. You've convinced me - I'm going retro (should've started there), and ext3. With your pet.

A real gem - Thankyou!

=====================================
SilverPuppy's Digital Diaper for Dilapidated Desktops

User avatar
mikeb
Posts: 11297
Joined: Thu 23 Nov 2006, 13:56

#19 Post by mikeb »

Thought I'd be noobie-smart and take the shortcut with "pfix=fsck" in the Grub menu.lst,
that only applies to frugal setups and only checks the pup_save and not the partition.

Hope this package helps....I have an old kayak and these fixes make for a reliable full install .

mike

PupGeek
Posts: 353
Joined: Sun 06 Sep 2009, 11:30

#20 Post by PupGeek »

yeah but couldn't you boot a live cd session and run fsck from there do scan your hard drive?

Post Reply