Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

First boot script to check for Live #64

Open
DocCyblade opened this issue Oct 18, 2015 · 6 comments
Open

First boot script to check for Live #64

DocCyblade opened this issue Oct 18, 2015 · 6 comments
Assignees
Milestone

Comments

@DocCyblade
Copy link
Owner

While reading some first boot inithooks I saw

# exit if running live
grep -qs boot=casper /proc/cmdline && exit 2

This gave me the idea to detect this using an first boot script and only if running Live, detect memory and warn them if they less that 1GB. This should be pretty easy and the code I would need to write some of it like the detection of memory and cores would be shared with #63 I think this could be pretty easy to whip up and to test.

So should this delay the first release or is this something we should just put in for the second release? Thoughts?

@l-arnold
Copy link
Collaborator

Conceptually this is a great Idea.
Conservatively though we have to also consider other processes also.
IE Htop did add Ram Overhead.
I expect some people will be adding Mail Servers at some Point which will add Overhead (Postfix is not a true mail server in that it is hard to get in and out of with a variety of users).
Samba
Additional Addons
etc

All can change the Matrix.
Minimally a "Accept or Reject" choice, and potentially a "Tweak Choice" would make sense.
Seems if could be implemented though it would be awesome.

I have spent lots of time both on the Joomla App and the Magento App working on Memory Tweaks and it is not easy.

I think coming at the subjects from both "App Specific" and "Server Generic" views would be very compelling.

Again, lots of work in all this though.

@l-arnold
Copy link
Collaborator

Also, in terms of bringing "value to the user" best is that they build the "RIGHT SIZE" Server and not over or underbuild it. RAM and Processor resources can be "expensive". They are less so if we have a server running in the garage... that said, running the server in the garage is not cheap either - whether it is running at full capacity or 1 % of its capacity.

@DocCyblade DocCyblade added this to the v14.1 milestone Oct 18, 2015
@DocCyblade
Copy link
Owner Author

@l-arnold - This was intended to remind the end user doing a "Live Preview" of running from the CD that it may not run as it should on hardware thats below a certain specs. You are correct that the right size would need to be specified. This was really only to give a clear expectation that depending on the hardware it may not function as well or if all as intended.

On that note, I will mark this as v14.1 or next release then

@DocCyblade DocCyblade self-assigned this Oct 18, 2015
@JedMeister
Copy link

Cool idea. IMO it's more of a "nice to have" rather than a "must have". I.e. I don't think that this would be a "release stopper".

It's perhaps something that could be used more broadly.. There are a few appliances that won't run well with low RAM that could benefit from this.

OT: On a tangent it might be useful to provide something similar for Micro servers. Anything that is CPU intensive doesn't run well on Micro so IMO a user who doesn't understand this may have a poor experience on a micro server think it is a TurnKey problem (rather than realise that it relates to resource usage)....

@DocCyblade
Copy link
Owner Author

Maybe this needs to be logged on the main TKL issue tracker as an enhancement for all devices? Maybe a general warning when booted into LIVE saying this is a LIVE boot your experience (blah blah blah) Or have pre-set ones via common, like high CPU, high memory so you could easy include it in the make file.

@l-arnold
Copy link
Collaborator

I agree. This should go to the TKL Tracker and be part of the base TKL logic. Seems to me anyway.

@DocCyblade DocCyblade modified the milestones: v14.1, v14.2 Mar 2, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants