We had been writing 01_ceph_kernel with the kernel title, and
relying on the fact that grub.cfg would never have submenus in it
(implemented by a hack to /etc/grub.d/10_linux which neutered its
submenu creation). However, that hack was modifying a package file,
and got in the way of later apt commands. Rather than doing it
that way, this divines the title of the submenu and sets the
default variable to "submenu>kernel", which works to select the
desired kernel.
It depends on there being only one level of submenu, and on the
format of the menuentry and submenu commands, dictated by grub2.
None of this is likely to work at all outside Ubuntu.
Fixes: #4496
Signed-off-by: Dan Mick <dan.mick@inktank.com>
Reviewed-by: Dan Mick <dan.mick@inktank.com>
This is a fix for issue #4677 which was caused by kdb output being
hard-coded to ttyS1 which is fine for all our hardware except mira
machines. This change just checks to see if mira is in the host's
name and uses ttyS2 instead (simple fix).
This lets you specify a path to an existing kernel deb
to be pushed and installed on the remote node.
Limitations:
- We don't build the deb for you. figuring out what
filename 'make deb-pkg' is building is annoying.
- We need to be able to figure out the sha1 from the provided
path. It shouldn't be a problem, given the way make deb-pkg
names the debs.
This normalize check would only trigger if a *single* key was specified.
Change it so that it triggers as long as all keys are in the list of valid
keys. This lets us specify both kdb: true and a sha1/branch/tag.
Phew!
The 'git pull <uri>' seemed to consistently fail on some nodes. Can't be
sure this was really the problem with them all down now, but this is more
common, and works.
Simplifies the flavor stuff into a tuple of
<package,type,flavor,dist,arch>
where package is ceph, kenrel, etc.
type is tarball, deb
flavor is basic, gcov, notcmalloc
arch is x86_64, i686 (uname -m)
dist is oneiric, etc. (lsb_release -s -c)
Previously, if we reconnected before shutdown completed we asserted
that the kernel did not boot into the new version, when we just needed
to wait for the machine to reboot.
This is sticky; that is, even if you install other kernels (manually/via fab/etc),
grub will keep booting up the one that was last enabled via teuthology config.
Use teuthology to switch kernels and it'll just work.
If the kernel the grub default points to is removed, grub will fall back to
booting the kernel with the greatest version number.
Closes: http://tracker.newdream.net/issues/1364
It is run before anything other than checking for conflicts.
This way it can't step on the connections used by other tasks,
or clobber test files in /tmp when rebooting.
