Feature #12644
Allow remembering boot options
0%
Description
A user asked to make Tails able to remember boot options, to avoid retyping them at each boot.
So here is the corresponding ticket
Subtasks
Related issues
| Related to Tails - Feature #5501: Persistence preset: locale and accessibility options (language, keyboard, and formats) in Greeter | Confirmed | 2015-12-31 | |
|
Related to Tails - |
Rejected | 2015-09-27 | |
|
Related to Tails - |
Rejected | 2017-12-05 |
History
#1 Updated by elouann 2017-06-06 15:21:46
- related to Feature #5501: Persistence preset: locale and accessibility options (language, keyboard, and formats) in Greeter added
#2 Updated by intrigeri 2017-06-07 14:09:08
- Category set to Persistence
- Priority changed from Normal to Low
I think there’s a way to do this, but it’ll require quite some work (days).
Anyone, feel free to make a good case about why this request is worth this much effort.
#3 Updated by sajolida 2017-06-08 07:51:43
- related to
Feature #10286: Boot options documentation: more options could be added added
#4 Updated by sajolida 2017-06-08 07:51:47
- related to
Bug #12474: Document troubleshooting tips for more failure scenarios throughout installation assistant added
#5 Updated by sajolida 2017-06-08 07:52:30
I do this on my Tails but editing the syslinux menu file from another Tails. So an alternative would be to document this. It might not even require going on the command line.
Now, I’m not convinced it’s worth it (and it might definitely be dangerous for people to do so) but I don’t have much data regarding which boot options people have to enter each time these days (and whether we should instead put our energy in fixing the root cause that require people to edit boot options).
So, a bit like for Bug #12474, I’m personally lacking information on which boot options are worth being documented. For example, seeing this only from very very far away it seems like people had to add many options related to graphics in the late days of the 2.x serie and the beta day of the 3.x serie but the final goal is to have graphics work for everybody out-of-box.
More info regarding boot option usage would be useful for this ticket as well as for Bug #12474 and I think that it should be the responsability of help desk to clarify this as explained in Bug #12474#note-11.
#6 Updated by intrigeri 2017-06-08 08:55:25
> For example, seeing this only from very very far away it seems like people had to add many options related to graphics in the late days of the 2.x serie and the beta day of the 3.x serie but the final goal is to have graphics work for everybody out-of-box.
Absolutely! One concern of mine is that if we make it too easy to customize boot options forever in order to workaround such issues, we’ll get less bugs reported (⇒ no chance we ever find+fix the root cause, no chance we add to the known issues page) and we’ll never learn when the workaround is not needed anymore (⇒ no chance to clean up the known issues page). OTOH most such problems are out of our reach, pretty often we can’t do anything about them but help the bug reporter report the bug upstream, which rarely happens.
#7 Updated by Anonymous 2017-06-29 12:06:18
- Tracker changed from Bug to Feature
#8 Updated by Anonymous 2017-06-29 12:07:50
- Assignee set to sajolida
I think this is only a power user option, for the abovementioned reasons. It might be sufficient to document to do this here, on this ticket. And then mark the ticket as resolved. What do you think?
#9 Updated by Anonymous 2018-01-15 16:19:06
ping @sajolida?
#10 Updated by Anonymous 2018-01-15 16:19:18
- Type of work changed from Code to User interface design
#11 Updated by sajolida 2018-02-01 21:05:01
- Status changed from Confirmed to Rejected
- Assignee deleted (
sajolida)
For me it’s not a feature for power users but as a feature to fix hardware compatibility issues. But as intrigeri said the cost is probably high and the benefits unclear, so let’s reject this for now.