On 2020-08-06 19:20, Aaron Bauman wrote:
> Wait, changes were made to genkernel to switch from mdev to (e)udev
> which causes breakage, but it is *not* an issue with genkernel?

Exactly.

This failure can happen with genkernel version created 15 years ago,
with new genkernel-4.1 which switched device manager or even with dracut
-- the mistake is using non-permanent device names for things like root.

I assume that most user don't do that. At least their default boot entry
in /boot/extlinux/extlinux.cfg or via /etc/default/grub will have a
permanent name -- but the problem are tools/scripts appending to that
existing command-line. They will overwrite a good value...

And it's even more a problem because even when you notice "Ah, something
is appending root argument" you won't question that because the value
you notice matches your expectation from POV of current running system.
So you have to realize that this is a non-permanent value which could be
different on next boot because you did X which caused and offset in
numbering for example...


> Aside from this, do we have any evidence or bugs validating that users
> experience breakage with randomly named boot devices in kexec?
> 
> It is great that you found an issue, but why try and be agnostic as to
> which one caused the issue? It looks worse that we cannot simply say:
> 
> "genkernel changed for the better and things *may* break now... please
> read this!"
> 
> Instead, we are pushing a news item to a lot of people simply because we
> *assume* it may be an issue for others with no evidence.

Well, the purpose of this is to educate and avoid problems for
headless/server users. But if so many devs seem to care about pushing
maybe unrelated information and believe that avoiding that has much more
value than avoid a problem like an unbootable system for just a few
people (and for headless/servers this is a major problem in case you
cannot trigger remote reboot)... ¯\_(ツ)_/¯


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to