Installing timidity when booting from CD for first time (ie no pup_save) is refused stating that timidity will require 50MB and there's only 40MB available (when over 100MB is actually showing on the status bar and timidity only requires 10MB anyway).
Saving to pup_save (of 32MB I think) and rebooting from that pup_save then allows timidity to be installed.
Seems that something's wrong with the calculations for how much space is available and how much space is needed.
This was the case with Puppy 2.14 and I assume hasn't been fixed.
Installing package makes wrong space requirement calculation
- BlackAdder
- Posts: 385
- Joined: Sun 22 May 2005, 23:29
Yes, a similar problem happened to me with EZPup.
I think the problem is caused by this code in Pupget:
It seems that the number of free blocks in the file system reported by STAT is the number of 4K blocks whereas the code thinks they are 1K blocks.
The code is around lines 880-890 depending on release. Changing it like this very crude hack worked with EZPup, but it might under-estimate required space for some .pets.
Hope that helps.
I think the problem is caused by this code in Pupget:
Code: Select all
EXPFREEB=`stat --filesystem --format=%f /` #no. free blocks.
EXPFILEB=`stat --format=%b $APKGNAMEEX` #no. blocks.
EXPNEEDB=`expr $EXPFILEB \* 5` #bz2 can expand up to x3, need twice temp space.
The code is around lines 880-890 depending on release. Changing it like this very crude hack worked with EZPup, but it might under-estimate required space for some .pets.
Code: Select all
EXPFREEB=`stat --filesystem --format=%f /` #no. free blocks.
EXPFILEB=`stat --format=%b $APKGNAMEEX` #no. blocks.
EXPNEEDB=`expr $EXPFILEB \* 1` #bz2 can expand up to x3, need twice temp space.
Yes, that's right - stat displays its results in the block size of the device that the file resides on, so pupget needs to be modified to adjust the number of blocks read by stat in each case to a standard unit. In fact, I wonder if stat has a bug. For example, "stat /zdrv_214.sfs" on my installation to hard disk shows 34728 blocks of 4096 bytes, but the file size is 17756160 bytes according to 'ls' and that would fit 34728 blocks of 512 bytes, so it looks like stat is reporting the wrong block size. 'du' on the same file shows 17364(kB) which matches 'ls'. I recommend dumping stat for file size calculation. Use "ls -l $FILE | awk '{print $5 / 1024}' " to get the size of $FILE in kB and using "stat -t -f / | awk '{print $7 / 1024 * $8}' " to get the available space in the / file system (again in kB). The 'ls' solution will work on every Unix variant I've met in the past 25 years. I'd prefer to use 'df' rather than stat but BusyBox df won't do "df /" and I haven't tested it when booted from CD to make sure that I pick / correctly.
Also, I think that a factor of 5 is a bit excessive. This may be the case for text but executables and compressed images would hardly be further compressed by gzip. A factor of 2 is more likely in my opinion.
Also, I think that a factor of 5 is a bit excessive. This may be the case for text but executables and compressed images would hardly be further compressed by gzip. A factor of 2 is more likely in my opinion.
ran into a similar problem with:jeffrey wrote:...BusyBox df won't do "df /"...
Code: Select all
ls -d */ | while read name
Code: Select all
df /*
Oops. Two posts in the wrong forum. Should have been in Bugs forum...
No, John, the point of "df /" is to ask the system for the one line which displays information for the file system mount at /. With Puppy I'm not sure how useful the full df would be anyway given the various methods of loading Puppy and the unionfs/aufs approach, loopback mounts, etc. Perhaps df can be used but it will probably need to be filtered with something like awk to select the right line no matter how Puppy is booted. I haven't time to test the various output and create a reliable filter.
No, John, the point of "df /" is to ask the system for the one line which displays information for the file system mount at /. With Puppy I'm not sure how useful the full df would be anyway given the various methods of loading Puppy and the unionfs/aufs approach, loopback mounts, etc. Perhaps df can be used but it will probably need to be filtered with something like awk to select the right line no matter how Puppy is booted. I haven't time to test the various output and create a reliable filter.