[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Breakage from grub-mkconfig changes for grub-file

From: Vladimir 'φ-coder/phcoder' Serbinenko
Subject: Re: Breakage from grub-mkconfig changes for grub-file
Date: Mon, 23 Dec 2013 23:21:38 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131103 Icedove/17.0.10

On 23.12.2013 23:01, Colin Watson wrote:
> ec824e0f2a399ce2ab3a2e3353d372a236595059 introduced extensive changes to
> grub-mkconfig, which among other things arranged to run all but a
> hardcoded list of grub.d scripts once for each of several platforms with
> their output enclosed in an "if" block.  I do not feel that this change
> was well-thought-out, and I think it should be rethought or reverted
> before 2.02.  I didn't see anything about it here in advance - did I
> miss a thread?
> The problems I have with it are illustrated by its effects on the Debian
> patch.  I must emphasise that I don't think this is unique to the case
> of distributions with non-trivial patch sets, and that it's also likely
> to affect users who have made reasonable changes to /etc/grub.d/ locally
> (as they're entitled to do); distributions are just a useful
> early-warning system here.
>   1) Awkward hardcoded list; poor configurability
>   00_header, 30_os-prober, 40_custom, and 41_custom are run only once.
>   The Debian patch set has an additional script which is not
>   platform-dependent and should be run only once, namely
>   05_debian_theme, so I had to add another case here.  Users will surely
>   have other such files; not only do they have to know on upgrade that
>   they need to take care of this, but they have no recourse that doesn't
>   involve editing $prefix/bin/grub-mkconfig, which is not a file that
>   should normally be edited by the system administrator; changes to that
>   file will not normally persist on upgrades.
>   This should be redesigned so that there is some way to declare in a
>   grub.d script that it requires multi-platform support and should be
>   run multiple times.  (It *must* be this way round so that upgrades
>   work properly.)
The idea was that platform-independent scripts were still runnable,
they'll just produce the same output N times and this list is just an
optimisations, specially to avoid running os-prober N times.
The alternative will be to have something along the lines of different
hashbang or implementing this functionality as sh functions.
>   2) Strange ad-hoc platform names
>   The platform names used in grub-mkconfig (x86 i386-xen-pae x86_64-xen
>   mips mipsel sparc64 powerpc ia64 arm arm64) are not the same as the
>   platform names used in the GRUB build system, but yet they're exported
>   across the interface to /etc/grub.d/ as GRUB_PLATFORM.  This is messy
>   and confusing, and it's not clear what promises we make about future
>   changes here.
>   We should rationalise this before issuing anything as part of a stable
>   release, perhaps by adopting the same target_cpu/platform terminology
>   used in the build system.  Furthermore, if we made the namespaces
>   match up then it would be fairly straightforward to only run grub.d
>   scripts for platforms for which we have installed GRUB modules, which
>   seems as though it would be sensible.
GRUB platform names don't match with the OS compatibility. On x86 other
than xen you can use the same kernel on all the platforms. On ARM, for
what is arm-uboot platform for us may require different kernels for
different hardware.
>   3) Breaks function definitions
>   In the GRUB script language, "function" is only permitted at the top
>   level.  This may be an oversight since bash doesn't share this
>   restriction and GRUB script generally tries to look like bash;
>   nevertheless it exists today.  Part of the Debian patch set causes
>   10_linux to emit a function definition, which now causes a syntax
>   error.
>   I think my preferred fix here would be to implement functions other
>   than at the top level, but it seems a bit rash to try to cram that
>   into 2.02.
>   4) Smaller bugs
>   Aside from the bug fixed in 77ec462a568fc9c89ef45e960bf33b5de73140fb,
>   I'm pretty sure that the condition for the "x86" platform is buggy;
>   shouldn't it have an extra "-a" in there?  This sort of thing makes me
>   worried about the level of testing these changes have had.
Nice catch.

> The grub-file tool seems reasonable and useful to me, but can we just
> revert the grub-mkconfig parts of these changes until after 2.02 so that
> the effects of these interface changes can be considered more carefully?
I think it's good to move it to "next", together with --root-directory
functionality of grub-mkconfig.
Paulo Flabiano Smorigo wanted this feature badly. Unless he has striking
arguments why 2.02 needs it, I'm ok with moving this to "next".

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]