| Author |
Message |
Patriot

Joined: 15 Jan 2009 Posts: 734
|
Posted: Tue 01 Jun 2010, 03:13 Post subject:
Re: Puppy 400 still has problems |
|
Hmmm .....
@don922
Please take a look at the amended code block above. I've added a sleep line to allow background stuffs to settle. Seems to help improve the remounting for puppy400 (only).
| don922 wrote: | | ..... I shutdown puppy400, booted into puppy412 and ran e2fsck with the following results: ..... |
Ah yes, you should reboot back into puppy400 for the auto fsck to run first .... If you rebooted into puppy412 then you need to do a manual fsck ... After the fsck is done (plus a reboot), then only you check for unmount stats ...
| don922 wrote: | On the next boot into puppy400 I saw the following in the boot message:
| Quote: | Setting up the Unionfs layered file system
Performing a switch_root to the new Unionfs file system |
I thought that the new menu.lst entry changed this.
Maybe puppy400 just won't cleanly unmount. |
The boot message is hardcoded. A mount status in a terminal will show that the union layer is using aufs.
Rgds
| Description |
Checking puppy 4.00 previous unmount savefile status |
| Filesize |
5.05 KB |
| Viewed |
1466 Time(s) |

|
|
|
Back to top
|
|
 |
don922
Joined: 19 Jan 2008 Posts: 337 Location: The land of 14" monitors
|
Posted: Tue 01 Jun 2010, 05:06 Post subject:
Puppy 400 must be jinxed |
|
I add the 2 lines for Puppy 400 /etc/rc.d/rc.shutdown, but I am still not getting it right.
I rebooted back into Puppy 400 and ran cat /initrd/tmp/chkret see the results below:
| Description |
|
| Filesize |
81.24 KB |
| Viewed |
1437 Time(s) |

|
_________________ Don -- Thailand

|
|
Back to top
|
|
 |
playdayz

Joined: 25 Apr 2008 Posts: 3704
|
Posted: Sat 05 Jun 2010, 10:42 Post subject:
|
|
| Code: | #v2.13 menno suggests this improvement...
STRAYPARTD="`cat /proc/swaps | grep "/dev/" | cut -f 1 -d " " | tr "\n" " "`"
for ONESTRAY in $STRAYPARTD
do
echo "Swapoff $ONESTRAY"
swapoff $ONESTRAY
done
sync
###should your code go here????
#rm -f /tmp/wmexitmode.txt
#note, there is a problem with unmounting, especially ntfs as it cannot be remounted
#ro (?). A ntfs part with ${DISTRO_FILE_PREFIX}save.2fs cannot be unmounted because of the mounted
#${DISTRO_FILE_PREFIX}save.2fs.
#at least, attempt to kill anything running in the ntfs partition...
#(i don't think anything will be, only /dev/loop1 (${DISTRO_FILE_PREFIX}save.2fs), but just in case)
ABSPUPHOME="" #100107
[ "$PUP_HOME" ] && ABSPUPHOME="/initrd${PUP_HOME}" #v2.16rc
[ ! "$ABSPUPHOME" ] && ABSPUPHOME="/initrd/mnt/dev_save" #v2.16rc
if [ "`busybox mount | grep "$ABSPUPHOME"`" != "" ];then
#BADPIDS="`fuser -v -m $ABSPUPHOME | grep -v --extended-regexp 'kernel|COMMAND|^$' | tr -s ' ' | cut -f 3 -d ' ' | tr '\n' ' '`"
BADPIDS="`fuser -m $ABSPUPHOME 2>/dev/null`" #100107
for ONEBAD in $BADPIDS
do
echo "Killing process $ONEBAD..."
kill $ONEBAD
sleep 1
kill -9 $ONEBAD 2>/dev/null
sync
done
killzombies #v3.99
fi
#v2.16rc try this too... SAVE_LAYER defined in /etc/rc.d/PUPSTATE...
if [ "$SAVE_LAYER" ];then
sync
SAVEDEV="`mount | grep "/initrd${SAVE_LAYER}" | cut -f 1 -d ' '`"
SAVEFS="`mount | grep "/initrd${SAVE_LAYER}" | cut -f 5 -d ' '`"
busybox mount -t $SAVEFS -o remount,ro $SAVEDEV /initrd${SAVE_LAYER} 2>/dev/null
umount-FULL -i -n -l /initrd/${SAVE_LAYER} 2>/dev/null #-l is lazy unmount.
fi
#v2.16 try one more thing for ntfs... lazy unmount, suggested by GuestToo...
MNTFUSE="`busybox mount | grep 'fuse' | head -n 1 | cut -f 3 -d ' '`"
if [ "$MNTFUSE" != "" ];then
#v2.17 hairywill found the -u is required with -z...
fusermount -z -u $MNTFUSE
#else
# if [ "$PDEV1" ];then #from PUPSTATE
# APATTERN="/dev/$PDEV1 "
# if [ "`busybox mount | grep "$APATTERN"`" != "" ];then
# #[ "$PUP_HOME" ] && busybox mount -t $DEV1FS -o remount,ro /dev/$PDEV1 /initrd${PUP_HOME}
# #...no, do not attempt ro remount, will prevent ${DISTRO_FILE_PREFIX}save clean shutdown if it didn't above.
# umount-FULL -i -n -l /dev/$PDEV1
# fi
# fi
fi
busybox umount -ar > /dev/null 2>&1
#the end# |
There is a report in this thread that your shutdown fix works for lupu. I am going to put it into a development release toward 5.1 named lucid-202. Here is the end of rc.shutdown. Does it seem that it should still go where you said? Thank you.
|
|
Back to top
|
|
 |
Patriot

Joined: 15 Jan 2009 Posts: 734
|
Posted: Sat 05 Jun 2010, 11:35 Post subject:
|
|
Hmmm .....
| playdayz wrote: | | ........ There is a report in this thread that your shutdown fix works for lupu. I am going to put it into a development release toward 5.1 named lucid-202. Here is the end of rc.shutdown. Does it seem that it should still go where you said? Thank you. |
I believe it should also work on quirky too ... ... and yes, the place you commented will do just fine ... You may want to take note that the shutdown fix here works fine for the savefiles only, not the partition it resides on (as pointed out earlier by jemimah).
Current progress:
Manual unmount of all the layers was already done. Putting it down into code started soon after but completion was delayed due to a borked partition. Don't ask me how 10GiB of my data got wiped out ..... already spent 3 days reconstructing the file tables ....
The complete-thru-the-layers-clean-unmount script is just about done and now it's going through some confidence testing on p412/p421/p431 ...
Rgds
|
|
Back to top
|
|
 |
Patriot

Joined: 15 Jan 2009 Posts: 734
|
Posted: Sun 06 Jun 2010, 13:27 Post subject:
|
|
Hmmm .....
I'm pleased to publish the complete-thru-the-layers clean-unmount-on-shutdowns script which can be found on the first post of this thread.
Also attached is busybox-1.16.1 static binary suitable as replacement for p412/p421/p431, if anyone's interested.
Rgds
|
|
Back to top
|
|
 |
jemimah

Joined: 26 Aug 2009 Posts: 4309 Location: Tampa, FL
|
Posted: Sun 06 Jun 2010, 14:44 Post subject:
|
|
I will test this shortly with Puppeee and Fluppy.
Now that we can cleanly unmount, do you know how to check if a filesystem is clean or not before mounting it? I'd like to implement fscks at startup, the way other distros do it - so if your computer crashes the fsck automatically runs.
Barry had a work around for this in Woof, but it's more complex than it needs to be since we can now unmount properly.
|
|
Back to top
|
|
 |
Patriot

Joined: 15 Jan 2009 Posts: 734
|
Posted: Mon 07 Jun 2010, 12:56 Post subject:
|
|
Hmmm .....
Hey there jemimah,
| jemimah wrote: | | ..... Now that we can cleanly unmount, do you know how to check if a filesystem is clean or not before mounting it? I'd like to implement fscks at startup, the way other distros do it - so if your computer crashes the fsck automatically runs. ..... |
I was thinking of adding dumpe2fs to initrd. It's quite easy to implement the auto-fsck thing ... there's just one other issue that needs fixing to have this work right: encrypted savefile fscks ... I don't use them but it'll be interesting to know where it borks ...
Anyway, a quick hack something like this should work for savefiles (right before the mounting routines):
| Code: | [ "$(dumpe2fs -h /dev/$PUPSAVEDEV 2>/dev/null | grep 'state:' | tr -s ' ' | cut -f3 -d' ')" = "clean" ] || PFSCK="yes"
#normal pup_save.2fs file. just mount it from where it is...
echo -n "Loading personal file $PUPSAVEFILE ($PUPSAVEDEV)..." > /dev/console
.....
.....
.....
losetup /dev/loop1 /mnt/dev_save${PUPSAVEFILE}
[ "$(dumpe2fs -h /dev/loop1 2>/dev/null | grep 'state:' | tr -s ' ' | cut -f3 -d' ')" = "clean" ] || PFSCK="yes"
fsck_func loop1 ext2 $PUPSAVEFILE #v3.01
mount -t ext2 -o noatime /dev/loop1 $CREATEPUPSAVE2FS |
(code updated for pdev1 and pupsave)
Yeah, there's a better way to do it .... but then, we're probably better off doing a total rewrite of the init ...
Rgds
|
|
Back to top
|
|
 |
gyro
Joined: 28 Oct 2008 Posts: 289 Location: Brisbane, Australia
|
Posted: Thu 10 Jun 2010, 04:43 Post subject:
|
|
Patriot,
Great, this is a giant step forward to improving the reliability of Puppy. I have often wondered how many hours have been wasted trying to fix problems that were in fact due to corrupted pupsave files due to continual failure to be cleanly unmounted.
I will try to produce a .pet and replacement initrd.gz including your fixes for Puppy 431, soon.
gyro
|
|
Back to top
|
|
 |
gyro
Joined: 28 Oct 2008 Posts: 289 Location: Brisbane, Australia
|
Posted: Thu 10 Jun 2010, 07:38 Post subject:
|
|
Patriot,
Thanks for this.
Just tested it in my Puppy 431, works great, pupsave.3fs is clean.
I have attached a replacement "initrd.gz" and an rc.shutdown-431.pet, to apply these mods to a standard Puppy 431.
(Obviously not tested a lot yet.)
gyro
Edit 15 Jun 2010: replaced pet, updated actual "rc.shutdown" to match Patriot's current version.
Edit 17 Jun 2010: replaced pet with updated one.
Edit 12 July 2010: updated pet to include Patriot's latest rc.shutdown
| Description |
Pet containing Patriot's code for puppy 431
|

Download |
| Filename |
rc.shutdown-431.pet |
| Filesize |
14.87 KB |
| Downloaded |
282 Time(s) |
| Description |
replacement initrd.gz containing Patriots mods for standard Puppy 431
|

Download |
| Filename |
initrd.gz |
| Filesize |
1.36 MB |
| Downloaded |
341 Time(s) |
Last edited by gyro on Mon 12 Jul 2010, 03:26; edited 3 times in total
|
|
Back to top
|
|
 |
Colonel Panic

Joined: 16 Sep 2006 Posts: 1224
|
Posted: Thu 10 Jun 2010, 08:17 Post subject:
|
|
Looks good, I'll check this out when I get home.
Cheers,
CP .
_________________ Pentium IV/3400, 2048 MB of RAM, 80 GB hard drive running Puppy Carolina 006 rc-2, Puppy Slacko 5.5, Manjaro 0.8.5 Cinnamon, Sparky 2.1, CrunchBang 11 "Waldorf," Salix 14 XFCE, OpenSUSE 12.3 KDE, Scientific 6.3 and DescentOS 4.04 beta.
|
|
Back to top
|
|
 |
gyro
Joined: 28 Oct 2008 Posts: 289 Location: Brisbane, Australia
|
Posted: Thu 10 Jun 2010, 10:00 Post subject:
|
|
Patriot,
The good news is that on 2 machines, it works perfectly.
The bad news is that on a third machine, I get error messages flashing past on shutdown. I think that it's complaining about "device is busy".
What is the easiest way to get a good look at these messages?
This machine is a laptop that with normal Puppy 431, won't poweroff, which I seem to remember as being caused by a module not unloading. So might be related.
(I don't often run Puppy on this machine, so haven't bothered tracking down the poweroff problem.)
gyro
|
|
Back to top
|
|
 |
Patriot

Joined: 15 Jan 2009 Posts: 734
|
Posted: Thu 10 Jun 2010, 10:49 Post subject:
|
|
Hmmm .....
| gyro wrote: | ..... I think that it's complaining about "device is busy".
What is the easiest way to get a good look at these messages?
This machine is a laptop that with normal Puppy 431, won't poweroff, ..... |
Many ways to do it. If you want to poke around then drop out to shell. Let's say you just want some info displayed, one simple example could be:
in rc.shutdown
| Code: | # Final Cleanup
echo '#!/bin/sh
exec 0<'$shtty'
exec 1>'$shtty' 2>&1
killall getty
# check your busybox if these applets are valid!
ls
mount
read -p "pausing ... " d
lsmod
ps
read -p "pausing ... " d
# Find and unmount union branches |
If at anytime a "device is busy" error msg comes out, something somewhere is still linked to the puppy rootfs (or savefile). You may want to add the above example to all your systems to compare for clues ...
Rgds
|
|
Back to top
|
|
 |
gyro
Joined: 28 Oct 2008 Posts: 289 Location: Brisbane, Australia
|
Posted: Fri 11 Jun 2010, 10:37 Post subject:
|
|
The problem with my third machine is solved.
By adding the following code | Code: | ps
echo "pausing ..."
sleep 30 | into "rc.shutdown" I discovered that "dhcpcd" was still running. Once I added code to ensure that "dhcpcd" is killed, the shutdown worked properly.
I didn't change any of Patriot's code, I just added the file "/etc/init.d/net-cleanup", containing the following script: | Code: | #!/bin/sh
#
# stop - kill dhcpcd.
#
case $1 in
start)
;;
stop)
ZPID=`pidof dhcpcd`
[ "$ZPID" ] && kill $ZPID
;;
*)
exit 1
;;
esac
exit 0 |
gyro
|
|
Back to top
|
|
 |
nooby
Joined: 29 Jun 2008 Posts: 9382 Location: SwedenEurope
|
Posted: Fri 11 Jun 2010, 11:00 Post subject:
|
|
I have tried to follow this thread but it is too advanced for my level.
1. Can the knowledge you have learned be used to after the fact know if it did shut down cleanly or not? I mean is there some log one can read at next boot that show if it did left things going that one fail to notice like graphic ard draining the laptop battery or LAN card that doesn't light up a LED or anything to indicate them draining the battery?
2. Could the knowledge be used to see what fails when activating Spotify in Wine for Lupu5.00 shut down in a non proper way. One need to hard reboot to get out of the hanged thing.
I mean is there any way to know what goes on when all get black. I mean looking in some log that indicate something unexpected was going on at shutdown?
_________________
I'm a noob so I use Google Search of Puppy Forum
|
|
Back to top
|
|
 |
Patriot

Joined: 15 Jan 2009 Posts: 734
|
Posted: Fri 11 Jun 2010, 11:21 Post subject:
|
|
Hmmm .....
| nooby wrote: | | I have tried to follow this thread but it is too advanced for my level. ..... |
Answer 1: Yes. No, no logs.
Answer 2: No. This has nothing to do with spotify nor wine.
There will be no logs. Any log files still opens during critical shutdown will prevent a clean shutdown. While possible to have a logging process, it makes clean shutdowns much more complicated than it needs to be ... IMHO, it's not worth the effort ...
Rgds
|
|
Back to top
|
|
 |
|