Re: [PATCH] util/grub.d/10_linux.in: Ignore kernel if initrd required but

[Didier Spaier]

Le 2/13/24 à 10:42, TJ a écrit :
> I have recently seen several bugs on Debian and Ubuntu whereby when a
> new kernel package is installed the host uses DKMS to build a module and
> that build fails (often the case with nvidia, but can also affect
> others, e.g. jool).The kernel install scripts stop before the initrd.img
> has been created but after the kernel image has been installed.
> 
> When non-technical owners/operators then follow 'random' suggestions
> from web searches or support chat and do `update-grub` or
> `grub-mkconfig` GRUB creates a new menuentry without an "initrd"
> statement and that results, on booting, with a kernel panic with
> unobvious messages.
> 
> This has been a problem for at least a decade but until now no effort
> has been made to deal with the root cause.
> 
> If this patch (or modifications of it) is accepted it allows distros to
> add logic to their kernel package install scripts similar to this, that
> I've used in a Debian proof-of-concept:
> 
> diff --git a/debian/templates/image.postinst.in
> b/debian/templates/image.postinst.in
> index 25e7dd6546..7041d10a4d 100755
> --- a/debian/templates/image.postinst.in
> +++ b/debian/templates/image.postinst.in
> @@ -11,6 +11,7 @@ depmod $version
> 
>  if [ -f /lib/modules/$version/.fresh-install ]; then
>  change=install
> +touch "${image_path%/*}/initrd.img-${version}.required"
>  else
>  change=upgrade
>  fi
> 
> When in use grub reports e.g:
> 
> Found linux image: /boot/vmlinuz-6.1.0-18-amd64
> Missing required 'initrd.img-6.1.0-18-amd64'; ignoring kernel version
> 6.1.0-18-amd64
> Found linux image: /boot/vmlinuz-6.1.0-18-amd64
> Missing required 'initrd.img-6.1.0-18-amd64'; ignoring kernel version
> 6.1.0-18-amd64

So if the issue occurs and this patch is applied a message like:

Missing required 'initrd.img-6.1.0-18-amd64'; ignoring kernel version
6.1.0-18-amd64

will be displayed.

But (speaking as a distribution maintainer) I am not sure that a non-technical
user will understand the consequences, not will know what to do next.

If the distribution's install kernel script keeps at least the kernel in use
when running grub-mkconfig or update-grub (which is a good thing IMO), the
machine will still be able to boot, whether or not the not_working boot entry is
included in the boot menu, but the kernel upgrade will still not be applied.

Shouldn't this issue be solved at the distribution level, e.g. modifying the
kernel install scripts appropriately, at least warning the user that the kernel
upgrade failed and giving some hints how to solve the issue, rather than
applying an upgrade deemed to fail?

Cheers, Didier


> ---
> 
> On some distros if the kernel package installation fails for some reason
> an initialramfs file may not be created although it is required for a
> successful boot.
> 
> Until now grub will still create the menuentry causing a kernel panic
> when used (as will happen if it is the default entry after a kernel
> package upgrade).
> 
> Allow other tools to indicate that the file must exist for a
> menuentry for that kernel version to be created.
> 
> Created by kernel package installation script, or manually, if
> 
> /boot/${initrd_file}.required
> 
> exists when
> 
> /boot/${initrd_file}
> 
> does not GRUB will skip creating the menuentry for this kernel.
> 
> Signed-off-by: Tj 
> ---
>  util/grub.d/10_linux.in | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/util/grub.d/10_linux.in b/util/grub.d/10_linux.in
> index cc393be7e..040c15713 100644
> --- a/util/grub.d/10_linux.in
> +++ b/util/grub.d/10_linux.in
> @@ -236,8 +236,15 @@ for linux in ${reverse_sorted_list}; do
>  if test -e "${dirname}/${i}" ; then
>initrd_real="${i}"
>break
> +elif test -e "${dirname}/${i}.required" ; then
> +  gettext_printf "Missing required '%s'; ignoring kernel version %s\n" 
> "$(echo $i)" "$(echo $version)" >&2
> +  linux=""
> +  break
>  fi
>done
> +  if test -z "$linux"; then
> + continue
> +  fi
>  
>initrd=
>if test -n "${initrd_early}" || test -n "${initrd_real}"; then

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH v2 0/5] loongarch: add relaxation support

[Didier Spaier]

Le 12/06/2023 à 15:29, Daniel Kiper a écrit :
> I am going to do code freeze this week...

Will the Argon2i and Argon2id key derival functions be supported in the new
release? I have not be able to find a commit about that, maybe I missed it?

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [RFC PATCH] kern/dl: Add module version check

[Didier Spaier]

Le 21/12/2022 à 09:43, Thomas Schmitt a écrit :
> I think that in any case an ISO made by grub-mkrescue should be tested.
> Maybe a distro developer is here who uses it for making a full fledged
> installation ISO or a live ISO.

I do for making a full fledged installation ISO in this function, with the
options you suggested privately:

make_iso() {
export MKRESCUE_SED_PARTNO=2
export MKRESCUE_SED_MODE=mjg
grub-mkrescue --locales='' --themes='' --compress=xz -V "$ISOLABEL" \
-o $PATHTOISO -iso_mbr_part_type 0x83 -partition_offset 16 -J \
--xorriso=./grub/grub-mkrescue-sed.sh $ISODIR
}

I'd be glad to help tetsing, if given detailed instructions about what to test
and how, as I am not a developer. However I can't test in Secure Boot enabled
context.

Cheers,
Didier

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: Automatically detecting empty configuration variables

[Didier Spaier]

Le 04/10/2022 à 13:28, Alberto Salvia Novella a écrit :
> Greetings boyos!
> 
> I have developed a grub configuration file that, instead of asking the user
> manually setting all the grub variables, it figures them out by itself
> automatically.
> 
> The file looks like this:
> https://pastebin.com/CUGHnckJ 
> 
> I was wondering if that logic could be included in GRUB C code itself. As if 
> the
> configuration file misses a variable, GRUB assumes the variable shall be 
> guessed
> automatically as in that config file.
> 
> If you agree with this change, I can summit a patch.

Hi Alberto,

speaking as a packager and a Linux distribution maintainer, I do not agree with
such a change:
1) I would not make an assumption like "if os-prober is installed, there are
several OS" nor that os-prober should be enabled in that case.
2) More generally it is to the package maintainer or local admin what to include
 by default in /etc/default/grub and up to the user to customize it.
3) In case a distribution does not include grub, I would expect a user wanting
to install it to read "info grub" and edit /etc/default grub as he or she sees 
fit.

Best regards,
Didier

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH v2 0/5] Automatic TPM Disk Unlock

[Didier Spaier]

Hi,

pardon me to top post just once, the answer below was sent in reply to v1 but
seems not to have made through as I do not find it in the archives, and it is
about the proposal in general.

Here goes (initially posted on Tue, 25 Jan 2022):

Sorry for a newbie question (I plan to allow installing Slint on a Secure Boot
enabled machine if/when I can but know almost nothing yet on this topic).

Currently we allow in the "auto" mode of installation to install Slint in a
fully encrypted drive (minus the ESP and the BIOS Boot partition), the user
typing then a passphrase only once when politely requested by GRUB before
displaying its menu (without using LVM as we store a LUKS key in the initramfs).

The main purpose is to forbid access to the system when the machine is powered
off, for instance in case of a laptop stolen during a travel.

Would the feature you describe possibly allow to circumvent this protection?

Thanks,
Didier
--
Didier Spaier
Slint maintainer


Le 01/02/2022 à 14:02, Hernan Gatta a écrit :
> Updates since v1:
> 
> 1. One key can unlock multiple disks:
>It is now possible to use key protectors with cryptomount's -a and -b
>options.
> 
> 2. No passphrase prompt on error if key protector(s) specified:
>cryptomount no longer prompts for a passphrase if key protectors are
>specified but fail to provide a working unlock key seeing as the user
>explicitly requested unlocking via key protectors.
> 
> 3. Key protector parameterization is separate:
>Previously, one would parameterize a key protector via a colon-separated
>argument list nested within a cryptomount argument. Now, key protectors are
>expected to provide an initialization function, if necessary.
> 
>As such, instead of:
> 
>cryptomount -k tpm2:mode=srk:keyfile=KEYFILE:pcrs=7,11...
> 
>one now writes:
> 
>tpm2_key_protector_init --mode=srk --keyfile=KEYFILE --pcrs=7,11 ...
>cryptomount -k tpm2
> 
>Additionally, one may write:
> 
>cryptomount -k protector_1 -k protector_2 ...
> 
>where cryptomount will try each in order on failure.
> 
> 4. Standard argument parsing:
>The TPM2 key protector now uses 'struct grub_arg_option' and the 
> grub-protect
>tool uses 'struct argp_option'. Additionally, common argument parsing
>functionality is now shared between the module and the tool.
> 
> 5. More useful messages:
>Both the TPM2 module and the grub-protect tool now provide more useful
>messages to help the user learn how to use their functionality (--help and
>--usage) as well as to determine what is wrong, if anything. Furthermore, 
> the
>module now prints additional debug output to help diagnose problems.
> 
> I forgot to mention last time that this patch series intends to address:
> https://bugzilla.redhat.com/show_bug.cgi?id=1854177
> 
> Previous series:
> https://lists.gnu.org/archive/html/grub-devel/2022-01/msg00125.html
> 
> Thank you,
> Hernan
> 
> Signed-off-by: Hernan Gatta 
> 
> Hernan Gatta (5):
>   protectors: Add key protectors framework
>   tpm2: Add TPM Software Stack (TSS)
>   protectors: Add TPM2 Key Protector
>   cryptodisk: Support key protectors
>   util/grub-protect: Add new tool
> 
>  .gitignore |1 +
>  Makefile.util.def  |   19 +
>  configure.ac   |1 +
>  grub-core/Makefile.am  |1 +
>  grub-core/Makefile.core.def|   11 +
>  grub-core/disk/cryptodisk.c|  166 +++-
>  grub-core/kern/protectors.c|   75 ++
>  grub-core/tpm2/args.c  |  129 
>  grub-core/tpm2/buffer.c|  145 
>  grub-core/tpm2/module.c|  710 +
>  grub-core/tpm2/mu.c|  807 
>  grub-core/tpm2/tcg2.c  |  143 
>  grub-core/tpm2/tpm2.c  |  711 +
>  include/grub/cryptodisk.h  |   14 +
>  include/grub/protector.h   |   48 ++
>  include/grub/tpm2/buffer.h |   65 ++
>  include/grub/tpm2/internal/args.h  |   39 +
>  include/grub/tpm2/internal/functions.h |  117 +++
>  include/grub/tpm2/internal/structs.h   |  675 
>  include/grub/tpm2/internal/types.h |  372 +
>  include/grub/tpm2/mu.h |  292 +++
>  include/grub/tpm2/tcg2.h   |   34 +
>  include/grub/tpm2/tpm2.h   |   38 +
>  util/grub-protect.c| 1314 
> 
>  24 files changed, 5897 insertions(+), 30 deletions(-)
>  create mode 100644 grub-core/kern/protectors.c
>  create mode 100644 grub-core/

Re: [PATCH 0/5] Automatic TPM Disk Unlock

[Didier Spaier]

Hi,

Le 24/01/2022 à 15:12, Hernan Gatta a écrit :
> This patch series adds support for automatically unlocking fully-encrypted 
> disks
> using a TPM 2.0.
> 
> Currently, when GRUB encounters a fully-encrypted disk that it must access, 
> its
> corresponding cryptodisk module (LUKS 1, LUKS2, or GELI) interactively prompts
> the user for a passphrase. An improvement to the boot process would be for 
> GRUB
> to automatically retrieve the unlocking key for fully-encrypted disks from a
> protected location and to unlock these transparently. To this end, a TPM may 
> be
> used to protect the unlocking key to a known-good state of the platform. Once
> the key is protected in this way, assuming that the platform remains
> trustworthy, GRUB can then utilize the TPM to release the key during boot and
> thus unlock fully-encrypted disks without user interaction. Such a model would
> not only be more convenient for end-users but also for virtual machines in 
> cloud
> environments where no user is ever present.
> 
> Design
> --
> 
> This patchset first adds a key protectors framework. This framework allows for
> key protector modules to register when loaded. A key protector is defined as a
> module that knows how to retrieve an unlocking key from a specific source. 
> This
> patchset adds a single such key protector module that understands how to
> retrieve an unlocking key from a TPM 2.0 by unsealing a sealed key file via a
> Storage Root Key (SRK).
> 
> Additionally, this patchset expands the cryptomount command to accept a key
> protector parameter. This parameter carries the information necessary to 
> select
> and parameterize a key protector to be used to retrieve an unlocking key for 
> the
> disk in question. That is, given an invocation of cryptomount to mount a
> specific disk (e.g., "cryptomount (hd0,gpt2)", "cryptomount -u UUID"), a key
> protector can be used to automatically retrieve an unlocking key without an
> interactive prompt.
> 
> Lastly, this patchset also includes a new tool, grub-protect, that allows the
> user to seal a key file against a set of Platform Configuration Registers 
> (PCRs)
> using an SRK. This sealed key file is expected to be stored in an unencrypted
> partition, such as the EFI System Partition (ESP), where GRUB can read it. The
> sealed key is then unsealed by the TPM2 key protector automatically, provided
> that the PCRs selected match on subsequent boots.

Sorry for a newbie question (I plan to allow installing Slint on a Secure Boot
enabled machine if/when I can but know almost nothing yet on this topic).

Currently we allow in the "auto" mode of installation to install Slint in a
fully encrypted drive (minus the ESP and the BIOS Boot partition), the user
typing then a passphrase only once when politely requested by GRUB before
displaying its menu (without using LVM as we store a LUKS key in the initramfs).

The main purpose is to forbid access to the system when the machine is powered
off, for instance in case of a laptop stolen during a travel.

Would the feature you describe possibly allow to circumvent this protection?

Thanks,
Didier
--
Didier Spaier
Slint maintainer

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH v2 2/2] mkconfig: use distro sorts when available

[Didier Spaier]

Hi Robbie and All,

Do i understand correctly that this will not change anything for distributions
(like Slint, based on Slackware, that I maintain) that are neither Debian-likes
nor Fedora-likes?

Cheers,
Didier

Le 20/01/2022 à 17:45, Robbie Harwood a écrit :
> For Debian-likes and Fedora-likes, use the distribution's sorting tools
> to determine the latest package before falling back to sort(1).  While
> Fedora's rpmdev-vercmp(1) is likely unavailable, Debian's is built into
> dpkg itself, and hence likely present.
> 
> Refactor to remove unused code and make it easy to add other package
> managers as needed.
> 
> Signed-off-by: Robbie Harwood 
> ---
>  util/grub-mkconfig_lib.in | 90 +--
>  1 file changed, 49 insertions(+), 41 deletions(-)
> 
> diff --git a/util/grub-mkconfig_lib.in b/util/grub-mkconfig_lib.in
> index 23d41475f..cc0ab790e 100644
> --- a/util/grub-mkconfig_lib.in
> +++ b/util/grub-mkconfig_lib.in
> @@ -200,62 +200,70 @@ grub_file_is_not_garbage ()
>return 0
>  }
>  
> -version_sort ()
> +# A $SORT function returns 0 if $1 is newer than $2, and 1 otherwise.  Other
> +# package managers can be plugged in here as needed with their own functions.
> +sort_dpkg ()
>  {
> -  case $version_sort_sort_has_v in
> -yes)
> -  LC_ALL=C sort -V;;
> -no)
> -  LC_ALL=C sort -n;;
> -*)
> -  if sort -V  /dev/null 2>&1; then
> -version_sort_sort_has_v=yes
> - LC_ALL=C sort -V
> -  else
> -version_sort_sort_has_v=no
> -LC_ALL=C sort -n
> -  fi;;
> -   esac
> +  left="`echo "$1" | sed -e "s/^[^0-9]*//"`"
> +  right="`echo "$2" | sed -e "s/^[^0-9]*//"`"
> +  dpkg --compare-versions "$left" gt "$right"
>  }
>  
> -version_test_numeric ()
> +sort_rpm ()
>  {
> -  version_test_numeric_a="$1"
> -  version_test_numeric_cmp="$2"
> -  version_test_numeric_b="$3"
> -  if [ "$version_test_numeric_a" = "$version_test_numeric_b" ] ; then
> -case "$version_test_numeric_cmp" in
> -  ge|eq|le) return 0 ;;
> -  gt|lt) return 1 ;;
> -esac
> -  fi
> -  if [ "$version_test_numeric_cmp" = "lt" ] ; then
> -version_test_numeric_c="$version_test_numeric_a"
> -version_test_numeric_a="$version_test_numeric_b"
> -version_test_numeric_b="$version_test_numeric_c"
> -  fi
> -  if (echo "$version_test_numeric_a" ; echo "$version_test_numeric_b") | 
> version_sort | head -n 1 | grep -qx "$version_test_numeric_b" ; then
> -return 0
> -  else
> -return 1
> +  left="`echo "$1" | sed -e "s/^[^0-9]*//"`"
> +  right="`echo "$2" | sed -e "s/^[^0-9]*//"`"
> +  rpmdev-vercmp "$left" "$right" >/dev/null
> +  if [ $? -eq 12 ]; then
> +return 0;
>fi
> +  return 1;
> +}
> +
> +sort_V ()
> +{
> +  left="`echo "$1" | sed -e "s/[^-]*-//" -e "s/_/-/g"`"
> +  right="`echo "$2" | sed -e "s/[^-]*-//" -e "s/_/-/g"`"
> +  printf "$left\n$right\n" | LC_ALL=C sort -V | head -n1 | grep -qx "$right"
> +}
> +
> +sort_n ()
> +{
> +  left="`echo "$1" | sed -e "s/[^-]*-//" -e "s/_/-/g"`"
> +  right="`echo "$2" | sed -e "s/[^-]*-//" -e "s/_/-/g"`"
> +  printf "$left\n$right\n" | LC_ALL=C sort -n | head -n1 | grep -qx "$right"
>  }
>  
>  version_test_gt ()
>  {
> -  version_test_gt_a="`echo "$1" | sed -e "s/[^-]*-//" -e "s/_/-/g"`"
> -  version_test_gt_b="`echo "$2" | sed -e "s/[^-]*-//" -e "s/_/-/g"`"
> -  version_test_gt_cmp=gt
> +  version_test_gt_a="$1"
> +  version_test_gt_b="$2"
> +
>if [ "x$version_test_gt_b" = "x" ] ; then
>  return 0
>fi
>case "$version_test_gt_a:$version_test_gt_b" in
>  *.old:*.old) ;;
> -*.old:*) version_test_gt_a="`echo "$version_test_gt_a" | sed -e 
> 's/\.old$//'`" ; version_test_gt_cmp=gt ;;
> -*:*.old) version_test_gt_b="`echo "$version_test_gt_b" | sed -e 
> 's/\.old$//'`" ; version_test_gt_cmp=ge ;;
> +*.old:*) version_test_gt_a="`echo "$version_test_gt_a" | sed -e 
> 's/\.old$//'`" ;;
> +*:*.old) version_test_gt_b="`echo "$version_test_gt_b" | sed -e 
> 's/\.old$//'`" ;;
>esac
> -  version_test_numeric "$version_test_gt_a" "$version_test_gt_cmp" 
> "$version_test_gt_b"
> -  return "$?"
> +
> +  if [ "$version_test_gt_a" = "$version_test_gt_b" ]; then
> +return 1;
> +  fi
> +
> +  if [ x"$SORT" = x ]; then
> +if command -v rpmdev-vercmp >/dev/null; then
> +  SORT=sort_rpm
> +elif command -v dpkg >/dev/null; then
> +  SORT=sort_dpkg
> +elif sort -V  /dev/null 2>&1; then
> +  SORT=sort_V
> +else
> +  SORT=sort_n
> +fi
> +  fi
> +  $SORT "$version_test_gt_a" "$version_test_gt_b"
>  }
>  
>  version_find_latest ()

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH v2] i386-pc: build verifiers API as module

[Didier Spaier]

Le 22/08/2021 à 21:50, Michael Schierl a écrit :

On Fri, 16 Apr 2021 22:23:39 +0100, Colin Watson wrote:

I have on my to-do list an item to add something to the Debian release
notes about this, since that's a way to reach less-engaged users who
won't read the GRUB manual or mailing lists.  That will likely help to
some extent, although I can't say how much.


Did anything like this happen for the Debian Bullseye release? I found
many interesting things in the release notes, but nothing about GRUB.

Also, updating some existing systems created emails about breaking
changes in some packages to the root user (I believe it is
apt-listchanges which is doing this) but nothing about GRUB either.
(Those systems either used a large MBR gap or a simple setup with only
ext4 and no LVM etc).

I also "just for fun" took the official Debian Installer ISO
(debian-11.0.0-i386-netinst.iso) and used it to install Debian Bullseye
into a new volume on an aleady existing LVM volume group (that is on a
part_msdos style partition that still uses a small MBR gap). The
installer did not complain, and proceeded to the point where it wanted
to install GRUB, but then stopped with a fatal error while executing
"grub install /dev/sda". Did not even show me the real error message.
Seems that core.img was 33 KB large and could therefore not be embedded
into the small MBR gap. To be honest, I am not sure whether this was
still possible with the GRUB version included in Buster.


According to the packages browser grub-2.06 didn't make its way in any
Debian version at time of writing. That's all I know.

Didier

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: GRUB 2.06 released

[Didier Spaier]

Le 08/06/2021 à 19:36, John Paul Adrian Glaubitz a écrit :

Hi Daniel!

On 6/8/21 7:34 PM, Daniel Kiper wrote:

GRUB maintainers are proud to announce GRUB 2.06 that has been just released.
You can find list of new features and major fixes since release 2.04 in the
NEWS file.


Congratulations. I'm glad the new release is finally out.


We would like to thank all the people who have contributed to the project.


I concur. Thanks a lot to everyone helping to make this happen!

Adrian


Congratulations and thanks from me too!

Cheers,
Didier

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: GRUB 2.06

[Didier Spaier]

Hi Daniel and John Paul Adrian,

Le 20/04/2021 à 15:53, Daniel Kiper a écrit :
> Hi Didier,
>
> On Thu, Apr 08, 2021 at 11:26:08PM +0200, Didier Spaier wrote:
>> Le 08/04/2021 à 21:28, Didier Spaier a écrit :
>>> I am fine with shipping GRUB up to some commit in Slint, but not all
>>> distributions accept to do that, or to carry a zillion patches as does
>>> Debian.
>>>
>>> As result, end users complain "GRUB is broken" whereas a patch that 
fix the
>>> issue of which they suffer of has been committed upstream a long 
time ago.

>>>
>>> An example that comes to mind is:
>>> 6643507ce30f775008e093580f0c9499dfb2c485
>>>
>>> Folks running Slackware-current also suffer of it:
>>> 
https://https://www.linuxquestions.org/questions/slackware-14/requests-for-current-14-2-15-0-a-4175620463/#post6236544www.linuxquestions.org/questions/slackware-14/requests-for-current-14-2-15-0-a-4175620463/#post6236544

>>
>> Sorry, wrong link, read:
>> 
https://www.linuxquestions.org/questions/slackware-14/requests-for-current-14-2-15-0-a-4175620463/#post6236544www.linuxquestions.org/questions/slackware-14/requests-for-current-14-2-15-0-a-4175620463/#post6236544

>
> I tried a few times but I am not able to open this link. Sorry...
> Could you explain your problem here?
>
> Daniel

Sorry for the link

Let's try again to paste it:
https://www.linuxquestions.org/questions/slackware-14/requests-for-current-14-2-15-0-a-4175620463/page4.html#post6236544

Anyway here is the posts' content, minus the forum's formatting:

-- pasted post below

Originally Posted by teoberi below:
The root cause is GRUB itself and if I understood correctly from what I 
read on the mailing lists it is not certain that problem will be solved!

@Didier, do you know anything about this?

Answer by Didier:
Indeed, this patch has been committed more than one year ago! From git 
log in the master branch:


[code]commit 6643507ce30f775008e093580f0c9499dfb2c485
Author: Simon Hardy 
Date:   Tue Mar 24 13:29:12 2020 +

build: Fix GRUB i386-pc build with Ubuntu gcc

With recent versions of gcc on Ubuntu a very large 
lzma_decompress.img file is
output. (e.g. 134479600 bytes instead of 2864.) This causes 
grub-mkimage to

fail with: "error: Decompressor is too big."

This seems to be caused by a section .note.gnu.property that is 
placed at an

offset such that objcopy needs to pad the img file with zeros.

This issue is present on:
Ubuntu 19.10 with gcc (Ubuntu 8.3.0-26ubuntu1~19.10) 8.3.0
Ubuntu 19.10 with gcc (Ubuntu 9.2.1-9ubuntu2) 9.2.1 20191008

This issue is not present on:
Ubuntu 19.10 with gcc (Ubuntu 7.5.0-3ubuntu1~19.10) 7.5.0
RHEL 8.0 with gcc 8.3.1 20190507 (Red Hat 8.3.1-4)

The issue can be fixed by removing the section using objcopy as 
shown in

this patch.

Signed-off-by: Simon Hardy 
Reviewed-by: Daniel Kiper [/code]So it's already in 2.06~rc1.

-- end of pasted post

So, it's hard to understand for many end users that:

1. The issue appeared after gcc-10 began to be used, well after the 
release of grub 2.04.

2. It has been fixed long ago.
3. But for the fix to be effective one of these conditions should be met:
a. A new grub version has been released and is provided by the 
distribution they use.
b. The distributon they use patches the source of GRUB 2.04 to bring the 
fix.
c. The distribution they use provides a package build from a source 
pulled from with the patch already committed.


Unfortunately if none of these conditions is met many users tend
to blame GRUB instead of the distributions and go saying in fora "I'll 
avoid to use GRUB, it's broken"


Best regards,
Didier

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: GRUB 2.06

[Didier Spaier]

Le 08/04/2021 à 21:28, Didier Spaier a écrit :

I am fine with shipping GRUB up to some commit in Slint, but not all
distributions accept to do that, or to carry a zillion patches as does 
Debian.


As result, end users complain "GRUB is broken" whereas a patch that fix the
issue of which they suffer of has been committed upstream a long time ago.

An example that comes to mind is:
6643507ce30f775008e093580f0c9499dfb2c485

Folks running Slackware-current also suffer of it:
https://https://www.linuxquestions.org/questions/slackware-14/requests-for-current-14-2-15-0-a-4175620463/#post6236544www.linuxquestions.org/questions/slackware-14/requests-for-current-14-2-15-0-a-4175620463/#post6236544 


Sorry, wrong link, read:
https://www.linuxquestions.org/questions/slackware-14/requests-for-current-14-2-15-0-a-4175620463/#post6236544www.linuxquestions.org/questions/slackware-14/requests-for-current-14-2-15-0-a-4175620463/#post6236544 



And sorry to have appended by mistake a quote from another thread.

Didier

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

GRUB 2.06

[Didier Spaier]

I am fine with shipping GRUB up to some commit in Slint, but not all
distributions accept to do that, or to carry a zillion patches as does 
Debian.


As result, end users complain "GRUB is broken" whereas a patch that fix the
issue of which they suffer of has been committed upstream a long time ago.

An example that comes to mind is:
6643507ce30f775008e093580f0c9499dfb2c485

Folks running Slackware-current also suffer of it:
https://https://www.linuxquestions.org/questions/slackware-14/requests-for-current-14-2-15-0-a-4175620463/#post6236544www.linuxquestions.org/questions/slackware-14/requests-for-current-14-2-15-0-a-4175620463/#post6236544

Best regards
Didier

Le 08/04/2021 à 18:53, Daniel Kiper a écrit :

On Wed, Mar 31, 2021 at 07:11:51PM -0500, Glenn Washburn wrote:

The first patch adds a long overdue note to the cryptomount command that UUIDs
should be specified without dash, differently than how fs uuids are specified.

The second patch makes the indentation of command description text for cutmem
and badmem conform with the indentation of the rest of the commands.

Glenn

Glenn Washburn (2):
   docs: Add note to cryptomount that UUIDs should be specified without
 dashes
   docs: Conform badmem and cutmem description indentations with other
 commands


Reviewed-by: Daniel Kiper 

Daniel

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel



___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: IS: 2.06-rc1 cut... WAS: Re: [PATCH v2] Add chainloaded image as shim's verifiable object

[Didier Spaier]

Le 10/03/2021 à 17:06, Daniel Kiper a écrit :

I have just pushed it together with other fixes and cleanups from the
grub-devel. If you can see something important missing drop me a line
immediately. Now I am working on 2.06-rc1 cut. If nothing blows up expect
it tomorrow or on Friday...


A least the disable-os-probing stuff works as expected, as far as I can
tell.

Didier

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] templates: Properly disable the os-prober by default

[Didier Spaier]

Le 05/03/2021 à 22:15, Philip Müller a écrit :

  - disable os-prober by default in grub-mkconfig.in by setting
  GRUB_DISABLE_OS_PROBER to true
  - fixes logic in 30_os-prober.in

Reason for code shuffle in grub-mkconfig.in:

The default was GRUB_DISABLE_OS_PROBER=false if you don't set
GRUB_DISABLE_OS_PROBER at all. To prevent os-prober from starting
we have to set it by default to true and shuffle GRUB_DISABLE_OS_PROBER
to executed by the script code section, but give the option to the user to
overwrite it with false, if he wants to execute os-prober after all.

Everyone who added GRUB_DISABLE_OS_PROBER=true in grub.cfg can remove
it by now.

Fixes: e3464147  templates: Disable the os-prober by default
---
  util/grub-mkconfig.in   | 5 -
  util/grub.d/30_os-prober.in | 2 +-
  2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/util/grub-mkconfig.in b/util/grub-mkconfig.in
index d3e879b8e..f8cbb8d7a 100644
--- a/util/grub-mkconfig.in
+++ b/util/grub-mkconfig.in
@@ -140,6 +140,9 @@ GRUB_DEVICE_PARTUUID="`${grub_probe} --device 
${GRUB_DEVICE} --target=partuuid 2
  GRUB_DEVICE_BOOT="`${grub_probe} --target=device /boot`"
  GRUB_DEVICE_BOOT_UUID="`${grub_probe} --device ${GRUB_DEVICE_BOOT} --target=fs_uuid 
2> /dev/null`" || true
  
+# Disable os-prober by default due to security reasons.

+GRUB_DISABLE_OS_PROBER="true"
+
  # Filesystem for the device containing our userland.  Used for stuff like
  # choosing Hurd filesystem module.
  GRUB_FS="`${grub_probe} --device ${GRUB_DEVICE} --target=fs 2> /dev/null || echo 
unknown`"
@@ -201,6 +204,7 @@ export GRUB_DEVICE \
GRUB_DEVICE_PARTUUID \
GRUB_DEVICE_BOOT \
GRUB_DEVICE_BOOT_UUID \
+  GRUB_DISABLE_OS_PROBER \
GRUB_FS \
GRUB_FONT \
GRUB_PRELOAD_MODULES \
@@ -242,7 +246,6 @@ export GRUB_DEFAULT \
GRUB_BACKGROUND \
GRUB_THEME \
GRUB_GFXPAYLOAD_LINUX \
-  GRUB_DISABLE_OS_PROBER \
GRUB_INIT_TUNE \
GRUB_SAVEDEFAULT \
GRUB_ENABLE_CRYPTODISK \
diff --git a/util/grub.d/30_os-prober.in b/util/grub.d/30_os-prober.in
index 80685b15f..a258ce71d 100644
--- a/util/grub.d/30_os-prober.in
+++ b/util/grub.d/30_os-prober.in
@@ -26,7 +26,7 @@ export TEXTDOMAINDIR="@localedir@"
  
  . "$pkgdatadir/grub-mkconfig_lib"
  
-if [ "x${GRUB_DISABLE_OS_PROBER}" = "xfalse" ]; then

+if [ "x${GRUB_DISABLE_OS_PROBER}" != "xfalse" ]; then
gettext_printf "os-prober will not be executed to detect other bootable 
partitions.\nSystems on them will not be added to the GRUB boot configuration.\nCheck 
GRUB_DISABLE_OS_PROBER documentation entry.\n"
exit 0
  fi


Just tested against git master, works as expected.

Thanks!
Best regards,
Didier

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [SECURITY PATCH 116/117] templates: Disable the os-prober by default

[Didier Spaier]

Le 03/03/2021 à 20:05, Lennart Sorensen a écrit :

On Wed, Mar 03, 2021 at 07:43:23PM +0100, John Paul Adrian Glaubitz wrote:

I'm not sure I'm able to follow the motivation to keep the naming scheme
as is.

If I have an option called "DISABLE_FEATURE_X", then I would expect setting
it to "true" would mean that the feature is disabled not the other way around.


And existing users have already set it to true to disable it, so true
better mean disabled.


And at least one existing user had willingly set it to false and didn't
understand why the expected boot entries were not generated after
having upgraded, as they were previously.

Didier

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [SECURITY PATCH 116/117] templates: Disable the os-prober by default

[Didier Spaier]

Le 02/03/2021 à 19:02, Daniel Kiper a écrit :

From: Alex Burmashev 
diff --git a/util/grub.d/30_os-prober.in b/util/grub.d/30_os-prober.in
index 1b91c102f..80685b15f 100644
--- a/util/grub.d/30_os-prober.in
+++ b/util/grub.d/30_os-prober.in
@@ -26,7 +26,8 @@ export TEXTDOMAINDIR="@localedir@"
  
  . "$pkgdatadir/grub-mkconfig_lib"
  
-if [ "x${GRUB_DISABLE_OS_PROBER}" = "xtrue" ]; then

+if [ "x${GRUB_DISABLE_OS_PROBER}" = "xfalse" ]; then
+  gettext_printf "os-prober will not be executed to detect other bootable 
partitions.\nSystems on them will not be added to the GRUB boot configuration.\nCheck 
GRUB_DISABLE_OS_PROBER documentation entry.\n"
exit 0
  fi


This is confusing: now to get boot entries from os-prober one have to
set:
GRUB_DISABLE_OS_PROBER=true
in /etc/default/grub.

Either revert that, or (better, in my opinion) label the variable
GRUB_ENABLE_OS_PROBER and set it to false by default.

Tested from grub pulled from git master with all patches committed.

Best regards,
Didier

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: How-to make grub play a sound when it asks a passphrase and/or in case of an issue.

[Didier Spaier]

Hi, thanks both for responding.

Le 04/02/2021 à 17:39, Vladimir 'phcoder' Serbinenko a écrit :


чт, 4 февр. 2021 г., 16:25 Lennart Sorensen 
mailto:lsore...@csclub.uwaterloo.ca>>:


On Wed, Feb 03, 2021 at 10:54:28PM -0800, Hanson Char wrote:
 > I don't know if Grub currently has any sound or accessibility
support.  How
 > about having a config option to send some ASCII bell characters
"\x07" to
 > the terminal upon the events that you described?  That would make
a sound,
 > but far from being a "tune".  Would such a simple solution be
good enough?

What terminal?  Might work for serial consoles but I suspect most people
are using VGA and grub has to implement that terminal itself and how to
play sound becomes very architecture specific.

GRUB has following ways to play a sound:
* Sending \x7 to terminal. If you use serial or BIOS terminal it will 
work. With GFX terminal it will result in a character instead. Other 
terminals the answer varies
* Using play command you can play any sound but it works only on i386-pc 
and uses speaker/PIT. Many systems don't have speakers or they are not 
connected to motherboards

* Using morse terminal. Same limitations as play command
* Spkmodem. It's not intended for end-user sounds


A bit more context for Slint and blind folks among its users:

* Only x86_64 Arch is supported, but if I could handle it I'd like to 
support

  also Arm for the Pi, ad Debian or Arch for instance?
* Grub is installed using the i386-pc and x86-64-efi targets. Our 
package also
  include x86-64-emu, which allows our users to preview the GRUB menu 
before
  booting after installation or after a change in grub.cfg. This comes 
handy

  especially for blind users, thanks for this feature by the way.
* We play a tune at boot using the play command both in EFI and Legacy 
modes.
* I have no statistics to sustain this claim but I assume that most 
blind users

  take choose a machine with a PC Speaker, allowing to hear this tune.
* Out of the box we have GRUB_TERMINAL_OUTPUT=console in 
/etc/default/GRUB. No

  fancy graphics (which also helps users with a low vision).

I understand that GRUB's scope is much wider in terms of targets and use 
cases

but permit me to speak on behalf of some of our users :-) I assume that the
bullets list above would not much differ for other accessible Linux
distributions, at least like Debian or Fedora, and maybe for other OS.

There's no proper way to hook up sound to described events but there're 
2 workarounds:

* Add \x7 to the messages, e.g. through using of .po/.mo translation
* Use morse terminal.
Proper implementation is a feature request


Please let me know if you need a more formal feature request using this 
list or

another channel and what it should include; in other words your requirements
for a request to be considered.

Thanks and best regards,
Didier

-- 
Len Sorensen




___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

How-to make grub play a sound when it asks a passphrase and/or in case of an issue.

[Didier Spaier]

Hello devs,

The new installer of the Slint Linux distribution that I maintain allows in
guided mode to fully (minus the BiosBoot partition and the ESP) encrypt the
drive where Slint is installed, if this drive is dedicated to Slint.

As the layout of the partition table then includes just one partition (and
optionally an additional one if there is enough space on the drive), we 
store

a LUKS keyfile in the initrd and use cryptmount so that GRUB asks the
passprase, no need to type it several times.

So far, so good.

To help blind users GRUB plays a tune when it displays its menu.

But in case of an encrypted drive this tune is played after decryption, thus
blind users don't know if/when GRUB asks the passphrase, and if they type it
blindly but don't hear the tune associated with the display of the boot menu
in a reasonable amount of time (10 or 15 seconds or so), they don't know 
what

happened: was the passphrase wrong, was it not asked for some reason, or did
GRUB ask to press Enter after a warning to continue?

I'd like that GRUB play a sound when asking the passphrase and/or in case of
events like: the passphrase doesn't match, or another issue require an user
intervention like pressing Enter to acknowledge a warning.

Is it already possible through some setting I didn't find? Or can the above
be considered as a feature request? In that latter case I am of course ready
to test a patch.

Best regards,

Didier

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: need hostname on menu

[Didier Spaier]

Sorry for the faulty paste, please keep only the part quoted below:

Le 24/01/2021 à 10:28, Didier Spaier a écrit :
> Hi,> > Le 24/01/2021 à 01:52, Humphrey van Polanen Petel a 
écrit :>> However, it seems to me that it would be a lot more useful to 
add a >> parameter allowing the user to display the name of the install 
from >> /etc/hostname.>> I won't repeat what grub developers said but in 
addition:> > 1) Other users could want to customize the name including 
an information> not available in /etc/hostname, like e.g. 
/etc/os-release> > 2) the customization is easy to do by the user or the 
package maintainer or> the distribution maintainer and there are several 
ways to do that, like:> a) Edit by hand grub.cfg> b) Write a customized 
config file as /etc/grub.d/_.> c) Write a script that 
customizes grub.cfg after having run grub-mkconfig> or update-grub.> d) 
Write a  wrapper script that runs grub-mkconfig or update-grub then do> 
the customization.> > Have a good day,> Didier


___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: need hostname on menu

[Didier Spaier]

Hi,

Le 24/01/2021 à 01:52, Humphrey van Polanen Petel a écrit :
However, it seems to me that it would be a lot more useful to add a 
parameter allowing the user to display the name of the install from 
/etc/hostname.


I won't repeat what grub developers said but in addition:

1) Other users could want to customize the name including an information
not available in /etc/hostname, like e.g. /etc/os-release

2) the customization is easy to by the user or the package maintainer
or the distribution maintainer and there are several ways to do that,
for instance edit by hand grub.cfg, or write a customized config file as
/etc/grub.d/_, or write a script that customizes grub.cfg
after having run grub-mkconfig or update-grub, possibly called
by a wrapper script that will run grub-mkconfig or update-grub first.

Have a good day,
Didier


I won't repeat what grub developers said but in addition:

1) Other users could want to customize the name including an information
not available in /etc/hostname, like e.g. /etc/os-release

2) the customization is easy to do by the user or the package maintainer or
the distribution maintainer and there are several ways to do that, like:
a) Edit by hand grub.cfg
b) Write a customized config file as /etc/grub.d/_.
c) Write a script that customizes grub.cfg after having run grub-mkconfig
or update-grub.
d) Write a  wrapper script that runs grub-mkconfig or update-grub then do
the customization.

Have a good day,
Didier

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] Warn if MBR gap is small and user uses advanced modules

[Didier Spaier]

Le 11/03/2020 à 13:43, Daniel Kiper a écrit :
> Adding Michael, Mihai, Javier and Peter...
> 
> Below you can find what more or less Vladimir and I agreed WRT small MBR
> gap. In general Vladimir convinced me to phase out small MBR gaps
> support gradually. This is first step in this journey. We think that we
> have to build some warnings into the code and extend documentation.
> Please chime in what you think about that...
> 
> On Tue, Mar 10, 2020 at 01:23:10PM +0100, Vladimir 'phcoder' Serbinenko wrote:
>> Daniel, do you want to adjust the whitelist?
>>
>> We don't want to support small MBR gap in pair with anything but
>> the simplest config of biosdisk+part_msdos+simple filesystem. In this
>> path "simple filesystems" are all current filesystems except zfs and
>> btrfs
> 
> Missing SOB...
> 
>> ---
>>  grub-core/partmap/gpt.c |  9 -
>>  grub-core/partmap/msdos.c   |  7 ++-
>>  include/grub/partition.h|  3 ++-
>>  include/grub/util/install.h |  7 +--
>>  util/grub-install-common.c  | 24 
>>  util/grub-install.c | 10 +++---
>>  util/grub-setup.c   |  2 +-
>>  util/setup.c|  5 +++--
>>  8 files changed, 56 insertions(+), 11 deletions(-)
>>
>> diff --git a/grub-core/partmap/gpt.c b/grub-core/partmap/gpt.c
>> index 103f6796f..25a5a1934 100644
>> --- a/grub-core/partmap/gpt.c
>> +++ b/grub-core/partmap/gpt.c
>> @@ -25,6 +25,9 @@
>>  #include 
>>  #include 
>>  #include 
>> +#ifdef GRUB_UTIL
>> +#include 
>> +#endif
>>
>>  GRUB_MOD_LICENSE ("GPLv3+");
>>
>> @@ -169,7 +172,8 @@ static grub_err_t
>>  gpt_partition_map_embed (struct grub_disk *disk, unsigned int *nsectors,
>>   unsigned int max_nsectors,
>>   grub_embed_type_t embed_type,
>> - grub_disk_addr_t **sectors)
>> + grub_disk_addr_t **sectors,
>> + int warn_short)
>>  {
>>struct gpt_partition_map_embed_ctx ctx = {
>>  .start = 0,
>> @@ -191,6 +195,9 @@ gpt_partition_map_embed (struct grub_disk *disk,
>> unsigned int *nsectors,
>>  N_("this GPT partition label contains no BIOS Boot Partition;"
>> " embedding won't be possible"));
>>
>> +  if (ctx.len < 450) {
> 
> Could you define constant somewhere?
> 
> Is it in sectors? Why 450? Should not it be 2048 if 1 MiB below?

Whichs lead to a question: would the slot between 24K (or maybe
32K or 64K if it is wise to round it?) and 1M still a good fit for
a Bios boot partition in case of a gpt? if not in which cases?

> ...and missing "&& warn_short" check...
> 
>> +grub_util_warn("Your BIOS Boot Partition is under 1 MiB, please
>> increase its size.");
>> +  }
>>if (ctx.len < *nsectors)
> 
> Could not we use this check somehow instead of adding new one?
> 
>>  return grub_error (GRUB_ERR_OUT_OF_RANGE,
>>  N_("your BIOS Boot Partition is too small;"
>> diff --git a/grub-core/partmap/msdos.c b/grub-core/partmap/msdos.c
>> index 7b8e45076..402bce050 100644
>> --- a/grub-core/partmap/msdos.c
>> +++ b/grub-core/partmap/msdos.c
>> @@ -236,7 +236,8 @@ static grub_err_t
>>  pc_partition_map_embed (struct grub_disk *disk, unsigned int *nsectors,
>>   unsigned int max_nsectors,
>>   grub_embed_type_t embed_type,
>> - grub_disk_addr_t **sectors)
>> + grub_disk_addr_t **sectors,
>> + int warn_short)
>>  {
>>grub_disk_addr_t end = ~0ULL;
>>struct grub_msdos_partition_mbr mbr;
>> @@ -390,6 +391,10 @@ pc_partition_map_embed (struct grub_disk *disk,
>> unsigned int *nsectors,
>>return GRUB_ERR_NONE;
>>  }
>>
>> +  if (end < 450 && warn_short) {
>> +grub_util_warn("You have a short MBR gap and use advanced config.
>> Please increase post-MBR gap");
> 
> Ditto?
> 
>> +  }
>> +
>>if (end <= 1)
>>  return grub_error (GRUB_ERR_FILE_NOT_FOUND,
>>  N_("this msdos-style partition label has no "
>> diff --git a/include/grub/partition.h b/include/grub/partition.h
>> index 7adb7ec6e..5697e28d5 100644
>> --- a/include/grub/partition.h
>> +++ b/include/grub/partition.h
>> @@ -55,7 +55,8 @@ struct grub_partition_map
>>grub_err_t (*embed) (struct grub_disk *disk, unsigned int *nsectors,
>>  unsigned int max_nsectors,
>>  grub_embed_type_t embed_type,
>> -grub_disk_addr_t **sectors);
>> +grub_disk_addr_t **sectors,
>> +int warn_short);
>>  #endif
>>  };
>>  typedef struct grub_partition_map *grub_partition_map_t;
>> diff --git a/include/grub/util/install.h b/include/grub/util/install.h
>> index 2631b1074..982115f57 100644
>> --- a/include/grub/util/install.h
>> +++ b/include/grub/util/install.h
>> @@ -193,13 +193,13 @@ grub_util_bios_setup (const char *dir,
>> const char *boot_file, const char *core_file,
>> const char *dest, int force,
>> int fs_probe, int allow_floppy,
>> -   int add_rs_codes);
>> +   int add_rs_codes, int warn_short_mbr_gap);
>>  void
>>  grub_util_sparc_setup (const char *dir,
>>  const char *boot_file, const char *core_file,
>>  const char *dest, int force,
>> 

Re: [PATCH v2 08/12] kern: Make grub_error() more verbose

[Didier Spaier]

Le 06/03/2020 à 18:03, David Michael a écrit :
> On Fri, Mar 6, 2020 at 9:02 AM Didier Spaier  wrote:
>> Le 06/03/2020 à 13:43, Daniel Kiper a écrit :
>>> If we go that way then we have to care about them by the end of the
>>> universe. And this means more and more issues like [1]. If somebody
>>> wants to use new GRUB then he/she have to reinstall the machine or
>>> something like that. IMO we should not care about users who do not want
>>> upgrade their machines or whatnot. Or at least their choices cannot
>>> impact GRUB development too much. And I think that this MBR constraint
>>> is hindering the project too much at this point. So, as above...
>>>
>>> Sorry for being blunt...
>>
>> Sorry to be off topic... In case of a GUID partition table, if I
>> understand the UEFI specification[1], as the first usable LBA should be
>> greater than or equal to 34 for a 512 bytes block size or 6 for a
>> 4096 bytes logical block size, it could begin after a gap of 24K.
>>
>> Then, if we assume that the first partition begins @ 1MiB, can't GRUB
>> use the space unused between the first usable LBA and 1MiB instead of
>> a Bios Boot partition, in case of "legacy" booting and a GPT? I ask as
>> then a Bios Boot partition wouldn't be necessary any more.
> 
> It would be best to use a boot partition so the core.img space is
> reserved by the GPT, but I once wanted to tack i386-pc GRUB onto an
> existing UEFI GPT disk, so I wrote the commands that do what you're
> describing here:
> 
> https://github.com/dm0-/installer/blob/master/examples/systems/fitpc.sh#L151-L178
> 
> I may be misremembering, but I think the core.img size was limited to
> around half a megabyte, so it should be safe to write it to the unused
> ~1MiB before the first partition after the GPT.  But yes, using the
> boot partition would probably be for the best if you are formatting a
> new disk.

Thanks for sharing David. This can be useful to allow Legacy booting
off a drive initially partitioned for UEFI booting only.

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH v2 08/12] kern: Make grub_error() more verbose

[Didier Spaier]

Le 06/03/2020 à 17:39, Lennart Sorensen a écrit :
> On Fri, Mar 06, 2020 at 05:30:23PM +0100, Didier Spaier wrote:
>> That'd be just one less thing to care about for the Slint installer
>> in case of  an 'automatic' installation, nothing major.
>>
>> Do you confirm that a Bios Boot partition starting at 1 KiB
>> and ending at 1 MiB won't overlap the GPT and is big enough?
> 
> It would absolutely overlap GPT since GPT usually starts at 512 bytes
> and goes up to 32KB or so.

My mistake, I should have written starting at 24 KiB as that is the
start address of the first usable LBA if I read correctly the UEFI
specification. Am I wrong?

Thanks for the heads-up.

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH v2 08/12] kern: Make grub_error() more verbose

[Didier Spaier]

Le 06/03/2020 à 15:38, Vladimir 'phcoder' Serbinenko a écrit :
> What's the problem with having bios boot partition? You can put it
> exactly in the spot you describe (in fact I do so) and it works as
> well, just additionally it marks this space as occupied

That'd be just one less thing to care about for the Slint installer
in case of  an 'automatic' installation, nothing major.

Do you confirm that a Bios Boot partition starting at 1 KiB
and ending at 1 MiB won't overlap the GPT and is big enough?

Thanks,
Didier


___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH v2 08/12] kern: Make grub_error() more verbose

[Didier Spaier]

Le 06/03/2020 à 13:43, Daniel Kiper a écrit :
> If we go that way then we have to care about them by the end of the
> universe. And this means more and more issues like [1]. If somebody
> wants to use new GRUB then he/she have to reinstall the machine or
> something like that. IMO we should not care about users who do not want
> upgrade their machines or whatnot. Or at least their choices cannot
> impact GRUB development too much. And I think that this MBR constraint
> is hindering the project too much at this point. So, as above...
> 
> Sorry for being blunt...

Sorry to be off topic... In case of a GUID partition table, if I
understand the UEFI specification[1], as the first usable LBA should be
greater than or equal to 34 for a 512 bytes block size or 6 for a
4096 bytes logical block size, it could begin after a gap of 24K.

Then, if we assume that the first partition begins @ 1MiB, can't GRUB
use the space unused between the first usable LBA and 1MiB instead of
a Bios Boot partition, in case of "legacy" booting and a GPT? I ask as
then a Bios Boot partition wouldn't be necessary any more.

I just hope this question is not too silly...

Best regards,
Didier


[1]https://uefi.org/sites/default/files/resources/UEFI_Spec_2_8_A_Feb14.pdf
§ 5.3.1 GPT overview

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] Add GRUB_DISABLE_UUID.

[Didier Spaier]

On 20/09/2019 15:23, Javier Martinez Canillas wrote:

On 9/20/19 2:42 PM, Daniel Kiper wrote:

On Thu, Sep 19, 2019 at 02:20:06PM +0200, Javier Martinez Canillas wrote:

Hello Daniel,

On 9/18/19 2:39 PM, Daniel Kiper wrote:

Adding Nicholas...

On Tue, Sep 17, 2019 at 05:48:45PM +0200, Javier Martinez Canillas wrote:

From: Peter Jones 

This will cause "search --fs-uuid --set=root ..." not to be generated by
grub2-mkconfig, and instead simply attempt to use the grub device name
as it understands it.

Signed-off-by: Peter Jones 
Signed-off-by: Javier Martinez Canillas 


We have this functionality in GRUB upstream. Please take a look at
commit 51be3372e (templates: Update grub script template files).
Could you pick it up in RH/Fedora?



That commit does something different if I'm reading it correctly. It's about
allowing to set the root kernel command line parameter to a PARTUUID instead
of a UUID or a device name, by using the grub-probe --target=partuuid option.

But Peter's patch is about setting the root param to a device name instead
of a UUID.

And also about not adding search commands in the grub.cfg to set the $root
and $boot grub environment variables by searching using a UUID.

Now digging more I found that there's already a GRUB_DISABLE_LINUX_UUID option


There are two variables: GRUB_DISABLE_LINUX_UUID and 
GRUB_DISABLE_LINUX_PARTUUID.



Yes. I didn't mention the GRUB_DISABLE_LINUX_PARTUUID variable because the 
search
command only has support to search using the UUID and not the PARTUUID.


It has support to search using the PARTUUID in case of a GPT, cf. commit
f2b9083f859c7dbf44a7a8e96ee0cf202f9a4187

As an aside, it would be very useful to extend this support to dos
partition tables. I believe that all partition tools create a disk
identifier when creating a dos partition table (at least fdisk, cfdisk
and parted do) so if I am not mislead-ed all dos partitions should have
a partuuid in the form DisklabelPartitionnumber.

This would allow e.g. to find the root Linux partitions from a rescue
media, even if the kernel has no associated initrd.

Maybe Jacob could propose a patch for that, as he did for gpt?


for the first part, so we only need to add an option for the second part.


OK.


Since this is not about Linux not using a UUID but grub not using it, I think
that we should add another option as this patch does. So GRUB_DISABLE_LINUX_UUID
would disable using a UUID for the root param and GRUB_DISABLE_UUID would be
about disabling using a UUID to set the $root (and $boot) variables in grub.

GRUB_DISABLE_UUID=true probably should imply GRUB_DISABLE_LINUX_UUID=true also


OK but only if GRUB_DISABLE_LINUX_UUID is not set explicitly. And what
about GRUB_DISABLE_LINUX_PARTUUID?



That's a good question. Would disabling using UUID mean "always use device name
for both GRUB and Linux" or "don't use the filesystem UUID for both GRUB and
Linux but allow Linux to use the partition UUID" ?

Peter's patch does the former. And yes, agreed that setting GRUB_DISABLE_LINUX*
to true should only be done if they weren't explicitly set.
  

I think. But I guess is OK to have separate options and the user could set both
if want to disable using the UUID for Linux and grub.

Another option is to extend GRUB_DISABLE_LINUX_UUID semantics and don't add
search commands if this is set to true, but I'm not sure if that's correct.


Hmmm... Probably I prefer former approach...


Agreed. I also prefer to introduce a new variable for this.



Daniel



Best regards,


Best regards,

Didier

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Windows versions identification needs an update in osdect.cfg

[Didier Spaier]

Hello,

didier[/data/GitHub/grub]$ grep Windows docs/osdetect.cfg
menuentry "Windows Vista bootmgr (on $device)" $device {
menuentry "Windows NT/2000/XP loader (on $device)" $device {
menuentry "Windows 98/ME (on $device)" $device {

Could this file be updated for Windows 7,8,8.1,10?

If this is a wrong list for such a request, where should I post it?

Best,

Didier

 


___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH v5] probe: Support probing for GPT partition UUID with -g

[Didier Spaier]

Hello,

On 13/05/2019 22:35, Jacob Kroon wrote:
> Hi Vladimir,
> 
> On Mon, May 13, 2019 at 10:11 PM Vladimir 'phcoder' Serbinenko
>  wrote:
>>
>> Ideally the option shouldn't be specific to GPT as other partmaps also have 
>> stable IDs. I think it's better not to have short option at all
>>
> 
> Ok, I have some questions below.
> 
>> On Mon, 13 May 2019, 20:33 Jacob Kroon,  wrote:
>>>
>>> Linux supports root=PARTUUID= boot argument, so add
>>> support for probing it. Compared to the fs UUID, the partition
>>> UUID does not change when reformatting a partition.
>>>
>>> Signed-off-by: Jacob Kroon 
>>> ---
>>>  docs/grub.texi |  2 +-
>>>  grub-core/commands/probe.c | 34 ++
>>>  2 files changed, 35 insertions(+), 1 deletion(-)
>>>
>>> Changes since v4:
>>>  * Do endianess byte-swapping on the fly when formatting string
>>>
>>> diff --git a/docs/grub.texi b/docs/grub.texi
>>> index 308b25074..d85818744 100644
>>> --- a/docs/grub.texi
>>> +++ b/docs/grub.texi
>>> @@ -4771,7 +4771,7 @@ a rest.
>>>  @node probe
>>>  @subsection probe
>>>
>>> -@deffn Command probe [@option{--set} var] 
>>> @option{--driver}|@option{--partmap}|@option{--fs}|@option{--fs-uuid}|@option{--label}
>>>  device
>>> +@deffn Command probe [@option{--set} var] 
>>> @option{--driver}|@option{--partmap}|@option{--fs}|@option{--fs-uuid}|@option{--label}|@option{--part-uuid}
>>>  device
>>>  Retrieve device information. If option @option{--set} is given, assign 
>>> result
>>>  to variable @var{var}, otherwise print information on the screen.
>>>  @end deffn
>>> diff --git a/grub-core/commands/probe.c b/grub-core/commands/probe.c
>>> index 95d272287..b26cbe2cc 100644
>>> --- a/grub-core/commands/probe.c
>>> +++ b/grub-core/commands/probe.c
>>> @@ -24,6 +24,7 @@
>>>  #include 
>>>  #include 
>>>  #include 
>>> +#include 
>>>  #include 
>>>  #include 
>>>  #include 
>>> @@ -45,6 +46,7 @@ static const struct grub_arg_option options[] =
>>>  {"fs", 'f', 0, N_("Determine filesystem type."), 0, 0},
>>>  {"fs-uuid",'u', 0, N_("Determine filesystem UUID."), 
>>> 0, 0},
>>>  {"label",  'l', 0, N_("Determine filesystem label."), 0, 0},
>>> +{"part-uuid",  'g', 0, N_("Determine GPT partition UUID."), 0, 0},
> 
> Is "part-uuid" ok ? I guess I should remove "GPT" from the help text ?

If I may interfere, lsblk names it PARTUUID (actually the case doesn't matter)
so I'd suggest partuuidn withjout a hyphen.

And yes, this field exists also with a 'dos' partition label (or 'msdos"
as parted calls it), not only a 'gpt'.

I can't say for other partition labels than those two, having only
used these.

 
> I've seen both 0 and -1 being passed as short option, do they both
> mean "no short option", or is there a preference which to use in this
> case ?
> 
> /Jacob

Best,

Didier

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] video: skip 'text' gfxpayload if not supported, to fallback to default

[Didier Spaier]

On 10/05/2019 15:24, Mathieu Trudel-Lapierre wrote:
> On Fri, May 10, 2019 at 7:52 AM Didier Spaier  wrote:
>>
>> On 10/05/2019 13:38, Daniel Kiper wrote:
>>> On Mon, Apr 29, 2019 at 01:57:02PM -0400, Mathieu Trudel-Lapierre wrote:
>>>> On UEFI, 'text' gfxpayload is not supported, but we still reach 
>>>> parse_modespec
>>>> with it, which will obviously fail. Fortunately, whatever gfxpayload is 
>>>> set,
>>>> we still still have the 'auto' default to fall back to. Allow getting to 
>>>> this
>>>> fallback by not trying to parse 'text' as a modespec.
>>>>
>>>> This is because 'text' correctly doesn't parse as a modespec, and ought to 
>>>> have
>>>> been ignored before we got to that point, just like it is immediately 
>>>> picked if
>>>> we're running on a system where 'text' is a supported video mode.
>>
>> As an aside, in a grub.cfg intended for both legacy and UEFI booting, can I
>> condition setting either 'vga=normal' or 'gfxpayload=text' depending on the
>> context detected by grub? If yes, how?
>>
> 
> In grub.cfg; you can check if you're on the right platform by checking
> 
> $grub_platform
> 
> On UEFI, it will read "efi".

Thanks!

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] video: skip 'text' gfxpayload if not supported, to fallback to default

[Didier Spaier]

On 10/05/2019 13:38, Daniel Kiper wrote:
> On Mon, Apr 29, 2019 at 01:57:02PM -0400, Mathieu Trudel-Lapierre wrote:
>> On UEFI, 'text' gfxpayload is not supported, but we still reach 
>> parse_modespec
>> with it, which will obviously fail. Fortunately, whatever gfxpayload is set,
>> we still still have the 'auto' default to fall back to. Allow getting to this
>> fallback by not trying to parse 'text' as a modespec.
>>
>> This is because 'text' correctly doesn't parse as a modespec, and ought to 
>> have
>> been ignored before we got to that point, just like it is immediately picked 
>> if
>> we're running on a system where 'text' is a supported video mode.

As an aside, in a grub.cfg intended for both legacy and UEFI booting, can I
condition setting either 'vga=normal' or 'gfxpayload=text' depending on the
context detected by grub? If yes, how?

Best,

Didier


___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: GRUB fails to load kernel on linux-sparc64

[Didier Spaier]

On 16/04/2019 21:38, John Paul Adrian Glaubitz wrote:
> That would indeed explain the problem. However, Debian's GRUB version
> does support compressed kernels on sparc64. I wonder whether we have
> a local modification that makes this possible.

Which makes me ask this OT question:
with the release of GRUB 2.04, will Debian be able to get rid of the 136 
patches currently applied in SID?

More generally will distributors be able get rid of the patches they apply?

Best,

Diider

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel