[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.
>
Ok.
> 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".
signature.asc
Description: OpenPGP digital signature