How to cleanly unmount your filesystem on shutdowns

[jemimah]

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.

[Patriot]

Hmmm .....

Hey there jemimah,

..... 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: Select all

[ "$(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

[gyro]

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

[gyro]

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

[Colonel Panic]

Looks good, I'll check this out when I get home.

Cheers,

CP .

[gyro]

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

[Patriot]

Hmmm .....

..... 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: Select all

# 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

[gyro]

The problem with my third machine is solved.

By adding the following code

Code: Select all

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: Select all

#!/bin/sh
#
# stop - kill dhcpcd.
#
case $1 in
	start)
		;;

	stop)
		ZPID=`pidof dhcpcd`
		[ "$ZPID" ] && kill $ZPID 
		;;

	*)
		exit 1
		;;
esac

exit 0

gyro

[nooby]

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?

[Patriot]

Hmmm .....

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

[nooby]

Thanks,

so when you say clean you mean things one know by LED still being on or battery draining being apparent or other such things? Okay such is a good thing too.

I wish we had your knowledge on the reboot thread.
http://murga-linux.com/puppy/viewtopic.php?t=56314

[Patriot]

Hmmm .....

The problem with my third machine is solved. .....

Thanks and appreciation goes to gyro for highlighting, determining and resolving his issue. I have noted down this possibility that could occur elsewhere and am currently testing a minor adjustment to cater for such condition.

Update: A fix has already been added to the rc.shutdown code block on the first page.


Rgds

[Patriot]

Hmmm .....

I've discovered a condition that prevents clean unmount on shutdowns from the command line. If one drops down to the command line (CLI), issuing a subsequent reboot/poweroff/xwin command causes bash to create a new process for these commands. This will result in a failure to detach from the puppy file system during shutdowns.

The correct execution of reboot/poweroff/xwin on the CLI requires the command exec to be used, ex:
# exec reboot

For a transparent operation, I'm recommending (more like implementing) minor changes to the reboot & poweroff scripts with additional aliases to the profile and .bashrc script. The reboot/poweroff/xwin commands will now be aliased to the proper exec statement on-the-fly.

These changes also attempts a quick fix to the running-X-from-shell issue as was described here and here.


Rgds

[nooby]

Thanks Patriot!






Hope I don't derail your thread too much. Is that finding that one should do exec reboot at the cli terminal console apply-able to the problem with the failure to reboot on the Toshiba Satellite in the other thread?

I mean maybe some hardware are very sensitive to how it is done. The sequence of things could be important for doing a reboot.

[Patriot]

Hmmm .....

Hope I don't derail your thread too much. Is that finding that one should do exec reboot at the cli terminal console apply-able to the problem with the failure to reboot on the Toshiba Satellite in the other thread? .....

No, it is not applicable. That toshiba thingy is not related. The one suggestion that I posted earlier works for an acquaintance's toshiba satellite a couple of years back. I believe it's most likely that the acpi bios misses on some hardware stuffs on shutdowns.

Rgds

[gyro]

A fix has already been added to the rc.shutdown code block on the first page.

Patriot's updated "rc.shutdown" solves my problem. I have now deleted the "net-cleanup" script, mentioned in my previous message.

NOTE: my tests are done on frugal installs of Puppy 431, in pupmode 12 and 13, using ext3 and ext2 pupsave files.

gyro

[gyro]

Patriot,

I just tried a fresh frugal install, no pupsave, pupmode 5.
On shutdown, after creating pupsave file, I got error messages, looked like "Device busy" on "/nroot".

I did this test booting puppy 431(+ your full rc.shutdown) off a vfat formatted SD card, so it ended up as pupmode13.

In pupmode13 every thing appeared to work, no error messages, so I kept going and connected my eth0 to the network, on shutdown still no errors. But when I checked the pupsave.2fs with fsck I get

Code: Select all

/mnt/sdc1/pupsave.2fs was not cleanly unmounted, check forced.

gyro

[Patriot]

Hmmm .....

Thanks for the report. I'll look into this soon ...

Rgds

[gyro]

Patriot,

I'm not sure if this is good news or bad news; I found our why "dhcpcd" was still running on my problem machine, but not on my good machines. Once this was 'fixed', I had no problems in pupmode12, even with the old version without "fuser".

Why did "dhcpcd" continue running on my problem machine?
In Puppy 431, there's a line in "rc.network"

Code: Select all

		ethtool $INTERFACE | grep -Fq 'Wake-on: g' && continue

that results in "dhcpcd" not being shutdown if "ethtool" indicates "wake-on-lan" is active.
On my good machines, "ethtool" does not indicate "wake-on-lan" as active on eth0. On my problem machine "ethtool" does indicate "wake-on-lan" as active on eth0, even though it is disabled in the bios.
Solution: Comment out that line in "rc.shutdown", or do

Code: Select all

ethtool -s eth0 wol d

before shutdown. Now "dhcpcd" gets shutdown when it should.

gyro

[Patriot]

Hmmm .....

@gyro,

I've tested pupmode=5 fresh setup on a usbflash but I could not duplicate your results. In pupmode=5, the unmount code blocks have no effect on the savefile. The savefile creation is done much earlier and unmounted immediately after completion. The savefile is clean at this stage.

The error messages during pupmode=5 shutdowns were harmless as the savefile partition is also unaffected (if any, it is unmounted earlier before swapoff). Anyway, I've already adjusted the unmount code block that should cater for fresh setups and eliminate those error messages ...

.....In Puppy 431, there's a line in "rc.network"

Code: Select all

		ethtool $INTERFACE | grep -Fq 'Wake-on: g' && continue

that results in "dhcpcd" not being shutdown if "ethtool" indicates "wake-on-lan" is active. .....

There could be a number of reasons why nic wol remains active. It could be that the nic eeprom defaults wol as enabled or whatever. At any rate, my tests with eth0 wol enabled shows that clean shutdowns is done correctly since the recent 11-June update.

Kindly check, compare and test my latest 15-June update. Also please ensure that your initrd.gz contains the init startup from tmpfs patch.


Rgds