Slacko 5.4 - FINAL 2 Dec 2012

News, happenings
Message
Author
User avatar
01micko
Posts: 8741
Joined: Sat 11 Oct 2008, 13:39
Location: qld
Contact:

#621 Post by 01micko »

----------------------------------------------------------------------------------------------

problem solved thanks to rcrsn51

See discussion further down page. This bug would likely affect many puppy versions.

----------------------------------------------------------------------------------------------
Jades wrote:Tested non-PAE Opera Slacko 5.3.7.7 on one of work's old Dell Optiplex GX270s. Pentium 4, 2.1GHz (IIRC) and 1GB of RAM. Tried to create a save file on the machine's NTFS-formatted hard drive, rebooted and encountered the same missing icons and config problem as I see on the Pentium D at home.
Bingo! Found the bug, but need to find an elegant fix... :shock:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Ok, some more on this situation and maybe some of our more knowledgable can lend a hand....

THIS line in /etc/rc.d/rc.shutdown is causing the issue..@line 225

Code: Select all

umount -a -t cifs,smbfs,nfs,sshfs #120220
Why on earth would that umount ntfs? IDK, but it does. Perhaps a bug in the ntfs-3g driver.

Now, if I had my network connected and some network filesystem mounted (didn't seem to matter which) then no bug, all good, save to ntfs is fine. Probably why I never saw the bug. So I got sick of connecting and didn't and could reproduce the bug on my old laptop. IDK if the speed of the machine made any difference. NOTE the date of the change (2012-Feb-20). Slacko-533 would have had the bug but previous versions not. Comment that line and no bug.

So, the question to you who are smarter coders is.. how do we ensure clean unmount of network type filesystems without compromising ntfs?

Here's the code with preceding comments..

Code: Select all

##111107 ldolse: unmount network shares before taking down the network
##(see 111106, need to do it sooner, but 111106 will remount read-only if failed to umount here)
#for MOUNTPOINT in `mount | grep '^//' | cut -d  ' ' -f 3 | tr '\n' ' '`
#do
# umount -f $MOUNTPOINT
#done 
##120219 hmmm, zekebaby reports above does not work for him. i looked up an ex: mount -t nfs boffo.clowns.org:/home/bozo /mnt/bozo
##so this is zekebaby's patch: (see http://murga-linux.com/puppy/viewtopic.php?p=605451#605451)
#for MOUNTPOINT in `mount | grep ':' | cut -d  ' ' -f 3 | tr '\n' ' '`
#do
#  umount -f $MOUNTPOINT
#done
umount -a -t cifs,smbfs,nfs,sshfs #120220
Is zekebaby's patch better? (probably what I'll go with if no better solution is brought forward).

I'd be interested to know if the same fails on other pups. TBH, I reckon saving to ntfs is a bad idea, but it's supported in woof so that's the way it is. Interestingly, it doesn't fail if you use noryb009's windows installer (there is one for 533).

NOTE: there seem to be a lot of potential bugs in rc.shutdown. We see it all the time ..."My pupppy won't shut down!" . There is one particular block of code that brings down the network interface before releasing the the IP lease. Well, that isn't the problem here but it could be affecting someone.

I'll attach, just for interest's sake, my crazy debugging routines added to the relevant files.. most commented with "Jades debug". :lol:

Guess I'm having fun eh? :lol:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -


Here's my crazy log..

Code: Select all

START DEBUG
/dev/sda2 /mnt/sda2 fuseblk rw,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096 0 0
PUPMODE=128
SAVEPART='sda2'
SAVEFS='ntfs'
PUPSAVE='sda2,ntfs,/slackosave-yes.2fs'
SAVEFILE='/slackosave-yes.2fs'
NAMEONLY='slackosave-yes.2fs'
SAVEPATH='/'
MYPASSWORD=''
SFEXT='2fs'
xPDEV='sr0'
xDEVFS='iso9660'
SMNTPT='/mnt/sda2'
CRYPTO=''
expBOOTDRV=''
save path = /mnt/sda2
Executing /etc/rc.d/rc.shutdown...
PUPMODE is 5
Killing X and all X apps...
Check breakage 1
AH HA! There's the bastard
Check breakage 2
The 5 is pupmode
CHECKPOINT 1: Check if ntfs is mounted rw
/dev/sda2 /mnt/sda2 fuseblk rw,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096 0 0
CHECKPOINT 2: Check if variables file exists
PUPMODE=128
SAVEPART='sda2'
SAVEFS='ntfs'
PUPSAVE='sda2,ntfs,/slackosave-yes.2fs'
SAVEFILE='/slackosave-yes.2fs'
NAMEONLY='slackosave-yes.2fs'
SAVEPATH='/'
MYPASSWORD=''
SFEXT='2fs'
xPDEV='sr0'
xDEVFS='iso9660'
SMNTPT='/mnt/sda2'
CRYPTO=''
expBOOTDRV=''
DEBUG log: 

Saving session to /slackosave-yes.2fs file on sda2 partition...
/proc/mounts BEFORE mounting /slackosave-yes.2fs
rootfs / rootfs rw,relatime 0 0
tmpfs /initrd/pup_rw tmpfs rw,relatime,size=665840k 0 0
tmpfs /initrd/mnt/tmpfs tmpfs rw,relatime,size=154692k 0 0
/dev/loop0 /initrd/pup_ro2 squashfs ro,noatime 0 0
unionfs / aufs rw,relatime,si=54be455e 0 0
none /proc proc rw,relatime 0 0
none /dev/pts devpts rw,relatime,gid=2,mode=620 0 0
none /sys sysfs rw,relatime 0 0
shmfs /dev/shm tmpfs rw,relatime,size=86552k 0 0
none /proc/bus/usb usbfs rw,relatime 0 0
/dev/sda2 /mnt/sda2 fuseblk rw,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096 0 0
PUPMODE=128
SAVEPART='sda2'
SAVEFS='ntfs'
PUPSAVE='sda2,ntfs,/slackosave-yes.2fs'
SAVEFILE='/slackosave-yes.2fs'
NAMEONLY='slackosave-yes.2fs'
SAVEPATH='/'
MYPASSWORD=''
SFEXT='2fs'
xPDEV='sr0'
xDEVFS='iso9660'
SMNTPT='/mnt/sda2'
CRYPTO=''
expBOOTDRV=''
Mounting /slackosave-yes.2fs...
added sleep 1 (clutching straws)
checking what got mounted, hopefully /mnt/sda2/slackosave-yes.2fs
/proc/mounts AFTER (attempting) mounting /slackosave-yes.2fs
rootfs / rootfs rw,relatime 0 0
tmpfs /initrd/pup_rw tmpfs rw,relatime,size=665840k 0 0
tmpfs /initrd/mnt/tmpfs tmpfs rw,relatime,size=154692k 0 0
/dev/loop0 /initrd/pup_ro2 squashfs ro,noatime 0 0
unionfs / aufs rw,relatime,si=54be455e 0 0
none /proc proc rw,relatime 0 0
none /dev/pts devpts rw,relatime,gid=2,mode=620 0 0
none /sys sysfs rw,relatime 0 0
shmfs /dev/shm tmpfs rw,relatime,size=86552k 0 0
none /proc/bus/usb usbfs rw,relatime 0 0
/dev/sda2 /mnt/sda2 fuseblk rw,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096 0 0
/dev/loop1 /tmp/save1stpup ext2 rw,noatime,errors=continue,user_xattr,acl 0 0
RDIRS=/initrd/pup_rw/root /initrd/pup_rw/var /initrd/pup_rw/usr /initrd/pup_rw/initrd /initrd/pup_rw/etc /initrd/pup_rw/lib

END DEBUG

Attachments
my_crazy_debug.tar.bz2
oops, attachment didn't take..

Note, adjusted are /usr/sbin/shutdownconfig and /etc/rc.d/rc.shutdown.
Use at own risk. For perusal only.
(20.6 KiB) Downloaded 688 times
Last edited by 01micko on Sat 24 Nov 2012, 21:13, edited 3 times in total.
Puppy Linux Blog - contact me for access

User avatar
zigbert
Posts: 6621
Joined: Wed 29 Mar 2006, 18:13
Location: Valåmoen, Norway
Contact:

#622 Post by zigbert »

pMusic 3.0.1

User avatar
01micko
Posts: 8741
Joined: Sat 11 Oct 2008, 13:39
Location: qld
Contact:

#623 Post by 01micko »

zigbert wrote:pMusic 3.0.1
Ah.. the pieces are coming together :)

Thank you!
Puppy Linux Blog - contact me for access

User avatar
pemasu
Posts: 5474
Joined: Wed 08 Jul 2009, 12:26
Location: Finland

#624 Post by pemasu »

http://bkhome.org/blog/?viewDetailed=02697

Check shinobar`s solution, would it help:

Code: Select all

#120203 pemasu and shinobar: space in smb or cifs share causes hanging in shutdown
for T in cifs smbfs nfs sshfs; do
  umount -a -t $T
done

User avatar
rcrsn51
Posts: 13096
Joined: Tue 05 Sep 2006, 13:50
Location: Stratford, Ontario

#625 Post by rcrsn51 »

01micko wrote:THIS line in /etc/rc.d/rc.shutdown is causing the issue..@line 225

Code: Select all

umount -a -t cifs,smbfs,nfs,sshfs #120220
Change this to "umount-FULL". In my tests with an NTFS-formatted flash drive, it solved the problem.

BTW, this problem with "umount -a -t cifs" conflicting with NTFS goes back at least as far as Quirky. It doesn't affect other filesystems.

User avatar
01micko
Posts: 8741
Joined: Sat 11 Oct 2008, 13:39
Location: qld
Contact:

#626 Post by 01micko »

pemasu wrote:http://bkhome.org/blog/?viewDetailed=02697

Check shinobar`s solution, would it help:

Code: Select all

#120203 pemasu and shinobar: space in smb or cifs share causes hanging in shutdown
for T in cifs smbfs nfs sshfs; do
  umount -a -t $T
done
NO, failure again, thanks anyway. It did occur to me that it's only a problem in PUPMODE=5. A test of that condition seems to fix it, however I don't know if this could bork future saves if someone tricks the system into thinking it's PUPMODE=13 when it's actually PUPMODE=12
rcrsn51 wrote:Change this to "umount-FULL". In my tests with an NTFS-formatted flash drive, it solved the problem.

BTW, this problem with "umount -a -t cifs" conflicting with NTFS goes back at least as far as Quirky. It doesn't affect other filesystems.
Yes, will try that right now. Report back in a few minutes.
Puppy Linux Blog - contact me for access

User avatar
don570
Posts: 5528
Joined: Wed 10 Mar 2010, 19:58
Location: Ontario

#627 Post by don570 »

I noticed that you included the excellent Caps plugins for LADSPA effects

/usr/lib/ladspa/

...but you need a version of mhwaveedit that will load ladspa plugins

I made one here.

__________________________________________________

User avatar
01micko
Posts: 8741
Joined: Sat 11 Oct 2008, 13:39
Location: qld
Contact:

#628 Post by 01micko »

don570 wrote:I noticed that you included the excellent Caps plugins for LADSPA effects

/usr/lib/ladspa/

...but you need a version of mhwaveedit that will load ladspa plugins

I made one here.

__________________________________________________
At this late stage I won't include your mhwaveedit but I will put it in the repo.

----------------------------------------------------------------------------


umount-FULL works and is a "proper" solution. I didn't give ntfs usb sticks a thought :oops: . Problem solved.

Thank you rcrsn51
Puppy Linux Blog - contact me for access

User avatar
rcrsn51
Posts: 13096
Joined: Tue 05 Sep 2006, 13:50
Location: Stratford, Ontario

#629 Post by rcrsn51 »

Excellent. The problem with the "umount" script is easy to demonstate.

1. Mount the NTFS partition sdxy.

2. Run "umount -a -t cifs"

3. Run "ls /mnt/sdxy"

The NTSF partition has gotten unmounted. However, the drive icon on the desktop still shows it as mounted!

User avatar
pemasu
Posts: 5474
Joined: Wed 08 Jul 2009, 12:26
Location: Finland

#630 Post by pemasu »

Bug fix to be carried to the woof ?

User avatar
01micko
Posts: 8741
Joined: Sat 11 Oct 2008, 13:39
Location: qld
Contact:

#631 Post by 01micko »

pemasu wrote:Bug fix to be carried to the woof ?
Hopefully!

Attached is what I'll be putting in Slacko-5.4 rc2. I have moved the call down to allow for responsible service scripts. (ie YASSM, network_roxapp)
Attachments
rc.shutdown.gz
This has the ntfs fix, goes in /etc/rc.d, try it if you like @ pfix=ram , save to an ntfs filesystem
(10.27 KiB) Downloaded 481 times
Puppy Linux Blog - contact me for access

User avatar
rcrsn51
Posts: 13096
Joined: Tue 05 Sep 2006, 13:50
Location: Stratford, Ontario

#632 Post by rcrsn51 »

Here was my test procedure.

1. Booted off the Live CD. It found the sfs on the hard drive.

2. Selected all the defaults and immediately made a save file on an NTFS flash drive. There WAS a network connection, so I don't know how that's significant.

3. Rebooted. The save file was detected, followed by a kernel panic!

4. Repeated using "umount-FULL". No problems.

User avatar
01micko
Posts: 8741
Joined: Sat 11 Oct 2008, 13:39
Location: qld
Contact:

#633 Post by 01micko »

rcrsn51 wrote:Here was my test procedure.

1. Booted off the Live CD. It found the sfs on the hard drive.

2. Selected all the defaults and immediately made a save file on an NTFS flash drive. There WAS a network connection, so I don't know how that's significant.

3. Rebooted. The save file was detected, followed by a kernel panic!

4. Repeated using "umount-FULL". No problems.
So looks like the fix is good then..

BTW, we got a prompt woof fix :)
Puppy Linux Blog - contact me for access

User avatar
rcrsn51
Posts: 13096
Joined: Tue 05 Sep 2006, 13:50
Location: Stratford, Ontario

#634 Post by rcrsn51 »

I repeated the procedure with both Wary 5.3 and Slacko 533 and got identical results. If I opened the bad save file from another Puppy, it was empty.

It's odd that when the save file is on an NTFS hard drive partition, it sometimes works.

User avatar
01micko
Posts: 8741
Joined: Sat 11 Oct 2008, 13:39
Location: qld
Contact:

#635 Post by 01micko »

rcrsn51 wrote:It's odd that when the save file is on an NTFS hard drive partition, it sometimes works.
My best explanation for this behaviour is that the buggy busybox umount isn't happy until it's found something it can unmount.

For example; more often than not if I'm testing on one of my other machines I'll connect with curl ftp to my main machine to get quick access to files I have edited and such. I was doing this testing shutdown scripts and wasn't getting the bug. So my best explanation for that was that busybox umount was unmounting the curlftpfs and then it was happy. I guess curlftpfs should be one of the umount arguments. I could reproduce the bug 100% of the time when I didn't connect. Took me awhile to figure that one out!

Still, that doesn't explain why it would sometimes work if you had a connection but definitely didn't mount anything over the network. Just a buggy busybox applet I guess.
Puppy Linux Blog - contact me for access

User avatar
Q5sys
Posts: 1105
Joined: Thu 11 Dec 2008, 19:49
Contact:

#636 Post by Q5sys »

Perhaps an odd request... but is there anyway we can get the IRC client to assign default nicks like it did in the past (I think it assigned by hostname, it was something like pupuserc627d8 where the last 6 are a hex value).

Its getting really confusing in the freenode #puppylinux room, because people are assigned defualt names in numerical order.
It has happened more than once that we are helping someone who has the nick Spupuser1, and in the middle they've gotten disconnected. They rejoin soon enough but someone else has joined before them so that new person gets spupuser1 and the old person gets spupuser2.
All we see is the disconnect and reconnect. So we assume we are helping the same person. Unless we happen to look at the IP reconnect info in detail we dont realize there is a difference.

I've seen it happen a few times where we continue to assist the first person but since we are addressing them as spupuser1 (since thats what they were) we end up having a new person doing things to their system that might have nothing to do with them and could cause them issues if we are trying to work through a config issue with someone.

The way the old systems used to work the person could disconnect and rejoin within a short period of time and still have the same nick. This made help sessions in irc a bit eaiser to manager if a person has to be logging in and out.
I've seen this happen several times when people were trying to work out their x.org drivers and had to drop out of X and then back in and reconnect.

just a simple request. Is there a reason this was changed... or was it just something that happened to change without any thought or intention?

tlchost
Posts: 2057
Joined: Sun 05 Aug 2007, 23:26
Location: Baltimore, Maryland USA
Contact:

#637 Post by tlchost »

[quote="Q5sys"

Its getting really confusing in the freenode #puppylinux room, because people are assigned defualt names in numerical order.[/quote]

That's why some of us suggest that a user with a "default" nick create a nick of their own.

Thom

User avatar
Q5sys
Posts: 1105
Joined: Thu 11 Dec 2008, 19:49
Contact:

#638 Post by Q5sys »

tlchost wrote:
Q5sys wrote:
Its getting really confusing in the freenode #puppylinux room, because people are assigned defualt names in numerical order.
That's why some of us suggest that a user with a "default" nick create a nick of their own.

Thom
I understand that, but when you are dealing with trying to help someone with very little computer skill do something, it's sometimes best not to futher confuse them by trying to walk them through how to register an irc nick and and configure their IRC client properly... which has nothing to do with the reason they came into the channel in the first place.
Yes I agree that someone who is going to be hanging out or will be around for a while should register a nick. But for a person just trying to get quick help on an immediate problem... they dont care about their nick... they just want to get their issue resolved.

Its a easy fix (I'd think) to go back to the old default nick system. And one that would help eliminate some confusion with new/inexperienced users when they come looking for help.

User avatar
01micko
Posts: 8741
Joined: Sat 11 Oct 2008, 13:39
Location: qld
Contact:

#639 Post by 01micko »

Q5sys

What is the limit of chars of a nick on IRC?

Here's what I can do:

Code: Select all

if [ -f $HOME/.xchat2/xchat.conf ];then
		sed -i -e "s|spupuser|slacko${HOSTNAME:5}|" \
				-e  "s|spupuser1|slacko${HOSTNAME:5}1|" \
				-e "s|spupuser2|slacko${HOSTNAME:5}2|" \
				$HOME/.xchat2/xchat.conf
  fi
If a user keeps the standard "puppypc12345" hostname (it's actually $RANDOM") then they would end up with slackopc12345, slackopc123451 and slackopc123452, all random of course except for the appended 1 and 2. That code can run once and only once in /usr/sbin/delayedrun.

It worked fine on the commandline and should in the script, I'll test when I do a build later tonight.

Ha... I'll just go on IRC and find out! (By the way, $HOSTNAME has a limit of 15 chars by convention)
Puppy Linux Blog - contact me for access

User avatar
Q5sys
Posts: 1105
Joined: Thu 11 Dec 2008, 19:49
Contact:

#640 Post by Q5sys »

01micko wrote:Q5sys

What is the limit of chars of a nick on IRC?
Not sure... depends on how the IRCD is configured. I've only messed around with unreal before... freenode uses ircd-seven... so I have no idea on nick limits. But Id guess 12~16 chars probably.

Post Reply