On 05.07.2018 15:51, Jake Edge wrote:
> On Thu, 5 Jul 2018 08:57:33 +0200 Harald Hoyer wrote:
>> On 04.07.2018 15:18, Jake Edge wrote:
>>> On Wed, 4 Jul 2018 15:06:58 +0200 Harald Hoyer wrote:
>>>> On 04.07.2018 14:50, Jake Edge wrote:
>>>>> On Wed, 4 Jul 2018 09:15:02 +0200 Harald Hoyer wrote:
>>>>>>
>>>>>>
>>>>>> apparently
>>>>>> /dev/disk/by-id/md-uuid-e40a0234-7e52-5f10-f267-658d8ec463fa
>>>>>>
>>>>>> changed its name to
>>>>>> /dev/disk/by-id/md-uuid-e40a0234:7e525f10:f267658d:8ec463fa
>>>>>>
>>>>>> Very strange...
>>>>>>
>>>>>> /lib/udev/rules.d/63-md-raid-arrays.rules:ENV{DEVTYPE}=="disk",
>>>>>> ENV{MD_UUID}=="?*", SYMLINK+="disk/by-id/md-uuid-$env{MD_UUID}"
>>>>>>
>>>>>> /sbin/mdadm -D --export /dev/md127
>>>>>> ...
>>>>>> MD_UUID=e40a0234:7e525f10:f267658d:8ec463fa
>>>>>>
>>>>>> I wonder if that changed with the new mdadm version.
>>>>>>
>>>>>> Jake, maybe changing the kernel command line option from
>>>>>> rd.md.uuid=e40a0234-7e52-5f10-f267-658d8ec463fa
>>>>>> to
>>>>>> rd.md.uuid=e40a0234:7e525f10:f267658d:8ec463fa
>>>>>> helps in your case.
>>>>>
>>>>> That certainly fixed things, thanks!
>>>>>
>>>>>> Please file a bug against mdadm, stating that apparently the
>>>>>> UUID changed.
>>>>>
>>>>> I guess I don't see how mdadm plays a role here -- it hasn't
>>>>> changed ... this was occurring on F26 and started months ago ...
>>>>> downgrading dracut (and only dracut) to 044-183.fc26.x86_64 and
>>>>> then running (for example for F28):
>>>>>
>>>>> dracut -v --kver 4.17.3-200.fc28.x86_64
>>>>>
>>>>> would create an initramfs that would boot ... either of the other
>>>>> two dracut versions since create an initramfs that won't boot (but
>>>>> apparently I can change the uuid format in grub2-efi.cfg as you
>>>>> figured out) ...
>>>>>
>>>>> seems weird that this happened and weirder that I am the only one
>>>>> (?) that has run into it ... thoughts?
>>>>>
>>>>> jake
>>>>>
>>>>
>>>> Yeah, I added a check for the /dev/disk/by-id/md-uuid-$MD_UUID
>>>> symlink in later versions. Seems like you hit that with newer
>>>> versions.
>>>
>>> so, should a bug be filed? against dracut? or is this something
>>> you just plan to fix in the next dracut update?
>>>
>>> thanks,
>>>
>>> jake
>>>
>>
>> Well, if the correct MD_UUID is specified, there is no bug. I just
>> wonder, if your MD_UUID changed over time, which would be a mdadm bug.
>
> Ok, but it would seem that whatever is creating the grub2-efi.cfg
> entries is passing the "wrong" uuid ... that works with the initramfs
> created by the older dracut because it does not do the check for the
> symlink?
>
> And it doesn't seem like the uuid itself has changed, just the format
> of how it is represented as a string, right?
>
>>>>>> rd.md.uuid=e40a0234-7e52-5f10-f267-658d8ec463fa
>>>>>> to
>>>>>> rd.md.uuid=e40a0234:7e525f10:f267658d:8ec463fa
>
> it must be the installation of a new kernel that kicks off the dracut
> to generate the initramfs and also adds an entry into the grub config?
> Where would it be grabbing the version with hyphens, instead of the
> right one with colons?
>
> this system has been around for quite some time, so perhaps it lived
> over a switch in format of the uuid but the old format still lingers
> somewhere?
>
> jake
>
Yes, those kind of kernel command line parameters are most likely from the first installation.
Automatically modifying your kernel command line parameters on updates would be a dangerous business :-)
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
