(old)Puppy Linux Discussion Forum

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).

I'm still getting an error from resize2fs

Code: Select all

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.

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

Code: Select all

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.

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: Select all

title 214R
kernel (hd2,0)/vmlinuz root=/dev/ram0
initrd (hd2,0)/initrd.gz
boot

What about PMEDIA=idehd?

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!

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.

Dougal wrote:What about PMEDIA=idehd?

just tried that no help.

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

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

Here is a replacement for yaf-splash:
http://murga-linux.com/puppy/viewtopic.php?t=25536
Mark

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): 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: 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.

/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?

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?

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.

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.

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?

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

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.

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.

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).

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...

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: Select all

		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: Select all

		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..).

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...

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...

@NewCrest - in my earlier test with 2.16, it still have the same performance problem as 2.15CE. I'm sure the bloat in my compiled NTFS is due to my own foresight ...

@MU - Thanks, I tried, but still the same

@Rest of 2.14R team - Thanks !

(there's a service pack that's been "nearly ready" for more than a month..)

I know how that goes. I've given myself an ultimatum to get all my "almost done" stuff finished by Sunday. My original plan was to have it all done by mid October. Last October that is.

Speaking of which, part if that stuff involves adding a boot.msg type deal to USB installs. Then when booting from USB you get the ability to add boot options ans such, just like with live-cd. It's pretty simple; mainly needs a tweak to the install scripts so they copy in a template syslinux.cfg file then append the final line to it (rather than creating the whole file on the fly). That way the same file can be used when setting up syslinux, extlinux, and isolinux, without having to modify code in a dozen places when you want to change some minor detail.

I should have it all togeather for 3.01 and 2.14 tonight, and maybe 2.14R (assuming there's a difference in the relevant scripts; haven't looked yet).

In case you're interested in the syslinux modifications I mentioned above, I just uploaded them here:
http://www.murga-linux.com/puppy/viewto ... 777#172777

Something to be aware of if you use it: my version uses f2.msg rather than f2.

Also, if you don't use it, I should let you know that as far as I can tell you didn't modify the remaster script nor the mulitisession scripts to take in account for the f2 file you added.
/etc/rc.d/rc.shutdown
/usr/sbin/pupremaster.sh
/usr/sbin/savesession-dvd

It's an easy fix, just use find to locate where it copies the boot.msg file, and add a line for f2. All three of the scripts are about the same.


One other thing about 2.14R that I took a while to realize: I like the GTK theme, but it's hard to tell at a glance if a check box is checked or unchecked. It took forever before I realized why Seamonkey wouldn't just shut up when I tried checking my email

Pizzasgood wrote:I like the GTK theme, but it's hard to tell at a glance if a check box is checked or unchecked.

Yeah, I know what you mean. It took Dougal and me quite some time to decide on a good GTK theme. It seems every one had some bad trait, e.g., while testing, there always seemed to be an app where the foreground colour and background colour were nearly the same making text hard to read. This one turned out to be the best compromise...

I do wish there was some way of changing the check boxes to use a check mark though :-/

Hi guys

Just wanted to stop by and say thanks for bringing out a thoroughly tested puppy. Im looking forward to the updated drivers/NTFS support. The first CE alpha will not be going out without these enhancements.

Keep up the good work!!! Woof Woof