(old)Puppy Linux Discussion Forum

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

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

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.

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

Nathan

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?

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

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.

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)

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

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.

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

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.

I've writtten a script to replace test-scsi.

Dougal,

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

Or perhaps it's changed for another reason!

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.

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

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

Here you are Dougal.

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.

Dougal, test results on dell 6400 using sata 100gb HDD and 1gb usb flash. Will this look for my built in cardreader?
Mike