(old)Puppy Linux Discussion Forum

OK, I've updated probedisk and probepart to the newest versions. I also grabbed Pawdio convertor to add to the tree. I'll see what I can do with the installer sometime soon.

Mike - about the glx problem, open up /etc/X11/xorg.conf and make sure there is a line like this: Also make sure it isn't commented out. It's possible it might not even run in Xvesa, too.

Nathan

Hi Dougal,

Here is the output of disktype on /dev/sdc (my CF card slot, definitely with a FAT16 car d inserted). As you can see I can mount the card, and a Grafpup installation is there.

sh-3.00# disktype /dev/sdc
--- /dev/sdc
Block device, size 488.7 MiB (512483328 bytes)
DOS partition map
Partition 1: 488.2 MiB (511934976 bytes, 999873 sectors from 63, bootable)
Type 0x06 (FAT16)
FAT16 file system (hints score 5 of 5)
Volume size 488.0 MiB (511664128 bytes, 62459 clusters of 8 KiB)
Volume name ""
Ext3 file system
UUID 775A90AB-A419-40E3-BBDD-0F2C3B17AEDF (DCE, v4)
Volume size 488.7 MiB (512483328 bytes, 500472 blocks of 1 KiB)

sh-3.00# sh-3.00# fdisk /dev/sdc
Command (m for help): p
Disk /dev/sdc: 512 MB, 512483328 bytes
16 heads, 63 sectors/track, 993 cylinders
Units = cylinders of 1008 * 512 = 516096 bytes
Device Boot Start End Blocks Id System
/dev/sdc1 * 1 992 499936+ 6 FAT16
Command (m for help): q
sh-3.00# mount -t vfat /dev/sdc1 /mnt/flash
sh-3.00# ls -l /mnt/flash
-rwxr-xr-x 1 root root 87732224 May 2 22:53 graf_005.sfs
-rwxr-xr-x 1 root root 0 May 2 22:52 ideflash
-rwxr-xr-x 1 root root 1298241 May 2 22:52 initrd.gz
-r-xr-xr-x 1 root root 9776 May 3 06:52 ldlinux.sys
-rwxr-xr-x 1 root root 74 May 2 22:52 syslinux.cfg
-rwxr-xr-x 1 root root 1833032 May 2 22:52 vmlinuz
-rwxr-xr-x 1 root root 18878464 May 2 22:53 zdrv_005.sfs
sh-3.00#


I can't swear that this card didn't ever have an ext3 fs on it, as I reprogrammed/formatted a lot of cards in a lot of ways. Perhaps there's a 'deleted partition' in the table which is being picked up on, or it's 'falling through' some logic.

And:

sh-3.00# probepart /dev/sdc
libcfdisk: unable to open /dev/sda
libcfdisk: unable to open /dev/sdb
libcfdisk: unable to open /dev/sdd
/dev/hdd1|ntfs|131074272|OS/2 HPFS or NTFS
/dev/hdd2|ntfs|143364060|OS/2 HPFS or NTFS
/dev/hdd3|ntfs|174080340|OS/2 HPFS or NTFS
/dev/hdd4|ntfs|39873330|OS/2 HPFS or NTFS
/dev/hdc1|vfat|28675962|Win95 FAT32 (LBA)
/dev/hdc2|ntfs|131395635|OS/2 HPFS or NTFS
/dev/hda|iso9660|0|PIONEER DVD-RW DVR-110
/dev/sdc1|msdos|999873|DOS 16-bit FAT >=32M
sh-3.00#

sh-3.00# /usr/lib/mut/bin/guess_fstype /dev/sdc
ext3
sh-3.00#

.... but .....

sh-3.00# /usr/lib/mut/bin/guess_fstype /dev/sdc1
vfat
sh-3.00#

So, if guess_fstype is used to look at /dev/sdc it says ext3, which is wrong since the card is partitioned, with the only partition being a vfat. Perhaps it can't cope with being called incorrectly (with sdc instead of sdc1)? guess_fstype is a binary so I can't have a look.

And your new probepart3:

sh-3.00# ./probepart3
/dev/hdc1|vfat|28675962
/dev/hdc2|ntfs|131395634
/dev/hdd1|ntfs|131074272
/dev/hdd2|ntfs|143364060
/dev/hdd3|ntfs|174080340
/dev/hdd4|ntfs|39873330
/dev/sdc1|vfat|999872
/dev/sdd|none|0
/dev/sdb|none|0
/dev/sda|none|0
/dev/hda|iso9660|0
sh-3.00#

I hope this helps you. I may try installing the probepart3 in /sbin and running the Installer.
Cheers,
Simon.

Dougal,

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.
It still completes ok as long as I follow the vfat instructions I posted before.

You'll need to remove the 3 from the end and replace the existing files in /sbin

Nathan,

Nathan F wrote:
Mike - about the glx problem, open up /etc/X11/xorg.conf and make sure there is a line like this:

Code: Select all

Load       "glx"

Nathan

Hmmmm, that was interesting There were 2 files called xorg.conf. One had the required line of code, and the other did not. I renamed the one without to xorgwrong.conf and tried blender from the terminal. It started and seemed to run ok, but put this message up:

sh-3.00# blender
Compiled with Python version 2.4.
Could not find platform independent libraries <prefix>
Could not find platform dependent libraries <exec_prefix>
Consider setting $PYTHONHOME to <prefix>[:<exec_prefix>]
'import site' failed; use -v for traceback
Checking for installed Python... No installed Python found.
Only built-in modules are available. Some scripts may not run.
Continuing happily.
Saved session recovery to /tmp/quit.blend

Blender quit
sh-3.00#

Mike

Mike -

Blender currently doesn't support Python-2.5, which happens to be the version which is in the repo. What it is telling you is that it cannot find a python-2.4 installation, so some of the extra scripting capabilities will not work. Blender actually contains an internal Python interpreter already, so most of the functionality will be there even without installing Python.

I have considered offering a Python-2.4 package for compatibility. However, it would be largely a waste as just about everything else can use the newer version.

Nathan

Thanks Nathan, I see what you mean.

Simon, thanks for the advice on the SD card.

You were right about the lack of facility in the bios to boot from flash cards. It would still be very handy to be able to use the built in cardreader for my sony camera card and for backing up, transferring files etc. with the sd card. Probedisk3 did not see it. Maybe it is a lack of driver?
Mike

You'll need to remove the 3 from the end and replace the existing files in /sbin

Yep, did that, thanks for the hint. I think the problem with the Installer identifying vfat/ext3 may not be dependent on probedisk/probepart.

Does the Installer use guess_fstype? If it does, and it uses 'guess_fstype /dev/sdc' then the FAT16 partition in /dev/sdc1 is not identified, and guess_fstype reports ext3. This is shown above in my post yesterday.


Mike,

It would still be very handy to be able to use the built in cardreader for my sony camera card and for backing up, transferring files etc. with the sd card. Probedisk3 did not see it. Sad Maybe it is a lack of driver?

Hmm. If they have put the cardreader hardware somewhere unconventional, ie. not on USB, then maybe a custom driver is required. You may not find one for Linux. I know nothing of laptops other than their hardware designs are often non-standard......

Last night I preserved a Static IP address over a reboot using a graf_save.2fs file on a HDD

I shall test it on a CF card next. I believe the only way to go, to avoid the 'graf_ro2 is overlapped' error mentioned in a previous post, is to use a Save File rather than writing to the Partition.

Cheers,
Simon.

Nathan, a small bug I found was running pbdict as a regular user. You need to make /usr/local/PBdict world writable becasue the program makes a temp file inside that directory.

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.