Grub not updating

[duroursu]

I am a new user of Anduin OS and i like it alot but a have a problem with grub not being updating to 5 sec to show , it defaults to 30 s even after sudo update-grub.
My grub has blue background
Any ideas ?
This is my grub looks :

GRUB_DEFAULT=0
GRUB_TIMEOUT_STYLE=menu
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR=( . /etc/os-release && echo ${NAME} )
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
GRUB_CMDLINE_LINUX=""

[FromLinuxWithLove]

Interesting, so you are not the only one experiencing weird GRUB / boot behavior. See: #422

[Anduin2017]

AnduinOS 2.0.3 will ship with a control panel allowing editing grub timeout with GUI:

[duroursu]

very cool , thanks for your reply

[Anduin2017]

Thank you for reporting this, and welcome to AnduinOS.

You did not configure GRUB incorrectly, and sudo update-grub is not broken. We traced the exact 30-second delay through Ubuntu's GRUB logic and the AnduinOS installation defaults. The behavior is reproducible, and the root cause is now clear.

The short version is:

AnduinOS uses Btrfs by default. GRUB cannot safely write its standard environment block when it is stored on Btrfs. On UEFI systems, Ubuntu's GRUB handles that condition by using GRUB_RECORDFAIL_TIMEOUT instead of the normal GRUB_TIMEOUT. If GRUB_RECORDFAIL_TIMEOUT is not set, Ubuntu defaults it to exactly 30 seconds.

That is why this configuration:

GRUB_TIMEOUT_STYLE=menu
GRUB_TIMEOUT=5

can still produce a 30-second menu.

The fix

Add GRUB_RECORDFAIL_TIMEOUT=5 to /etc/default/grub so that the relevant section contains all three settings:

GRUB_TIMEOUT_STYLE=menu
GRUB_TIMEOUT=5
GRUB_RECORDFAIL_TIMEOUT=5

Then regenerate the GRUB configuration:

sudo update-grub

After that, both the normal GRUB path and the Btrfs+UEFI safety path will use a five-second timeout.

There is no need to run grub-install, and you should not edit /boot/grub/grub.cfg directly.

Why GRUB_TIMEOUT=5 was not enough

GRUB has more than one timeout path.

GRUB_TIMEOUT controls the ordinary boot-menu delay. Ubuntu also supports GRUB_RECORDFAIL_TIMEOUT, which controls the delay used when the previous boot is considered unsuccessful or when GRUB cannot safely maintain its writable environment state.

On a normal writable setup, the generated GRUB configuration can use the ordinary value:

GRUB_TIMEOUT=5

However, Ubuntu's GRUB checks whether it can write its environment block, normally located at:

/boot/grub/grubenv

GRUB uses that small environment block for persistent state such as boot-success and one-shot selections. GRUB can read files from Btrfs, but it cannot safely perform the required in-place rewrite of a GRUB environment block stored there.

When Ubuntu's GRUB detects Btrfs, it marks the standard record-failure mechanism as unavailable:

recordfail_broken=1

On UEFI, Ubuntu then deliberately keeps the boot menu accessible by generating logic equivalent to:

if [ $grub_platform = efi ]; then
  set timeout=${GRUB_RECORDFAIL_TIMEOUT:-30}
  if [ x$feature_timeout_style = xy ]; then
    set timeout_style=menu
  fi
fi

The important expression is:

${GRUB_RECORDFAIL_TIMEOUT:-30}

It means: use GRUB_RECORDFAIL_TIMEOUT if it has been defined; otherwise use 30.

The complete path on a default AnduinOS installation is therefore:

GRUB_TIMEOUT=5 is set in /etc/default/grub
                 │
                 ▼
update-grub correctly generates the normal five-second branch
                 │
                 ▼
GRUB detects that its environment block is stored on Btrfs
                 │
                 ▼
recordfail_broken=1
                 │
                 ▼
The UEFI safety branch sets the effective timeout again
                 │
                 ▼
GRUB_RECORDFAIL_TIMEOUT is not defined
                 │
                 ▼
Ubuntu uses its default value: 30 seconds

So update-grub did read the user's configuration. It generated the requested five-second normal path, but it also generated Ubuntu's later Btrfs+UEFI safety path. The second path is the one that determines the visible timeout on this machine.

This behavior comes from an Ubuntu GRUB patch

This is not a guess based only on the number 30. Ubuntu carries a GRUB patch called quick-boot-lvm.patch that implements this behavior explicitly.

The patch explains why it exists: if GRUB has no writable grubenv, its recordfail mechanism cannot work. On UEFI systems, GRUB also cannot reliably detect a held modifier key such as Shift in the same way it can on legacy BIOS systems. Without a non-zero timeout, the user could lose a reliable way to open the boot menu. Ubuntu therefore reuses GRUB_RECORDFAIL_TIMEOUT for this safety case.

The upstream sources are available here:

• quick-boot-lvm.patch in Debian Sources
• Ubuntu Launchpad bug #1800722
• Ubuntu Community Help Wiki: GRUB 2

The patch's filesystem check includes Btrfs among the filesystems to which GRUB cannot safely write its environment state. Its UEFI fallback then uses:

GRUB_RECORDFAIL_TIMEOUT

with a default of:

30 seconds

This exactly matches the reported symptom.

The AnduinOS source confirms every condition in the chain

The following links are pinned to AnduinOS Packages commit e35624879e83c993ef01617fbc7fcc0be17eb51e, so the evidence remains attached to the version we inspected.

AnduinOS installs to Btrfs by default

The installer model defines Btrfs as the default filesystem:

• StorageSpec.filesystem = Filesystem.BTRFS

The installation planner also falls back to btrfs when no different filesystem is selected:

• choices.get("filesystem") or "btrfs"

Btrfs is therefore not an unusual edge case for AnduinOS. It is the normal installation path.

AnduinOS already accounts for the GRUB-on-Btrfs write limitation elsewhere

The AnduinOS Disk Snapshots Manager package contains this explicit comment:

GRUB cannot safely rewrite an environment block stored on Btrfs.

The relevant source is here:

• anduinos-btrfs-snapshots-manager/scripts/postinst.sh

Because of that limitation, Disk Snapshots Manager stores its own one-shot recovery selector on the writable EFI System Partition.

That is important evidence: the Btrfs write limitation is already recognized inside AnduinOS itself. However, this external environment block belongs specifically to the snapshot-recovery protocol. It does not replace the standard /boot/grub/grubenv used by Ubuntu's ordinary GRUB scripts. Ubuntu's recordfail_broken path therefore still activates.

The current AnduinOS GRUB defaults do not define the fallback timeout

The current anduinos-grub-style configuration sets only the GRUB graphics mode and the Linux graphics payload:

• 20-anduinos-style.cfg

It does not define either timeout:

GRUB_TIMEOUT
GRUB_RECORDFAIL_TIMEOUT

That leaves Ubuntu's implicit 30-second value active in the Btrfs+UEFI safety branch.

The new AnduinOS Control Panel already writes both values

The boot-settings helper in AnduinOS Control Panel writes both timeout variables when a user saves the boot menu wait time:

f"GRUB_TIMEOUT={timeout}\n"
f"GRUB_RECORDFAIL_TIMEOUT={timeout}\n"

Source:

• anduinos-control-panel/scripts/boot-settings-helper

The Control Panel model separately represents the normal timeout and the interrupted-boot timeout. It also recognizes the latter's default as 30 seconds:

• DEFAULT_GRUB_TIMEOUT and DEFAULT_GRUB_RECORDFAIL_TIMEOUT

This independently confirms the diagnosis. It also explains why changing the value through the new Control Panel works: the helper writes both settings, not only GRUB_TIMEOUT.

Machines that have not saved this setting through the new Control Panel can still lack GRUB_RECORDFAIL_TIMEOUT, particularly when the user edited only /etc/default/grub by following standard GRUB instructions.

Who or what is at fault?

The responsibility is clear:

• The user did not make a mistake. GRUB_TIMEOUT=5 is a standard and reasonable setting.
• update-grub is functioning correctly. It generated both the ordinary timeout and Ubuntu's safety timeout.
• Ubuntu's behavior is intentional. It preserves access to the boot menu on UEFI systems when GRUB cannot maintain writable state.
• AnduinOS has an integration gap in its defaults. We chose Btrfs as the default filesystem but did not explicitly define the corresponding GRUB_RECORDFAIL_TIMEOUT policy for that default path.

Using Btrfs is not itself the defect. The defect is failing to integrate Ubuntu GRUB's Btrfs+UEFI timeout behavior into the AnduinOS default configuration and test coverage.

The blue background is unrelated. It reflects how GRUB is rendered and does not control the timeout branch.

A clean way to apply the setting

Adding the following line directly to /etc/default/grub is sufficient:

GRUB_RECORDFAIL_TIMEOUT=5

Users who prefer to keep local changes in a separate file can instead create:

/etc/default/grub.d/99-local-timeout.cfg

with this content:

GRUB_TIMEOUT_STYLE=menu
GRUB_TIMEOUT=5
GRUB_RECORDFAIL_TIMEOUT=5

Then run:

sudo update-grub

The separate drop-in also makes it easier to see which settings are local administrative choices rather than package defaults.

How to verify this on an affected machine

The following commands are read-only and show the entire configuration chain:

# Confirm the root filesystem type.
# A default AnduinOS installation should report: btrfs
findmnt -no FSTYPE /

# Show timeout assignments from the main file and every GRUB drop-in.
grep -RnsE '^[[:space:]]*GRUB_(RECORDFAIL_)?TIMEOUT=' \
  /etc/default/grub /etc/default/grub.d

# Inspect the timeout branches that update-grub actually generated.
grep -n -C 4 -E 'recordfail|set timeout=' /boot/grub/grub.cfg

Before the fix, the generated grub.cfg may contain a normal five-second assignment followed by a 30-second EFI safety assignment. That is expected given the upstream logic and explains why searching only for the first set timeout= can be misleading.

After adding:

GRUB_RECORDFAIL_TIMEOUT=5

and running:

sudo update-grub

the generated EFI safety branch should also use five seconds.

If it still uses 30 seconds, inspect every file under /etc/default/grub.d/. GRUB sources those files in addition to /etc/default/grub, and a later assignment can override an earlier value:

grep -RnsE '^[[:space:]]*GRUB_(RECORDFAIL_)?TIMEOUT=' \
  /etc/default/grub /etc/default/grub.d

Please post that output, together with the complete output of sudo update-grub, if the problem continues.

What should not be done

Please do not work around this issue by directly editing generated or package-owned GRUB scripts:

• Do not edit /boot/grub/grub.cfg; update-grub will overwrite it.
• Do not run grub-install merely to change the timeout; reinstalling the bootloader is unrelated and introduces unnecessary risk.
• Do not patch /etc/grub.d/00_header; package upgrades may overwrite it, and GRUB_RECORDFAIL_TIMEOUT is the supported configuration mechanism.
• Do not disable safety features such as OS detection without a separate reason. They are not required to fix this specific 30-second fallback.

What we will correct in AnduinOS

This report exposed a real default-integration issue, and we should fix it on the distribution side rather than expecting every user to discover an Ubuntu-specific secondary timeout.

The AnduinOS fix should include the following work:

1. Define an explicit GRUB_RECORDFAIL_TIMEOUT policy in an appropriate AnduinOS GRUB defaults drop-in so the default Btrfs installation does not inherit an unexpected implicit 30-second delay.
2. Preserve the current Control Panel behavior of writing GRUB_TIMEOUT and GRUB_RECORDFAIL_TIMEOUT together.
3. Keep administrator overrides possible through a later local file under /etc/default/grub.d/.
4. Add a UEFI+Btrfs regression test that examines the actual generated /boot/grub/grub.cfg, including the recordfail_broken path.
5. Add a passive virtual-machine boot test, without injected keyboard input, that verifies the real menu countdown rather than checking only that update-grub exits successfully.
6. Document the distinction between the normal timeout and the recordfail/unwritable-environment timeout.

Testing only the exit status of update-grub would not have caught this problem, because update-grub succeeds here. The test must validate the effective generated branches or observe the real boot menu.

A note about the GRUB_DISTRIBUTOR line shown in the discussion

The post renders this line as:

GRUB_DISTRIBUTOR=( . /etc/os-release && echo ${NAME} )

If that is literally what is stored in /etc/default/grub, it is not a valid shell assignment. update-grub should then report a syntax error and leave the previous generated configuration in place.

However, the more likely explanation is Markdown formatting: if the original line used backticks and the configuration was not placed inside a fenced code block, GitHub may have interpreted those backticks as inline-code markers.

We therefore do not consider this a confirmed second error. If the timeout fix does not work, please paste the literal file contents and the full sudo update-grub output inside a triple-backtick block so that Markdown cannot alter them.

Final answer

The observed 30-second delay has a specific, verified cause:

AnduinOS defaults to Btrfs
+ GRUB cannot safely rewrite its standard grubenv on Btrfs
+ UEFI cannot rely on Shift-key detection to expose a hidden menu
+ Ubuntu activates its recordfail_broken safety path
+ GRUB_RECORDFAIL_TIMEOUT is not defined
= Ubuntu falls back to exactly 30 seconds

The user-facing fix is:

GRUB_TIMEOUT_STYLE=menu
GRUB_TIMEOUT=5
GRUB_RECORDFAIL_TIMEOUT=5

followed by:

sudo update-grub

This is not a failed update-grub, and it is not caused by the blue GRUB background. It is an AnduinOS default-integration gap exposed by Ubuntu GRUB's intentional Btrfs+UEFI safety behavior.

Thank you again for reporting it. The exact 30-second observation was the key clue that allowed us to trace the issue to the correct upstream branch and identify what AnduinOS needs to change.

[duroursu]

Thank you for reporting this, and welcome to AnduinOS.

You did not configure GRUB incorrectly, and sudo update-grub is not broken. We traced the exact 30-second delay through Ubuntu's GRUB logic and the AnduinOS installation defaults. The behavior is reproducible, and the root cause is now clear.

The short version is:

AnduinOS uses Btrfs by default. GRUB cannot safely write its standard environment block when it is stored on Btrfs. On UEFI systems, Ubuntu's GRUB handles that condition by using GRUB_RECORDFAIL_TIMEOUT instead of the normal GRUB_TIMEOUT. If GRUB_RECORDFAIL_TIMEOUT is not set, Ubuntu defaults it to exactly 30 seconds.

That is why this configuration:

GRUB_TIMEOUT_STYLE=menu
GRUB_TIMEOUT=5

can still produce a 30-second menu.

The fix

Add GRUB_RECORDFAIL_TIMEOUT=5 to /etc/default/grub so that the relevant section contains all three settings:

GRUB_TIMEOUT_STYLE=menu
GRUB_TIMEOUT=5
GRUB_RECORDFAIL_TIMEOUT=5

Then regenerate the GRUB configuration:

sudo update-grub

After that, both the normal GRUB path and the Btrfs+UEFI safety path will use a five-second timeout.

There is no need to run grub-install, and you should not edit /boot/grub/grub.cfg directly.

Why GRUB_TIMEOUT=5 was not enough

GRUB has more than one timeout path.

GRUB_TIMEOUT controls the ordinary boot-menu delay. Ubuntu also supports GRUB_RECORDFAIL_TIMEOUT, which controls the delay used when the previous boot is considered unsuccessful or when GRUB cannot safely maintain its writable environment state.

On a normal writable setup, the generated GRUB configuration can use the ordinary value:

GRUB_TIMEOUT=5

However, Ubuntu's GRUB checks whether it can write its environment block, normally located at:

/boot/grub/grubenv

GRUB uses that small environment block for persistent state such as boot-success and one-shot selections. GRUB can read files from Btrfs, but it cannot safely perform the required in-place rewrite of a GRUB environment block stored there.

When Ubuntu's GRUB detects Btrfs, it marks the standard record-failure mechanism as unavailable:

recordfail_broken=1

On UEFI, Ubuntu then deliberately keeps the boot menu accessible by generating logic equivalent to:

if [ $grub_platform = efi ]; then
  set timeout=${GRUB_RECORDFAIL_TIMEOUT:-30}
  if [ x$feature_timeout_style = xy ]; then
    set timeout_style=menu
  fi
fi

The important expression is:

${GRUB_RECORDFAIL_TIMEOUT:-30}

It means: use GRUB_RECORDFAIL_TIMEOUT if it has been defined; otherwise use 30.

The complete path on a default AnduinOS installation is therefore:

GRUB_TIMEOUT=5 is set in /etc/default/grub
                 │
                 ▼
update-grub correctly generates the normal five-second branch
                 │
                 ▼
GRUB detects that its environment block is stored on Btrfs
                 │
                 ▼
recordfail_broken=1
                 │
                 ▼
The UEFI safety branch sets the effective timeout again
                 │
                 ▼
GRUB_RECORDFAIL_TIMEOUT is not defined
                 │
                 ▼
Ubuntu uses its default value: 30 seconds

So update-grub did read the user's configuration. It generated the requested five-second normal path, but it also generated Ubuntu's later Btrfs+UEFI safety path. The second path is the one that determines the visible timeout on this machine.

This behavior comes from an Ubuntu GRUB patch

This is not a guess based only on the number 30. Ubuntu carries a GRUB patch called quick-boot-lvm.patch that implements this behavior explicitly.

The patch explains why it exists: if GRUB has no writable grubenv, its recordfail mechanism cannot work. On UEFI systems, GRUB also cannot reliably detect a held modifier key such as Shift in the same way it can on legacy BIOS systems. Without a non-zero timeout, the user could lose a reliable way to open the boot menu. Ubuntu therefore reuses GRUB_RECORDFAIL_TIMEOUT for this safety case.

The upstream sources are available here:

* [`quick-boot-lvm.patch` in Debian Sources](https://sources.debian.org/patches/grub2/2.06-3~deb10u1/quick-boot-lvm.patch/)

* [Ubuntu Launchpad bug #1800722](https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1800722)

* [Ubuntu Community Help Wiki: GRUB 2](https://help.ubuntu.com/community/Grub2#Last_Boot_Failed_or_Boot_into_Recovery_Mode)

The patch's filesystem check includes Btrfs among the filesystems to which GRUB cannot safely write its environment state. Its UEFI fallback then uses:

GRUB_RECORDFAIL_TIMEOUT

with a default of:

30 seconds

This exactly matches the reported symptom.

The AnduinOS source confirms every condition in the chain

The following links are pinned to AnduinOS Packages commit e35624879e83c993ef01617fbc7fcc0be17eb51e, so the evidence remains attached to the version we inspected.

AnduinOS installs to Btrfs by default

The installer model defines Btrfs as the default filesystem:

* [`StorageSpec.filesystem = Filesystem.BTRFS`](https://github.com/AiursoftWeb/AnduinOS-Packages/blob/e35624879e83c993ef01617fbc7fcc0be17eb51e/anduinos-installer-beta/src/installer_core/model.py#L74-L79)

The installation planner also falls back to btrfs when no different filesystem is selected:

* [`choices.get("filesystem") or "btrfs"`](https://github.com/AiursoftWeb/AnduinOS-Packages/blob/e35624879e83c993ef01617fbc7fcc0be17eb51e/anduinos-installer-beta/src/installer_core/planning.py#L65-L72)

Btrfs is therefore not an unusual edge case for AnduinOS. It is the normal installation path.

AnduinOS already accounts for the GRUB-on-Btrfs write limitation elsewhere

The AnduinOS Disk Snapshots Manager package contains this explicit comment:

GRUB cannot safely rewrite an environment block stored on Btrfs.

The relevant source is here:

* [`anduinos-btrfs-snapshots-manager/scripts/postinst.sh`](https://github.com/AiursoftWeb/AnduinOS-Packages/blob/e35624879e83c993ef01617fbc7fcc0be17eb51e/anduinos-btrfs-snapshots-manager/scripts/postinst.sh#L31-L38)

Because of that limitation, Disk Snapshots Manager stores its own one-shot recovery selector on the writable EFI System Partition.

That is important evidence: the Btrfs write limitation is already recognized inside AnduinOS itself. However, this external environment block belongs specifically to the snapshot-recovery protocol. It does not replace the standard /boot/grub/grubenv used by Ubuntu's ordinary GRUB scripts. Ubuntu's recordfail_broken path therefore still activates.

The current AnduinOS GRUB defaults do not define the fallback timeout

The current anduinos-grub-style configuration sets only the GRUB graphics mode and the Linux graphics payload:

* [`20-anduinos-style.cfg`](https://github.com/AiursoftWeb/AnduinOS-Packages/blob/e35624879e83c993ef01617fbc7fcc0be17eb51e/anduinos-grub-style/assets/20-anduinos-style.cfg#L1-L4)

It does not define either timeout:

GRUB_TIMEOUT
GRUB_RECORDFAIL_TIMEOUT

That leaves Ubuntu's implicit 30-second value active in the Btrfs+UEFI safety branch.

The new AnduinOS Control Panel already writes both values

The boot-settings helper in AnduinOS Control Panel writes both timeout variables when a user saves the boot menu wait time:

f"GRUB_TIMEOUT={timeout}\n"
f"GRUB_RECORDFAIL_TIMEOUT={timeout}\n"

Source:

* [`anduinos-control-panel/scripts/boot-settings-helper`](https://github.com/AiursoftWeb/AnduinOS-Packages/blob/e35624879e83c993ef01617fbc7fcc0be17eb51e/anduinos-control-panel/scripts/boot-settings-helper#L30-L35)

The Control Panel model separately represents the normal timeout and the interrupted-boot timeout. It also recognizes the latter's default as 30 seconds:

* [`DEFAULT_GRUB_TIMEOUT` and `DEFAULT_GRUB_RECORDFAIL_TIMEOUT`](https://github.com/AiursoftWeb/AnduinOS-Packages/blob/e35624879e83c993ef01617fbc7fcc0be17eb51e/anduinos-control-panel/src/anduinos_control_panel/model.py#L21-L27)

This independently confirms the diagnosis. It also explains why changing the value through the new Control Panel works: the helper writes both settings, not only GRUB_TIMEOUT.

Machines that have not saved this setting through the new Control Panel can still lack GRUB_RECORDFAIL_TIMEOUT, particularly when the user edited only /etc/default/grub by following standard GRUB instructions.

Who or what is at fault?

The responsibility is clear:

* The user did not make a mistake. `GRUB_TIMEOUT=5` is a standard and reasonable setting.

* `update-grub` is functioning correctly. It generated both the ordinary timeout and Ubuntu's safety timeout.

* Ubuntu's behavior is intentional. It preserves access to the boot menu on UEFI systems when GRUB cannot maintain writable state.

* AnduinOS has an integration gap in its defaults. We chose Btrfs as the default filesystem but did not explicitly define the corresponding `GRUB_RECORDFAIL_TIMEOUT` policy for that default path.

Using Btrfs is not itself the defect. The defect is failing to integrate Ubuntu GRUB's Btrfs+UEFI timeout behavior into the AnduinOS default configuration and test coverage.

The blue background is unrelated. It reflects how GRUB is rendered and does not control the timeout branch.

A clean way to apply the setting

Adding the following line directly to /etc/default/grub is sufficient:

GRUB_RECORDFAIL_TIMEOUT=5

Users who prefer to keep local changes in a separate file can instead create:

/etc/default/grub.d/99-local-timeout.cfg

with this content:

GRUB_TIMEOUT_STYLE=menu
GRUB_TIMEOUT=5
GRUB_RECORDFAIL_TIMEOUT=5

Then run:

sudo update-grub

The separate drop-in also makes it easier to see which settings are local administrative choices rather than package defaults.

How to verify this on an affected machine

The following commands are read-only and show the entire configuration chain:

# Confirm the root filesystem type.
# A default AnduinOS installation should report: btrfs
findmnt -no FSTYPE /

# Show timeout assignments from the main file and every GRUB drop-in.
grep -RnsE '^[[:space:]]*GRUB_(RECORDFAIL_)?TIMEOUT=' \
  /etc/default/grub /etc/default/grub.d

# Inspect the timeout branches that update-grub actually generated.
grep -n -C 4 -E 'recordfail|set timeout=' /boot/grub/grub.cfg

Before the fix, the generated grub.cfg may contain a normal five-second assignment followed by a 30-second EFI safety assignment. That is expected given the upstream logic and explains why searching only for the first set timeout= can be misleading.

After adding:

GRUB_RECORDFAIL_TIMEOUT=5

and running:

sudo update-grub

the generated EFI safety branch should also use five seconds.

If it still uses 30 seconds, inspect every file under /etc/default/grub.d/. GRUB sources those files in addition to /etc/default/grub, and a later assignment can override an earlier value:

grep -RnsE '^[[:space:]]*GRUB_(RECORDFAIL_)?TIMEOUT=' \
  /etc/default/grub /etc/default/grub.d

Please post that output, together with the complete output of sudo update-grub, if the problem continues.

What should not be done

Please do not work around this issue by directly editing generated or package-owned GRUB scripts:

* Do not edit `/boot/grub/grub.cfg`; `update-grub` will overwrite it.

* Do not run `grub-install` merely to change the timeout; reinstalling the bootloader is unrelated and introduces unnecessary risk.

* Do not patch `/etc/grub.d/00_header`; package upgrades may overwrite it, and `GRUB_RECORDFAIL_TIMEOUT` is the supported configuration mechanism.

* Do not disable safety features such as OS detection without a separate reason. They are not required to fix this specific 30-second fallback.

What we will correct in AnduinOS

This report exposed a real default-integration issue, and we should fix it on the distribution side rather than expecting every user to discover an Ubuntu-specific secondary timeout.

The AnduinOS fix should include the following work:

1. Define an explicit `GRUB_RECORDFAIL_TIMEOUT` policy in an appropriate AnduinOS GRUB defaults drop-in so the default Btrfs installation does not inherit an unexpected implicit 30-second delay.

2. Preserve the current Control Panel behavior of writing `GRUB_TIMEOUT` and `GRUB_RECORDFAIL_TIMEOUT` together.

3. Keep administrator overrides possible through a later local file under `/etc/default/grub.d/`.

4. Add a UEFI+Btrfs regression test that examines the actual generated `/boot/grub/grub.cfg`, including the `recordfail_broken` path.

5. Add a passive virtual-machine boot test, without injected keyboard input, that verifies the real menu countdown rather than checking only that `update-grub` exits successfully.

6. Document the distinction between the normal timeout and the recordfail/unwritable-environment timeout.

Testing only the exit status of update-grub would not have caught this problem, because update-grub succeeds here. The test must validate the effective generated branches or observe the real boot menu.

A note about the GRUB_DISTRIBUTOR line shown in the discussion

The post renders this line as:

GRUB_DISTRIBUTOR=( . /etc/os-release && echo ${NAME} )

If that is literally what is stored in /etc/default/grub, it is not a valid shell assignment. update-grub should then report a syntax error and leave the previous generated configuration in place.

However, the more likely explanation is Markdown formatting: if the original line used backticks and the configuration was not placed inside a fenced code block, GitHub may have interpreted those backticks as inline-code markers.

We therefore do not consider this a confirmed second error. If the timeout fix does not work, please paste the literal file contents and the full sudo update-grub output inside a triple-backtick block so that Markdown cannot alter them.

Final answer

The observed 30-second delay has a specific, verified cause:

AnduinOS defaults to Btrfs
+ GRUB cannot safely rewrite its standard grubenv on Btrfs
+ UEFI cannot rely on Shift-key detection to expose a hidden menu
+ Ubuntu activates its recordfail_broken safety path
+ GRUB_RECORDFAIL_TIMEOUT is not defined
= Ubuntu falls back to exactly 30 seconds

The user-facing fix is:

GRUB_TIMEOUT_STYLE=menu
GRUB_TIMEOUT=5
GRUB_RECORDFAIL_TIMEOUT=5

followed by:

sudo update-grub

This is not a failed update-grub, and it is not caused by the blue GRUB background. It is an AnduinOS default-integration gap exposed by Ubuntu GRUB's intentional Btrfs+UEFI safety behavior.

Thank you again for reporting it. The exact 30-second observation was the key clue that allowed us to trace the issue to the correct upstream branch and identify what AnduinOS needs to change.

It actualy works with adding GRUB_RECORDFAIL_TIMEOUT=5 to grub ,Thanks again.
I have two more questions :

1. is there an option to make the grub black insteed of blue ?
2. how can i revert to a previous shapshot from grub ?