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.
--
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
