From: Andrei Borzenkov <arvidjaar@gmail.com>
To: Peter Jones <pjones@redhat.com>
Cc: Vladimir 'phcoder' Serbinenko <phcoder@gmail.com>,
Colin Watson <cjwatson@debian.org>,
The development of GRUB 2 <grub-devel@gnu.org>
Subject: Re: Bugs and tasks for 2.02[~rc1]
Date: Fri, 11 Mar 2016 21:38:04 +0300 [thread overview]
Message-ID: <56E3108C.6060900@gmail.com> (raw)
In-Reply-To: <20160308214738.GA31913@redhat.com>
09.03.2016 00:47, Peter Jones пишет:
>>>
>>>>> e704140 Move bash completion script (#922997)
>>>>
>>>> Well, this is obvious compatibility question. Is there any way to detect
>>>> it at configure time? Does bash have pkg-config or similar?
>>>
>>> I don't see anything obviously like that, unfortunately, and I'm not
>>> really sure in what version they switched it.
>>>
>>
>> There is.
>>
>> bor@bor-Latitude-E5450:~/src/systemd$ pkg-config --variable
>> completionsdir bash-completion
>> /usr/share/bash-completion/completions
>>
>> Could you add configure.ac option that checks for it and defaults to
>> current value?
>
> Gah, it's in bash-completion not in bash. Well, anyway: sure thing,
> I'll fix up configure.ac, though I'm not that well versed in autoconf.
> Currently what I have is here, and I welcome any feedback:
> https://github.com/vathpela/grub2-fedora/commit/04844de3eb04f
>
Default should be current value.
This should use PKG_CHECK_EXISTS which also correctly handles missing
pkg-config at configure time. It is OK to require pkg-config for
building from GIT though.
We may want to make it into --with-bashcompletiondir so users can set it
also if pkg-config and/or bash-completion are not available.
Also please print bashcompletiondir value in final summary.
> Note that I've built that version but not actually tested it yet.
>
...
>
>>>>> 73545c7 Add GRUB_DISABLE_UUID.
>>>>
>>>> If name as detected by GRUB is correct, there will be no search because
>>>> hints will be correct (just direct verification that device is indeed
>>>> correct). If name is wrong you need search, otherwise you fail to boot
>>>> or boot wrong binary. I do not see what we gain here.
>>>
>>> So, the bug report from our QA dept believed
>>> GRUB_DISABLE_LINUX_UUID=true should accomplish this, and that it's
>>> pointless without it. And I think they've kind of got a point, since if
>>> the user has the problem GRUB_DISABLE_LINUX_UUID was meant to solve,
>>> there's no reason to believe they can't have the same problem with the
>>> other filesystem. We made them separate settings because one is about
>>> /boot and one is about / , but fundamentally they're both doing parts of
>>> the same thing.
>>>
>>
>> Not really. Linux UUIDs cannot be used without initrd, so if you have
>> monolithic kernel without initrd you cannot really use UUIDs for root.
>> So you can disable them in this case.
>>
>> It really needs some more details about problem it was intended to solve.
>
> Original bug is here:
> https://bugzilla.redhat.com/show_bug.cgi?id=1027833 . I'm not
> personally very invested in this one, except inasmuch as it's in my
> tree and I'd like that diff to get smaller over time... :)
>
So user has /boot UUID changing all the time? Unfortunately this bug
does not really explain why it happens. I mean, normally UUID of /boot
changes when you re-create filesystem, but then your /boot/grub is lost
as well together with grub.cfg and you need to create it again at which
point you get new UUID.
next prev parent reply other threads:[~2016-03-11 18:38 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-02 15:01 Bugs and tasks for 2.02[~rc1] Vladimir 'phcoder' Serbinenko
2016-03-02 22:24 ` Daniel Kiper
2016-03-09 10:49 ` Daniel Kiper
[not found] ` <20160309144557.GA19753@char.us.oracle.com>
2016-03-09 14:51 ` Vladimir 'phcoder' Serbinenko
2016-03-09 20:05 ` Daniel Kiper
2016-03-04 20:06 ` Peter Jones
2016-03-05 8:38 ` Andrei Borzenkov
2016-03-07 19:00 ` Peter Jones
2016-03-07 19:57 ` Vladimir 'phcoder' Serbinenko
2016-03-07 20:33 ` Andrei Borzenkov
2016-03-07 20:40 ` Vladimir 'phcoder' Serbinenko
2016-03-07 20:57 ` Andrei Borzenkov
2016-03-07 21:03 ` Vladimir 'phcoder' Serbinenko
2016-03-07 21:20 ` Peter Jones
2016-03-07 21:29 ` Andrei Borzenkov
2016-03-07 22:01 ` Peter Jones
2016-03-07 22:07 ` Vladimir 'phcoder' Serbinenko
2016-03-08 4:16 ` Michael Chang
2016-03-08 3:40 ` Michael Chang
2016-03-08 4:57 ` Andrei Borzenkov
2016-03-09 15:18 ` Matt Fleming
2016-03-09 20:15 ` Linux loader EFI handover (was: Bugs and tasks for 2.02[~rc1]) Andrei Borzenkov
2016-03-10 14:21 ` Matt Fleming
2016-03-11 17:46 ` Linux loader EFI handover Andrei Borzenkov
2016-03-07 21:42 ` Bugs and tasks for 2.02[~rc1] Matt Fleming
2016-03-11 15:51 ` Vladimir 'phcoder' Serbinenko
2016-03-14 15:17 ` Matt Fleming
2016-03-15 17:38 ` Vladimir 'phcoder' Serbinenko
2016-03-22 17:54 ` Peter Jones
2016-03-07 21:14 ` Peter Jones
2016-03-07 21:50 ` Vladimir 'phcoder' Serbinenko
2016-03-07 21:10 ` Peter Jones
2016-03-11 18:01 ` Andrei Borzenkov
2016-03-07 21:03 ` Peter Jones
2016-03-07 21:08 ` Andrei Borzenkov
2016-03-07 21:26 ` Peter Jones
2016-03-07 21:08 ` Vladimir 'phcoder' Serbinenko
2016-03-08 17:57 ` Andrei Borzenkov
2016-03-08 21:47 ` Peter Jones
2016-03-11 18:38 ` Andrei Borzenkov [this message]
2016-03-09 6:38 ` Olaf Hering
2016-03-09 7:54 ` Michael Chang
2016-03-09 8:13 ` Andrei Borzenkov
2016-03-11 16:04 ` Vladimir 'phcoder' Serbinenko
2016-04-13 8:49 ` Olaf Hering
2016-03-13 6:30 ` Andrei Borzenkov
2016-03-22 18:48 ` Vladimir 'phcoder' Serbinenko
2016-03-22 19:51 ` Andrei Borzenkov
2016-04-18 4:18 ` Vladimir 'phcoder' Serbinenko
[not found] ` <20160328145903.GF17944@char.us.oracle.com>
2016-04-12 16:44 ` Konrad Rzeszutek Wilk
2016-04-18 4:20 ` Vladimir 'phcoder' Serbinenko
2016-04-12 17:53 ` Bruce Dubbs
2016-04-18 4:20 ` Vladimir 'phcoder' Serbinenko
-- strict thread matches above, loose matches on Subject: below --
2016-03-03 14:47 Juergen Gross
2016-03-09 10:52 ` Daniel Kiper
2016-03-11 15:47 ` Vladimir 'phcoder' Serbinenko
2016-03-11 15:57 ` Juergen Gross
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=56E3108C.6060900@gmail.com \
--to=arvidjaar@gmail.com \
--cc=cjwatson@debian.org \
--cc=grub-devel@gnu.org \
--cc=phcoder@gmail.com \
--cc=pjones@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).