generic-extlinux-compatible: Add option to set extlinux.conf prompt value

[fooker]

Description of changes

Always add the PROMPT option to the generated extlinux.conf with default value set to true but allowing to disable the prompt completely.

Requires u-boot/739e8361f3fe78038251216df6096a32bc2d5839 to work.

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

This is a follow-up of #271663.

[samueldr]

Always add the PROMPT option to the generated extlinux.conf with default value set to true but allowing to disable the prompt completely.

That's what the changes implement, but what is the rationale behind the change? Is there a change of behaviour desired? Is this fixing a bug?

I have a Raspberry Pi which uses the serial 0 RX pin for a different purpose by remapping it after boot. The wiring for the pin is in a way that it is pulled to GND which triggers the key-press detection mechanism during boot and stops the timer. > Disabling the prompt solves the problem for me.

Right, so the intent here is to add a feature where it is possible to configure the PROMPT configuration for extlinux-compatible boot.

And the rationale for configuring PROMPT (not that the rationale is required here) is to work around an issue with a "spurious input" making the boot stop.

This helps understand what the expectations are here.

• The current behaviour is not buggy
• This should keep the observable behaviour by default
• This allows further configuring the behaviour.

[samueldr]

Hijacking this line for a sub-thread

---

The way the different "extlinux-compatible" bootloadery bits behave is a total mess.

---

From syslinux txt/syslinux.cfg.txt

*PROMPT* 'flag_val'::                                                 
If 'flag_val' is 0, display the boot: prompt only if the Shift or Alt
key is pressed, or Caps Lock or Scroll lock is set (this is the   
default).  If 'flag_val' is 1, always display the boot: prompt.

I haven't looked at the source to confirm, but it should be assumed its default really is 0.

And at 0 the prompt will only be shown if modifiers are held/set.

---

From U-Boot common/menu.c

timeout - A delay in seconds to wait for user input. If 0, timeout is
disabled, and the default choice will be returned unless prompt is 1.

prompt - If 0, don't ask for user input unless there is an interrupted    
timeout. If 1, the user will be prompted for input regardless of the value
of timeout.                                                               

Side-note, in U-Boot, the default is 0 unless MENU is present in the config, which will set prompt = 1. So in practice since we have MENU it should set prompt = 1. Uh, I need to review this statement, since there's the thing about interrupted timeout... 🫠

Though this all should be taken with a big pile of salt, since the commit referenced implies the documented behaviour might not have been matching reality. It is unclear from the commit alone if this was from a regression, or it never worked as documented.

---

🫠

Considering both of those differ in behaviour, and also historically U-Boot may have differed in behaviour, I'm not sure adding outright PROMPT is a good idea.

We might want to make it a nullable option. Leave its default to null, and only add PROMPT when a conscious choice is made.

@dasJ thoughts?

[fooker]

I'm okay with implementing this as a three-state thing and leave the default null. If @dasJ has no objections, I will update this PR.

[fooker]

Updated this to a tri-state flag as mentioned above