Colin Guthrie skrev 15.2.2012 11:35:
'Twas brillig, and David W. Hodgins at 14/02/12 23:21 did gyre and gimble:
On Tue, 14 Feb 2012 10:55:17 -0500, Colin Guthrie
<[email protected]> wrote:
Can everyone please test the new dracut please? Especially those of you
I'll test it shortly. I think there is a slight problem when dracut gets
updated at the same time as the kernel, udev, or anything else that is
going to get installed in the initramfs.
Rather then triggering the running of dracut when the kernel gets
installed,
I think it would be better to have something that runs at the end of urpmi
or MageiaUpdate, that check to see if dracut or anything in the existing
initramfs has been updated, and if so, then run dracut.
The best I can do from kernel pov is to change %post into %posttrans so
creating initrd would happend at end of install transaction
Strangely enough I was thinking vaguely along the same lines. My issue
was udev specifically. Sadly working out exactly when to rebuild the
initramfs is pretty tricky, e.g. if lvm or dm tools are updated do we
really need them in this particular setup's initramfs? Should we rebuild
anyway (it should be safe) and accept the unnecessary work in those
cases? Might be a reasonable thing to do...
"it should be safe" - famous last words... :)
I guess then a filetrigger could be written that checks for files
certain locations and triggers an initrd rebuild. For the kernel it
would only build one, but for udev, dm, lvm etc. it would rebuild all of
them...
We should _never_ rebuild all initrds.
If/when one of the updated packaged has a critical systemcrashing bug,
we render the whole system unbootable.
Might confuse some people however and create cases working systems are
hosed unnecessarily, and I'm not sure how much of real, practical
problem it is to simply have a slightly outdated tools in the initram
fs? Perhaps we just need to get ordering better on updates such that
udev, lvm, dm etc. are all ordered before kernel during updates? Maybe
that will solve 95% of the issues?
That could be an option of we can get the tools to differentiate between
high-priority (glibc/rpm/urpm*/...), priority (udev/lvm/dm/...) and the
rest...
Otoh, most of the issues we see now is Cauldron -> Cauldron updates.
in a stable release many of the packages wont change.
Of course that still leaves distro upgrades, but maybe that can be
handled in the installer or by adding versionated conflicts to kernel
to help urpmi figure out the order to update...
--
Thomas
