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