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

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!

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.

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

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._________________Fatdog64, Slacko and Puppeee user. Puppy user since 2.13.
Contributed Fatdog64 packages thread.

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.

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?

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

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

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

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