Quick question from a not-quite-proficient=yet xnix hack: can someone guide me to a post on how best to upgrade from v.11 to v.13 of the ISO and retain sda2 and sda3 (RAMDISK install).
Whoops, I forgot to upload the new mineos+.tcz to the test build folder to make this possible.
I'm doing so now, will be available in a couple minutes.
To upgrade just delete the old mineos+.tcz file from /mnt/<install drive>/tce/optional
Place the new file in there with an SCP client.
Backup your worlds/Stop your Minecraft servers
from the command line:
sudo filetool.sh -b
sudo reboot
to save and reboot
and enjoy the added functionality.
I will be writing a script to check if a newer version is out, download, install it and prompt for a reboot to be included in a later version. Yes, you will be able to run it from the web-panel.
In short, I'm not sure. I have not tried making a USB install of MineOS+ yet, so I can only speculate. It is possible the script files lost executable permissions during the transfer, or that file ownership was changed somehow. Those were the problems we ran into trying to rebuild the iso in Ubuntu, so it wouldn't surprise me at all. I now rebuild directly from within MineOS+ and that seems to have fixed everything.
Unfortunately with limited time to develop the project, USB install support isn't very high on the priority list right now. Hopefully we will have time in the future to get a USB install version out, but it probably will not be until after the bugs are all ironed out, and we have a 64-bit version, as those are top priority right now.
If you do manage to get it working, be sure and let me know what you did!
I think I have a working hypotheses for this behavior.
There is an error that comes up for me during boot. Something about cache and the harddrive. If this error has not come up by the time colored bootup text is gone (setting timezone, installing extensions, etc.) then the home folder will be vacant, and nothing seems to work (cfdisk is not there, for example).
So what I did was stick a random CD in the drive. When the computer is booting, it takes some extra time to spinup the CD and that gives enough time for my cache error to come up before the colored text is gone. Then it goes on to generate RSA keys and the install scripts magically appear.
I have not gone on from there yet due to lack of time but I will report further failures/successes as they happen.
btw, I have tried this with MineOS+ 10, 11 and 13 as well as MineOS.iso itself. Fairly consistent results.
In short, I'm not sure. I have not tried making a USB install of MineOS+ yet, so I can only speculate. It is possible the script files lost executable permissions during the transfer, or that file ownership was changed somehow. Those were the problems we ran into trying to rebuild the iso in Ubuntu, so it wouldn't surprise me at all. I now rebuild directly from within MineOS+ and that seems to have fixed everything.
Unfortunately with limited time to develop the project, USB install support isn't very high on the priority list right now. Hopefully we will have time in the future to get a USB install version out, but it probably will not be until after the bugs are all ironed out, and we have a 64-bit version, as those are top priority right now.
If you do manage to get it working, be sure and let me know what you did!
I think I have a working hypotheses for this behavior.
There is an error that comes up for me during boot. Something about cache and the harddrive. If this error has not come up by the time colored bootup text is gone (setting timezone, installing extensions, etc.) then the home folder will be vacant, and nothing seems to work (cfdisk is not there, for example).
So what I did was stick a random CD in the drive. When the computer is booting, it takes some extra time to spinup the CD and that gives enough time for my cache error to come up before the colored text is gone. Then it goes on to generate RSA keys and the install scripts magically appear.
I have not gone on from there yet due to lack of time but I will report further failures/successes as they happen.
btw, I have tried this with MineOS+ 10, 11 and 13 as well as MineOS.iso itself. Fairly consistent results.
Keep me posted. I've heard of this happening with USB drives before on other linux distros. I think it is related to how usb devices are read on boot or something, and it takes longer initially then a hard drive or something like that. When I get more time I'll look it back up. I'm fairly sure this is a general USB install problem on certain hardware and requires adjustments to the bootloader settings when you create the USB drive.
@Phant0mX
LOL I am in the middle of installing Build 13 and i was about to report that as a bug.
is crontabs set already?
Lol, my bad. In the future you can just mount the cd and copy the mineos+.tcz out of /tce/optional if I forget to upload it again. I have to remember to upload it first, because the iso takes forever and then I get distracted. :tongue.gif:
crontabs are not set by default yet, however the bug that was keeping them from working once set is fixed.
Just follow the default MineOS tutorial, and I'll try and add them to the first update after we release. If we keep adding new features without releasing something stable first it will never get done, lol.
As long as I can finish one more admin.py function, and fix the grub screen bug, and our web guru gets the last immediate changes to the interface done we will officially launch MineOS+ tomorrow (night probably? hopefully? lol)
And here is another little taste of the future:
A cellphone friendly admin page is being developed, as well as plans for an android app...
The default username and password used to be "tc : minecraft2011" (Now its blank, was that intended?)
I believe Hexparrot changed that in his last release. It makes sense, as it forces you to enter to run 20_passwords.sh, and you don't have to worry about looking up a default password anywhere so I'm fine with it.
I am planning on integrating the whole install process into a single user friendly script in the near future. It will do automatic partitioning by disk size percentage and not force you to view the uservars file by default, or you will be able to select advanced install to keep the functionality of the current scripts, but without having to run 4 of them.
Quote from Rachus »
Quote from Phant0mX »
<snip>... mineos+tcz uploaded to test build folder
Maybe Sourceforge is malfunctioning, but I can see the new testbuild13_tcz folder, and SF states:
Totals: 1 Item 569.3 KB
...but the file isn't present. I logged into Sourceforge, but still no file. Odd?
Very odd.. I'm about to upload test build 14 anyway, which finally fixes the usebukkit bug and the grub menu boot image bug. You will have to run this line to fix the grub menu if you are updating not reinstalling:
Apparently there can be a delay from when the files are uploaded to sourceforge until they can be downloaded for whatever reason. I'll add it to the repository, and post a link there if it isn't ready by the time i'm done with that.
Ha, thanks, I see both 13 and 14 now, I'd grabbed the whole ISO earlier -- no big deal, extracted the new tcz from it, have the new commands, Thanks for 14 and thanks for the grub splash fix!
Ha, thanks, I see both 13 and 14 now, I'd grabbed the whole ISO earlier -- no big deal, extracted the new tcz from it, have the new commands, Thanks for 14 and thanks for the grub splash fix!
No problem. Glad to see its being used. Please let me know of any bugs you run across, as 14 will be the first official release as soon as the web-panel logo and readme documentation are updated to reflect the fork to MineOS+
Watch for the official release and thread change, hopefully tomorrow.
Been using Will's MineOS since ~ December or so. Noticed the MineOS+ project. Thanks for taking over the development of MineOS!
So, I've setup both version 13&14 and I'm trying to edit the iptables to add new ports ( 9901&9902. Yeah, I know but that's what we have been using all along ) and it looks like the iptables in /usr/local/etc is now a link ( symlink? ). This link points to /tmp/tcloop/mineos+/usr/local/etc/iptables-rules . Prevsiulsy, there was no link and I could edit the iptables file to add the required ports.
How can I do this now? Looked over the last 20 pages in this thread but didn't see anything. Maybe I missed something - please don't shoot me.
This may have been covered already, I tried google with no results and I don't have time to sift through 70 pages looking for an answer, so sorry if this is a repeat.
I am trying to install as a primary OS. I am booting from CD, and using both the ISO from Hexaparot (I know its out of date) and test build 13 of MineOS+ I am getting the same problem. When I install it on my primary machine under Virtual Box using the same CD everything works as it should. But when I put the CD in my server box and boot up, it seems to skip past some stuff and the home directory is emtpy. I read above about a solution for booting from USB, but booting from USB is not an option as the motherboard does not support it.
Any help would be greatly appreciated
Rollback Post to RevisionRollBack
zombiecraft.serverbeer.com - Permissions enabled home server, focusing on big builds
while you kids were playing around, i made it work :tongue.gif: (j/k)
credit goes to yossi for figuring out that the usb needs time to load...
Nice! I'll try and add the info to the wiki tonight if I get the chance. Thanks!
Quote from bnm12 »
atm i'm trying to setup a wireless connection (yeah i know it's not perfect for servers, but i gotta work with what i have...)
but it's all sorts of annoying when you have a wpa secured network.. -.-
Wireless config from the command line? Ugh, yeah I bet thats fun.
Quote from Bassackwards »
So, I've setup both version 13&14 and I'm trying to edit the iptables to add new ports ( 9901&9902. Yeah, I know but that's what we have been using all along ) and it looks like the iptables in /usr/local/etc is now a link ( symlink? ). This link points to /tmp/tcloop/mineos+/usr/local/etc/iptables-rules . Prevsiulsy, there was no link and I could edit the iptables file to add the required ports.
The unedited file is a symlink, but once you edit it and run 'sudo filetool.sh -b' it should then show up as an actual file, which is backed up in /mnt/<boot driv>/tce/mydata.tgz
You can actually copy your old iptables-rules over and run the filetool script and that will work too.
This is just the way Tiny Core/Micro Core Linux works, as it always mounts the mineos+.tcz file system as read only and creates symlinks to the files unless it finds them while extracting mydata.tgz.
This allows the original files to remain unchanged.
Quote from Kayda »
Can this be used as a standalone Operating systes|
That's what its designed for. A standalone Linux OS completely dedicated to Minecraft hosting without any extras to eat up memory. If you need a GUI, or are looking to use it as your main daily use system however, this probably isn't your best option.
Quote from bionicsniper »
I will have some KVM tutorial stuff at some point tomorrow.
This may have been covered already, I tried google with no results and I don't have time to sift through 70 pages looking for an answer, so sorry if this is a repeat.
I am trying to install as a primary OS. I am booting from CD, and using both the ISO from Hexaparot (I know its out of date) and test build 13 of MineOS+ I am getting the same problem. When I install it on my primary machine under Virtual Box using the same CD everything works as it should. But when I put the CD in my server box and boot up, it seems to skip past some stuff and the home directory is emtpy. I read above about a solution for booting from USB, but booting from USB is not an option as the motherboard does not support it.
Any help would be greatly appreciated
Hmm, sounds like a similar problem where the microcore kernel isn't waiting long enough to get the info off the disk. Is it an older cdrom drive? There is probably a similar flag in the F2 boot options as discussed above about USB (if not try the usbwait fix posted above as I think I read that forces the system to wait in general, not just for USB devices).
Let me know how that works for you, and if it still isn't working and I'll check it out when I get back tonight.
So, I've setup both version 13&14 and I'm trying to edit the iptables to add new ports ( 9901&9902. Yeah, I know but that's what we have been using all along ) and it looks like the iptables in /usr/local/etc is now a link ( symlink? ). This link points to /tmp/tcloop/mineos+/usr/local/etc/iptables-rules . Prevsiulsy, there was no link and I could edit the iptables file to add the required ports.
The unedited file is a symlink, but once you edit it and run 'sudo filetool.sh -b' it should then show up as an actual file, which is backed up in /mnt/<boot driv>/tce/mydata.tgz
You can actually copy your old iptables-rules over and run the filetool script and that will work too.
This is just the way Tiny Core/Micro Core Linux works, as it always mounts the mineos+.tcz file system as read only and creates symlinks to the files unless it finds them while extracting mydata.tgz.
This allows the original files to remain unchanged.
Hmm. I've tried to edit and save but it tells me its read only. Never had that problem before. Naive here - how can I edit/save?
Whoops, I forgot to upload the new mineos+.tcz to the test build folder to make this possible.
I'm doing so now, will be available in a couple minutes.
To upgrade just delete the old mineos+.tcz file from /mnt/<install drive>/tce/optional
Place the new file in there with an SCP client.
Backup your worlds/Stop your Minecraft servers
from the command line:
sudo filetool.sh -b
sudo reboot
to save and reboot
and enjoy the added functionality.
I will be writing a script to check if a newer version is out, download, install it and prompt for a reboot to be included in a later version. Yes, you will be able to run it from the web-panel.
Edit: mineos+tcz uploaded to test build folder
I think I have a working hypotheses for this behavior.
There is an error that comes up for me during boot. Something about cache and the harddrive. If this error has not come up by the time colored bootup text is gone (setting timezone, installing extensions, etc.) then the home folder will be vacant, and nothing seems to work (cfdisk is not there, for example).
So what I did was stick a random CD in the drive. When the computer is booting, it takes some extra time to spinup the CD and that gives enough time for my cache error to come up before the colored text is gone. Then it goes on to generate RSA keys and the install scripts magically appear.
I have not gone on from there yet due to lack of time but I will report further failures/successes as they happen.
btw, I have tried this with MineOS+ 10, 11 and 13 as well as MineOS.iso itself. Fairly consistent results.
LOL I am in the middle of installing Build 13 and i was about to report that as a bug.
is crontabs set already?
Keep me posted. I've heard of this happening with USB drives before on other linux distros. I think it is related to how usb devices are read on boot or something, and it takes longer initially then a hard drive or something like that. When I get more time I'll look it back up. I'm fairly sure this is a general USB install problem on certain hardware and requires adjustments to the bootloader settings when you create the USB drive.
Lol, my bad. In the future you can just mount the cd and copy the mineos+.tcz out of /tce/optional if I forget to upload it again. I have to remember to upload it first, because the iso takes forever and then I get distracted. :tongue.gif:
crontabs are not set by default yet, however the bug that was keeping them from working once set is fixed.
Just follow the default MineOS tutorial, and I'll try and add them to the first update after we release. If we keep adding new features without releasing something stable first it will never get done, lol.
As long as I can finish one more admin.py function, and fix the grub screen bug, and our web guru gets the last immediate changes to the interface done we will officially launch MineOS+ tomorrow (night probably? hopefully? lol)
And here is another little taste of the future:
A cellphone friendly admin page is being developed, as well as plans for an android app...
Superb. Thank you kindly.
Maybe Sourceforge is malfunctioning, but I can see the new testbuild13_tcz folder, and SF states:
Totals: 1 Item 569.3 KB
...but the file isn't present. I logged into Sourceforge, but still no file. Odd?
EDIT: ...grabbed the whole ISO, extracted the new tcz from it, have the new commands, Thanks!
I believe Hexparrot changed that in his last release. It makes sense, as it forces you to enter to run 20_passwords.sh, and you don't have to worry about looking up a default password anywhere so I'm fine with it.
I am planning on integrating the whole install process into a single user friendly script in the near future. It will do automatic partitioning by disk size percentage and not force you to view the uservars file by default, or you will be able to select advanced install to keep the functionality of the current scripts, but without having to run 4 of them.
Very odd.. I'm about to upload test build 14 anyway, which finally fixes the usebukkit bug and the grub menu boot image bug. You will have to run this line to fix the grub menu if you are updating not reinstalling:
cp –p /home/tc/splashimage.xpm.gz /mnt/<your boot drive>/boot/grub
New tcz will be up in about 5 minutes, with the iso coming whenever it finishes uploading.
edit: Testbuild 14 download working fine for me.
No problem. Glad to see its being used. Please let me know of any bugs you run across, as 14 will be the first official release as soon as the web-panel logo and readme documentation are updated to reflect the fork to MineOS+
Watch for the official release and thread change, hopefully tomorrow.
Nice going!
Been using Will's MineOS since ~ December or so. Noticed the MineOS+ project. Thanks for taking over the development of MineOS!
So, I've setup both version 13&14 and I'm trying to edit the iptables to add new ports ( 9901&9902. Yeah, I know but that's what we have been using all along ) and it looks like the iptables in /usr/local/etc is now a link ( symlink? ). This link points to /tmp/tcloop/mineos+/usr/local/etc/iptables-rules . Prevsiulsy, there was no link and I could edit the iptables file to add the required ports.
How can I do this now? Looked over the last 20 pages in this thread but didn't see anything. Maybe I missed something - please don't shoot me.
Any help appreciated - still a linux newbie.
Thanks!
Bassackwards
-Cheers!
I will have some KVM tutorial stuff at some point tomorrow.
I am trying to install as a primary OS. I am booting from CD, and using both the ISO from Hexaparot (I know its out of date) and test build 13 of MineOS+ I am getting the same problem. When I install it on my primary machine under Virtual Box using the same CD everything works as it should. But when I put the CD in my server box and boot up, it seems to skip past some stuff and the home directory is emtpy. I read above about a solution for booting from USB, but booting from USB is not an option as the motherboard does not support it.
Any help would be greatly appreciated
See what we are building here: http://zombiecraft.servebeer.com
Nice! I'll try and add the info to the wiki tonight if I get the chance. Thanks!
Wireless config from the command line? Ugh, yeah I bet thats fun.
The unedited file is a symlink, but once you edit it and run 'sudo filetool.sh -b' it should then show up as an actual file, which is backed up in /mnt/<boot driv>/tce/mydata.tgz
You can actually copy your old iptables-rules over and run the filetool script and that will work too.
This is just the way Tiny Core/Micro Core Linux works, as it always mounts the mineos+.tcz file system as read only and creates symlinks to the files unless it finds them while extracting mydata.tgz.
This allows the original files to remain unchanged.
That's what its designed for. A standalone Linux OS completely dedicated to Minecraft hosting without any extras to eat up memory. If you need a GUI, or are looking to use it as your main daily use system however, this probably isn't your best option.
Thanks!
Hmm, sounds like a similar problem where the microcore kernel isn't waiting long enough to get the info off the disk. Is it an older cdrom drive? There is probably a similar flag in the F2 boot options as discussed above about USB (if not try the usbwait fix posted above as I think I read that forces the system to wait in general, not just for USB devices).
Let me know how that works for you, and if it still isn't working and I'll check it out when I get back tonight.
Hmm. I've tried to edit and save but it tells me its read only. Never had that problem before. Naive here - how can I edit/save?
Thanks
Bassackwards