Syncing fixes between mkinitrd and dracut

classic Classic list List threaded Threaded
34 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Syncing fixes between mkinitrd and dracut

Michal Vyskocil-2
Hi,

there is a new request [1] for mkinitrd fixing few bugs for openSUSE
Factory. However there was a big effort to replace dracut as a default
initrd tool, which seems to be turned on in Factory (see This will
replace mkinitrd with dracut as the default initrd generator. in
dracut.changes).

So I would expect all development and fixing effort should go into
dracut instead of mkinitrd (which is hard as even 13.1 won't have it as
a default, so most reports are for mkinitrd). So atm the best we can do
is to port mkinitrd fixes to dracut (and vice-versa?).

Are all interested people aware about the intended switch and is there a
process to forward bugs/feature requests from one group to an another?

CCying people found in last .changes for both as not sure, who is
subscribed here

[1] https://build.opensuse.org/request/show/203579

BTW: there is no bugowner for dracut in Base:System/dracut

Regards
Michal Vyskocil

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Syncing fixes between mkinitrd and dracut

Sid Boyce
On 17/10/13 15:49, Michal Vyskocil wrote:

> Hi,
>
> there is a new request [1] for mkinitrd fixing few bugs for openSUSE
> Factory. However there was a big effort to replace dracut as a default
> initrd tool, which seems to be turned on in Factory (see This will
> replace mkinitrd with dracut as the default initrd generator. in
> dracut.changes).
>
> So I would expect all development and fixing effort should go into
> dracut instead of mkinitrd (which is hard as even 13.1 won't have it as
> a default, so most reports are for mkinitrd). So atm the best we can do
> is to port mkinitrd fixes to dracut (and vice-versa?).
>
> Are all interested people aware about the intended switch and is there a
> process to forward bugs/feature requests from one group to an another?
>
> CCying people found in last .changes for both as not sure, who is
> subscribed here
>
> [1] https://build.opensuse.org/request/show/203579
>
> BTW: there is no bugowner for dracut in Base:System/dracut
>
> Regards
> Michal Vyskocil
My first build of a 3.12-rc5 kernel using dracut could not find devices
(see my posts looked at by Christian).
Yesterday I did a zypper dup, did a git pull on 3.12-rc5 and built it as
3.5.12.0-rc5a-smp+.

On boot it also drops into a shell.

This time all the devices were created except for the USB stick which I
had hoped to copy dmesg and
/run/initramfs/rdsosreport.txt, jounalctl, etc. to. I tried copying to /
but it's not there when I boot up a kernel that was set up with mkinitrd
instead of dracut it's not there.
Looks like everything lives in memory only and is only a subset.

There is no /etc/fstab, no /boot
mount says
rootfs on / type rootfs (rw)

Just what is mounted I can't tell as there isn't a "df" command but ls
-l isn't showing what I know to be on /dev/sda2 which is / and so there
is no /usr/src/, /usr/local.

Trying to mount /dev/sda2 (root partition) to /tmp/2 or /dev/sda1 to
/tmp/1 (boot partition) says they are already mounted.

I wish I could find a way to get those files off that box.
Regards
Sid.

--
Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot
Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support
Senior Staff Specialist, Cricket Coach
Microsoft Windows Free Zone - Linux used for all Computing Tasks

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Syncing fixes between mkinitrd and dracut

Olaf Hering-3
In reply to this post by Michal Vyskocil-2
On Thu, Oct 17, Michal Vyskocil wrote:

> there is a new request [1] for mkinitrd fixing few bugs for openSUSE
> Factory. However there was a big effort to replace dracut as a default
> initrd tool, which seems to be turned on in Factory (see This will
> replace mkinitrd with dracut as the default initrd generator. in
> dracut.changes).

Not too long ago we had this sort of "throw it in and see if it also
swims" approach with another core component of the system. As said
earlier, before going that route people have to sit down and compare
features/code one by one to avoid regressions.

There was advocating and some code was written, but I'm sure its
fulltime job to replace one core component with another.

> So I would expect all development and fixing effort should go into
> dracut instead of mkinitrd (which is hard as even 13.1 won't have it as
> a default, so most reports are for mkinitrd). So atm the best we can do
> is to port mkinitrd fixes to dracut (and vice-versa?).

> Are all interested people aware about the intended switch and is there a
> process to forward bugs/feature requests from one group to an another?

We better had a process, and a fulltimer to do the work.


In the meantime mkinitrd bugs have to be fixed once they are known.

Olaf
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Syncing fixes between mkinitrd and dracut

Cristian Rodríguez-2
El 17/10/13 18:13, Olaf Hering escribió:

> There was advocating and some code was written, but I'm sure its
> fulltime job to replace one core component with another.

Thomas Renninger already submitted the critical compatibility patches to
upstream and they were accepted.

> We better had a process, and a fulltimer to do the work.

Yeah, right..just like mkinitrd that didn't even had a maintainer.





--
"If debugging is the process of removing bugs, then programming must be
the process of putting them in." - Edsger Dijkstra
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Syncing fixes between mkinitrd and dracut

Michal Vyskocil-2
In reply to this post by Olaf Hering-3
On Thu, Oct 17, 2013 at 11:13:17PM +0200, Olaf Hering wrote:
> On Thu, Oct 17, Michal Vyskocil wrote:
>
> > there is a new request [1] for mkinitrd fixing few bugs for openSUSE
> > Factory. However there was a big effort to replace dracut as a default
> > initrd tool, which seems to be turned on in Factory (see This will
> > replace mkinitrd with dracut as the default initrd generator. in
> > dracut.changes).

Hi Olaf,

>
> Not too long ago we had this sort of "throw it in and see if it also
> swims" approach with another core component of the system. As said
> earlier, before going that route people have to sit down and compare
> features/code one by one to avoid regressions.
>
> There was advocating and some code was written, but I'm sure its
> fulltime job to replace one core component with another.

I can only agree with ya, even if I am not sure that such strong
feature/code check is needed.

>
> > So I would expect all development and fixing effort should go into
> > dracut instead of mkinitrd (which is hard as even 13.1 won't have it as
> > a default, so most reports are for mkinitrd). So atm the best we can do
> > is to port mkinitrd fixes to dracut (and vice-versa?).
>
> > Are all interested people aware about the intended switch and is there a
> > process to forward bugs/feature requests from one group to an another?
>
> We better had a process, and a fulltimer to do the work.
Yes, that would be ideal.

>
> In the meantime mkinitrd bugs have to be fixed once they are known.

I was not arguing about bugfixing of mkinitrd. If my email can be
interpreted such way, then I am sorry and have to be more carefull about
my text in the future.

All I wanted is to let both* parties know about each other and think
about some way how to change fixes bug reports. Otherwise all past
efforts regarding dracut will became pointless. And as mkinitrd is the
curent default, the most probable route is mkinitrd->dracut.

* note that I am not a part of any such party, so please don't shoot the
  messenger. IOW better to reply to factory ML than to me.

Best regards
Michal Vyskocil

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Syncing fixes between mkinitrd and dracut

Michal Marek
Dne 18.10.2013 09:50, Michal Vyskocil napsal(a):
> All I wanted is to let both* parties know about each other and
> think about some way how to change fixes bug reports. Otherwise all
> past efforts regarding dracut will became pointless. And as
> mkinitrd is the curent default, the most probable route is
> mkinitrd->dracut.

So should we CC Thomas or somebody else on mkinitrd bugs, to always
check if dracut is affected or not? That's about what can be done. The
code is so different that sharing actual bug _fixes_ is not possible.

Michal
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Syncing fixes between mkinitrd and dracut

Olaf Hering-3
On Fri, Oct 18, Michal Marek wrote:

> Dne 18.10.2013 09:50, Michal Vyskocil napsal(a):
> > All I wanted is to let both* parties know about each other and
> > think about some way how to change fixes bug reports. Otherwise all
> > past efforts regarding dracut will became pointless. And as
> > mkinitrd is the curent default, the most probable route is
> > mkinitrd->dracut.
>
> So should we CC Thomas or somebody else on mkinitrd bugs, to always
> check if dracut is affected or not? That's about what can be done. The
> code is so different that sharing actual bug _fixes_ is not possible.

I think the obvious approach is to go down the .changes file for each
/lib/mkinitrd/scripts/* file and check if each bugfix or feature is
indeed in dracut.

Olaf
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Syncing fixes between mkinitrd and dracut

Olaf Hering-3
In reply to this post by Michal Vyskocil-2
On Thu, Oct 17, Michal Vyskocil wrote:

> there is a new request [1] for mkinitrd fixing few bugs for openSUSE
> Factory. However there was a big effort to replace dracut as a default
> initrd tool, which seems to be turned on in Factory (see This will
> replace mkinitrd with dracut as the default initrd generator. in
> dracut.changes).

Now that I see what you mean with the last sentence, here are my
thoughts about the switch:

Rather than pretend to be mkinitrd, dracut should just be what it is:
dracut. As such it should create the filenames it creates per default
(initramfs instead of initrd), and it should be called by its name
(dracut instead of mkinitrd). That means at some point, when dracut is
ready, the places where mkinitrd is called should be changed to call
dracut instead. And where code looks for /boot/initrd* it should look
for /boot/initramfs*. At rpm packaging level the Requires should be
adjusted to point to dracut, perhaps also something like a
Conflict: perl-Bootloader < $oldversion should be added as needed.
I think mmarek has a better understanding about what places need
adjustments.

If its done in such a way then mkinitrd can be used in parallel and no
fileconflicts in /boot would occur.


Olaf
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Syncing fixes between mkinitrd and dracut

Per Jessen
Olaf Hering wrote:

> On Thu, Oct 17, Michal Vyskocil wrote:
>
>> there is a new request [1] for mkinitrd fixing few bugs for openSUSE
>> Factory. However there was a big effort to replace dracut as a
>> default initrd tool, which seems to be turned on in Factory (see This
>> will replace mkinitrd with dracut as the default initrd generator. in
>> dracut.changes).
>
> Now that I see what you mean with the last sentence, here are my
> thoughts about the switch:
>
> Rather than pretend to be mkinitrd, dracut should just be what it is:
> dracut. As such it should create the filenames it creates per default
> (initramfs instead of initrd), and it should be called by its name
> (dracut instead of mkinitrd). That means at some point, when dracut is
> ready, the places where mkinitrd is called should be changed to call
> dracut instead. And where code looks for /boot/initrd* it should look
> for /boot/initramfs*. At rpm packaging level the Requires should be
> adjusted to point to dracut, perhaps also something like a
> Conflict: perl-Bootloader < $oldversion should be added as needed.
> I think mmarek has a better understanding about what places need
> adjustments.
>
> If its done in such a way then mkinitrd can be used in parallel and no
> fileconflicts in /boot would occur.

That would be very nice.



--
Per Jessen, Zürich (15.2°C)
http://www.hostsuisse.com/ - dedicated server rental in Switzerland.

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Syncing fixes between mkinitrd and dracut

Thomas Renninger
In reply to this post by Olaf Hering-3
Hi,

On Monday, October 21, 2013 05:25:01 PM Olaf Hering wrote:
> On Thu, Oct 17, Michal Vyskocil wrote:
> > there is a new request [1] for mkinitrd fixing few bugs for openSUSE
> > Factory.
If there are fixes for mkinitrd, they should still go in.
It's still possible to switch back to mkinitrd, especially for finding
issues/incompatibilities with dracut via:
rpm -e dracut --nodeps
zypper install mkinitrd

> > However there was a big effort to replace dracut as a default
> > initrd tool, which seems to be turned on in Factory (see This will
> > replace mkinitrd with dracut as the default initrd generator. in
> > dracut.changes).
>
> Now that I see what you mean with the last sentence, here are my
> thoughts about the switch:
>
> Rather than pretend to be mkinitrd, dracut should just be what it is:
> dracut. As such it should create the filenames it creates per default
> (initramfs instead of initrd), and it should be called by its name
> (dracut instead of mkinitrd). That means at some point, when dracut is
> ready, the places where mkinitrd is called should be changed to call
> dracut instead. And where code looks for /boot/initrd* it should look
> for /boot/initramfs*. At rpm packaging level the Requires should be
> adjusted to point to dracut, perhaps also something like a
> Conflict: perl-Bootloader < $oldversion should be added as needed.
> I think mmarek has a better understanding about what places need
> adjustments.

Right now with dracut serving mkinitrd calls, every mkinitrd call
should result in a syslog message with a short notice which program
called mkinitrd and with which parameters.
Yes, callers should be identified and adjusted to call dracut directly.
Until these have been found and adjusted, dracut needs the mkinitrd
wrapper.
 
> If its done in such a way then mkinitrd can be used in parallel and no
> fileconflicts in /boot would occur.
I do not see the advantage of having installed both mkinitrd and dracut.
For debugging you could choose and let the initrd be built by the one
or the other.

       Thomas
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Syncing fixes between mkinitrd and dracut

Stefan Seyfried
Am 21.10.2013 19:09, schrieb Thomas Renninger:

> I do not see the advantage of having installed both mkinitrd and dracut.
> For debugging you could choose and let the initrd be built by the one
> or the other.

seeing the state dracut is in, I'd very much welcome if I could create
both an initramfs (dracut) and an initrd (mkinitrd).
Then if the initramfs does not work, I just edit my grub command line
and use the initrd.
--
Stefan Seyfried
"If your lighter runs out of fluid or flint and stops making
 fire, and you can't be bothered to figure out about lighter
 fluid or flint, that is not Zippo's fault." -- bkw
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Syncing fixes between mkinitrd and dracut

Cristian Rodríguez-2
El 21/10/13 17:39, Stefan Seyfried escribió:
> Am 21.10.2013 19:09, schrieb Thomas Renninger:
>
>> I do not see the advantage of having installed both mkinitrd and dracut.
>> For debugging you could choose and let the initrd be built by the one
>> or the other.
>
> seeing the state dracut is in,

what do you mean exactly ? I have tried it in at least 4 different
setups, latest versions (034) worked just fine in all of them.




--
"If debugging is the process of removing bugs, then programming must be
the process of putting them in." - Edsger Dijkstra
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Syncing fixes between mkinitrd and dracut

Stefan Seyfried
Am 21.10.2013 23:11, schrieb Cristian Rodríguez:

> El 21/10/13 17:39, Stefan Seyfried escribió:
>> Am 21.10.2013 19:09, schrieb Thomas Renninger:
>>
>>> I do not see the advantage of having installed both mkinitrd and dracut.
>>> For debugging you could choose and let the initrd be built by the one
>>> or the other.
>>
>> seeing the state dracut is in,
>
> what do you mean exactly ? I have tried it in at least 4 different
> setups, latest versions (034) worked just fine in all of them.

Last time I tried, I could not kdump onto a NFS filer via VLAN tagged
network interface. But that was a few days ago.
--
Stefan Seyfried
"If your lighter runs out of fluid or flint and stops making
 fire, and you can't be bothered to figure out about lighter
 fluid or flint, that is not Zippo's fault." -- bkw
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Syncing fixes between mkinitrd and dracut

Cristian Rodríguez-2
El 21/10/13 18:28, Stefan Seyfried escribió:

> Last time I tried, I could not kdump onto a NFS filer via VLAN tagged
> network interface. But that was a few days ago.

package kexec-tools is to blame, it does not have the needed dracut
-kdump module or any systemd/udev support at all, it is not surprising
it does not work.. all the needed code is available in the Fedora git
repository however.



--
"If debugging is the process of removing bugs, then programming must be
the process of putting them in." - Edsger Dijkstra
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Syncing fixes between mkinitrd and dracut

Michal Kubecek
On Mon, Oct 21, 2013 at 07:44:06PM -0300, Cristian Rodríguez wrote:
> El 21/10/13 18:28, Stefan Seyfried escribió:
>
> > Last time I tried, I could not kdump onto a NFS filer via VLAN tagged
> > network interface. But that was a few days ago.
>
> package kexec-tools is to blame, it does not have the needed dracut
> -kdump module or any systemd/udev support at all, it is not surprising
> it does not work.. all the needed code is available in the Fedora git
> repository however.

Exactly the typical systemd way of thinking. We break half of the system
but it is everyone else's fault because they don't do things our way and
it doesn't matter that they were here all the time and we just came...

I weep for Linux userspace and its future.

                                                          Michal Kubeček

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Syncing fixes between mkinitrd and dracut

Cristian Rodríguez-2
El 22/10/13 03:17, Michal Kubecek escribió:

> Exactly the typical systemd way of thinking. We break half of the system
> but it is everyone else's fault because they don't do things our way and
> it doesn't matter that they were here all the time and we just came...
>

and what do expect, magic ? kdump cannot work in the dracut generated
initrd without the code equivalent to

/lib/mkinitrd/scripts/boot-kdump.sh
/lib/mkinitrd/scripts/setup-kdump.sh
/lib/mkinitrd/scripts/setup-kdumpfs.sh
/lib/mkinitrd/scripts/setup-mkdumprd.sh

for the old mkinitrd-based setup, which is included in the "kdump"
package...(on which I stand corrected, in 13.1 it does have systemd/udev
support)






--
"If debugging is the process of removing bugs, then programming must be
the process of putting them in." - Edsger Dijkstra
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Syncing fixes between mkinitrd and dracut

Olaf Hering-3
In reply to this post by Thomas Renninger
On Mon, Oct 21, Thomas Renninger wrote:

> Yes, callers should be identified and adjusted to call dracut directly.
> Until these have been found and adjusted, dracut needs the mkinitrd
> wrapper.

No, until callers have been identified and adjusted to use dracut, its
not yet the time to make dracut the default. And noone is going to read
these messages sent to syslog anyway. The right tool to find users is a
grep in the whole source tree. In a few hours you will find the result
in my $HOME.

> > If its done in such a way then mkinitrd can be used in parallel and no
> > fileconflicts in /boot would occur.
> I do not see the advantage of having installed both mkinitrd and dracut.
> For debugging you could choose and let the initrd be built by the one
> or the other.

Right, and to be able to do so its required to be able to install both
at the same time without hassle.

So I think the current state of dracut is wrong and should be reverted,
then a clean approach to switch from mkinitrd/initrd to dracut/initramfs
should be implemented.


Olaf
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Syncing fixes between mkinitrd and dracut

Michal Marek
On 23.10.2013 09:32, Olaf Hering wrote:
> On Mon, Oct 21, Thomas Renninger wrote:
>
>> Yes, callers should be identified and adjusted to call dracut directly.
>> Until these have been found and adjusted, dracut needs the mkinitrd
>> wrapper.
>
> No, until callers have been identified and adjusted to use dracut, its
> not yet the time to make dracut the default.

Let me repeat: I am not going to change the kernel %post script to call
dracut directly instead of mkinitrd, at least not as long the kernel
package otherwise works on older distributions. Also, I think that
having to ship a mkinitrd wrapper is the least problem, the more
important part is making sure that dracut supports the storage setups
that mkinitrd does.

Michal
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Syncing fixes between mkinitrd and dracut

Olaf Hering-3
On Wed, Oct 23, Michal Marek wrote:

> On 23.10.2013 09:32, Olaf Hering wrote:
> > On Mon, Oct 21, Thomas Renninger wrote:
> >
> >> Yes, callers should be identified and adjusted to call dracut directly.
> >> Until these have been found and adjusted, dracut needs the mkinitrd
> >> wrapper.
> >
> > No, until callers have been identified and adjusted to use dracut, its
> > not yet the time to make dracut the default.
>
> Let me repeat: I am not going to change the kernel %post script to call
> dracut directly instead of mkinitrd, at least not as long the kernel
> package otherwise works on older distributions. Also, I think that
> having to ship a mkinitrd wrapper is the least problem, the more
> important part is making sure that dracut supports the storage setups
> that mkinitrd does.

The kernel does not seem to call mkinitrd, it calls
/usr/lib/module-init-tools/weak-modules2. So old dists are unlikely to
be affected if that script starts to make use of dracut in Factory.

What I see right now is yet another bananaware approach...


Olaf
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Syncing fixes between mkinitrd and dracut

Olaf Hering-3
In reply to this post by Thomas Renninger
On Mon, Oct 21, Thomas Renninger wrote:

> Hi,
>
> On Monday, October 21, 2013 05:25:01 PM Olaf Hering wrote:
> > On Thu, Oct 17, Michal Vyskocil wrote:
> > > there is a new request [1] for mkinitrd fixing few bugs for openSUSE
> > > Factory.
> If there are fixes for mkinitrd, they should still go in.
> It's still possible to switch back to mkinitrd, especially for finding
> issues/incompatibilities with dracut via:
> rpm -e dracut --nodeps
> zypper install mkinitrd

A few days ago we talked about this in person.

The outcome was to allow dracut to be installed in addition to mkinitrd.
As the next step dracut will create /boot/initramfs files, and all tools
fiddling with mkinitrd|mkinitrd_setup|initrd|/boot/initrd* will be
updated to call dracut instead of mkinitrd. And they will be updated to
handle /boot/initramfs* instead of /boot/initrd*. The only change
affecting kernel-binary.rpm is that an additional, empty ghost file
/boot/initramfs* has to be created to remove old initrds.

I already did a grep through the entire source tree. Packages matching
the pattern above were linked to home:olh:dracut. Now its my task to
wade through that and remove false matches, so that only affected
packages remain in that project.

But as a first step its required to step back and remove mkinitrd
conflicts from dracut, and to create /boot/initramfs* files. Whoever is
in charge for that, please make this change.


Olaf
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

12