On 06/12/2012 09:34 PM, Nishanth Aravamudan wrote: > On 12.06.2012 [21:23:19 -0300], Lucas Meneghel Rodrigues wrote: >> On Tue, Jun 12, 2012 at 5:18 PM, Nishanth Aravamudan >> <n...@linux.vnet.ibm.com> wrote: >>> On 12.06.2012 [14:11:27 -0400], Cleber Rosa wrote: >>>>> Folks, >>>>> >>>>> I've just found what's going on. boottool code requires grubby >= >>>>> 8.11, which at the time, meant an unreleased version. >>>>> >>>>> So, our patches for grubby have not yet been commited, and now, with >>>>> grubby 8.11 and 8.12 shipping on many recent distros, the native >>>>> grubby binary is recent enough for boottool, but lacks necessary >>>>> features. >>>>> >>>>> I'm preparing a fix, and will ping the grubby maintainer again. >>>>> >>>>> Thanks for reporting this. >>>>> CR. >>>>> >>>> So, to be clear, this is *also* happening when native grubby >= 8.11. >>>> The enviroment reported by Steve is different, but the end result is >>>> the same, so I believe they are closely related. >>> Does it make sense to just always build & install the grubby from >>> autotest? I know it might mean down-revving, but if we need some >>> specific set of features/code, it makes sense to be certain they are >>> always there. >> We'd really really like to not need to resort to a patched grubby in >> the future, that's why we tried to reuse grubby and the code that >> already exists to handle bootloaders. Ideally, it'd be the same as >> resorting to 'ls' or any other external utility. We'll need to nag the >> upstream maintainer of grubby and hope he actually considers our >> patches for inclusion.
Yes, that was one of the main motivations for this work. We even went to great lengths to make grubby supported on other distros, hoping this could eventually lead to an universal boot configuration tool and interface, as Lucas said, just like 'ls'. > Sure. > >> So, while it might be OK to always build and install grubby from >> autotest, I really want to get rid of this in a couple of Fedora >> release cycles (~1 year). I also really want to see this systems not needing the compilation step, but since we're supposed to be distro agnostic, the compile code would have to stay. Ideally it's going to be used only on very few distros, and hopefully it will only fail on very very obscure custom hacked distros. > Absolutely -- I didn't mean it as a hard & fast rule, but as a > "practically speaking, we have to do this". And one can imagine other > distributions with grubby 8.11 may not have the patches, etc.? It seems > like if we are going to depend on a feature and that feature is not yet > upstream, we must require autotest to build from source (which brings > in its own pile of issues, of course) unconditionally until we are sure > that there is a consistent, sane way to check for the existence of the > feature we depend on. I am guessing version-string checking is not good > enough. By now it's obvious that we did not have a clear policy on official versus patches versions. I *hoped* that the time between 8.10 and 8.11 was going to be enough for upstream inclusion, so the check was limited to version numbers. It's possible to expand the version info and add a "vendor code", say, grubby 8.12-autotest. This is already done at the tarball level and could be expanded to the reported binary version and of course to the version check done by boottool. As you've put yourself, and I want to make it extra clear, we have to come up with a short-term policy on this, and follow with its implementation. As for actions, I've tried to isolate and replicate this issue. Right now I'm waiting on 2 jobs on different machine types (had different results from each type) with packaged based stock grubby 8.11. I'll report on that as soon as they're finished. Other urgent actions from my behalf will be to push the upstream inclusions of those patches. > > -Nish > _______________________________________________ Autotest mailing list Autotest@test.kernel.org http://test.kernel.org/cgi-bin/mailman/listinfo/autotest
