more troubleshooting and data
collection so I can open a new problem report for the lockup.)
Thanks again,
Scott
-Original Message-
From: Moritz Muehlenhoff [mailto:j...@inutil.org]
Sent: Wednesday, March 17, 2010 6:30 PM
To: Bailey, Scott (Server Management Virtualization)
Cc
This problem appears to be traceable to an old aboot boot image, and has
been corrected as described in bug 480014. Please close this report and
refer it to that one.
Thanks,
-Scott
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
I've been a long-time victim of this problem, too.
After a recent round of other updates to my Alphaserver 4100 5/466, I
decided to try the latest bind9 in testing -- 1:9.4.2-10 -- and was
surprised/pleased to see that it is working!
Other reporters might want to revisit this and see if their
Steve was correct. I updated both member drives of my RAID-1 /boot
array;
# swriteboot /dev/sda /boot/bootlx
# swriteboot /dev/sdg /boot/bootlx
My reboot problems were gone after this. I suspect that whenever aboot
updated itself last, it got confused by my configuration and never did
the
Thanks for your patience, it is hard to know what information is useful
sometimes. Martin also suggested using rootdelay, and I am please to
report that works as advertised. (Even on sparc using silo...) I should
be good going forward with this solution.
I think Martin already closed this report.
Here is console output from an earlier trial (with the 2.6.24 kernel)
showing the boot failure, some diagnostic output, and the subsequent
successful boot of my 2.6.22 kernel.
Hoping this is useful,
-Scott
P00boot -fl 1
Initializing...
SROM V3.0 on cpu0
SROM V3.0 on cpu1
SROM V3.0 on cpu2
FWIW, this problem persists in linux-image-2.6.22-3-alpha-smp 2.6.22-5.
Excellent! The packages you provided fixed my problem too!
Many thanks,
Scott
-Original Message-
From: Emanuele Rocca [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 04, 2007 4:21 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; Vladimir Volovich; Filipus Klutiero; Bailey
Jurij, thanks very much for the follow-up.
Executive Summary: I am working now (!!!)
Details:
- I took the xorg.conf you provided, and edited it to account
for my monitor. (Tweaked sync ranges, added '1600x1200' to modes).
This worked immediately.
- I then diff'd my working xorg.conf with the
I coincidentally just saw this issue with PostgreSQL over the weekend.
In my case, I had updated the postgresql packages (using aptitude) which
caused a database shutdown and restart. The bacula director process was
brain-damaged and spewed these errors until I recycled it too, after
which
Thanks are due to Ian Dall for the following patch. It replaces
hard-coded
30-second timeouts in qla1280.c, enabling tape operations that take
longer
than 30 seconds to work again. :-)
This patch applies cleanly to 2.6.17.11 with an offset of 1 line.
Signed-off-by: R. Scott Bailey [EMAIL
Of
Massimo Gais
Sent: Wednesday, July 12, 2006 6:27 AM
To: Bailey, Scott
Subject: Issue with qla1280.c (Debian bug #366730)
Hello,
I read about your bug report, and I'd like to know if
there is any development. By googling I've found
that you received only one answer on linux-scsi m/l,
so... any
Funny this should come up now, just after my last note. I found a patch
that looks better than mine in the report filed at
http://bugzilla.kernel.org/show_bug.cgi?id=6275 by Ian Dall. Alas, it
was posted in March and hasn't seen any activity (including a response)
since then.
Cheers,
John Goerzen wrote:
On Mon, May 22, 2006 at 05:54:24PM -0700, Nicolas Lopez wrote:
ii gcc4.0.3-4The GNU C compiler
ii gcc-4.04.0.3-3The GNU C compiler
[EMAIL PROTECTED]:~$ gcc --version
gcc (GCC) 4.0.4 20060507 (prerelease) (Debian 4.0.3-3)
Copyright (C)
This is somewhat odd; this is on an 2.6.8-3 machine (kernel from
stable):
sikkert:~# grep init_nfsd /proc/kallsyms
c8879000 t init_nfsd[nfsd]
Perhaps alpha is doing something odd? Or did you do anything to your
kernel?
Color me puzzled. I just finished updating to 2.6.16-8 this morning
Title: Me too :-)
Just a confirmation that I ran into this issue also after installing the new xserver-xorg 6.9 kits on my Ultra60 with an Elite3D/M3 card. The suggested workaround (putting cfb and cfb32 in the xorg.conf modules list) worked for me.
Luckily I didn't get around to installing
no 2.6.10 is unsupported, we are switching to 2.6.12 atm
there is some delay due to the new unified packaging,
but if you just need x86 version you can test those out:
http://charm.itp.tuwien.ac.at/~mattems/
anyway please report back if 2.6.12 works for you?
Stay tuned. The system that was
db4.2_recover did the trick!
hamster:/var/lib/onak# db4.2_recover -v
db_recover: Finding last valid log LSN: file: 2 offset 4913056
db_recover: Recovery starting from [2][4909836]
db_recover: Recovery complete at Fri Jul 8 16:08:32 2005
db_recover: Maximum transaction ID 8488 Recovery
If this helps, on my quest to build a 9.3.1 version of
dnssec-makekeyset, it appears the vanilla ISC distribution does not
build this executable by default. I have been hacking on the source
tarball's bin/dnssec/Makefile to add this to the list of targets to be
built (and duplicating information
Title: Close this bug (user error) :-)
I see, reviewing the ISC web site, that dnssec-makekeyset was intentionally removed and that somehow the appropriate keyset file is magically created by the remaining utilities in a way that isn't very well explained by any of the documentation I could
José,
I don't have any reason to believe this is specific to Bacula on Debian, so I
figured you likely would just kick this along to Kern; it just happens that at
the point I got fed up enough to file the report, it was easier to use
reportbug on the command line than visit bugs.bacula.org :-)
21 matches
Mail list logo
