FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Kernel

 
 
LinkBack Thread Tools
 
Old 03-24-2010, 06:35 PM
Ian Campbell
 
Default Collecting additional bootloader/hypervisor information from reportbug hooks?

#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? 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?

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. I was wondering if that had been
considered and rejected for some reason (privacy issues perhaps?) 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).

Ian.

--
Ian Campbell

"In matters of principle, stand like a rock; in matters of taste, swim with
the current."
-- Thomas Jefferson
 
Old 03-24-2010, 11:24 PM
Ben Hutchings
 
Default Collecting additional bootloader/hypervisor information from reportbug hooks?

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.
 
Old 03-26-2010, 07:47 AM
Ian Campbell
 
Default Collecting additional bootloader/hypervisor information from reportbug hooks?

On Thu, 2010-03-25 at 00:24 +0000, Ben Hutchings wrote:
> 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 to list anything which Provides: xen-hypervisor. It looks like
the firmware packages don't have a common Provides so I don't think you
can shorten your list.

> > 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.

OK, that probably covers the majority of cases.

> 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).

Sounds reasonable.

> > 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).

Agreed. I've just looked at the grub and grub2 reportbug hooks and they
obscures passwords, so I think/hope someone has already gone through the
iterations and we can just crib from there.

> For now I think explicit support for LILO, GRUB 1 and GRUB
> 2 should cover 99% of the systems out there.

I'll try and dig into that.

How gross to people think it would be to just
call /usr/share/bug/{grub-legacy,grub-pc,lilo}/script from the kernel's
script (with appropriate checks for existence first)? At least looking
at the grub-legacy and grub-pc ones they seem to contain pretty much
what we would want.

Thanks,

Ian
--
Ian Campbell

Elegance and truth are inversely related.
-- Becker's Razor
 

Thread Tools




All times are GMT. The time now is 10:12 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org