GithubHelp home page GithubHelp logo

log2ram for x86? about mynode HOT 4 OPEN

cwiggs avatar cwiggs commented on August 13, 2024
log2ram for x86?

from mynode.

Comments (4)

tehelsper avatar tehelsper commented on August 13, 2024

Yeah, that change would be beneficial. The model two (which is x86) boots off of a SD card or USB flash drive, so this was added as an optimization for that platform.

It may be better to leave it installed and just disable log2ram if it's not on an SD card during startup or add an option to enable/disable on the settings page manually. The images are typically made using log2ram while they are on an USB drive, so any detection done during setup_device.sh may not represent the final drive the device is actually using. There's also one other install location in mynode_post_upgrade.sh.

from mynode.

cwiggs avatar cwiggs commented on August 13, 2024

The model two (which is x86) boots off of a SD card or USB flash drive, so this was added as an optimization for that platform.

Ah okay that makes sense.

It may be better to leave it installed and just disable log2ram if it's not on an SD card during startup or add an option to enable/disable on the settings page manually.

Yeah that makes sense. For the time being I'll do some work to see why it's failing on Debian 12 and either fix it or create an option to disable starting the service.

The images are typically made using log2ram while they are on an USB drive, so any detection done during setup_device.sh may not represent the final drive the device is actually using.

Okay. I'm just using the setup_device.sh script on a Debian 12 VM so I'm not sure how that merges with the building the image logic. Any suggestions and how to deal with this?

There's also one other install location in mynode_post_upgrade.sh.

I see there is a lot of duplicated code in mynode_post_upgrade.sh and setup_device.sh, are you okay if I create a libs directory and put some simple bash scripts in there with common functions that we can import (source) in both of the scripts? This would allow us to write the code once and just use it when we need it in multiple places.

from mynode.

cwiggs avatar cwiggs commented on August 13, 2024

For the time being I'll do some work to see why it's failing on Debian 12 and either fix it or create an option to disable starting the service.

I was able to fix the issue with Debian 12, PR is her: #869

I still think it's good to do a few things:

  • Detect if the system is on an Sdcard, USB, etc and install log2ram by default.
  • Have an option in the mynode webui to enable/disable log2ram.
  • Have a libs directory for common bash function that can just be imported into various scripts.

Let me know what you think about the above things, and the questions from my previous comment and I'd be happy to support PRs for all of this.

Thanks for the app, MyNode has been super helpful for me, I just switched to it from Umbrel.

from mynode.

tehelsper avatar tehelsper commented on August 13, 2024

Glad to hear you've been liking it!

Okay. I'm just using the setup_device.sh script on a Debian 12 VM so I'm not sure how that merges with the building the image logic. Any suggestions and how to deal with this?

OK, I see how you've been using setup_device. That's basically the use case, when running it on a base debian distro, it will add and install and the default apps and software. Your PR change was good.

I see there is a lot of duplicated code in mynode_post_upgrade.sh and setup_device.sh, are you okay if I create a libs directory and put some simple bash scripts in there with common functions that we can import (source) in both of the scripts? This would allow us to write the code once and just use it when we need it in multiple places.

I see there is a lot of duplicated code in mynode_post_upgrade.sh and setup_device.sh

There is a lot of duplication between the two, but they have different use cases and at this point, that code almost never needs to change. I'd prefer not to change it up at this point. A lot duplicate code that does change was pulled out into a separate script and all future apps use the SDK approach so they go into their own locations without needing to be in either setup_device.sh or mynode_post_upgrade.sh. You can see some of that in mynode_app_versions.sh and rootfs/standard/usr/share/mynode_apps/.

I like the second suggested option the most. The first could be nice, but I worry it could be error-prone. I'm not sure how to consistently detect the type of hardware.

from mynode.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.