Re: Netra T1 200 watchdog timeouts
Jurij Smakov wrote:
Should I be raising this as a bug, or can I assume that the people who
need to know about it are already aware of the issue?
Given that this affects Wheezy then a Debian bug is certainly in order.
It went in as 688521 at about the same time as you posted. Pity I didn't
hold off for another hour or so.
I haven't had time to track the development of Wheezy closely but I
think that it is pretty much using upstream SILO. I vaguely remember
a few changes upstream recently for both ext2/4 support and for cpu
detection. One of those could be causing your problem on the Wheezy
Well, Mark mentioned that the same issue is encountered in both Wheezy
and Squeeze SILO versions, which predates the recent ext2/4 changes.
Wheezy and Lenny, but not Squeeze. Which is odd in view of the
(upstream) version numbers, and suggests that it's either something very
specific to the distro version (e.g. kernel length) or is caused by the
precise version of the compiler.
And yes, there haven't been any Debian-specific changes to upstream
SILO as of version 1.4.14+git20100228-1, uploaded in February 2010.
Before that we had some Debian-specific patches included.
Mark, if you can try different SILO versions and find out which one
introduced the regression, that would be great. As far as I can tell,
releases shipped with the following versions:
Lenny : 1.4.13a+git20070930-3
Assuming that the failure was introduced between 1.4.13a+git20070930-3
(Lenny version) and 1.4.14+git20100228-1+b1 (Squeeze version), you
just have one intermediate version (1.4.14+git20100207-1) to test.
This is something I've not had to do before- Debian usually "just works"
or I have to go upstream if I want something bleeding-edge. Is this
syntax right and in view of the message what should I have in
root@firewall3:/home/markMLl# apt-get install silo=1.4.14+git20100228-1+b1
E: Version '1.4.14+git20100228-1+b1' for 'silo' was not found
Given the nature of the problem I think it would be useful to have a
good description of your installation in the bug. In particular
filesystem layout (partition table), type (ext2/3/4) etc. may be
relevant. A copy of the console session would be good to attach too.
Yep, the bug would be useful. Given that it's the first report like
this that I see and that a simple enough workaround exists, I would
don't think it qualifies as RC.
The problem here is that it mandates having a terminal attached to a
headless system since auto-boot doesn't work. Setting auto-boot-retry?
true doesn't help.
I'd have reported this earlier if I'd not spent three weeks messing
around with the OBP's lom@ and lom!, potential ways of getting at it
from Linux and looking for the Solaris LOM package :-/
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk
[Opinions above are the author's, not those of his employers or colleagues]