Grafpup-2.xx fourth (and final) alpha

For talk and support relating specifically to Puppy derivatives
Message
Author
User avatar
Nathan F
Posts: 1764
Joined: Wed 08 Jun 2005, 14:45
Location: Wadsworth, OH (occasionally home)
Contact:

#271 Post by Nathan F »

OK, more bad behavior assuming a user is root. I'll look at the code and see if I can move the temp file into a users home directory, or perhaps into /tmp. I don't like making all sorts of things world writable all over the filesystem.

Nathan
Bring on the locusts ...

plinej
Posts: 1742
Joined: Mon 14 Aug 2006, 02:21

#272 Post by plinej »

I agree. It should be easy enough, I'd look into it but I've got a few other things going right now.

SimonW
Posts: 60
Joined: Wed 28 Mar 2007, 23:15
Location: UK

#273 Post by SimonW »

Hi,

Trying to make use of a graf_save.2fs file on hda, where hda is a CF card, didn't work. In the shutdown process I spotted and error from '/usr/sbin/snapmergegrafpup: No such file or directory'.

I had configured and 'saved' a Static IP address setup and predictably it didn't restore on reboot. Looks like a script is missing?

The save file & restore Static IP worked on a desktop booted from CD though.

User avatar
Nathan F
Posts: 1764
Joined: Wed 08 Jun 2005, 14:45
Location: Wadsworth, OH (occasionally home)
Contact:

#274 Post by Nathan F »

OK that's courtesy of one bonehead developer (me). That should be snapmeregepuppy and explains a lot. The proper script was being called by the background daemon which runs and saves things periodically, but not at shutdown, so some files will have gotten saved and some not saved. Now fixed.

It would work from cd, with a save file on a normal hard drive, because then things are getting saved directly into the save file rather than being held in memory and periodically flushed.

I'll not be using Turma to replace text on important scripts anymore :oops:

Nathan
Bring on the locusts ...

SimonW
Posts: 60
Joined: Wed 28 Mar 2007, 23:15
Location: UK

#275 Post by SimonW »

Bonehead? Nope. It's amazing you know exactly the root of a problem 'just like that'.

In case you haven't already done it, I've attached a version of rc.shutdown in which all occurences of snapmergegrafpup have been changed to snapmergepuppy.
The good news is, now on the compact flash hda system, a static ip setup is preserved over a reboot! I did see a couple of chmod usage errors fly past on shutdown which I didn't get a chance to note.

While we're on the subject of things being flushed occasionally, if I run with hda as a memory card, do I have to take precautions to avoid excessive writes to the card? What's the flush rate? Does it only happen when changes occur?

I've previously used Unslung on a NSLU2 booting from usb key, and that avoids excessive writes to flash by keeping /var in a ramdisk, and uses 'noatime' on the root filesystem.
Bearing in mind that all Puppies run from Ram, there shouldn't be a real problem with flash wear - am I right?
Attachments
rc.shutdown.gz
(10.93 KiB) Downloaded 718 times

User avatar
Nathan F
Posts: 1764
Joined: Wed 08 Jun 2005, 14:45
Location: Wadsworth, OH (occasionally home)
Contact:

#276 Post by Nathan F »

As long as it is running in mode 13 (which it should, and I believe we've established that it has been) you shouldn't have to take any extra precautions to prolong the flash card. I used the same bootable pendrive with Puppy for a really long time and it's still going strong.

There are actually a few different scenarios for how Puppy and it's varients can run, based on how it is booted and/or installed. The very first time it is booted from a cd everything including any files you create are being held in ram. If you create a save file and then reboot using the cd, then the OS will be running in ram, but the save file will be mounted diretly as the top union layer. So any files you have created (including installed software) are being accessed directly off the hard drive, via your save file. With a full HD install things are totally different though, and all files exist on the hard drive.

Now for the two more special cases. A "frugal" install to a conventional hard drive runs pretty much exactly the same as it would running from cd, with one exception that I will get to in a minute. However, when you boot from flash things work a little bit differently. Rather than mounting the save file as the top union layer it is mounted one layer down, and the top layer is a tmpfs (a fancier ramdisk). So in this case the main OS files are running in ram, anything you saved in any previous sessions are being accessed from your save file (essentially from the flash drive) and any files you create or modify are stored in the top layer tmpfs, running in ram. This is where snapmergepuppy and savepuppyd come in.

Snapmergepuppy is the script that does the actual copy of the temp files into the save file. Savepuppyd is the background daemon which tells it when to do so. The actual interval varies depending on the circumstances and ranges from five minutes to half an hour. In general, the more space you have in the tmpfs the less often it will save the files. Normally it will happen about every ten minutes. You would have to write to the media a lot more often than this to really wear it out. Remember that this is the same media that is used in professional digital cameras, which are often taking several exposures a minute for a large portion of the day and even under those circumstances are expected to last for a couple years. In my experience they usually do, too.

The exception I hinted at above seems to be occuring sporadically with frugal installs on sata drives. In that case init is getting confused and treating the sata drive as if it were flash, so Grafpup (and Puppy) end up running in mode 13, with modified files held in ram and periodically flushed to the savefile. This needs addressed sometime.

One thing Puppy currently has going for it that Grafpup does not, at least not yet, is true flushing of the tmpfs. This is the case in 2.16 alpha anyway, and was only made possible by the switch to aufs. I intend to follow suit shortly, but for now when the files are copied from the tmpfs to the savefile they are not removed from the tmpfs.

Nathan
Bring on the locusts ...

SimonW
Posts: 60
Joined: Wed 28 Mar 2007, 23:15
Location: UK

#277 Post by SimonW »

A very full answer, thanks Nathan. It will also help other wishing to boot from memory sticks/keys etc.

You are right that Compact Flash is used in cameras, my own included, and products which didn't last would be quickly identified (in the pro world at least). The longevity of usb memory 'keys' intended for file backup might be less.

The NSLU that I use hasn't worn out a usb key memory in almost 1 year, although this is with 'noatime' and with the system log in ramdisk.

I have every confidence that Grafpup won't wear out flash now, thanks.

User avatar
Béèm
Posts: 11763
Joined: Wed 22 Nov 2006, 00:47
Location: Brussels IBM Thinkpad R40, 256MB, 20GB, WiFi ipw2100. Frugal Lin'N'Win

Unable to save grf_save to hda2/cf card

#278 Post by Béèm »

Just downloaded and tried the 27 April beta of grafpup 2.0.
When I shutdown I get the question to save the grf_save file. I have a hda2 with a vfat partition on my laptop. I choose to save to disk but get the message: no suitable partition found.

I tried on my desktop also. I have a cf card on sda1.
Again I get the message: no suitable partition found.

I have this whether I am root or grafpup.

Something wrong on the 27 April beta? (note that I haven't tried any beta/alpha version of grafpup before)

User avatar
Dougal
Posts: 2502
Joined: Wed 19 Oct 2005, 13:06
Location: Hell more grotesque than any medieval woodcut

#279 Post by Dougal »

SimonW wrote:Installing probedisk3 and probepart3 in the /sbin directory, and running the Puppy Installer doesn't produce any improvements since I reported last. The dialog box showing 'what Puppy has found out about the drive' still shows sdc1 as having ext3 format.
That's 'cause I don't use probepart/probedisk...

What **is** disturbing is that guess_fstype misdetects the fs! That app just contains the kernel code for detecting the fs, so it should be in agreement with the kernel... I'll see what Jesse has to say.

Nathan: if you intend to use the probedisk/probepart scripts in the initrd, you'll have to add to the init script the mounting (and unmounting) of /sys. (it's trivial, I did it, but important...).
What's the ugliest part of your body?
Some say your nose
Some say your toes
But I think it's your mind

SimonW
Posts: 60
Joined: Wed 28 Mar 2007, 23:15
Location: UK

#280 Post by SimonW »

In case you haven't already done it, I've attached a version of rc.shutdown in which all occurences of snapmergegrafpup have been changed to snapmergepuppy.
The good news is, now on the compact flash hda system, a static ip setup is preserved over a reboot! I did see a couple of chmod usage errors fly past on shutdown which I didn't get a chance to note.
They were actually 'chown' errors in fact. I am only logging in as 'root' so far.

Other little niggles I spotted, I have to run lxpanel -> refresh menu after each CF boot, since most of the menu icons are a red x on white background.

I've added sshd to a /etc/rc.d/services but don't see it started on bootup. EDIT: File should be called rc.services

Dougal,
Shame about guess_fstype misdetecting. The only thing I can see is if I give it /dev/sda and /dev/sda1 it gets the latter correct. Pmount itself is still showing FAT16 CF cards as ext3.

User avatar
Nathan F
Posts: 1764
Joined: Wed 08 Jun 2005, 14:45
Location: Wadsworth, OH (occasionally home)
Contact:

#281 Post by Nathan F »

The issue with the missing icons has to do with the fact that the icons have to be cached to a directory in /tmp. Interesting problem here, lxpanel does not have an icon search path, so when the menu is created the full path to each icon must be specified. What I did is to have lxpanel go through a series of directories and copy the icons to /tmp/icons, and then the menu generator prepends that path to all the icon names. It works but what is happening is that it isn't getting finished by the time lxpanel has started, so not all the icons are present yet.

Anyway it's a bug I've known about for a couple weeks now, but the solution may not be totally straightforward. I suppose I could move it from /tmp/icons to somewhere persistent and that would be one solution, but then you have an extra copy of all those icons in the savefile. Or I could just have the menu generator prepend /usr/share/pixmaps to every icon path, since most icons are located there anyway. That solution works but with a couple problems, because then there will definately be some applications missed, but it would also improve the overall startup time. Whatever I decide you can trust it will be fixed for the final.

I also spotted the "chown" errors. This is once again something in the "snapmergepuppy" script, which flushes the files into the savefile. If it is erroring there the files should definately have still gotten saved, but it's possible the ownership might change to root:root. There was a big problem with this not long ago in Puppy and I submitted a patch to Barry to fix it, which was at the time working. It's possible something external might have caused it to ail though. I will do some experiments with it to see what is going on.

Assumin you added sshd to /etc/rc.d/services as you mentioned then that explains it all, because the correct file is /etc/rc.d/rc.services. Of course you could have just mistyped on the forum here in which case there reaqlly is a problem for us to track down.

Nathan
Bring on the locusts ...

SimonW
Posts: 60
Joined: Wed 28 Mar 2007, 23:15
Location: UK

#282 Post by SimonW »

The issue with the missing icons has to do with the fact that the icons have to be cached to a directory in /tmp.
...
Anyway it's a bug I've known about for a couple weeks now, but the solution may not be totally straightforward.
No problem. I can live with it - after all it will be a mostly unattended machine in the end. Access by vnc and ssh normally.

Assumin you added sshd to /etc/rc.d/services as you mentioned then that explains it all, because the correct file is /etc/rc.d/rc.services. Of course you could have just mistyped on the forum here in which case there reaqlly is a problem for us to track down.
Yep, I added sshd in a new file called /etc/rc.d/rc.services and it worked like a dream. Now I'm working on samba setup....

If it's not a long answer, could someone explain (even if it's just a link to another part of the Puppy forums) regarding how to remaster? After I've customised, I'd like to burn it all to a master CD so I can then create CF cards without doing all the configuration again. My remaster will include the application 'motion' which is a cctv and webcam motion detection program (open-source).

Thanks,
Simon.

User avatar
Dougal
Posts: 2502
Joined: Wed 19 Oct 2005, 13:06
Location: Hell more grotesque than any medieval woodcut

#283 Post by Dougal »

I've writtten a script to replace test-scsi.
Attachments
test-scsi.gz
(390 Bytes) Downloaded 686 times
What's the ugliest part of your body?
Some say your nose
Some say your toes
But I think it's your mind

SimonW
Posts: 60
Joined: Wed 28 Mar 2007, 23:15
Location: UK

#284 Post by SimonW »

Dougal,

Should I look for changed behaviour in Pmount with test-scsi changed for your version?

Or perhaps it's changed for another reason!

User avatar
Dougal
Posts: 2502
Joined: Wed 19 Oct 2005, 13:06
Location: Hell more grotesque than any medieval woodcut

#285 Post by Dougal »

SimonW wrote:Should I look for changed behaviour in Pmount with test-scsi changed for your version?
No, I think Pmount only uses probedisk and probepart.
What's the ugliest part of your body?
Some say your nose
Some say your toes
But I think it's your mind

msumner
Posts: 205
Joined: Fri 05 Jan 2007, 01:10
Location: Lincolnshire, England.

#286 Post by msumner »

SimonW wrote:
If it's not a long answer, could someone explain (even if it's just a link to another part of the Puppy forums) regarding how to remaster?
Hi Simon, I guess that you could not find remaster in the menu. Me neither. There are two remastering programs in /usr/sbin/, They are pupremaster.sh which appears to be an adaptation of dougals enhanced remaster, and remasterpup2 which looks like a Nathan experiment, as it invites anyone to give it a try. Both come with instructions, so take a look. I have not tried them yet, but I should as I am looking into putting a remastering section in the help files.
Cheers, Mike

User avatar
Dougal
Posts: 2502
Joined: Wed 19 Oct 2005, 13:06
Location: Hell more grotesque than any medieval woodcut

#287 Post by Dougal »

I've updated the installer to (hopefully) fix the problem with vfat being regognized as ext3. It's up to Nathan now to update his version... (it's really trivial and shouldn't require any Grafpup-specific coding, so the new code can just be added to the old installer)


While I'm here: anyone (especially those with SATA drives) feel like running my hardware test dotpup? It shouldn't take more than a few seconds...
Attachments
HW-test.pup
(1.86 KiB) Downloaded 662 times
What's the ugliest part of your body?
Some say your nose
Some say your toes
But I think it's your mind

SimonW
Posts: 60
Joined: Wed 28 Mar 2007, 23:15
Location: UK

#288 Post by SimonW »

Here you are Dougal.
Attachments
results-simonw.tar.gz
On a VIA EIPA machine with 1 Sata drive and 1 CF in IDE adapter (booted from)
(7.07 KiB) Downloaded 710 times

SimonW
Posts: 60
Joined: Wed 28 Mar 2007, 23:15
Location: UK

#289 Post by SimonW »

I've found a couple more things (sorry Nathan!):

When I first boot up my VIA EPIA machine with Sata drive and CF boot media, Grafpup always comes up in (what looks like) 640x480 mode. It might be 800x600 but is a shock compared to the expected 1024x768.

Looking round for clues I spotted an error message, it might not be related, but:
In /var/log/bootsysinit.log ... savepuppyd: Line 16: -eq : Unary operator expected.
At line 16 of /usr/sbin/savepuppyd we have a [ test checking the variable $PUPMODE to be 2.
I could be wrong, but should this be testing GRAFMODE now?

A menu-initiated reboot comes up in the expected 1024x768. But the strangest thing is that a menu-power-off and then a manual turn-on is then in 1024x768 again. Wow!
I noted a message flying by after the echo "This script will run X windows for you" but am not quick enough to read it. I do not know if X uses a log file to see the error later. It's not in /var/log/messages.


The second thing is that the beta iso's ffmpeg installation might have a problem?
Trying to compile my motion application resulted in a missing libdts.so.0 error - my app could not link.

Typing 'ffmpeg' on its own also resulted in this same error. What should happen is a long 'usage' message. The full text of the error was:
ffmpeg: error while loading shared libraries: libdts.so.0: Cannot open shared object file: No such file or directory.
And a 'find' does not show any files in the entire filesystem by that name.

EDIT: Found this earlier in this thread....
Posted: Sat Apr 28, 2007 2:12 pm Post subject:
Just go to a command line, cd to the directory that has your libdts-0.0.2.tar.gz and as root type:

pkgtool -install libdts-0.0.2

Will try this tonight.

Second Edit:
The libdts package in the repository didn't seem to install correctly, so I downloaded another - which had to be compiled from source - from here:
http://debian.unnet.nl/pub/videolan/libdts/0.0.2/

did './configure' then 'make' then 'make install' and my application, motion, which uses ffmpeg, then linked correctly. Brilliant.

Note that under grafpup if you want to repeat my steps, you'll need the 'devx_005.sfs' package.
Last edited by SimonW on Thu 10 May 2007, 11:56, edited 2 times in total.

msumner
Posts: 205
Joined: Fri 05 Jan 2007, 01:10
Location: Lincolnshire, England.

#290 Post by msumner »

Dougal, test results on dell 6400 using sata 100gb HDD and 1gb usb flash. Will this look for my built in cardreader?
Mike
Attachments
results-msumner.tar.gz
(8.11 KiB) Downloaded 731 times

Post Reply