Shawn Ferry wrote: > Jorgen, > > You may want to try running 'bootadm update-archive' > > Assuming that your boot-archive problem is an out of date boot-archive > message at boot and/or doing a clean reboot to let the system try to > write an up to date boot-archive.
Yeah, it is remembering to do so after something has changed that's hard. In this case, I had to break the mirror to install OpenSolaris. (shame that the CD/DVD, and miniroot, doesn't not have md driver). It would be tempting to add the bootadm update-archive to the boot process, as I would rather have it come up half-assed, than not come up at all. And yes, other servers are on remote access, but since was a temporary trial, we only ran 1 network cable, and 2x 200V cables. Should have done a proper job at the start, I guess. This time I made sure it was reboot-safe :) Lund > > I would also encourage you to connect the LOM to the network in case you > have such issues again, you should be able to recover remotely. > > Shawn > > On Dec 13, 2007, at 10:33 PM, Jorgen Lundman wrote: > >> NOC staff couldn't reboot it after the quotacheck crash, and I only >> just >> got around to going to the Datacenter. This time I disabled NFS, and >> the rsync that was running, and ran just quotacheck and it completed >> successfully. The reason it didn't boot what that damned boot-archive >> again. Seriously! >> >> Anyway, I did get a vmcore from the crash, but maybe it isn't so >> interesting. I will continue with the stress testing of UFS on zpool >> as >> it is the only solution that would be acceptable. Not given up yet, I >> have a few more weeks to keep trying. :) >> >> >> >> -rw-r--r-- 1 root root 2345863 Dec 14 09:57 unix.0 >> -rw-r--r-- 1 root root 4741623808 Dec 14 10:05 vmcore.0 >> >> bash-3.00# adb -k unix.0 vmcore.0 >> physmem 3f9789 >> $c >> top_end_sync+0xcb(ffffff0a5923d000, ffffff001f175524, b, 0) >> ufs_fsync+0x1cb(ffffff62e757ad80, 10000, fffffffedd6d2020) >> fop_fsync+0x51(ffffff62e757ad80, 10000, fffffffedd6d2020) >> rfs3_setattr+0x3a3(ffffff001f1757c8, ffffff001f1758b8, >> ffffff1a0d942080, >> ffffff001f175b20, fffffffedd6d2020) >> common_dispatch+0x444(ffffff001f175b20, ffffff0a5a4baa80, 2, 4, >> fffffffff7c7ea78 >> , ffffffffc06003d0) >> rfs_dispatch+0x2d(ffffff001f175b20, ffffff0a5a4baa80) >> svc_getreq+0x1c6(ffffff0a5a4baa80, fffffffec7eda6c0) >> svc_run+0x171(ffffff62becb72a0) >> svc_do_run+0x85(1) >> nfssys+0x748(e, fecf0fc8) >> sys_syscall32+0x101() >> >> >> BAD TRAP: type=e (#pf Page fault) rp=ffffff001f175320 addr=0 >> occurred in >> module >> "<unknown>" due to a NULL pointer dereference >> >> >> >> >> >> -- >> Jorgen Lundman | <[EMAIL PROTECTED]> >> Unix Administrator | +81 (0)3 -5456-2687 ext 1017 (work) >> Shibuya-ku, Tokyo | +81 (0)90-5578-8500 (cell) >> Japan | +81 (0)3 -3375-1767 (home) >> _______________________________________________ >> zfs-discuss mailing list >> zfs-discuss@opensolaris.org >> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss > > -- > Shawn Ferry shawn.ferry at sun.com > Senior Primary Systems Engineer > Sun Managed Operations > 571.291.4898 > > > > > > _______________________________________________ > zfs-discuss mailing list > zfs-discuss@opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss > -- Jorgen Lundman | <[EMAIL PROTECTED]> Unix Administrator | +81 (0)3 -5456-2687 ext 1017 (work) Shibuya-ku, Tokyo | +81 (0)90-5578-8500 (cell) Japan | +81 (0)3 -3375-1767 (home) _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
