[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#404784: marked as done (upgrade-reports: sarge -> Etch : megaraid driver problem)

Your message dated Tue, 2 Jan 2007 00:08:27 -0800
with message-id <20070102080827.GC9706@mauritius.dodds.net>
and subject line Bug#404784: upgrade-reports: sarge -> Etch : megaraid driver problem
has caused the attached Bug report to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere.  Please contact me immediately.)

Debian bug tracking system administrator
(administrator, Debian Bugs database)
--- Begin Message --- 
Package: upgrade-reports
Severity: important

Hi,

Upgrading from Sarge to Etch on a serveur with a HP Netraid 1M / 2M raid 
controler is likely to fail. (HP LC 2000 here)

Everything would be fine (that is, not better nor worse than on any 
other servers) until the final reboot : then, the raid controler 
wouldn't be found, so a kernel panic will occur if your root partition 
is on the raid controler, or sometimes an infinite loop depending on the 
initramfs-tool configuration.

The problem is that the new megaraid driver generation is used 
(megaraid_mm + megaraid_mbox) instead of the legacy one (megaraid) The 
PCI ID for the Netraid card are not considered by the legacy driver, so 
it won't claim the controler. 

If you have modules=dep in your initramfs.conf, the problem would be 
slightly different : megaraid_mm / megaraid_mbox will be loaded and try 
to send commands unknown by the controler, causing an infinite loop 
(sending command, waiting 300 secs for response, sending again, waiting 
300 secs, and so on).

This caused by a bug in the megaraid driver that was once patched, 
but the patch has gone between 2.6.14 and 2.6.18-3 kernels and need to 
be re-applied (see bug #317258).

The patched fixed the problem in my case, though I also had to change 
modules=dep to modules=most, but this won't be a problem for most 
installs as modules=most is the default.

Best regards,
-- 

Clement Hermann (nodens)

-- System Information:
Debian Release: 4.0
  APT prefers testing
  APT policy: (500, 'testing'), (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-3-686-custom0
Locale: LANG=fr_FR@euro, LC_CTYPE=fr_FR@euro (charmap=ISO-8859-15)

--- End Message ---
--- Begin Message --- 
Really closing the report :)

On Tue, Jan 02, 2007 at 12:06:23AM -0800, Steve Langasek wrote:
> Hi Clément,
> 
> On Thu, Dec 28, 2006 at 10:05:34AM +0100, Clément Hermann wrote:
> > Upgrading from Sarge to Etch on a serveur with a HP Netraid 1M / 2M raid 
> > controler is likely to fail. (HP LC 2000 here)
> 
> > Everything would be fine (that is, not better nor worse than on any 
> > other servers) until the final reboot : then, the raid controler 
> > wouldn't be found, so a kernel panic will occur if your root partition 
> > is on the raid controler, or sometimes an infinite loop depending on the 
> > initramfs-tool configuration.
> 
> > The problem is that the new megaraid driver generation is used 
> > (megaraid_mm + megaraid_mbox) instead of the legacy one (megaraid) The 
> > PCI ID for the Netraid card are not considered by the legacy driver, so 
> > it won't claim the controler. 
> 
> > If you have modules=dep in your initramfs.conf, the problem would be 
> > slightly different : megaraid_mm / megaraid_mbox will be loaded and try 
> > to send commands unknown by the controler, causing an infinite loop 
> > (sending command, waiting 300 secs for response, sending again, waiting 
> > 300 secs, and so on).
> 
> > This caused by a bug in the megaraid driver that was once patched, 
> > but the patch has gone between 2.6.14 and 2.6.18-3 kernels and need to 
> > be re-applied (see bug #317258).
> 
> > The patched fixed the problem in my case, though I also had to change 
> > modules=dep to modules=most, but this won't be a problem for most 
> > installs as modules=most is the default.
> 
> Thanks for the report.  Since you're not reporting any problems with the
> upgrade process itself, only with the software that's installed on your
> system at the end of the upgrade, and the bug in that software is already
> reported as bug #317258, I'm going to go ahead and close out this bug.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
vorlon@debian.org                                   http://www.debian.org/

--- End Message ---
Reply to: