Nice VadimSonya, though I would note the file paths in those instructions only apply to ramdisk installs, and that a world backup must be done for imports to persist after boot in ramdisk installs.
For regular installs the minecraft worlds folder is located at /mnt/<yourdrive>/minecraft/<world number> eg: /mnt/sda1/minecraft/one and backing up isn't required afterwords for the imported world to persist (though still recommended)
Nice VadimSonya, though I would note the file paths in those instructions only apply to ramdisk installs, and that a world backup must be done for imports to persist after boot in ramdisk installs.
For regular installs the minecraft worlds folder is located at /mnt/<yourdrive>/minecraft/<world number> eg: /mnt/sda1/minecraft/one and backing up isn't required afterwords for the imported world to persist (though still recommended)
I'll change that on the wiki.
Edit: Done, hope everything works out.
The cleaned up interface courtesy of Segana is in, but I'm still having problems with commands from the web panel not being executed.
The iso is in the test build folder I linked earlier under mineos+_testbuild10.iso if anyone wants to take a look at it. The admin.py methods are executed fine by admin_console.py, but don't seem to get executed by admin.cgi. I haven't figured out how to manually test the cgi script from the command line yet, so if anyone knows how or has any suggestions let me know.
None of these scripts has been modified at all (all our fixes have all been to the install scripts), so I do not understand why they are not working anymore.
The good news is that the updated install scripts seem to work fine, and manually updating server with the admin_console.py update script pulls the right files for everything, and mapping now works again as advertised.
Unless anyone has any other ideas, I am starting with a fresh copy of MineOS 1.27 when I wake up and reimplementing the changes again to the individual files see if there is some weird file encoding issue from moving between different OSs.
Thanks Mike, you helped me find half the problem! Commands from the web panel are working fine now. I am uploading MineOS+_testbuild11.iso to the test release folder, and as long as everything else checks out will be releasing it as MineOS+ v0.1.0 this afternoon. Then we can start rewriting the install to make it simpler and more automated, and implementing new features.
is there a workaround for minecraft blanking out the server.properties file?
I have not run into this bug yet. Any more info? Is it on RAMDISK or regular install?
Test build 11 still has the bug where the usebukkit file is not created on RAMDISK installs. Can anyone confirm if this is the case on regular installs too?
Excellent, I'm trying to nail down the usebukkit bug now.
@ people testing - BTW, the server hosting the craftbukkit jar is down, and they are working on getting it back up. Update server files will download an empty craftbukkit jar because of this. You can manually download craftbukkit from one of the mirrors in the meantime.
Thanks for picking up hexparrot's work guys, i was worried the entire project would die.
I was forced to run MineOS on a VirtualBox because my Windows 7 host would drop users (I'm guessing due to the poor network code Minecraft uses).
Where should we add feature requests? The sourceforge project?
Rollback Post to RevisionRollBack
"Operation grass-seed": Before and Current
(current link is updated dynamically from my MC server...)
Images are made using c10t with --limits, run every 5 minutes, images are compared to a MD5 of the previous image, only changes are kept.
Hi- I'm running the latest version of MineOS with build 614 of Bukkit and have been running one server on port 25565 for ages. However, when I try to use 25566 for a second world it gives users Connection Timed Out: Connect. I have it forwarded and have it opened up in the firewall of MineOS, so I don't see what the problem could be....any help?
is there a workaround for minecraft blanking out the server.properties file?
I have not run into this bug yet. Any more info? Is it on RAMDISK or regular install?
ramdisk install.
i think this is a minecraft bug, rather than a mineos bug. i have just run into it for the 3rd or 4th time. right now i have to copy over a backup server.properties file whenever this happens. i thought hexaparrot attempted to address this by doing something with SQL and then gave up. all this really needs is for the python scripts to maintain 2 copies of the file (new world, editing any setting, etc.), and whenever the server is started, it should check if the size of server.properties is 0 and if so copy over from the backup copy.
is there a workaround for minecraft blanking out the server.properties file?
I have not run into this bug yet. Any more info? Is it on RAMDISK or regular install?
ramdisk install.
i think this is a minecraft bug, rather than a mineos bug. i have just run into it for the 3rd or 4th time. right now i have to copy over a backup server.properties file whenever this happens. i thought hexaparrot attempted to address this by doing something with SQL and then gave up. all this really needs is for the python scripts to maintain 2 copies of the file (new world, editing any setting, etc.), and whenever the server is started, it should check if the size of server.properties is 0 and if so copy over from the backup copy.
Couple more questions to make sure I understand the full scope of the problem:
You are running MineOS 1.28.11 not the failed 2.0 version he posted then withdrew right?
Does this only occur after a reboot, or can it happen with a stop/start world?
Keeping a backup of the server.properties file and checking for a 0 byte file on start shouldn't be difficult to add in, just want to make sure it is necessary and not something else that's wrong as this is the first time I have heard of this occurring.
Phant0mX wrote:
yossi wrote:
is there a workaround for minecraft blanking out the server.properties file?
I have not run into this bug yet. Any more info? Is it on RAMDISK or regular install?
ramdisk install.
i think this is a minecraft bug, rather than a mineos bug. i have just run into it for the 3rd or 4th time. right now i have to copy over a backup server.properties file whenever this happens. i thought hexaparrot attempted to address this by doing something with SQL and then gave up. all this really needs is for the python scripts to maintain 2 copies of the file (new world, editing any setting, etc.), and whenever the server is started, it should check if the size of server.properties is 0 and if so copy over from the backup copy.
From what i experienced, this is due to an improper shutdown of mineos, i had this problem only on reboot after crashes.
Phant0mX wrote:
yossi wrote:
is there a workaround for minecraft blanking out the server.properties file?
I have not run into this bug yet. Any more info? Is it on RAMDISK or regular install?
ramdisk install.
i think this is a minecraft bug, rather than a mineos bug. i have just run into it for the 3rd or 4th time. right now i have to copy over a backup server.properties file whenever this happens. i thought hexaparrot attempted to address this by doing something with SQL and then gave up. all this really needs is for the python scripts to maintain 2 copies of the file (new world, editing any setting, etc.), and whenever the server is started, it should check if the size of server.properties is 0 and if so copy over from the backup copy.
From what i experienced, this is due to an improper shutdown of mineos, i had this problem only on reboot after crashes.
I hope this helps a bit.
I agree - this only happened to me when I had Virtual Box (and hence MineOS) crash and I had to do a hard reboot. Apart from that I didnt have the error.
Until this new + version is out as I able to update my current server file via FTP and carry on with my 1.3 world?
Easiest workaround would be sure you do a "sudo filetool.sh -b" after a new world has been created, and then started for the first time, or run the 90_reboot_sudo.sh script again (does the same thing, just reboots after). What is happening is that the server.properties file is tagged for persistence, but isn't created until the mc server is first started, which is after the create world script backed it up, lol. It's a pretty small bug as you only need to properly shutdown once to ensure it doesn't happen to you. Will look into a better fix as we start modifying the python scripts.
For now, yes you can just copy a good server.properties over. Just make sure you "sudo filetool.sh -b" or "sudo ./90_reboot_sudo.sh" afterwords so it doesn't keep happening. Do the same if you ever edit it.
We probably should add web panel buttons labeled "save changes" and "reboot server" respectfully that run those two scripts.
Hi- I'm running the latest version of MineOS with build 614 of Bukkit and have been running one server on port 25565 for ages. However, when I try to use 25566 for a second world it gives users Connection Timed Out: Connect. I have it forwarded and have it opened up in the firewall of MineOS, so I don't see what the problem could be....any help?
Make sure opened the port in the MineOS firewall (within ip-tables), and don't forget to "sudo filetool.sh -b" after edits.
Hi- I'm running the latest version of MineOS with build 614 of Bukkit and have been running one server on port 25565 for ages. However, when I try to use 25566 for a second world it gives users Connection Timed Out: Connect. I have it forwarded and have it opened up in the firewall of MineOS, so I don't see what the problem could be....any help?
Make sure opened the port in the MineOS firewall (within ip-tables), and don't forget to "sudo filetool.sh -b" after edits.
Automatically opening a port with ip-tables if it isn't already when a new world is created added to the list of things to do, lol.
Sure. Are you running windows?
@Lhun - Great. Help is always appreciated, especially good testing feedback which you sound very capable of.
Assembled rather haphazardly but should do the trick.
http://mineos.000a.biz/index.php/Transferring_Worlds
Nice VadimSonya, though I would note the file paths in those instructions only apply to ramdisk installs, and that a world backup must be done for imports to persist after boot in ramdisk installs.
For regular installs the minecraft worlds folder is located at /mnt/<yourdrive>/minecraft/<world number> eg: /mnt/sda1/minecraft/one and backing up isn't required afterwords for the imported world to persist (though still recommended)
I'll change that on the wiki.
Edit: Done, hope everything works out.
The iso is in the test build folder I linked earlier under mineos+_testbuild10.iso if anyone wants to take a look at it. The admin.py methods are executed fine by admin_console.py, but don't seem to get executed by admin.cgi. I haven't figured out how to manually test the cgi script from the command line yet, so if anyone knows how or has any suggestions let me know.
None of these scripts has been modified at all (all our fixes have all been to the install scripts), so I do not understand why they are not working anymore.
The good news is that the updated install scripts seem to work fine, and manually updating server with the admin_console.py update script pulls the right files for everything, and mapping now works again as advertised.
Unless anyone has any other ideas, I am starting with a fresh copy of MineOS 1.27 when I wake up and reimplementing the changes again to the individual files see if there is some weird file encoding issue from moving between different OSs.
Will let you all know how it goes.
I have not run into this bug yet. Any more info? Is it on RAMDISK or regular install?
Test build 11 still has the bug where the usebukkit file is not created on RAMDISK installs. Can anyone confirm if this is the case on regular installs too?
Test build folder link again for those who don't want to go back through the thread looking for it:
https://sourceforge.net/projects/mineosplus/files/Test%20Builds/
@ people testing - BTW, the server hosting the craftbukkit jar is down, and they are working on getting it back up. Update server files will download an empty craftbukkit jar because of this. You can manually download craftbukkit from one of the mirrors in the meantime.
Craftbukkit official mirrors:
http://bukkit.org/craftbukkit-b617.jar
http://evilseph.malloc.us/.int/bukkit/c ... t-b617.jar
make sure and rename it to craftbukkit-0.0.1-SNAPSHOT.jar before uploading it to your server.
I was forced to run MineOS on a VirtualBox because my Windows 7 host would drop users (I'm guessing due to the poor network code Minecraft uses).
Where should we add feature requests? The sourceforge project?
(current link is updated dynamically from my MC server...)
Images are made using c10t with --limits, run every 5 minutes, images are compared to a MD5 of the previous image, only changes are kept.
ramdisk install.
i think this is a minecraft bug, rather than a mineos bug. i have just run into it for the 3rd or 4th time. right now i have to copy over a backup server.properties file whenever this happens. i thought hexaparrot attempted to address this by doing something with SQL and then gave up. all this really needs is for the python scripts to maintain 2 copies of the file (new world, editing any setting, etc.), and whenever the server is started, it should check if the size of server.properties is 0 and if so copy over from the backup copy.
Couple more questions to make sure I understand the full scope of the problem:
You are running MineOS 1.28.11 not the failed 2.0 version he posted then withdrew right?
Does this only occur after a reboot, or can it happen with a stop/start world?
Keeping a backup of the server.properties file and checking for a 0 byte file on start shouldn't be difficult to add in, just want to make sure it is necessary and not something else that's wrong as this is the first time I have heard of this occurring.
From what i experienced, this is due to an improper shutdown of mineos, i had this problem only on reboot after crashes.
I hope this helps a bit.
i am using MineOS 1.28.11
2.0 was retracted when he gave up on the overly complicated SQL solution to this bug.
/me goes to look through the earlier parts of this thread for the relevant posts
Easiest workaround would be sure you do a "sudo filetool.sh -b" after a new world has been created, and then started for the first time, or run the 90_reboot_sudo.sh script again (does the same thing, just reboots after). What is happening is that the server.properties file is tagged for persistence, but isn't created until the mc server is first started, which is after the create world script backed it up, lol. It's a pretty small bug as you only need to properly shutdown once to ensure it doesn't happen to you. Will look into a better fix as we start modifying the python scripts.
For now, yes you can just copy a good server.properties over. Just make sure you "sudo filetool.sh -b" or "sudo ./90_reboot_sudo.sh" afterwords so it doesn't keep happening. Do the same if you ever edit it.
We probably should add web panel buttons labeled "save changes" and "reboot server" respectfully that run those two scripts.
Make sure opened the port in the MineOS firewall (within ip-tables), and don't forget to "sudo filetool.sh -b" after edits.
Automatically opening a port with ip-tables if it isn't already when a new world is created added to the list of things to do, lol.