Loading...
  OR  Zero-K Name:    Password:   

Post edit history

Skirmish freeze (i.e "Spring starting...") and no infolog.txt

To display differences between versions, select one or more edits in the list using checkboxes and click "diff selected"
Post edit history
Date Editor Before After
8/14/2015 6:42:24 AMCArankPOLAX before revert after revert
8/14/2015 12:29:44 AMCArankPOLAX before revert after revert
8/14/2015 12:26:24 AMCArankPOLAX before revert after revert
8/14/2015 12:24:59 AMCArankPOLAX before revert after revert
Before After
1 Okay I just want to give a shout out to all the players, like Anarchid, who offered to help me out with a special thanks to Chesti for helping me resolve this (you're gettin' the kudos from me you deserve too for this one buddy). Even though this is embarrassing and I ended up with some egg on my face I figured I should do a writeup in case someone else ends up in the same situation: 1 Okay I just want to give a shout out to all the players, like Anarchid, who offered to help me out with a special thanks to Chesti for helping me resolve this (you're gettin' the kudos from me you deserve too for this one buddy). Even though this is embarrassing and I ended up with some egg on my face I figured I should do a writeup in case someone else ends up in the same situation:
2 \n 2 \n
3 Both the crash and the hang were due to the Zero-K Lobby (in .NET) being unable to run the spring executable. It turns out that (in order to lighten the RAM demand on this system running with no HDD) I had moved the .spring folder to a USB Thumbdrive and soft-linked it to my home directory (e.g. ~/.spring -> /media/mint/Thumbdrive/Spring). The problem occurred because the FAT file system under Linux (vfat) is not a full VFS implementation and doesn't implement eXecution unless specially mounted. So one solution would be to remount the Thumbdrive (e.g. mount -o umask=000 /dev/sdb1 /media/mint/Thumbdrive). The other solution (the one I opted for) was to create a 1.5GB loopback device with a "real" (i.e. fully VFS compliant) filesystem on it as follows: 3 Both the crash and the hang were due to the Zero-K Lobby (in .NET) being unable to run the spring executable. It turns out that (in order to lighten the RAM demand on this system running with no HDD) I had moved the .spring folder to a USB Thumbdrive and soft-linked it to my home directory (e.g. ~/.spring -> /media/mint/Thumbdrive/Spring). The problem occurred because the FAT file system under Linux (vfat) is not a full VFS implementation and doesn't implement eXecution unless specially mounted. So one solution would be to remount the Thumbdrive (e.g. mount -o umask=000 /dev/sdb1 /media/mint/Thumbdrive). The other solution (the one I opted for) was to create a 1.5GB loopback device with a "real" (i.e. fully VFS compliant) filesystem on it as follows:
4 [code] 4 [spoiler]
5 dd if=/dev/zero of=/media/mint/Thumbdrive/thumbdrive2.img bs=1M count=1500 5 dd if=/dev/zero of=/media/mint/Thumbdrive/thumbdrive2.img bs=1M count=1500
6 mkreiserfs -fl 'Spring Files' /media/mint/Thumbdrive/thumbdrive2.img 6 mkreiserfs -fl 'Spring Files' /media/mint/Thumbdrive/thumbdrive2.img
7 losetup -f /media/mint/Thumbdrive/thumbdrive2.img 7 losetup -f /media/mint/Thumbdrive/thumbdrive2.img
8 mkdir /mnt/ThumbDrive2 8 mkdir /mnt/ThumbDrive2
9 mount /dev/loop1 /mnt/ThumbDrive2 9 mount /dev/loop1 /mnt/ThumbDrive2
10 mv /media/mint/Thumbdrive/Spring /mnt/ThumbDrive2 10 mv /media/mint/Thumbdrive/Spring /mnt/ThumbDrive2
11 [/code] 11 [/spoiler]
12 \n 12 \n
13 TADA! Done... 13 TADA! Done...