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
--
Jake Edge - LWN - jake@xxxxxxx - https://lwn.net
--
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
