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

Warn users when installing Toltec on an unsupported OS version #445

Closed
matteodelabre opened this issue Sep 27, 2021 · 9 comments · Fixed by #759 or #858
Closed

Warn users when installing Toltec on an unsupported OS version #445

matteodelabre opened this issue Sep 27, 2021 · 9 comments · Fixed by #759 or #858
Labels
install Installation scripts
Milestone

Comments

@matteodelabre
Copy link
Member

No description provided.

@matteodelabre matteodelabre added the install Installation scripts label Sep 27, 2021
@LinusCDE
Copy link
Member

That's a really good idea. How about using remarkable-framebuffers list of versions in a whitelist used for installation as well as reenabling (or downloading it).
If /etc/version has no match in this list, we should prevent installtion and reenabling by default and require setting an env to bypass this (e.g. toltec_ignore_version_error=1).

@Eeems
Copy link
Member

Eeems commented Oct 14, 2021

Instead of an environment variable to bypass, it might make more sense to just have a --force command line argument.

@LinusCDE
Copy link
Member

That is a good idea, but I think this shouldn't be too easy. If it were add --force to it, some users might simply bypass that check and then wonder why the device doesn't reboot properly.

Saying set the env toltec_ignore_version_error to 1 should rule a good portion of those users preventing them from accidentally bricking their devices.

@Eeems
Copy link
Member

Eeems commented Oct 14, 2021

I think that will only work for a short while, until someone tells someone to just run it with toltec_ignore_version_error=1 before the command and then everybody will start using it that way.

I think we should just not tell people to use --force if the reenable fails, and have a strong warning in the --help output.

@LinusCDE
Copy link
Member

Good point! 👍

@dominique-unruh
Copy link

I think we should just not tell people to use --force if the reenable fails, and have a strong warning in the --help output.

Maybe it should have a more dangerous name. --force-and-brick-my-device or something. I guess most users will then at least check the documentation or Google for it.

@Eeems
Copy link
Member

Eeems commented Feb 6, 2022

The help output would have the documentation required in my proposal. You'll find that having more "dangerous" names doesn't actually keep users from using it without knowing what it actually does. As soon as one person posts a blog post, or reddit comment saying to use it, people will just start using it without reading up on what it does.

@Eeems Eeems added this to the 3.x support milestone Nov 25, 2023
@Eeems Eeems linked a pull request Dec 20, 2023 that will close this issue
@Eeems Eeems mentioned this issue Jan 7, 2024
@ZeKap
Copy link

ZeKap commented Mar 8, 2024

It looks like no one did a PR for it, may I try to make one?

@Eeems
Copy link
Member

Eeems commented Mar 8, 2024

There is a linked PR for this already

@Eeems Eeems linked a pull request May 24, 2024 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
install Installation scripts
Projects
None yet
5 participants