The time now is Thu 12 Dec 2019, 00:50
All times are UTC - 4 |
Author |
Message |
Dougal

Joined: 19 Oct 2005 Posts: 2504 Location: Hell more grotesque than any medieval woodcut
|
Posted: 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
|
|
 |
HairyWill

Joined: 26 May 2006 Posts: 2946 Location: Southampton, UK
|
Posted: 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
|
|
 |
HairyWill

Joined: 26 May 2006 Posts: 2946 Location: Southampton, UK
|
Posted: 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
|
|
 |
MU

Joined: 24 Aug 2005 Posts: 13647 Location: Karlsruhe, Germany
|
Posted: 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
|
|
 |
Pizzasgood

Joined: 04 May 2005 Posts: 6266 Location: Knoxville, TN, USA
|
Posted: 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
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.
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
|
|
 |
HairyWill

Joined: 26 May 2006 Posts: 2946 Location: Southampton, UK
|
Posted: 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
|
|
 |
Newcrest
Joined: 03 Mar 2007 Posts: 203
|
Posted: 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
|
|
 |
jamesbond
Joined: 26 Feb 2007 Posts: 3387 Location: The Blue Marble
|
Posted: 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 forum links: Latest version | Contributed packages | ISO builder
|
Back to top
|
|
 |
Newcrest
Joined: 03 Mar 2007 Posts: 203
|
Posted: 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
|
|
 |
Newcrest
Joined: 03 Mar 2007 Posts: 203
|
Posted: 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
|
|
 |
MU

Joined: 24 Aug 2005 Posts: 13647 Location: Karlsruhe, Germany
|
Posted: 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
|
|
 |
tempestuous
Joined: 10 Jun 2005 Posts: 5472 Location: Australia
|
Posted: 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
|
|
 |
Dougal

Joined: 19 Oct 2005 Posts: 2504 Location: Hell more grotesque than any medieval woodcut
|
Posted: 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
|
|
 |
Dougal

Joined: 19 Oct 2005 Posts: 2504 Location: Hell more grotesque than any medieval woodcut
|
Posted: 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  |
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
|
|
 |
Dougal

Joined: 19 Oct 2005 Posts: 2504 Location: Hell more grotesque than any medieval woodcut
|
Posted: 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
|
|
 |
|
|
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
|