On Wed, 2010-03-24 at 19:35 +0000, Ian Campbell wrote:
> #575183 suggests that it would be useful to know which hypervisor was
> installed when reportbug is used to report a bug against the kernel.
>
> Any objection to adding "xen-hypervisor" to
> linux-2.6/debian/templates/image.plain.bug/control?
If you specify just 'xen-hypervisor' does that cover all package names
beginning with that string? If so we should be doing the same with
'firmware-' rather than listing them all...
> It seems from a
> quick test that this follow dependencies and generates what seems to be
> the right thing to me e.g
> Versions of packages linux-image-2.6.32-3-xen-amd64 is related to:
> pn firmware-bnx2 <none> (no description available)
> pn firmware-bnx2x <none> (no description available)
> pn firmware-ipw2x00 <none> (no description available)
> ii firmware-ivtv 0.23 Binary firmware for iTVC15-family
> pn firmware-iwlwifi <none> (no description available)
> pn firmware-linux <none> (no description available)
> ii firmware-linux-nonfree 0.23 Binary firmware for various driver
> pn firmware-qlogic <none> (no description available)
> pn firmware-ralink <none> (no description available)
> ii xen-hypervisor-3.4-amd64 [xe 3.4.3~rc3-1 The Xen Hypervisor on AMD64
>
> Given that I would like to make changes in both trunk and the sid branch
> is there a normal procedure there or should I just make equivalent
> commits in both places?
Do it in both places.
> I was also thinking it might also be useful to include the output of "ls
> -lRt /boot" and/or /boot/grub/{grub.cfg,menu.lst}/other-bootloader-cfgs
> via one of the report bug hooks.
When the running kernel matches the package being reported on, then no,
we already have /proc/cmdline.
When the running kernel does not match then maybe the boot loader
configuration could be included. This might be a case where we should
ask the user first (same as with networking).
> I was wondering if that had been
> considered and rejected for some reason (privacy issues perhaps?)
If we do it then we need to be careful to obscure passwords (we've just
been through this with network configuration and took a few iterations
to cover the various possible WPA credentials).
> I guess perhaps the bootloader config thing might be appropriately handled
> by having bootloader packages drop some control info in "the right
> place" (whatever that might be).
Historically kernel packages had to know about every boot loader. This
has changed lately and new boot loaders are expected to install hook
scripts. But even that only covers updating the loader configuration;
there is no way to read it. (I think this is something to address in
squeeze+1.) For now I think explicit support for LILO, GRUB 1 and GRUB
2 should cover 99% of the systems out there.
Ben.
--
Ben Hutchings
I haven't lost my mind; it's backed up on tape somewhere.
Attachment:
signature.asc
Description: This is a digitally signed message part