[opensuse-factory] Syncing fixes between mkinitrd and dracut
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
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: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
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: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
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: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
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
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: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
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: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
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: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
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: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
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: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
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: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
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: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
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: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
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: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
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: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
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: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
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: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
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: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
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: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
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.
Due to bugs in the implementation its not easy to change from /boot/initrd* to /boot/initramfs*: rpm/post.sh calls /usr/lib/module-init-tools/weak-modules2 which defaults to /boot/initrd-<version> when it runs mkinitrd. Later rpm/post.sh calls "/usr/lib/bootloader/bootloader_entry ... initrd-<version>". If that string is changed to something else, the bootloader config entry and the actual filename in /boot will differ. So if its a hard requirement to let Kernel:HEAD work out of the box in older dists we are stuck with /boot/initrd and the currently implemented package conflict. Olaf -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 11/12/13, 11:44 AM, Olaf Hering wrote:
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.
Due to bugs in the implementation its not easy to change from /boot/initrd* to /boot/initramfs*: rpm/post.sh calls /usr/lib/module-init-tools/weak-modules2 which defaults to /boot/initrd-<version> when it runs mkinitrd. Later rpm/post.sh calls "/usr/lib/bootloader/bootloader_entry ... initrd-<version>". If that string is changed to something else, the bootloader config entry and the actual filename in /boot will differ.
So if its a hard requirement to let Kernel:HEAD work out of the box in older dists we are stuck with /boot/initrd and the currently implemented package conflict.
We've never had a hard requirement that Kernel:HEAD couldn't require updated dependencies. In the past we've required newer mkinitrd and newer udev pretty regularly. -Jeff -- Jeff Mahoney SUSE Labs
On Tuesday, November 12, 2013 12:45:24 PM Jeff Mahoney wrote:
On 11/12/13, 11:44 AM, Olaf Hering wrote:
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.
Due to bugs in the implementation its not easy to change from /boot/initrd* to /boot/initramfs*: rpm/post.sh calls /usr/lib/module-init-tools/weak-modules2 which defaults to /boot/initrd-<version> when it runs mkinitrd. Later rpm/post.sh calls "/usr/lib/bootloader/bootloader_entry ... initrd-<version>". If that string is changed to something else, the bootloader config entry and the actual filename in /boot will differ.
So if its a hard requirement to let Kernel:HEAD work out of the box in older dists we are stuck with /boot/initrd and the currently implemented package conflict.
We've never had a hard requirement that Kernel:HEAD couldn't require updated dependencies. In the past we've required newer mkinitrd and newer udev pretty regularly.
... and that was not nice. I hit that often in the past, I ignored the dependency and fortunately the stuff still came up. I also think that if we really want to switch to initramfs instead of initrd name, it should be done in a second step, before running into above or possible other issues where tools we did not even think about expect the initrd being named /boot/initrd*. I am currently looking at adjusting kdump (mkdumprd) to dracut. There may be others , at least for openSUSE factory not elementary features which need to get adjusted now one by one. Olaf's list of possibly affected packages is perfect for finding these. It should get concentrated on those instead of opening another construction site. Maybe I should write a short Wiki article how to switch back to mkinitrd by ignoring package dependencies if someone runs into such issues. It's not more than: #> rpm -e dracut --nodeps #> zypper install mkinitrd #> mkinitrd Thomas -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 13.11.2013 04:07, Thomas Renninger wrote:
On Tuesday, November 12, 2013 12:45:24 PM Jeff Mahoney wrote:
On 11/12/13, 11:44 AM, Olaf Hering wrote:
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.
Due to bugs in the implementation its not easy to change from /boot/initrd* to /boot/initramfs*: rpm/post.sh calls /usr/lib/module-init-tools/weak-modules2 which defaults to /boot/initrd-<version> when it runs mkinitrd. Later rpm/post.sh calls "/usr/lib/bootloader/bootloader_entry ... initrd-<version>". If that string is changed to something else, the bootloader config entry and the actual filename in /boot will differ.
So if its a hard requirement to let Kernel:HEAD work out of the box in older dists we are stuck with /boot/initrd and the currently implemented package conflict.
We've never had a hard requirement that Kernel:HEAD couldn't require updated dependencies. In the past we've required newer mkinitrd and newer udev pretty regularly.
Because there were real problems with older udev and mkinitrd? But if the only problem with dracut is that it needs a wrapper called 'mkinitrd' that creates /boot/initrd-*, then so what? Just use the wrapper. Or to put it other way around: If the only benefit of dracut is that the initramfs image is renamed, then let's please stay with mkinitrd. But my guess is that 1) there are actual benefit of switching to dracut, 2) there may be real problems with the switch, that we only find out by switching ASAP. This "let's patch every occurrence of 'initrd'" effort only delays the switch for questionable benefit.
I am currently looking at adjusting kdump (mkdumprd) to dracut. There may be others , at least for openSUSE factory not elementary features which need to get adjusted now one by one. Olaf's list of possibly affected packages is perfect for finding these. It should get concentrated on those instead of opening another construction site.
Exactly. Michal -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Michal Marek wrote:
[snip] If the only benefit of dracut is that the initramfs image is renamed, then let's please stay with mkinitrd. But my guess is that 1) there are actual benefit of switching to dracut,
All I have seen sofar is a slightly smaller initrd, which is largely irrelevant, except maybe to desktops which are booted more often and where the initrd can be quite large.
2) there may be real problems with the switch, that we only find out by switching ASAP. This "let's patch every occurrence of 'initrd'" effort only delays the switch for questionable benefit.
If we start opening bugreports on dracut, will anyone actually look at them? I've played with dracut a couple of times, and always ended up getting stuck on network and iSCSI support. I've asked about this on this list, noone appears to care much. -- Per Jessen, Zürich (4.5°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 13.11.2013 04:07, schrieb Thomas Renninger:
Maybe I should write a short Wiki article how to switch back to mkinitrd by ignoring package dependencies if someone runs into such issues. It's not more than: #> rpm -e dracut --nodeps #> zypper install mkinitrd #> mkinitrd
Having both installed would mean that people would be able to test. mkinitrd; dracut boot, try the dracut initramfs It fails => boot again, use the initrd. If only one is installable, at least I will certainly not install dracut until several people I trust have told me that it really works in all cases. And the "non essential for opensuse" cases you mention -- like kdump -- are actually very essential for many people. -- 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: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
В Wed, 13 Nov 2013 15:48:43 +0100 Stefan Seyfried <stefan.seyfried@googlemail.com> пишет:
Am 13.11.2013 04:07, schrieb Thomas Renninger:
Maybe I should write a short Wiki article how to switch back to mkinitrd by ignoring package dependencies if someone runs into such issues. It's not more than: #> rpm -e dracut --nodeps #> zypper install mkinitrd #> mkinitrd
Having both installed would mean that people would be able to test.
mkinitrd; dracut
And how all tools out there will now decide what to use - /boot/initrd or /boot/initramfs?
boot, try the dracut initramfs It fails => boot again, use the initrd.
If only one is installable, at least I will certainly not install dracut until several people I trust have told me that it really works in all cases.
And the "non essential for opensuse" cases you mention -- like kdump -- are actually very essential for many people.
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 13.11.2013 16:58, schrieb Andrey Borzenkov:
В Wed, 13 Nov 2013 15:48:43 +0100 Stefan Seyfried <stefan.seyfried@googlemail.com> пишет:
Am 13.11.2013 04:07, schrieb Thomas Renninger:
Maybe I should write a short Wiki article how to switch back to mkinitrd by ignoring package dependencies if someone runs into such issues. It's not more than: #> rpm -e dracut --nodeps #> zypper install mkinitrd #> mkinitrd
Having both installed would mean that people would be able to test.
mkinitrd; dracut
And how all tools out there will now decide what to use - /boot/initrd or /boot/initramfs?
Only one tool is concerned about that, and that's the boot loader config stuff. Letting perl-bootloader default to initramfs is fine -- everyone who wants to reliably boot his machine has a manually created entry which points to the vmlinuz / initrd symlinks in menu.lst anyway :-P All others could just call dracut *and* mkinitrd. The default should of course be to have only one installed, but it should not be hard to install both. -- 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: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
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: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, Nov 11, 2013 at 2:17 PM, Olaf Hering <ohering@suse.de> wrote:
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*.
Are you going to permit coexistence of initrd and initramfs for the same kernel or is it either/or? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, Nov 11, Andrey Borzenkov wrote:
Are you going to permit coexistence of initrd and initramfs for the same kernel or is it either/or?
dracut should create /boot/initramfs, mkinitrd will continue to create /boot/initrd. Just the tools around both will be updated to work with just dracut. Olaf -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Olaf Hering wrote:
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.
Has dracut been updated to deal with network boot and iSCSI too? I checked only a few weeks ago, and it wasn't working then. -- Per Jessen, Zürich (4.2°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
El 11/11/13 19:09, Per Jessen escribió:
Has dracut been updated to deal with network boot and iSCSI too? I checked only a few weeks ago, and it wasn't working then.
likely related to http://git.kernel.org/cgit/boot/dracut/dracut.git/commit/?id=c2ab99093817d46... -- "Judging by their response, the meanest thing you can do to people on the Internet is to give them really good software for free". - Anil Dash -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Cristian Rodríguez wrote:
El 11/11/13 19:09, Per Jessen escribió:
Has dracut been updated to deal with network boot and iSCSI too? I checked only a few weeks ago, and it wasn't working then.
likely related to
http://git.kernel.org/cgit/boot/dracut/dracut.git/commit/?id=c2ab99093817d46...
A change of returncode? Last I looked at the initrd built by dracut, there was also no iscsi config included, but I guess that could have changed in the meantime. -- Per Jessen, Zürich (4.4°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
El 14/11/13 07:45, Per Jessen escribió:
A change of returncode? Last I looked at the initrd built by dracut, there was also no iscsi config included, but I guess that could have changed in the meantime.
Got it, it indeed fails, because the open-iscsi package does not include utility iscsistart(8) # If our prerequisites are not met, fail anyways. type -P iscsistart hostname iscsi-iname >/dev/null || return 1 Fixed in request id 206964 -- "Judging by their response, the meanest thing you can do to people on the Internet is to give them really good software for free". - Anil Dash -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (11)
-
Andrey Borzenkov -
Cristian Rodríguez -
Jeff Mahoney -
Michal Kubecek -
Michal Marek -
Michal Vyskocil -
Olaf Hering -
Per Jessen -
Sid Boyce -
Stefan Seyfried -
Thomas Renninger