Hang in v0,9 deactivating porteus modules inserted during po

Please reproduce your error on a second machine before posting, and check the error by running without saved changes or extra modules (See FAQ No. 13, "How to report a bug"). For unstable Porteus versions (alpha, beta, rc) please use the relevant thread in our "Development" section.
Post Reply
Falcony
Full of knowledge
Full of knowledge
Posts: 235
Joined: 01 Jan 2011, 12:44
Location: Russia

Hang in v0,9 deactivating porteus modules inserted during po

Post#1 by Falcony » 16 Jan 2011, 05:49

If you after booting up you load additional modules and you load many and big modules and after that try to shutdown Porteus may hang at
"deactivating porteus modules inserted during porteus session"

Work aroung

Add in /etc/rc.d/rc.6 after rows

Code: Select all

echo "deactivating porteus modules inserted during porteus session"
for x in `grep devpts -A 500 /proc/mounts | grep .lzm | cut -d " " -f2`; do deactivate $x ; done
this row

Code: Select all

sync ; sync ; sync ; sleep 5

User avatar
fanthom
Site Admin
Site Admin
Posts: 4620
Joined: 28 Dec 2010, 02:42
Distribution: Porteus Kiosk
Location: Poland, currently - Cork, IE
Contact:

Re: Hang in v0,9 deactivating porteus modules inserted durin

Post#2 by fanthom » 16 Jan 2011, 09:58

@all
when LZM's are placed in /porteus/base or /porteus/modules (or /porteus/optional) then they are inserted during boot time and linuxrc creates /dev/loop* for each inside initrd.
When LZM's are activated by users after boot (during live session), then /dev/loop* are created inside the union and not initrd. Loops need to be freed up by deactivating of these modules, otherwise union will be 'busy' and not properly unmounted.
That's why i have added extra function to rc.6 - mentioned by Falcony.

@Falcony
I have seen this hang few times after activating 10-15 modules. A question - is a sleep 5 necessary in all cases? it will slow down the shutdown procedure a bit.

Also, when you activate 006-devel package then you wont be able to deactivate it (old bug present also in slax-6.1.2 ). I think it's about /etc/ld.so.conf or /etc/ld.so.cache which are present in devel module, so when you insert it - /sbin/ldconfig is run (have a look at very few last lines of /usr/bin/activate script)
Did you find a solution to this?

Last question - i can remember when on slax forum you had some troubles with conky and Imlib and you were proposing of forcing updates of shared library links after each module insertion. I have added 'ldconfig' to rc.S and was not able to reproduce this error on my PC. Do you know if conky/Imlib bug is still present on your machines?

Thanks
Please add [Solved] to your thread title if the solution was found.

Falcony
Full of knowledge
Full of knowledge
Posts: 235
Joined: 01 Jan 2011, 12:44
Location: Russia

Re: Hang in v0,9 deactivating porteus modules inserted durin

Post#3 by Falcony » 17 Jan 2011, 21:23


I have seen this hang few times after activating 10-15 modules. A question - is a sleep 5 necessary in all cases? it will slow down the shutdown procedure a bit.
It is average time - not solution for all possible big numbers modules in memory

May be sync && sync ; sleep 1 ; sync && sync will be also ok for most situation
But need to test

Also, when you activate 006-devel package then you wont be able to deactivate it (old bug present also in slax-6.1.2 ). I think it's about /etc/ld.so.conf or /etc/ld.so.cache which are present in devel module, so when you insert it - /sbin/ldconfig is run (have a look at very few last lines of /usr/bin/activate script)
Did you find a solution to this?
you are absolutely right it is of /etc/ld.so.conf

The solution have to be opposite activation code

in deactivate script something like this

Code: Select all

if [ -e "$MOD/etc/ld.so.conf" -o -e "$MOD/etc/ld.so.cache" ]; then
   echo "Module contains ld.so.conf or ld.so.cache, updating libs cache..."
 diff ld.so.conf /etc/ld.so.conf | grep ">" | sed "s|> ||g" >  /etc/ld.so.conf.new
rm -f /etc/ld.so.conf
mv  /etc/ld.so.conf.new  /etc/ld.so.conf
   /sbin/ldconfig
fi

But not sure - neet to check



Last question - i can remember when on slax forum you had some troubles with conky and Imlib and you were proposing of forcing updates of shared library links after each module insertion. I have added 'ldconfig' to rc.S and was not able to reproduce this error on my PC. Do you know if conky/Imlib bug is still present on your machines?
It was in 64-bit
Now I use 32
When I have test 64 bit I will check

Post Reply