One of the motivations for UsrMerge is to have all read-only parts of
the operating system in /usr. The kernel packages install files in /boot
though which isn't in line with that idea.
Looking at Fedora they install files like vmlinuz that used to be named
/boot/$name-$kver as (/usr)/lib/modules/$kver/$name instead. They
include /boot/$name-$kver as %ghost.
Since all necessary information is passed to
/usr/lib/bootloader/bootloader_entry in %post, that script could create
links or copies in /boot if needed.
Does anyone have a better idea or can we just follow Fedora's approach here?
(o_ Ludwig Nussel
SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer
HRB 36809 (AG Nürnberg)
Hi, I have a vintage (2007) laptop, upgraded to openSUSE Leap 15.3. When using 15.3 kernel 5.3.18-57 there is no yenta module, so my PCMCIA cards are not working (a legacy Creative Soundblaster Audigy for example). If I boot into my Leap 15.2 kernel then it is working fine (with boot option "pci=cbmemsize=8M" workaround)
Is openSUSE removing support for legacy PCMCIA?
Is there a way to determine if/when this fix will appear in the kernel?
Or is it possible for the patch to be added?
I'm on the GNOME DE and have an AMD RX550, the only way for me at
present is adding amdgpu.dc=0 and loose hdmi sound support :(
Cheers Malcolm °¿° SUSE Knowledge Partner (Linux Counter #276890)
Tumbleweed 20210517 | GNOME Shell 40.0 | 5.12.3-1-default
HP Z440 | Xeon E5-2690 V3 X24 @ 2.60GHz | AMD RX550/Nvidia GT1030
up 18:11, 2 users, load average: 0.79, 0.40, 0.30
Forwarding, per Takashi's suggestion. Let's keep the discussion here.
-------- Forwarded Message --------
Subject: Re: Heads up: sunsetting mkinitrd
Date: Tue, 18 May 2021 17:46:03 +0200
From: Takashi Iwai <tiwai(a)suse.de>
To: Daniel Molkentin <dmolkentin(a)suse.de>
CC: factory(a)lists.opensuse.org, packaging(a)lists.opensuse.org
On Tue, 18 May 2021 17:21:20 +0200,
Daniel Molkentin wrote:
> with the pending submission of Dracut 054, which removes mkinitrd from
> the upstream sources, it's time to finally remove mkinitrd in Factory,
> Changes starting with 054
> - mkinitrd will temporarily live in its own dracut-mkinitrd-deprecated
> package. It will still be installed when requiring "mkinitrd" and
> requires dracut, so nothing changes here.
> - If you only required dracut, but meant to require mkinitrd, you need
> to change this temporarily or change your scripts to directly call dracut.
> mkinitrd has always been a rather mediocre wrapper that claimed to keep
> compatibility with the SLES 11 implementation. However:
> - it has a lot of bugs, quite some documented (!) flags have never
> worked, others are marked unimplemented or will say so only if invoked.
> I see little point in doing that given
> - it adds little value over just using plain Dracut
> Differences in calling dracut over calling mkinitrd:
> - Dracut only updates the initrd for the currently running kernel,
> unless either a kernel version or --regenerate-all is called
> - mkinitrd updates the bootloader by default. Dracut has no such option.
> Then again, those are two different concerns that are only merged into a
> single command for convenience. Usually this should be invoked from the
> kernel install script.
> - mkinitrd parses the no longer existing /etc/sysconfig/kernel file.
> - mkinitrd handles xen-specific modules. I have not enough understanding
> of the state of Xen in Factory to judge whether this is still required.
> If so, it should be handled in a dracut module. However, judging by the
> fact that the default is sourced from the defunc'ed kernel sysconfig
> file, this is probably also dead.
> - mkinitrd has slightly different semantics on how to specify a boot
> device for NFS & Co.
> Point of Contact
> If you have concerns how this affects your package, please let us (me,
> Thomas Blume or Neil) know. For the Kernel and other packages that are
> definitely impacted once mkinitrd would go away (e.g. YaST), we will
> reach out separately and / or file bugzilla issues.
I believe that the more suitable place to post would have been
In anyway, two biggest breakages would be the kernel packages
themselves and suse-module-tools package. There can be a few KMP
packages that have dependency on mkinitrd, but they could be fixed
since the dependency should be superfluous.
For the kernel packages, at least two things, AFAIK:
* kernel-* binary packages have dependency on mkinitrd
* kernel-obs-build explicitly creates the initrd with mkinitrd.
Both are relatively easy to fix, I suppose.
However, the major pains would be rather for the scripts in
suse-module-tools package. Better to ask Martin Wilck about that.