Bug#1017887: grub-efi-amd64-signed: SecureBoot Grub-Install with Custom Bootloader ID Drops Grub into Grub Shell
Package: grub-efi-amd64-bin Version: 1+2.04+20 Severity: important X-Debbugs-Cc: hollowaykea...@gmail.com Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? When performing a manual grub-install in a debootstrap Debian OS setup, installing SecureBoot Grub with --bootloader-id value other than 'debian' causes the Grub to drop into Grub Shell (failed to locate /boot/grub/grub.cfg) despite having the UUID and root prefix values correct at /boot/EFI//grub.cfg level. Exact cause is unknown (still not sure what causes the drop). The only workaround is NOT to mess with the --bootloader-id or set --bootloader-id to strictly 'debian' as value. The same thing happens when SecureBoot is turned off at BIOS. Investigation steps are properly documented, made available at: https://salsa.debian.org/-/snippets/617 * What exactly did you do (or not do) that was effective (or ineffective)? Don't mess with --bootloader-id or set --bootloader-id to 'debian' only have the target OS bootable and not drop into Grub Shell. Messing it with anything else than 'debian', Grub will drop into Grub Shell. * What was the outcome of this action? Option is offered but not functioning as expected. At the moment, it's compulsory not to use that option. * What outcome did you expect instead? Some unknown bug(s) are fixed or detailed documentations are published regarding the --bootloader-id usage. -- System Information: Debian Release: 11.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.18.0-0.bpo.1-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages grub-efi-amd64-signed depends on: ii grub-common 2.04-20 Versions of packages grub-efi-amd64-signed recommends: ii shim-signed 1.38+15.4-7 grub-efi-amd64-signed suggests no packages. Versions of packages grub-efi-amd64-bin depends on: ii grub-common 2.04-20 Versions of packages grub-efi-amd64-bin recommends: ii efibootmgr 17-1 -- no debconf information
Bug#1017858: grub-efi-amd64-signed: Failed to Perform SecureBoot Grub EFI Installation via Debootstrap
Package: grub-efi-amd64-bin Version: 1+2.04+20 Severity: important X-Debbugs-Cc: hollowaykea...@gmail.com Dear Maintainer, * What led up to the situation? When building a new minimal Debian OS (Bullseye stable) via debootstrap non-interactively using a script tool, the resulting medium failed to build a SecureBoot capable Grub EFI bootloader Debian OS without heavy manual interventions. The reason this path is pursued over Calamares is the precise minimal setup and seamless build automation for various targets, especially for building a firmware-like OS image consistently (e.g. generate an img file and set it up for disk flashing). Additionally, it has pinpoint percision for OS configurations without too much manual interventions (e.g. percisely install non-free firmware, fleet management configurations in 1 go). There are 2 expectations: 1. Maintainer: keep everything inside `shim-signed` and `grub-efi-ARCH-signed` packages' automation and any additional steps are considered as bugs as noted in https://lists.debian.org/debian-efi/2022/08/msg00019.html. 2. Me: as long as the Grub-EFI removable SecureBoot installation using `grub-install` is working accordingly will do. * What exactly did you do (or not do) that was effective (or ineffective)? The ideal build step specified by Maintainer failed to install SecureBoot grub-efi into the target OS at all (after Maintainer's guidance). Both apt packages did not setup a grub inside /boot directory. The build steps are available at (look for Apt installing bullseye-backports' SecureBoot EFI Grub bootloader): https://salsa.debian.org/-/snippets/615 The workaround I'm looking for a fix (currently failed) would be having a removable Secureboot grub-efi properly installed (without disabling SecureBoot at target BIOS). The current result is that the target enters a boot-loop at EFI level (contiue boot --> reset system) when SecureBoot is enabled at BIOS. Disabling SecureBoot at BIOS works fine but SecureBoot benefits were forfeited. The build steps are available at (look for Apt installing bullseye-backports' SecureBoot EFI Grub bootloader...): https://salsa.debian.org/-/snippets/616 The only workaround left is to directly build the target OS on the target system (breaking the firmware build tool's purpose) and must mess with its efi nvram. This breaks existing Linux benefits where the installed medium can be swapped across different (but same type) of hardware. The build steps are available at (look for Apt installing bullseye-backports' SecureBoot EFI Grub bootloader...): https://salsa.debian.org/-/snippets/614 NOTE: 1. all methods were properly investigated on a SecureBoot laptop target, with a complete built Debian OS using method in https://salsa.debian.org/-/snippets/614 manually. 2. Both `shim-signed` and `grub-efi-amd64-signed` packages where investigated with `defconf-show` command. No `debconf-set-selections` options available like `locales` and `keyboard-configuration` packages. * What was the outcome of this action? Maintainer: apt installing `shim-signed` and `grub-efi-amd64-signed` packages failed to install a working SecureBoot capable grub bootloader. Me: Both removable and non-removable SecureBoot `grub-install` command failed to install SecureBoot capable Grub bootloader. However, `shim-signed` and `grub-efi-amd64-signed` current status are within expectations (I don't expect them to smartly know what I'm planning to do BUT I don't mind for having Maintainer's expectations). * What outcome did you expect instead? Maintainer: `apt install shim-signed grub-efi-amd64-signed` should automatically installed everything. There is no need to manually setup or mess with `grub-install`. Me: `grub-install` command works for removable SecureBoot should work without any manual intervention without forcing a requirement to mess with target's EFI nvram stats. The built-target must maintain the Linux swappable capability in both SecureBoot and non-SecureBoot UEFI boot boundaries. Legacy boot support is outside of this report scope (I won't be looking for non-SecureBoot hardware around year 2022). -- System Information: Debian Release: 11.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.18.0-0.bpo.1-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages grub-efi-amd64-signed depends on: ii grub-common 2.04-20 Versions of packages grub-efi-amd64-signed recommends: ii shim-signed 1.38+15.4-7 grub-efi-amd64-signed suggests no packages. Versions of packages grub-efi-amd64-bin depends on: ii grub-common 2.04-20 Versions of packages
Bug#906288: openbox-lxde-session: /usr/bin/startlxde overrides XDG_DATA_DIRS making all local .desktop files unable to show on menu
Package: openbox-lxde-session
Version: 0.99.2-3
Severity: normal
Dear Maintainer,
* What led up to the situation?
When I install snaps in a freshly installed Debian 9 with LXDE. The
snaps with .desktop should be populated automatically inside the menu,
but it didn't.
* What exactly did you do (or not do) that was effective (or
ineffective)?
After thorough investigation (logged in
https://forum.snapcraft.io/t/snaps-not-appearing-in-debian9-stretch-lxde-menu-not-wayland-bug/6866/14),
I discovered the /usr/bin/lxde has this line overrides all the
XDG_DATA_DIRS set by Xsession.d configuration files:
```
export
XDG_DATA_DIRS="/usr/local/share/:/usr/share/:/usr/share/gdm/:/var/lib/menu-xdg/"
```
By replacing that line with a proper checking before overwriting, the
issue disappeared and all the custom paths appears in the menu properly.
```
xdg_path="/usr/local/share/:/usr/share/:/usr/share/gdm/:/var/lib/menu-xdg/"
if [ -z "$XDG_DATA_DIRS" ]; then
export XDG_DATA_DIRS="$xdg_path"
else
if [ -z "$(echo "$XDG_DATA_DIRS" | grep "$xdg_path")" ]; then
export XDG_DATA_DIRS="${XDG_DATA_DIRS}:$xdg_path"
fi
fi
unset xdg_path
```
* What was the outcome of this action?
All custom .desktop path are properly populated without manual
intervention.
* What outcome did you expect instead?
I expect all the .desktop are populated properly, without monkey
patching anything created by the package.
Currently, those UI-based snaps are quite hard to access, but not
impossible.
* p/s
I'm too new to debian mailing list and reportbug tool. In case of
silence, please reach me at kean.ho.c...@zoralab.com. I'm willing
to help.
-- System Information:
Debian Release: 9.5
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.9.0-7-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages openbox-lxde-session depends on:
ii lxde-common 0.99.2-3
ii lxsession0.5.3-2
ii openbox 3.6.1-4
openbox-lxde-session recommends no packages.
openbox-lxde-session suggests no packages.
-- no debconf information
