[opensuse-factory] dracut runs during update
Hi list, just did an update to 20180313. During the update, dracut was running 4 (four!) times: kernel-default-4.15.8-1.1.x86_64 virtualbox-host-kmp-default-5.2.8_k4.15.8_1-1.1.x86_64 bbswitch-kmp-default-0.8_k4.15.8_1-28.76.x86_64 kmod-25-2.1.x86_64.rpm %posttrans Can't that be reduced to one single run at the end? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi, It would be nice, but how? On 2018-03-15 21:44, Peter Suetterlin wrote:
Hi list,
just did an update to 20180313.
During the update, dracut was running 4 (four!) times:
kernel-default-4.15.8-1.1.x86_64 virtualbox-host-kmp-default-5.2.8_k4.15.8_1-1.1.x86_64 bbswitch-kmp-default-0.8_k4.15.8_1-28.76.x86_64 kmod-25-2.1.x86_64.rpm %posttrans
Can't that be reduced to one single run at the end? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Le jeudi 15 mars 2018 à 21:54 +1000, Konstantin Voinov a écrit :
Hi,
It would be nice, but how?
We have macros to handle that in TW: %post {?regenerate_initrd_post} %postun %{?regenerate_initrd_post} %posttrans %{?regenerate_initrd_posttrans}
On 2018-03-15 21:44, Peter Suetterlin wrote:
Hi list,
just did an update to 20180313.
During the update, dracut was running 4 (four!) times:
kernel-default-4.15.8-1.1.x86_64 virtualbox-host-kmp-default-5.2.8_k4.15.8_1-1.1.x86_64 bbswitch-kmp-default-0.8_k4.15.8_1-28.76.x86_64 kmod-25-2.1.x86_64.rpm %posttrans
Can't that be reduced to one single run at the end?
-- Frederic Crozat Enterprise Desktop Release Manager SUSE -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thu, Mar 15, Frederic Crozat wrote:
Le jeudi 15 mars 2018 à 21:54 +1000, Konstantin Voinov a écrit :
Hi,
It would be nice, but how?
We have macros to handle that in TW:
%post {?regenerate_initrd_post}
%postun %{?regenerate_initrd_post}
%posttrans %{?regenerate_initrd_posttrans}
And they seem to work. On my systems, there is only the kernel who generates the initrd directly and does not use the posttrans for it. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & CaaSP SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Thorsten Kukuk wrote:
On Thu, Mar 15, Frederic Crozat wrote:
%posttrans %{?regenerate_initrd_posttrans}
And they seem to work. On my systems, there is only the kernel who generates the initrd directly and does not use the posttrans for it.
So no virtualbox/bbswitch on your machines I guess. Not sure - is that bugreport-worthy? Or feature request? How about the kernel - should it use %posttrans, too? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
15.03.2018 15:56, Peter Suetterlin пишет:
Thorsten Kukuk wrote:
On Thu, Mar 15, Frederic Crozat wrote:
%posttrans %{?regenerate_initrd_posttrans}
And they seem to work. On my systems, there is only the kernel who generates the initrd directly and does not use the posttrans for it.
So no virtualbox/bbswitch on your machines I guess.
Not sure - is that bugreport-worthy? Or feature request? How about the kernel - should it use %posttrans, too?
As I was answered a while back - kernel intentionally runs mkinitrd immediately to ensure installed kernel is actually bootable. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 15.03.2018 um 16:46 schrieb Andrei Borzenkov:
As I was answered a while back - kernel intentionally runs mkinitrd immediately to ensure installed kernel is actually bootable.
Which would be ok. But every -kmp does so as well. And then %posttrans does it *again*. Olaf's trick will probably the best thing to implement in ~/.alias for now ( 1/12) Installing: acpi_call-kmp-default-1.1.0_k4.16.0_rc5_1.g0dfffad-3.24.x86_64 ...[done] Additional rpm output: cat: write error: Broken pipe cat: write error: Broken pipe Creating initrd: /boot/initrd-4.16.0-rc5-1.g0dfffad-default dracut: Executing: /usr/bin/dracut --logfile /var/log/YaST2/mkinitrd.log --force /boot/initrd-4.16.0-rc5-1.g0dfffad-default 4.16.0-rc5-1.g0dfffad-default dracut: *** Including module: bash *** [...] dracut: *** Creating initramfs image file '/boot/initrd-4.16.0-rc5-1.g0dfffad-default' done *** ( 2/12) Installing: bluez-5.49-3.4.x86_64 ............................................[done] [...] ( 8/12) Installing: tp_smapi-kmp-default-0.43_k4.16.0_rc5_1.g0dfffad-1.11.x86_64 .....[done] Additional rpm output: cat: write error: Broken pipe cat: write error: Broken pipe Creating initrd: /boot/initrd-4.16.0-rc5-1.g0dfffad-default dracut: Executing: /usr/bin/dracut --logfile /var/log/YaST2/mkinitrd.log --force /boot/initrd-4.16.0-rc5-1.g0dfffad-default 4.16.0-rc5-1.g0dfffad-default dracut: *** Including module: bash *** [...] dracut: *** Creating initramfs image file '/boot/initrd-4.16.0-rc5-1.g0dfffad-default' done *** [...] (12/12) Installing: libdvbsi++-devel-0.3.8-1.12.x86_64 ...............................[done] Output of acpi_call-kmp-default-1.1.0_k4.16.0_rc5_1.g0dfffad-3.24.x86_64.rpm %posttrans script: Creating initrd: /boot/initrd-4.16.0-rc5-1.g0dfffad-default dracut: Executing: /usr/bin/dracut --logfile /var/log/YaST2/mkinitrd.log --force /boot/initrd-4.16.0-rc5-1.g0dfffad-default 4.16.0-rc5-1.g0dfffad-default dracut: *** Including module: bash *** [...] dracut: *** Creating image file '/boot/initrd-4.16.0-rc5-1.g0dfffad-default' *** dracut: *** Creating initramfs image file '/boot/initrd-4.16.0-rc5-1.g0dfffad-default' done *** Three times for only 2 kmp packages. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
I don't understate how it may helps. It's rpm-macros and proceeds with every rpm command. I think the zypper somehow should decide to run dracut or to not, but it's not safe way imo. On 2018-03-15 22:04, Frederic Crozat wrote:
Le jeudi 15 mars 2018 à 21:54 +1000, Konstantin Voinov a écrit :
Hi,
It would be nice, but how?
We have macros to handle that in TW:
%post {?regenerate_initrd_post}
%postun %{?regenerate_initrd_post}
%posttrans %{?regenerate_initrd_posttrans}
On 2018-03-15 21:44, Peter Suetterlin wrote:
Hi list,
just did an update to 20180313.
During the update, dracut was running 4 (four!) times:
kernel-default-4.15.8-1.1.x86_64 virtualbox-host-kmp-default-5.2.8_k4.15.8_1-1.1.x86_64 bbswitch-kmp-default-0.8_k4.15.8_1-28.76.x86_64 kmod-25-2.1.x86_64.rpm %posttrans
Can't that be reduced to one single run at the end?
-- Frederic Crozat Enterprise Desktop Release Manager SUSE -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Konstantin Voinov wrote:
I don't understate how it may helps. It's rpm-macros and proceeds with every rpm command. I think the zypper somehow should decide to run dracut or to not, but it's not safe way imo.
This is what posttrans is for, post transaction, i.e., at the end of the zypper command, no? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2018-03-15 23:38, Peter Suetterlin wrote:
Konstantin Voinov wrote:
I don't understate how it may helps. It's rpm-macros and proceeds with every rpm command. I think the zypper somehow should decide to run dracut or to not, but it's not safe way imo.
This is what posttrans is for, post transaction, i.e., at the end of the zypper command, no?
I think no, zypper just runs rpm with proper keys in dependency order, it doesn't do anything deeper -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thu, Mar 15, Konstantin Voinov wrote:
I don't understate how it may helps. It's rpm-macros and proceeds with every rpm command.
I suggest to read the macros, it does not proceed with every rpm command, it's a proper implemented posttrans.
I think the zypper somehow should decide to run dracut or to not, but it's not safe way imo.
And people who use RPM will never be able to boot? We had this "let zypper decide" in the past, it's called "update-scripts". Doesn't work as reliable as RPM does, because package developers test their RPMs with "rpm" and not zypper after test building them and never see the errors. Thorsten
On 2018-03-15 22:04, Frederic Crozat wrote:
Le jeudi 15 mars 2018 à 21:54 +1000, Konstantin Voinov a écrit :
Hi,
It would be nice, but how?
We have macros to handle that in TW:
%post {?regenerate_initrd_post}
%postun %{?regenerate_initrd_post}
%posttrans %{?regenerate_initrd_posttrans}
On 2018-03-15 21:44, Peter Suetterlin wrote:
Hi list,
just did an update to 20180313.
During the update, dracut was running 4 (four!) times:
kernel-default-4.15.8-1.1.x86_64 virtualbox-host-kmp-default-5.2.8_k4.15.8_1-1.1.x86_64 bbswitch-kmp-default-0.8_k4.15.8_1-28.76.x86_64 kmod-25-2.1.x86_64.rpm %posttrans
Can't that be reduced to one single run at the end?
-- Frederic Crozat Enterprise Desktop Release Manager SUSE -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & CaaSP SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2018-03-15 23:59, Thorsten Kukuk wrote:
On Thu, Mar 15, Konstantin Voinov wrote:
I don't understate how it may helps. It's rpm-macros and proceeds with every rpm command.
I suggest to read the macros, it does not proceed with every rpm command, it's a proper implemented posttrans.
Still don't get. rpm can read install/update packages stack (if it is a stack, does zypper puts it?) and macros will run one time only if there similar commands in rpm?
I think the zypper somehow should decide to run dracut or to not, but it's not safe way imo.
And people who use RPM will never be able to boot? We had this "let zypper decide" in the past, it's called "update-scripts". Doesn't work as reliable as RPM does, because package developers test their RPMs with "rpm" and not zypper after test building them and never see the errors.
That what I mean by "unsafe". There many different scenarios, when install/update process may be interrupted, what will be with these macros? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, 2018-03-16 at 00:35 +1000, Konstantin Voinov wrote:
On 2018-03-15 23:59, Thorsten Kukuk wrote:
On Thu, Mar 15, Konstantin Voinov wrote:
I don't understate how it may helps. It's rpm-macros and proceeds with every rpm command.
I suggest to read the macros, it does not proceed with every rpm command, it's a proper implemented posttrans.
Still don't get. rpm can read install/update packages stack (if it is a stack, does zypper puts it?) and macros will run one time only if there similar commands in rpm?
If packagers do the right thing, yes. You have %pre/%post which run before/after the respective package has been installed then there is %pretrans/%posttrans - which runs ones for an entire transaction, which is 'one zypper call' (or rpm -i file1.rpm file2.rpm - the two together will form a transaction) Cheers Dominique
On 15.03.2018 15:51, Dominique Leuenberger / DimStar wrote:
If packagers do the right thing, yes.
I believe that in case of KMP packages, you (as a packager) cannot do the right thing: https://build.opensuse.org/package/view_file/home:seife:testing/tp_smapi-kmp... No %pre/%post or similar, but still rebuilds the initrd. I think that the %suse_kernel_module pacakge might be to blame, but this is black magic to almost everyone. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Stefan Seyfried wrote:
On 15.03.2018 15:51, Dominique Leuenberger / DimStar wrote:
If packagers do the right thing, yes.
I believe that in case of KMP packages, you (as a packager) cannot do the right thing:
https://build.opensuse.org/package/view_file/home:seife:testing/tp_smapi-kmp...
No %pre/%post or similar, but still rebuilds the initrd. I think that the %suse_kernel_module pacakge might be to blame, but this is black magic to almost everyone.
Which could come as a good thing: 'Fixing' it in one place would solve it for all kmp packaged :D -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2018-03-16 00:51, Dominique Leuenberger / DimStar wrote:
On Fri, 2018-03-16 at 00:35 +1000, Konstantin Voinov wrote:
On 2018-03-15 23:59, Thorsten Kukuk wrote:
On Thu, Mar 15, Konstantin Voinov wrote:
I don't understate how it may helps. It's rpm-macros and proceeds with every rpm command.
I suggest to read the macros, it does not proceed with every rpm command, it's a proper implemented posttrans.
Still don't get. rpm can read install/update packages stack (if it is a stack, does zypper puts it?) and macros will run one time only if there similar commands in rpm?
If packagers do the right thing, yes.
You have %pre/%post which run before/after the respective package has been installed
then there is %pretrans/%posttrans - which runs ones for an entire transaction, which is 'one zypper call' (or rpm -i file1.rpm file2.rpm - the two together will form a transaction)
Cheers Dominique
I see (and I read the scripts). Thanks to all for explanation. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am Thu, 15 Mar 2018 12:44:11 +0100
schrieb Peter Suetterlin
Can't that be reduced to one single run at the end?
The current mindset is that mkinitrd must be run unconditionally when a kernel or kmp is installed, contrary to all other pkgs, they use %posttrans to update either bootloader or initrd just once at the very end of the transaction. To compensate for that mindset, the minimal version of a workaround looks like that: # touch /.buildenv # zypper dup # test -e /boot/initrd || mkinitrd -B Good luck. Olaf
On Thu, 2018-03-15 at 16:48 +0100, Olaf Hering wrote:
To compensate for that mindset, the minimal version of a workaround looks like that: # touch /.buildenv # zypper dup # test -e /boot/initrd || mkinitrd -B
Good luck.
I think the last statement here is the most important one in this mail: "GOOD LUCK" Cheers Dominique
Dominique Leuenberger / DimStar wrote:
On Thu, 2018-03-15 at 16:48 +0100, Olaf Hering wrote:
To compensate for that mindset, the minimal version of a workaround looks like that: # touch /.buildenv # zypper dup # test -e /boot/initrd || mkinitrd -B
Good luck.
I think the last statement here is the most important one in this mail:
"GOOD LUCK"
Hmm, update is online, and isn't online gambling prohibited ;^> I'm well adventurous, but I guess I'll pass on that one and rather wait a bit longer during the updates... -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Olaf Hering composed on 2018-03-15 16:48 (UTC+0100):
The current mindset is that mkinitrd must be run unconditionally when a kernel or kmp is installed, contrary to all other pkgs, they use %posttrans to update> either bootloader or initrd just once at the very end of the transaction.
To compensate for that mindset, the minimal version of a workaround looks like that: # touch /.buildenv # zypper dup # test -e /boot/initrd || mkinitrd -B
How (approximately - I'm an MC adherent) I constrain initrd creation: # zypper al kernel-default # zypper up # zypper -v dup # zypper in kernel-default # rm /boot/do_purge_kernels # reboot # chattr +i /boot/initrd-<version-latest> -- "Wisdom is supreme; therefore get wisdom. Whatever else you get, get wisdom." Proverbs 4:7 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (9)
-
Andrei Borzenkov -
Dominique Leuenberger / DimStar -
Felix Miata -
Frederic Crozat -
Konstantin Voinov -
Olaf Hering -
Peter Suetterlin -
Stefan Seyfried -
Thorsten Kukuk