enemy territory

darut · 2005-04-20 09:32:47

When I try to install ET I get this:

"Verifying archive integrity... All good.
Uncompressing Enemy Territory 2.55.........................
Extraction failed.
Signal caught, cleaning up"

anybody had such problem?

polarrr · 2005-04-20 10:18:13

I had that with another game. What did it was commenting out tmpfs line in fstab and reboot and try extracting the game. I don't know if it's a legitimate way of fixing things, but it does the job for me and I haven't really come across any problems, so. Give it a try.

darut · 2005-04-20 10:31:58

thank you
it solved the problem

Beavis · 2005-04-20 14:11:01

Yeah I had that problem as well and with some other games too. I believe it happens because /tmp becomes full before the installer has finished uncompressing. To solve it permanently just modify your fstab file to make the /tmp size larger as shown below.

# <file system>        <dir>         <type>    <options>          <dump> <pass> 
   tmpfs                /tmp          tmpfs     size=2g            0      0

This should give you a 2 gig /tmp instead of the default of 256 meg.

Stinky · 2005-04-20 14:52:27

Yeah. The default size for the tmpfs is like 256MB. It will fill up uncompressing a game...downloading a large file...etc. If I remember right, (it's been well over a year) the way I fixed it is I commented out the line in fstab...rebooted...then renamed /tmp to tmp.old...then made a sym link called /tmp that went to /var/tmp. Uncommented the line in fstab and rebooted again and tmpfs is now mounted on /var/tmp. Which is a 7GB drive so it has plenty of room.
I guess there's not really a "right" way to do it. Just however you'd rather take care of it.
Thanks,
Tim

iphitus · 2005-04-20 14:59:04

just remember, /tmp when used as tmpfs is in ram, so you cant set its value higher than the ram you have.

the alternative is to not mount it at all and let it use hdd

Stinky · 2005-04-20 15:09:40

I got a chance to ssh in..(i'm at work) and I almost had it right. I did make the /tmp symlink to /var/tmp because /var is on a bigger partition. But I left the tmpfs entry in fstab commented out.
I was close!

Jacob · 2005-04-21 20:28:49

Beavis wrote:

Yeah I had that problem as well and with some other games too. I believe it happens because /tmp becomes full before the installer has finished uncompressing. To solve it permanently just modify your fstab file to make the /tmp size larger as shown below.
# <file system>        <dir>         <type>    <options>          <dump> <pass> 
   tmpfs                /tmp          tmpfs     size=2g            0      0
This should give you a 2 gig /tmp instead of the default of 256 meg.

This is good advise for everyone, I would like to see this as a permanent part of Arch (i.e. a larger /tmp)

If anyone has tried to do a cd-copy with K3B, it too writes the initial ISO to the /tmp folder. Which usually ends in failure when /tmp fills up.

This is a good tip!

Jacob

Meshuggin · 2005-04-21 21:25:47

Jacob wrote:

If anyone has tried to do a cd-copy with K3B, it too writes the initial ISO to the /tmp folder. Which usually ends in failure when /tmp fills up.
This is a good tip!
Jacob

Yes Jacob, I have this problem with GnomeBaker, so I've been burning CD's on command line , I'll try this tip to see if it works

iphitus · 2005-04-22 01:46:49

Jacob wrote:

Beavis wrote:
Yeah I had that problem as well and with some other games too. I believe it happens because /tmp becomes full before the installer has finished uncompressing. To solve it permanently just modify your fstab file to make the /tmp size larger as shown below.
# <file system>        <dir>         <type>    <options>          <dump> <pass> 
   tmpfs                /tmp          tmpfs     size=2g            0      0
This should give you a 2 gig /tmp instead of the default of 256 meg.
This is good advise for everyone, I would like to see this as a permanent part of Arch (i.e. a larger /tmp)
If anyone has tried to do a cd-copy with K3B, it too writes the initial ISO to the /tmp folder. Which usually ends in failure when /tmp fills up.
This is a good tip!
Jacob

No, it wouldnt be good as a permanent part of Arch, not everyone has that much ram to throw around.

However its a good tip for those with more ram, and should be put in the wiki

Jacob · 2005-04-22 04:43:00

iphitus wrote:

No, it wouldnt be good as a permanent part of Arch, not everyone has that much ram to throw around.
However its a good tip for those with more ram, and should be put in the wiki

The key to this being effective on low memory systems is to designate a large swap partition.

tmpfs uses RAM/Swap not just RAM iphitus. It beats having to go through all the programs which are pre-configured to use /tmp and change it to something else... (like /var/whatever)

Or if you like to live dangerously (like me) run out and get a 1gig key. Format it and make it into a swap partition. Transfer rate of USB key -> system is faster than the transfer rate of HD -> system. Get a little performance boost, just remember to unplug

Jacob

xor · 2005-04-22 20:52:40

Answer of the first question may be:
--help when running the "et" installer will give you the --target option to unpack to another dir, not using /tmp
./et-linux-2.60.x86.run --target ET_unpack
Same with Q3 I think it was...
/xor

Dreameen · 2005-04-22 23:05:03

Or you can always hack the *.run file. Just open it in your favourite editor and change the destination variable(usually stated right at the beggining of file) from /tmp to some other directory that can handle the extra space. I usually unpack mine games to /home/dreameen/games as it has over 50 GB left

iphitus · 2005-04-23 01:48:00

Jacob wrote:

iphitus wrote:
No, it wouldnt be good as a permanent part of Arch, not everyone has that much ram to throw around.
However its a good tip for those with more ram, and should be put in the wiki
The key to this being effective on low memory systems is to designate a large swap partition.
tmpfs uses RAM/Swap not just RAM iphitus. It beats having to go through all the programs which are pre-configured to use /tmp and change it to something else... (like /var/whatever)
Or if you like to live dangerously (like me) run out and get a 1gig key. Format it and make it into a swap partition. Transfer rate of USB key -> system is faster than the transfer rate of HD -> system. Get a little performance boost, just remember to unplug
Jacob

I have 512mb ram, so that isnt a problem -- i also have an obsolete and totally useless 1gb swap partiiton that usually has at most, 500kb used.

Buying a USB key for that? That'd be a ridiculous waste of money, and the performance boost would be totally negligable.

Even on my old computer with 160mb ram, I can tell you, swap wasnt used a lot.

Jacob · 2005-04-23 03:45:03

iphitus wrote:

Jacob wrote:
iphitus wrote:
No, it wouldnt be good as a permanent part of Arch, not everyone has that much ram to throw around.
However its a good tip for those with more ram, and should be put in the wiki
The key to this being effective on low memory systems is to designate a large swap partition.
tmpfs uses RAM/Swap not just RAM iphitus. It beats having to go through all the programs which are pre-configured to use /tmp and change it to something else... (like /var/whatever)
Or if you like to live dangerously (like me) run out and get a 1gig key. Format it and make it into a swap partition. Transfer rate of USB key -> system is faster than the transfer rate of HD -> system. Get a little performance boost, just remember to unplug
Jacob
I have 512mb ram, so that isnt a problem -- i also have an obsolete and totally useless 1gb swap partiiton that usually has at most, 500kb used.
Buying a USB key for that? That'd be a ridiculous waste of money, and the performance boost would be totally negligable.
Even on my old computer with 160mb ram, I can tell you, swap wasnt used a lot.

Let me try to explain... "Low-memory" system (not by Linux kernel standard but by age of system) has about 128-256 megs of RAM. To buy archaic EDO ram, or expensive laptop SO-DIMM memory would cost too much money, and wouldn't be as effective as a USB key.

Looking at my laptop (for example), which has 256Megs of RAM, running KDE uses up all of this memory. I get anywhere from 50-150Megs of swap being utilized. To turn a RAM drive (based on a USB key) into swap is much faster and cheaper.

The reason for 1gig USB key and not anything smaller is because if someone wants to rip a CD to ISO, they'll need 700Megs, plus the additional 50-150Megs.

Lastly, when running KDE or GNOME on a computer which has low memory, this solution IS a viable solution.

Regards,

Jacob

Arch Linux

#1 2005-04-20 09:32:47

enemy territory

#2 2005-04-20 10:18:13

Re: enemy territory

#3 2005-04-20 10:31:58

Re: enemy territory

#4 2005-04-20 14:11:01

Re: enemy territory

#5 2005-04-20 14:52:27

Re: enemy territory

#6 2005-04-20 14:59:04

Re: enemy territory

#7 2005-04-20 15:09:40

Re: enemy territory

#8 2005-04-21 20:28:49

Re: enemy territory

#9 2005-04-21 21:25:47

Re: enemy territory

#10 2005-04-22 01:46:49

Re: enemy territory

#11 2005-04-22 04:43:00

Re: enemy territory

#12 2005-04-22 20:52:40

Re: enemy territory

#13 2005-04-22 23:05:03

Re: enemy territory

#14 2005-04-23 01:48:00

Re: enemy territory

#15 2005-04-23 03:45:03

Re: enemy territory

Board footer