Puppy Linux Discussion Forum Forum Index Puppy Linux Discussion Forum
Puppy HOME page : puppylinux.com
"THE" alternative forum : puppylinux.info
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

The time now is Mon 20 Oct 2014, 06:24
All times are UTC - 4
 Forum index » Taking the Puppy out for a walk » Announcements
Pup214R v1.01 uploaded
Moderators: Flash, Ian, JohnMurga
Post new topic   Reply to topic View previous topic :: View next topic
Page 3 of 8 [112 Posts]   Goto page: Previous 1, 2, 3, 4, 5, 6, 7, 8 Next
Author Message
Dougal


Joined: 19 Oct 2005
Posts: 2505
Location: Hell more grotesque than any medieval woodcut

PostPosted: Fri 01 Feb 2008, 09:30    Post subject: Re: Testing  

HairyWill wrote:
Dougal wrote:
I think maybe it would be best to just put up a yaf-splash window with a message saying "a new tab has been opened in Mozilla" or something.
I think MU has posted some comments about problems internationalising yaf-splash. It might also be sensible to include.
"To open a new tab yourself in fire/sea/ice/monster press CTRL-T."

Well yaf-splash is also ugly, so it can just be gxmessage, but the same thing. My idea was to actually open the tab for them and let them know (they'll learn to use tabs over time).

Quote:
I'm still getting an error from resize2fs
Code:
ext2fs_check_mount_point: No such file or directory while determining whether /mnt/dev_save/pup_save.2fs is mounted

But didn't it run after giving that message?
That message appears every time e2fsck is run on the pup_save, since when in the ramdisk we don't have /etc/mtab, but it still seems to run ok.

Quote:
I also noticed and error on shutdown when creating the pup_save.

Code:
Saving session to /pup_save.2fs file on hdc1 partition...
Mounting /pup_save.2fs...cp: cannot stat `/initrd/pup_rw/root/*': No such  directory

Yeah, I know that. It doesn't really matter -- it just tries to copy what isn't there. Barry tends to pipe all errors to /dev/null but I prefer to allow them to show, in case something real happens.


Quote:
I have initrd.gz, vmlinuz and both sfs files in the root of the partition in both machines and my grub config looks like
Code:
title 214R
kernel (hd2,0)/vmlinuz root=/dev/ram0
initrd (hd2,0)/initrd.gz
boot

What about PMEDIA=idehd?

Quote:
Even the pfix=ram is a none issue for me as I can easily ensure that at least two pup_saves get found. Why am I trying to hunt this one down?

I find it really odd that you would have a problem with pfix=ram, since it should simply ignore all pup_save files!

_________________
What's the ugliest part of your body?
Some say your nose
Some say your toes
But I think it's your mind
Back to top
View user's profile Send private message 
HairyWill


Joined: 26 May 2006
Posts: 2949
Location: Southampton, UK

PostPosted: Fri 01 Feb 2008, 11:05    Post subject: Re: Testing  

Dougal wrote:
My idea was to actually open the tab for them and let them know (they'll learn to use tabs over time).
that is what I meant though I didn't put it well

Dougal wrote:
That message appears every time e2fsck is run on the pup_save, since when in the ramdisk we don't have /etc/mtab, but it still seems to run ok.
That is even less helpful. This means that resize2fs is failing silently.... great.
I have put in lines to sync,mount,df,umount, sync the pup_save before and after the resize they also support that no change is made to the filesystem, weird.

line 935 of init has a check_status $? call after resize2fs surely this always results in a error being shown by check_status? There is also a check_status(0) call a couple of lines down. My guess is the first one shouldn't be there though it doesn't help me.

[quote="Dougal"]What about PMEDIA=idehd?[quote]just tried that no help.

Quote:
I find it really odd that you would have a problem with pfix=ram, since it should simply ignore all pup_save files!
I find it odd too and won't be able to investigate this machine for a few days
_________________
Will
contribute: community website, screenshots, puplets, wiki, rss
Back to top
View user's profile Send private message 
HairyWill


Joined: 26 May 2006
Posts: 2949
Location: Southampton, UK

PostPosted: Fri 01 Feb 2008, 19:26    Post subject:  

KOWABUNGA

After more hours than I would care to admit I've fixed my resize problem.

I have recompiled e2fsprogs 1.40.5 and set the routine in resize2fs main.c which checks to see if the filesystem is mounted to ignore the result of the check. I have rebuilt pup_214.sfs with the modified resize2fs. One of the reasons I found this hard to spot was because the check_mount_point error being thrown by resize2fs was the same as the check_mount_point error from e2fsck. e2fsck ignores the error and repairs the filesystem anyway whilst resize2fs just exits

Somewhere in all of this I also have a dodgy clock so most of the time the superblock last mount time is about 8 hours ahead. I have noticed this before and just confirmed this using e2fsdebug. hwclock and date both agree on the correct time.

whew

_________________
Will
contribute: community website, screenshots, puplets, wiki, rss
Back to top
View user's profile Send private message 
MU


Joined: 24 Aug 2005
Posts: 13642
Location: Karlsruhe, Germany

PostPosted: Fri 01 Feb 2008, 19:51    Post subject:  

Here is a replacement for yaf-splash:
http://murga-linux.com/puppy/viewtopic.php?t=25536
Mark
Back to top
View user's profile Send private message Visit poster's website 
Pizzasgood


Joined: 04 May 2005
Posts: 6270
Location: Knoxville, TN, USA

PostPosted: Sat 02 Feb 2008, 00:16    Post subject:  

I finally managed to bork my ancient (to me) save file last night. Rather than spend more hours trying to fix it, I decided to try 2.14R.

So, initial impression: great stuff!

The single biggest annoyance so far is that the Geany key-bindings are all different. Not hard for me to change back or anything, just annoying Rolling Eyes

The lack of a desktop icon for Geany was also annoying, but I guess I can see why it would be omitted.

Since I'm procrastinating over something (I forget what), I decided to look at the /usr/sbin/wag-profiles.sh script. I notice these lines (927,928):
Code:
      if [ ${KEY_SIZE} -lt 9 ] || [ ${KEY_SIZE} -gt 64 ] ; then
         Xdialog --left --title "Puppy Network Wizard" --msgbox "Shared key must be either\n- Alphanumeric betwen 8 and 63 characters or\n- 64 characters hexadecimal " 0 0       

I'm pretty sure that should be -lt 8

Also, back in December I had access to some WPA-capible equipment, and from what I could tell the line at 951:
Code:
      wpa_cli reconfigure >> ${TMPLOG} 2>&1
was causing issues. It seemed to run fine without it, and seems redundant since wpa_supplicant is shut down in the next line anyways. Also, when that line caused an error, I had to completely bring down the interface before it would go away.

I don't know a whole lot about WPA though, as I only messed with it for about a week. So maybe that line is important for some reason I don't see.


Otherwise I like it so far, and I'll let you know about any bugs I rustle up. Smile

Now I just need to remember how I managed to configure everything last time. Usually I start fresh every couple months; this time it was six or seven months so I'm a bit rusty.

_________________
Between depriving a man of one hour from his life and depriving him of his life there exists only a difference of degree. --Muad'Dib

Back to top
View user's profile Send private message Visit poster's website 
HairyWill


Joined: 26 May 2006
Posts: 2949
Location: Southampton, UK

PostPosted: Sat 02 Feb 2008, 07:00    Post subject:  

/usr/bin/qiv-command

The messages associated with pressing keys 4-0 in qiv lack end of line terminators. This means that qiv does not show the last line of the message. Either remove the -n switch for echo or add \n.

If you switch qiv to fullscreen mode and then press one of the bound number keys ie 2 for mtpaint, mtpaint starts hidden behind qiv and qiv locks up in fullscreen.

This scenario is unlikely but its impact is severe as the only recovery I could make was to start another VT and kill qiv (presumably CTRL-ALT-BACKSPACE would work as well to kill X)

This can be overcome by binding the qiv command to something like
2) killall qiv ; defaultpaint "$2"
killing qiv is not ideal but probably better than the risk of hanging it

I wonder if there is any way to send qiv a signal to force it out of fullscreen?

_________________
Will
contribute: community website, screenshots, puplets, wiki, rss
Back to top
View user's profile Send private message 
Newcrest

Joined: 03 Mar 2007
Posts: 203

PostPosted: Sat 02 Feb 2008, 23:27    Post subject:  

It does not appear that 2.14R has the improved NTFS support included in 2.16:
NTFS support and general partition management improved. A swag of packages have been upgraded, namely FUSE, ntfs-3g, ntfsprogs.

Puppy 2.14 and 2.15CE don't reliably write to NTFS partitions and cause corruption after a few writes have taken place. Shouldn't these changes be done in 2.14R especially if it is going to be used as a base for community editions?
Back to top
View user's profile Send private message 
jamesbond

Joined: 26 Feb 2007
Posts: 2221
Location: The Blue Marble

PostPosted: Sun 03 Feb 2008, 00:12    Post subject:  

I suggested taking the latest ntfs-3g (and libfuse). The version in 2.15CE definitely has problems copying files over 1GB to NTFS partition - anything over 1.5GB is practically uncopyable.

I have compiled it (1.1120 but now they have just released 1.2129 !!!) - but found out that for it to take effect, I need to update the version both in initrd.gz and in the pup_215.sfs. Unfortunately my static version is around ~630kb - unlike the original was around ~130K.

_________________
Fatdog64, Slacko and Puppeee user. Puppy user since 2.13.
Contributed Fatdog64 packages thread
Back to top
View user's profile Send private message 
Newcrest

Joined: 03 Mar 2007
Posts: 203

PostPosted: Sun 03 Feb 2008, 00:47    Post subject:  

jamesbond wrote:
I suggested taking the latest ntfs-3g (and libfuse). The version in 2.15CE definitely has problems copying files over 1GB to NTFS partition - anything over 1.5GB is practically uncopyable.


It is not just files over 1GB that there is a problem with. After writing a few files of 100MB size the partition can become corrupted and further writes of any size larger than 1MB will become near impossible. Puppy 2.16 and newer does not have this problem and uses less cpu when writing as well.
Back to top
View user's profile Send private message 
Newcrest

Joined: 03 Mar 2007
Posts: 203

PostPosted: Sun 03 Feb 2008, 01:00    Post subject:  

jamesbond wrote:

I need to update the version both in initrd.gz and in the pup_215.sfs. Unfortunately my static version is around ~630kb - unlike the original was around ~130K.


I just looked at the version in Puppy 2.16 and it is ~145K. Given that it works and does not have the hugely major problems that the version in 2.14/2.15CE has, would it not be a worthwhile compromise?
Back to top
View user's profile Send private message 
MU


Joined: 24 Aug 2005
Posts: 13642
Location: Karlsruhe, Germany

PostPosted: Sun 03 Feb 2008, 01:31    Post subject:  

jamesbond wrote:
Unfortunately my static version is around ~630kb - unlike the original was around ~130K.


Please try to strip binaries and libs.
strip /usr/bin/TEST
strip /usr/lib/TEST.so

"strip" removes developers debug-messages, those are not needed in the public binaries.

Mark
Back to top
View user's profile Send private message Visit poster's website 
tempestuous

Joined: 10 Jun 2005
Posts: 5270
Location: Australia

PostPosted: Sun 03 Feb 2008, 02:07    Post subject:  

Be patient guys. Upgraded NTFS support for 214R is on the way. So, too, upgraded ALSA.

Pizzasgood, Dougal has already noted those Network Wizard fixes for the next release. Expect upgraded wifi drivers, too.
Back to top
View user's profile Send private message 
Dougal


Joined: 19 Oct 2005
Posts: 2505
Location: Hell more grotesque than any medieval woodcut

PostPosted: Sun 03 Feb 2008, 08:31    Post subject:  

HairyWill wrote:
I have recompiled e2fsprogs 1.40.5 and set the routine in resize2fs main.c which checks to see if the filesystem is mounted to ignore the result of the check. I have rebuilt pup_214.sfs with the modified resize2fs. One of the reasons I found this hard to spot was because the check_mount_point error being thrown by resize2fs was the same as the check_mount_point error from e2fsck. e2fsck ignores the error and repairs the filesystem anyway whilst resize2fs just exits

Oh my, you really went to a lot of trouble with this... I have a simpler solution that i intend to try: before running e2fsck/resize2fs I will just create /etc/mtab using /proc/mounts... should solve the problem.

Quote:
Somewhere in all of this I also have a dodgy clock so most of the time the superblock last mount time is about 8 hours ahead. I have noticed this before and just confirmed this using e2fsdebug. hwclock and date both agree on the correct time.

8 hours ahead?
When we're in the initial ramdisk the clock is not set, so we're always somewhere in 1970, so if you run e2fsck (or resize2fs) it sets the "last checked" date to that...
When I added pfix=fsck I had that problem and tried setting the clock (and making sure it was set!) before running fsck, but for some reason it still said 1970! So I ended up moving the checks for all partitions other than the one with the pup_save to shutdown (also doesn't keep the user waiting).

_________________
What's the ugliest part of your body?
Some say your nose
Some say your toes
But I think it's your mind
Back to top
View user's profile Send private message 
Dougal


Joined: 19 Oct 2005
Posts: 2505
Location: Hell more grotesque than any medieval woodcut

PostPosted: Sun 03 Feb 2008, 08:40    Post subject:  

Pizzasgood wrote:
The single biggest annoyance so far is that the Geany key-bindings are all different. Not hard for me to change back or anything, just annoying Rolling Eyes

That's Enrico, not me... they changed to more "standard" keybindings. It took me a while to stop hitting Ctrl+Y and using F3...


Quote:
Since I'm procrastinating over something (I forget what), I decided to look at the /usr/sbin/wag-profiles.sh script. I notice these lines (927,928):
Code:
      if [ ${KEY_SIZE} -lt 9 ] || [ ${KEY_SIZE} -gt 64 ] ; then
         Xdialog --left --title "Puppy Network Wizard" --msgbox "Shared key must be either\n- Alphanumeric betwen 8 and 63 characters or\n- 64 characters hexadecimal " 0 0       

I'm pretty sure that should be -lt 8

Also, back in December I had access to some WPA-capible equipment, and from what I could tell the line at 951:
Code:
      wpa_cli reconfigure >> ${TMPLOG} 2>&1
was causing issues. It seemed to run fine without it, and seems redundant since wpa_supplicant is shut down in the next line anyways. Also, when that line caused an error, I had to completely bring down the interface before it would go away.

I don't know a whole lot about WPA though, as I only messed with it for about a week. So maybe that line is important for some reason I don't see.

All that has been fixed a while ago, we just haven't updated the iso yet (there's a service pack that's been "nearly ready" for more than a month..).

_________________
What's the ugliest part of your body?
Some say your nose
Some say your toes
But I think it's your mind
Back to top
View user's profile Send private message 
Dougal


Joined: 19 Oct 2005
Posts: 2505
Location: Hell more grotesque than any medieval woodcut

PostPosted: Sun 03 Feb 2008, 08:49    Post subject:  

HairyWill wrote:
This can be overcome by binding the qiv command to something like
2) killall qiv ; defaultpaint "$2"
killing qiv is not ideal but probably better than the risk of hanging it

Does that work at all? The way qiv-command works is that it runs as a sub-process of qiv and as a result you can't close qiv until you have closed the application that's running as a sub-process...
It's odd that the app opens behind qiv.
We need something more sophisticated than this, since you don't want to kill all qiv processes...

Quote:
I wonder if there is any way to send qiv a signal to force it out of fullscreen?

There probably is -- it has heaps of options and keybindings -- but the problem is that qiv will probably fill up the screen when viewing a huge image...

_________________
What's the ugliest part of your body?
Some say your nose
Some say your toes
But I think it's your mind
Back to top
View user's profile Send private message 
Display posts from previous:   Sort by:   
Page 3 of 8 [112 Posts]   Goto page: Previous 1, 2, 3, 4, 5, 6, 7, 8 Next
Post new topic   Reply to topic View previous topic :: View next topic
 Forum index » Taking the Puppy out for a walk » Announcements
Jump to:  

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001, 2005 phpBB Group
[ Time: 0.1136s ][ Queries: 13 (0.0057s) ][ GZIP on ]