On Sat, Mar 20, 2010 at 1:16 AM, Ron Mexico ronmex...@mailinator.comwrote:
I have a storage server running on snv_129. When trying to reboot my server
it was stuck in the perpetual loop of the happy face boot screen. After
trying to boot in single-user mode, I got this error message:
I have a storage server running on snv_129. When trying to reboot my server
it was stuck in the perpetual loop of the happy face boot screen. After
trying to boot in single-user mode, I got this error message:
WARNING: The following lines in / differ from the boot archive:
changed
Thanks for that explanation of why there is no failsafe boot option for
OpenSolaris. I had wondere
d about that, since I'd seen it in Solaris Nevada/Express.
Ok, except that the CD boot is much slower.
Why is that a problem? Why should one worry about the boot time for a
rescue procedure?
On 20/03/2010 11:34, casper@sun.com wrote:
This problem should not have happened it is completely avoidable.
And CR6276367, recovery from boot_archive failures could be more fully
automated, does just that, as of build 136 =O) Took them a while, but
they fixed it, and it looks like a
Situation improves ... after I disabled compression on the swap Firefox no
longer hangs. At least yet.. Should I make a separate partition for it?
The kernel freeze I debugged with http://www.bruningsystems.com/runq.d and it
says:
(just a part here):
de7c4ac0 on run queue, execname =
Hi Jouko,
You might try running mdb -k and see what is thread 0xd8db3dc0 using:
d8db3dc0::threadlist -v
Jouko Holopainen wrote:
Situation improves ... after I disabled compression on the swap Firefox no
longer hangs. At least yet.. Should I make a separate partition for it?
The kernel
d8db3dc0::threadlist -v
ADDR PROC LWP CLS PRIWCHAN
d8db3dc0 fec21dd80 0 60 d2bb902c
PC: _resume_from_idle+0xb1TASKQ: atge_mii0
stack pointer for thread d8db3dc0: d8db3c58
swtch+0x188()
cv_timedwait_hires+0xc5()
cv_reltimedwait+0x52()
You could try making a copy of /etc/driver_aliases. Then rem_drv atge
(you may need a reboot afterwards). Then see if the problem goes away.
Also, try disabling nwam. That may stop the taskq thread(s) for atge.
max
Jouko Holopainen wrote:
d8db3dc0::threadlist -v
ADDR PROC
It is started to smell like a Dell specific problemmy Sony Vaio laptop runs
just fine.
Thanks,
Keith
--
This message posted from opensolaris.org
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
On 03/21/10 09:12 AM, keithk wrote:
It is started to smell like a Dell specific problemmy Sony Vaio laptop runs
just fine.
No, I have an Asus P6T system that never powers off.
--
Ian.
___
opensolaris-discuss mailing list
On 20.03.2010 21:20, Ian Collins wrote:
On 03/21/10 09:12 AM, keithk wrote:
It is started to smell like a Dell specific problemmy Sony Vaio
laptop runs just fine.
No, I have an Asus P6T system that never powers off.
It sounds like an ACPI2.0 bug, the same which Microsoft had to issue a
update-archive -R /mnt/foo
I assume you mean: bootadm update-archive -R /mnt/foo ?
I did that, and it said missing /boot/grub on root /mnt/rpool
--
This message posted from opensolaris.org
___
opensolaris-discuss mailing list
bootadm update-archive -R /
shutdown -y -g0 -i6
I would do this, but the machine wont start up in single user mode.
--
This message posted from opensolaris.org
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
On Sun, Mar 21, 2010 at 3:14 AM, Ron Mexico ronmex...@mailinator.com wrote:
update-archive -R /mnt/foo
I assume you mean: bootadm update-archive -R /mnt/foo ?
I did that, and it said missing /boot/grub on root /mnt/rpool
Bingo! And that is the reason why I had written:
(Im not sure right
14 matches
Mail list logo
