Page 1 of 2

4.1full install does not boot after power loss (USB related)

Posted: Mon 22 Dec 2008, 20:49
by viperpiper
Hi,

+ Puppy 4.1.0 full install
+ USB Keyboard and mouse (PS2 not an option)
+ Was running fine for a few days
+ The machine suffered power loss when puppy was running and now does not boot - hangs with"#" after doing the USB 1 2 3..10 and does not accept any keyboard input
+ I can boot puppy from CD, mount my HD and view the files/folders of my puppy install, but booting from the HD always results in the hang. Note that when booting from CD the "Waiting for modules to complete loading" runs quicker - it does "usb 1" then is done.

I've found loads of useful information in other threads, particularly with regard to setting up journaling to try and prevent this sort of thing happening again (which I will do).

In the meantime my problem remains trying to get the system to boot again. I've tried running fsck on the file system (after booting from CD) but that has not solved the problem.

Having a look at the bit in the /etc/rc.d/rc.sysinit where it does the "Waitingfor modules to complete loading" bit the while loop exits after 10 iterations. So when I see "usb 1 2 3 4 5 6 7 8 9 10" what that really means is that the usb module did not load ?

One other thing I notice is that when trying to boot from HD I get this message:

Code: Select all

/etc/rc.d/rc.sysinit: line 23: /etc/rc.d/PUPSTATE: Read-only filesystem
I'm not sure if this is normal or a symptom.

Any help would be much appreciated!

Posted: Sat 27 Dec 2008, 18:03
by viperpiper
This problem is repeatable with 4.1.2:

+ Clean install of 4.1.2 (formatted HDD)
+ Turned on journaling (kernel and fstab)
+ Restarted Puppy a few times - no problems.
+ Deliberately caused a power loss
+ Puppy will now not boot with the same problem.The first boot after power loss I got a screen saying a serial mouse was detected, but was unable to do anything on this screen as the keyboard was not working. Powercycled again and now puppy just hangs in the same place as before. The only difference is the "Waitingfor modules to complete loading" now does: "1 2 3 4 5 6 7 8 9 10 usb-storage 11 12 13 14 15"

Posted: Sat 27 Dec 2008, 19:48
by Aitch
I may be talking rubbish here, and this is a hunch, but have you tried booting with

Puppy pfix=purge

at the 5 second bootscreen from a live CD boot

I think it should still pick up the filesystem from the hard drive, ..... but may be wrong

pfix=purge is the filesystem repair parameter, AFAIK

Aitch :)

Posted: Sat 27 Dec 2008, 21:51
by viperpiper
Hi Aitch,

Thanks for the suggestion. I gave pfix=purge a try, and as with a normal boot from CD it boots fine, but when I restart and try to boot from the hard drive again the same problem occurs.

Posted: Sun 28 Dec 2008, 01:51
by d4p
I guess you need to delete Oldmousedevice and Mousedevice files inside etc folder. Hope it will work after rebooting.

Posted: Sun 28 Dec 2008, 11:13
by viperpiper
Hi d4p,

Thanks for the suggestion but deleting Oldmousedevice and Mousedevice did not help. The only difference is that after deleting them I get to the Mouse configuration screen during startup but as before am unable to do anything in that screen because the keyboard does not work.

I think the problem is related to the modules not being loaded properly, but don't know enough about how Puppy works to fix this.

Does anyone know what actions Puppy takes when doing an ordered shutdown?

Posted: Sun 28 Dec 2008, 17:26
by viperpiper
I had a look at the shutdown scripts looking for the difference between a clean shutdown and an unexpected poweroff. I noticed that one of the things the shutdown script does is to clean up some temporary files. I booted from CD and did this manually, and now I am able to boot :D

To cope with this in the future (as this is repeatable every time I have a powerloss) I added the following to my /etc/rc.sysini script just after the line
ln -s /proc/mounts /etc/mtab
:

Code: Select all

#If we were not shutdown cleanly, try and recover
if [ -f /tmp/RUNNING ];then
 echo -n "(Cleaning up after unclean shutdown)" >/dev/console
 rm -f /var/log/X*
 rm -rf /tmp/*
 rm -f /var/lock/LCK*
 rm -f /var/run/*.pid
 rm -rf /root/tmp 2> /dev/null
 rm -rf /root/.thumbnails/* 2> /dev/null
fi

#create a file in tmp that should be deleted on a clean shutdown
echo 'this file is deleted during a clean shutdown' > /tmp/RUNNING
My puppy linux box will now boot after a power loss without me having to boot from CD to fix things.

I was wondering if anyone had a better way of doing this?
I guess for some people it might be worth copying the temp files to another location before deleting them?

Posted: Sun 28 Dec 2008, 23:27
by d4p
I dont have a better way, it will work if you replace with ps2 keyboard.

Posted: Mon 29 Dec 2008, 03:43
by d4p
upgrade install is possible also

Posted: Mon 12 Jan 2009, 23:38
by bambuko
viperpiper wrote:. . . I noticed that one of the things the shutdown script does is to clean up some temporary files. I booted from CD and did this manually, and now I am able to boot :D. . .
faced with the same problem in 4.1.2 I have found your posting and did exactly as you recommend - deleted all the contents of /tmp/ folder
and this has solved the problem - I was able to restart with no problem
big THANK YOU :D

Posted: Thu 05 Feb 2009, 03:29
by edoc
Just booted with pupy pfix=ram and deleted the entire content of /tmp then rebooted, same failure.

I have previously run Clean and Purge and replaced the Frugal system files from a known-good iso CD

What else might I try, please?

Posted: Thu 05 Feb 2009, 04:31
by edoc
viperpiper wrote:I had a look at the shutdown scripts looking for the difference between a clean shutdown and an unexpected poweroff. I noticed that one of the things the shutdown script does is to clean up some temporary files. I booted from CD and did this manually, and now I am able to boot :D

To cope with this in the future (as this is repeatable every time I have a powerloss) I added the following to my /etc/rc.sysini script just after the line
ln -s /proc/mounts /etc/mtab
:

Code: Select all

#If we were not shutdown cleanly, try and recover
if [ -f /tmp/RUNNING ];then
 echo -n "(Cleaning up after unclean shutdown)" >/dev/console
 rm -f /var/log/X*
 rm -rf /tmp/*
 rm -f /var/lock/LCK*
 rm -f /var/run/*.pid
 rm -rf /root/tmp 2> /dev/null
 rm -rf /root/.thumbnails/* 2> /dev/null
fi

#create a file in tmp that should be deleted on a clean shutdown
echo 'this file is deleted during a clean shutdown' > /tmp/RUNNING
My puppy linux box will now boot after a power loss without me having to boot from CD to fix things.

I was wondering if anyone had a better way of doing this?
I guess for some people it might be worth copying the temp files to another location before deleting them?
Did thi manually and did the edit as well, should I have let it create a new pup_save on reboot?

Still getting the failure at "Setting up the layered filesystem"

That is followed by "Bumping the last lines of /tmp/bootinit.log" and then 11 lines of stuff then

Pausing for 60 seconds ...

Then "Performing a 'switch_root' to the layered filesystem....kernel panic - not syncing: Attempted a kill init!

Then it locks up everything.

Posted: Thu 05 Feb 2009, 14:57
by mikeb
Edoc you have a frugal setup so this fix probably doesn't apply but I have a HD install which does exactly this so I'm off to test the fix...should be incorporated into puppy :)

regards

mike

Posted: Fri 06 Feb 2009, 14:22
by viperpiper
Hi Edoc,

Sorry, but looks like your problem is different - as mikeb said I suspect that my particular problem and solution only apply to the full setup. I would suggest creating a new topic detailing the exact problem and error messages shown.

Posted: Fri 06 Feb 2009, 14:54
by mikeb
Excellent...tested several times and recovered just fine plus no longer losing alsa this way....wonder if that's related...perhaps one could narrow down what exactly causes the lockup.

nice find anyway..appreciated

regards

mike

Posted: Fri 06 Feb 2009, 15:29
by edoc
I guess that I can reformat the HDD and start truly fresh and in that way begin to eliminate the hardware as the source of the problem.

I am guessing that BIOS is not involved as this appears to be well after BIOS in the boot process.

Posted: Mon 09 Feb 2009, 02:31
by Stevo954
I don't know what causes this problem, but I know how to get the computer booted up again. At the prompt type startx, which will bring up the desktop, but you will not have USB or network capabilities. Go to the menu and reboot the system. At this point everything should be fine. This at least works for me, hopefully for you too. Running puppy 4.1, if that makes any difference.

Posted: Mon 09 Feb 2009, 02:58
by edoc
Do you mean at the prompt for the Puppy boot disk or some other prompt, please?

I tried it at the Puppy prompt and got an error that such a kernel was not available - then it booted from the CD.

Posted: Mon 09 Feb 2009, 04:24
by vtpup
Replace your vmlinuz and intird.gz with the ones on the CD.

Also be sure that your Grub is pointing to the right one of these if you have several in puplet directories, and one outside of them. Look at your menu.lst carefully for typos.

Initrd.gz and vmlinuz must be the correct ones for your sfs version. Unfortunately they all have the same name.

I'm going to guess your vmlinuz is bad or wrong or not pointed to correctly.

Posted: Mon 09 Feb 2009, 12:11
by SmartCyber

Code: Select all

#If we were not shutdown cleanly, try and recover 
if [ -f /tmp/RUNNING ];then 
 echo -n "(Cleaning up after unclean shutdown)" >/dev/console 
 rm -f /var/log/X* 
 rm -rf /tmp/* 
 rm -f /var/lock/LCK* 
 rm -f /var/run/*.pid 
 rm -rf /root/tmp 2> /dev/null 
 rm -rf /root/.thumbnails/* 2> /dev/null 
fi 

#create a file in tmp that should be deleted on a clean shutdown 
echo 'this file is deleted during a clean shutdown' > /tmp/RUNNING
This seems to solve all my problems but one thing missing I don't see RUNNING in /tmp anyone?

SmartCyber