[Bug 1191322] New: Optimize building initrd when updating system
http://bugzilla.opensuse.org/show_bug.cgi?id=1191322 Bug ID: 1191322 Summary: Optimize building initrd when updating system Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.3 Hardware: All OS: Other Status: NEW Severity: Enhancement Priority: P5 - None Component: Kernel Assignee: kernel-bugs@opensuse.org Reporter: Ulrich.Windl@rz.uni-regensburg.de QA Contact: qa-bugs@suse.de Found By: --- Blocker: --- When installing updates, dracut is called multiple times to update the initrds of all kernels, for example when lvm2 is updated or when the kernel is updated. It would be better if the initrds were updated once at the end of the transaction (as Fedora does it, for example). Despite of that when keeping older kernels, there may be reasons _not_ to update the initrds of the older kernels: First, some may be removed on next boot anyway, and second, more important: If the idea of older kernels (and initrds) is to have a failback in case the new kernel, initrd or and binaries inside are broken (and thus fail to boot), it seems preferable to have the proven old kernel and initrd. -- You are receiving this mail because: You are the assignee for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1191322
http://bugzilla.opensuse.org/show_bug.cgi?id=1191322#c4
--- Comment #4 from Ulrich Windl
http://bugzilla.opensuse.org/show_bug.cgi?id=1191322
http://bugzilla.opensuse.org/show_bug.cgi?id=1191322#c7
--- Comment #7 from Ulrich Windl
Can you see which packages triggered the update-booloader invocations?
Unsure I'll find it from the logs, but my guess is (among others): lvm2, virtual box kernel modules, kernel modules, kernel, mdadm, device mapper, etc.
Unless I'm mistaken, calling grub2-mkconfig isn't that expensive, unless you have enabled the OS prober and have a lot of parallel OS installations.
On that machine OS-prober is on (it always was), and it takes *a lot* of time.
initramfs building takes much more time.
Well I didn't find a way to find the dracut invocations, but my guess is at least 10 during upgrade. -- You are receiving this mail because: You are the assignee for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1191322
http://bugzilla.opensuse.org/show_bug.cgi?id=1191322#c8
--- Comment #8 from Ulrich Windl
Then again running grub2-mkconfig without creating the ramdisk first is pointless so if we do optimize ramdisk creation we can as well do grub2-mkconfig along with it.
Interestingly with auto-detecting the installed OSes and re-building the GRUB menu after each initrd change, the main advantage of GRUB (that is: not needing to reinstall/refresh it when the kernel files changed) vaporizes. The OS-prober is way to dumb and inefficient. -- You are receiving this mail because: You are the assignee for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1191322
http://bugzilla.opensuse.org/show_bug.cgi?id=1191322#c10
Sinisa Bandin
http://bugzilla.opensuse.org/show_bug.cgi?id=1191322
http://bugzilla.opensuse.org/show_bug.cgi?id=1191322#c17
--- Comment #17 from Ulrich Windl
Without parallel: real 0m43.247s user 0m32.279s sys 0m14.510s
With parallel: real 0m6.568s user 0m30.678s sys 0m9.899s
The fact that parallel execution uses less user and sys CPU made me wonder: Did you flush the caches before each test? -- You are receiving this mail because: You are the assignee for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1191322
http://bugzilla.opensuse.org/show_bug.cgi?id=1191322#c18
--- Comment #18 from Ulrich Windl
http://bugzilla.opensuse.org/show_bug.cgi?id=1191322
http://bugzilla.opensuse.org/show_bug.cgi?id=1191322#c19
--- Comment #19 from Sinisa Bandin
(In reply to Sinisa Bandin from comment #15)
Without parallel: real 0m43.247s user 0m32.279s sys 0m14.510s
With parallel: real 0m6.568s user 0m30.678s sys 0m9.899s
The fact that parallel execution uses less user and sys CPU made me wonder: Did you flush the caches before each test?
No, this is all after running dracut a few times without "time" and doing some other random stuff. I just wanted to see the general effect, didn't mind about +/- 10% Now that you say it, it is interesting observation... will take another try afternoon, flushing the caches before each run. -- You are receiving this mail because: You are the assignee for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1191322
http://bugzilla.opensuse.org/show_bug.cgi?id=1191322#c20
--- Comment #20 from Sinisa Bandin
Another note: The original bug was about avoiding needless rebuilds of initrd, while parallel execution in presence of multiple kernels would still be called needlessly (event though in parallel for multiple kernels), I'm afraid. So you fixed the symptom, not the cause.
Yes, sorry about hijacking the thread, but this has been bothering me for quite some time. It would still be nice to have some flag to tell zypper to run dracut only once at the end. That would save more time, and disk writes too. -- You are receiving this mail because: You are the assignee for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1191322
http://bugzilla.opensuse.org/show_bug.cgi?id=1191322#c21
--- Comment #21 from Sinisa Bandin
(In reply to Sinisa Bandin from comment #15)
I did seem to have a problem: old initramfs files were called "initrd-xxxxxx", new ones are "initramffs-xxxxxxxx"
I suppose you simply copied dracut.sh from upstream? In that case this is expected. Upstream changed from "initrd" to "initramfs" a while ago (the term is technically more accurate), but openSUSE kept the name "initrd" for backward compatibility reasons.
Yes, I did, and only changed default behavior for "rebuild-all". Maybe I should have applied the diff, but this was quicker. Hopefully, changes will soon end up in official repo, but this works for me just fine for now. -- You are receiving this mail because: You are the assignee for the bug.
participants (1)
-
bugzilla_noreply＠suse.com