grub-devel
[Top][All Lists]
Advanced

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

Re: Bugs and tasks for 2.02[~rc1]


From: Andrei Borzenkov
Subject: Re: Bugs and tasks for 2.02[~rc1]
Date: Fri, 11 Mar 2016 21:38:04 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0

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.
>>
>> address@hidden:~/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.



reply via email to

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