'Twas brillig, and Thomas Backlund at 15/02/12 10:09 did gyre and gimble: > 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 >>> <mag...@colin.guthr.ie> 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. Did we not used to do it when e.g. the bootspash theme changed? I remember a while back I had a problem as my /boot was quite modest and it ended up getting filled up with lots of .old files for the initrds.... That said, I can't really disagree. >> 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. Yeah I think overall Cauldron->Cauldron is not that important in the overall scheme of things. Users hear should be able to rebuild their initrd with a quick command or two easily enough when needed. > 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... Yeah, that's probably a good shout. Just before release, we can put a "Conflicts: udev < $latest" and similar stuff into the kernel... that would likely catch most potential problems. Col -- Colin Guthrie colin(at)mageia.org http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/