Error messages when loading persistant image

takayama!

Thanks for jumping in with the answer. So maybe the fuser command wasn't so crazy after all... :)
I had been meaning to try and kill pump and see how that worked... but it slipped my mind.
Then I saw your post... and killed it, and rebooted. Bingo! No error so you are indeed correct in this.
Thank You!

Btw, I would like to have an option to make the knoppix.img a ext3 filesystem... and noticed that ext2 is hardcoded in the scripts.
I had the knoppix.img on an ext3 partition... but the journal did not fix this problem. For example... hdb6 is ext3. Knoppix.img resides on hdb6... in the root. I kept getting those errors on bootup and wondered why if hdb6 was journaled.

Bug fixed.

What I am curious about is this. Do the great majority of Knoppix users out there have these error messages and just ignore them? Or are there just 2 or 3 of us that have these messages?

About what all users get and do about it... I can say this. I happened no matter how I had mine setup. So I would guess everybody got the errors. But they also could not see any loss of functionality caused by it.

In /etc/init.d/knoppix-reboot at line 53 I changed mine to:
BLACKLIST="cardmgr dhcpcd dhclient init aufs* *mount portmap udevd ntfs-3g"

and now no errors.

I am also going to point out that it shuts down much faster too.
Cheers!

MOON:

I have been having this problem for as long as I can remember and have just ignored it, but I knew it was an issue. Lately it's become more irritating and hence I stumbled on this thread.

I would be a great convenience if this worked correctly. If anyone comes across a patch/update to correct this, please share! :D

In the meantime I'll try johnrw's BLACKLIST trick... (Thanks)

Hello all,

I've been meaning to get back to this but I haven't had a chance until now. johnrw and takayama did a great job of getting to the bottom of this issue. John's BLACKLIST fix does work in getting rid of the errors. The only problem with this is that pump is required if any NFS filesystems are to be unmounted. If pump is removed from the BLACKLIST, it will be killed before the NFS filesystems are unmounted. If NFS filesystems are not used, removing pump from the BLACKLIST will work just fine. However I do use NFS sometimes to exchange files between my two computers. My solution was to insert the pump-killing code after the NFS filesystems are unmounted. The code that I came up with is at the end of this message.

The only thing I am not entirely sure of is how much time to allow between the sending of the kill signal and when it can be assumed that the process (pump) is killed. In the code below, I allowed 1 second however this was entirely arbitrary. Maybe on a very slow computer it would not be enough time. If in doubt, this time can be increased. If anyone has any comments on how the timing of the kill command should be handled, it would be greatly appreciated.

If /etc/init.d/knoppix-halt has not been modified the new code should be inserted at line 199. Before any changes are made, the code around line 199 looks like this:

Code:

---

esac
done

# Clean up all mount references carefully, except for /cdrom and /KNOPPIX

---

After the new code is added it looks like this: ( I hope no unprintable characters got into this as a result of pasting it here)

Code:

---

esac
done

# Kill pump here so umounts are clean.
# Get pump's process id from ps for use in kill command.
ps | gawk '$4~/pump/{print $1 }' | ( read pumpPID      #Closing parenthesis comes later
if [ -n "$pumpPID" ]
then
 kill -15 $pumpPID 2>/dev/null    # Send TERM signal
 sleep 1                          # Sleep for 1 second
 kill -9 $pumpPID 2>/dev/null    # Send KILL signal
 sleep 1                          # Sleep for 1 second
fi
)        # Don't forget to put closing parenthesis here

# Clean up all mount references carefully, except for /cdrom and /KNOPPIX

---

Regards,
Bill

Bill... why not make a while loop to be sure?
This slight change would make sure pump is dead(I hope)

# Kill pump here so umounts are clean.
# Get pump's process id from ps for use in kill command.
pumpkill() {
ps | gawk '$4~/pump/{print $1 }' | ( read pumpPID #Closing parenthesis comes later
if [ -n "$pumpPID" ]
then
kill -15 $pumpPID 2>/dev/null # Send TERM signal
sleep 1 # Sleep for 1 second
kill -9 $pumpPID 2>/dev/null # Send KILL signal
sleep 1 # Sleep for 1 second
fi
) # Don't forget to put closing parenthesis here
} # and the closing brace

while [[ ! -z `ps -A | grep pump` ]] ; do
pumpkill
done

I think your way is better than the BLACKLIST hack... I haven't even used NFS yet.
But I have been enjoying seeing those clean image mounting since we started to resolve ourselves to fixing this bug.

cheers

Hi John,

I was thinking about a loop but my reasoning is this. If a loop is used and if the kill signal is sent to pump and something abnormal happens and pump refuses to kill itself, the loop will continue indefinitely and the system would hang while shutting down. Maybe it's best to just give the kill command(s) once and hope for the best. If pump gets killed, all well and good - if it doesn't, I don't think there is anything that can be done about it anyway so maybe it's best to just continue with the shutdown script. I notice that that is what the author of knoppix-halt did when killing the other processes earlier in the script. I've done a lot of Windows programming but I am kind of new to Linux and I certainly don't know about the nuances of shutting down a Linux system so I am far from an expert on this. Any comments would be appreciated.

Later,
Bill

Well you're right again Bill...
I am lazy. Here is a infinite loopkiller version... lol
I'm sure you knew that too... but for

LMAX=2
LCOUNT=0

while [[ ! -z `ps -A | grep pump` ]] || [ "$LCOUNT" -le "$LMAX" ] ; do
pumpkill
LCOUNT=$(($LCOUNT+1))
done

Otoh... I guess we could just upgrade pump in the persistent $home.
Did anyone trythat? Ok... I will see if a new version fixes it.

http://bugs.debian.org/cgi-bin/pkgre...;dist=unstable
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=261803

Quote:

---

Package: pump
Version: 0.8.19-2
Severity: normal


unlike dhcp3-client (dhclient3) and its usage, pump continues to run
during shutdown even after everything else has been killed.

consequently, /var and /usr cannot be unmounted, because pump is still
using those partitions (even though lsof /var does not think so).

luckily, dhcp3-client _does_ work properly!

---

Well this is an old bug... 3 years and 220 days old; Modified 3 years and 220 days ago.

Hi Bill,

Ok... I installed the latest pump... and put the knoppix-halt script back to the default actions...
and got errors on reboot.

So instead of loops and whatnot... down around line 170 I killed pump with it's own kill daemon option
after the last network command I could see. Comments in the file seem to indicate a 'bring network down'
procedure was envisioned but not implemented formally. So just try this out with some nfs stuff.


# Unmount network filesystems first before shutting down network
NFSBUSY=""
NETMOUNTS="$(gawk '{if($1~/:/){print $2}}' /proc/mounts 2>/dev/null)"
if [ -n "$NETMOUNTS" ]; then
echo "${BLUE}Unmounting network filesystems.${NORMAL}"
# Preload programs we need later, in case we lose the network too early
swapoff --help >/dev/null 2>&1
losetup --help >/dev/null 2>&1
mount --help >/dev/null 2>&1
umount --help >/dev/null 2>&1
gawk --help >/dev/null 2>&1
tac --help >/dev/null 2>&1
# Umount NFS (if not busy)
umount -t nfs,nfs4,smbfs -alv 2>/dev/null
fi
# see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=261803 for why this is needed here.
# When knoppix-persistent home feature is used... pump prevents their umount from succeeding.
# unless killed explicitly.
pump -k

# Umount devpts early (otherwise UNIONFS may stay busy)
umount -t devpts -a 2>/dev/null

# UNIONFS umount
if [ "$(ls -l1d /lib | gawk '{print $NF}')" = "/UNIONFS/lib" ]
then

cheers

If it works for you... then I'll post this as a bug to fix on the debian-knoppix list with link to this topic.