Puppy Linux Discussion Forum

gray · Posted: Sat 13 Oct 2007, 19:38 Post_subject: Remaster problem

BarryK · Posted: Sat 13 Oct 2007, 19:58 Post_subject:

gray, okay, I think that I found the problem. Try this (in /usr/sbin):

BarryK · Posted: Sat 13 Oct 2007, 20:03 Post_subject:

Ha, ha, you posted just when I did! The script was excluding ntfs partitions, but I think now they can be allowed for temp storage while building the remaster, so another change:

BarryK · Posted: Sat 13 Oct 2007, 20:10 Post_subject:

rerwin, thanks for the fix for 'puppyinstaller', have applied it.

BarryK · Posted: Sat 13 Oct 2007, 20:14 Post_subject:

gray · Posted: Sat 13 Oct 2007, 20:19 Post_subject: Remaster [solved]

Barry,

The new remasterpup2 works a treat. Very Happy

Lobster

BarryK · Posted: Sun 14 Oct 2007, 03:53 Post_subject:

Well, I'm intending to upload 3.01final about 12 hours from now, or thereabouts. As usual, it's a matter of deciding on a cut-off point, and anything else gets held over until 3.02.

Lobster · Posted: Sun 14 Oct 2007, 05:20 Post_subject: inode

Here is a pic of the inode error message (after adding Ezpup)

Sorry about the pic quality and providing so late in the day . . .

I have just loaded and run NOP (based on Puppy 3.01 Beta) everything OK with a puppy pfix=ram boot
Then I added an sfs using the bootmanager (after first rebooting to create a NOP save file)
Got those inode messages again . . .

vern72023 · Joined: 26 Dec 2005 Posts: 158 Location: Jacksonville Fl

I am getting exactly the same Lobster - - even using a completely new pup_save.
On the first reboot everything was fine - just got 8 lines or so that showed that it was doing its checks.
then I changed the wm to icewm and removed icons from the desktop and the error messages appeared on reboot and kept appearing every boot thereafter.

So i repeated the process - new pup_save - okay on first reboot _ changed to icewm - remove icons - reboot - error messages

I repeated this 3 times and it exhibited the exact same behaviour every time
At least its consistent and repeatable

The other thing to note is that these so-called error do not seem to have any impact on performance or stability - so it makes me wonder if they are "real" errors that fsck is reporting
George

vern72023 · Joined: 26 Dec 2005 Posts: 158 Location: Jacksonville Fl

Okay its got nothing to do with changing the desktop.
How I am doing this is that I have a 2fs blank that i created
I take this and copy in everything from the initrd\pup_rw then give it a discrete Pup_save name
2 things are consistnet
The first time i Boot with this new file as a choice it does not throw the inode errors but it does restore the standard desktop and icewm menu but works just fine
In prior tests I have restored the desktop and icewm menu to my custm preferences and got inode errors
Now I have tested it a couple of times without dioing that - just rebooting it
and it still displays the erorrs

Even if I do shutdown rather than reboot I get the same result
The only commonality now is the reboot.
Maybe someting in the way that the shutdown process is happeneing is not closing the mount down cleanly

George

Lobster · Posted: Sun 14 Oct 2007, 10:06 Post_subject:

jcoder24 · Joined: 06 May 2005 Posts: 601 Location: Barbados

From what I see, 3.01 does two fscks on my system. It first reports that the partition containing the save file "was not cleanly unmounted, check forced" and checks it (although no changes are made). Next it reports the same thing for /dev/loop1 (the save file).

As an additional test I booted with pfix=ram and run fsck on /dev/hda3 and /dev/loop1 which finds and fixes some errors. If I then reboot with save file I just all is well. However, on the next reboot the problem comes back.

NB. I also repeated all of my tests booting from cd without any change.

I would have to agree that it looks like a shutdown problem. I'm also wondering if the version of fsck in the initrd maybe buggy. The version in initrd is "1.40.2 (12-Jul-2007)" while that in the booted puppy is "fsck 1.39 (29-May-2006)"

This fsck problem wasn't in v3.00.

vern72023 · Joined: 26 Dec 2005 Posts: 158 Location: Jacksonville Fl

Okay following up on that I decided to see what woukd happen if I used the same file that was in the fugal install on a USB drive boot
I did it the sam eway that i used before
I have a 2fs blank that i created
I take this and copy in everything from the initrd\pup_rw then saved it to the usb drive as pup_save.2fs
Booted
No issues - interestingly unlike the times I did it on the Frugal it did not overwrite my puppy-pin or icewm customizations -
So I rebooted
and it did report 1 error under Check 5 - groups where it reported an error in the number of Groups - but nothing like the numver of errors and fixs that I got under the frugal install
Now one main difference of course is that in the Frugal it mnounts the pup_save at the top layer as rw whereas with the usb it is saving the rw back to the r01.
What I would like an option to do is to handle the mounting of the pup_save as r01 in the frugal install instead of mounting it rw - I think there is a way to force that but I cant remember how

George

GrumpyWolfe · Joined: 26 Nov 2006 Posts: 496

Hi BarryK and all

I have a hard drive install I like testing out the bates and all. Did a full install wiping out the old 3.0. Just wish know how to save passwords for the browser. All seemed to go well have not ran into anything wrong so far. Installed pidgin 2.0.2 throw puppy package manger and downloaded and installed gslapt package manger have not installed anything with it yet.

If I can test this beta out in some way Barry let me know.

edit: just installed java with gslapt package manger and restarted seamonkey and yes jave is configed to work end edit