From jcarroll65 at cfl.rr.com Wed Aug 4 12:40:20 2010 From: jcarroll65 at cfl.rr.com (jcarroll65 at cfl.rr.com) Date: Wed, 4 Aug 2010 12:40:20 -0400 Subject: SUMMARY: PCA suddenly not working In-Reply-To: <20100803151807.SHFT8.69908.root@cdptpa-web21-z01> Message-ID: <20100804164020.25J84.79283.root@cdptpa-web27-z01> The problem seems to have resolved itself as PCA now works as expected. Others reported similar issues and posited that it may be due to Sun switching to Akamai For the record: - Yes I have a valid support contract and ID. - It was not firewall issue as the network guys say they haven't changed anything. ;) - I've applied to join the PCA mail list, but haven't heard back as yet. JC ---- jcarroll65 at cfl.rr.com wrote: > I've been using PCA for quite some time and now is seems to no longer work. When I try to get the last patchdiag.xref I get "patchdiag.xref not found". The command with debugging: > > # ./pca --debug --getxref --xrefdir=/tmp > Option getxref: 1 > Option xrefdir: /tmp > Option patchdir: /export/home/jcarroll/junk/. > Option debug: 1 > Command: ./pca > ARGV: missing > Version: 20100727-01 > CWD: /export/home/jcarroll/junk > Found /usr/sfw/bin/wget (1.12, 11200, https) > Using /usr/sfw/bin/wget > Found /usr/bin/uname > Prerequisites for threads not met, setting threads to 0 > Never update > Expanded patch list: missing > Downloading xref file to /tmp/patchdiag.xref > Trying https://sunsolve.sun.com/ (1/1) > /usr/sfw/bin/wget --progress=dot:binary "https://sunsolve.sun.com/pdownload.do?target=patchdiag.xref" --ca-certificate=. > /pca -O /tmp/patchdiag.xref > --2010-08-03 15:06:06-- https://sunsolve.sun.com/pdownload.do?target=patchdiag.xref > Resolving sunsolve.sun.com... 192.18.108.40 > Connecting to sunsolve.sun.com|192.18.108.40|:443... connected. > HTTP request sent, awaiting response... 200 OK > Length: 0 [text/html] > Saving to: `/tmp/patchdiag.xref' > > 0K 0.00 =0s > > 2010-08-03 15:10:09 (0.00 B/s) - `/tmp/patchdiag.xref' saved [0/0] > > Failed (Unknown Error) > Failed (patchdiag.xref not found) > # > > I am using the latest pca and it worked Sunday (I have a cron job that gets the latest patchdiag.xref every Sunday night). The xref is available on http://sunsolve.sun.com/patchdiag.xref. Has Oracle (Sun) changed something without telling the world? (Kind of like changing java such that some applications now fail.) _______________________________________________ sunmanagers mailing list sunmanagers at sunmanagers.org http://www.sunmanagers.org/mailman/listinfo/sunmanagers From skendric at fhcrc.org Mon Aug 9 18:59:05 2010 From: skendric at fhcrc.org (Stuart Kendrick) Date: Mon, 09 Aug 2010 15:59:05 -0700 Subject: SUMMARY: Setting tcp_recv_hiwat but not seeing the result on the wire In-Reply-To: <4C5F4723.2080503@fhcrc.org> References: <4C5F4723.2080503@fhcrc.org> Message-ID: <4C608839.3010908@fhcrc.org> Per several correspondents, setting the maximum possible TCP buffer is a good start, but the application may or may not take advantage of this. In Samba's case, one can tell Samba to grab a larger buffer: /etc/samba/smb.conf [global] socket options = SO_RCVBUF=65536 And in fact, I can see the Solaris box advertising a TCP Window size of 64,240 bytes now, when I examine packet traces of file copies over SMB. A more complete socket options line might look as follows: [global] socket options = TCP_NODELAY SO_SNDBUF=65536 SO_RCVBUF=65536 Thank you for your assistance, --sk On 8/8/2010 5:09 PM, Stuart Kendrick wrote: > Hi folks, > > I'm setting TCP Receive Window size (along with other parameters) in a > custom /etc/init.d script: > > /usr/sbin/ndd -set /dev/tcp tcp_max_buf 4096000 > /usr/sbin/ndd -set /dev/tcp tcp_xmit_hiwat 4096000 > /usr/sbin/ndd -set /dev/tcp tcp_recv_hiwat 4096000 > /usr/sbin/ndd -set /dev/tcp tcp_wscale_always 1 > /usr/sbin/ndd -set /dev/tcp tcp_tstamp_if_wscale 1 > /usr/sbin/ndd -set /dev/tcp tcp_cwnd_max 4096000 > > Seems successful. > > > /usr/sbin/ndd -get /dev/tcp tcp_recv_hiwat > 4096000 > > > > But, for grins, I reboot anyway. > > > /usr/sbin/ndd -get /dev/tcp tcp_recv_hiwat > 4096000 > > > > However, when I negotiate a TCP session with the box, I see TCP Receive > Window sizes ranging around 48-49K, as seen in a packet trace, same as I > what I saw prior to fiddling with tcp_recv_hiwat > > https://vishnu.fhcrc.org/fred/telnet-to-fred5.pcap > https://vishnu.fhcrc.org/fred/shiva-to-fred5-smb-negotiate.pcap > > > I would expect the box to advertise a TCP Receive Window size of > 4096000, not 49232 and 49202 (telnet/TCP negotiation) or 49680 and 49532 > and 48300 (SMB/TCP negotiation). And for it to use RFC1323 window > scaling to do so. > > Any ideas why not? > > > uname -a > SunOS fred5 5.10 Generic_142900-05 sun4v sparc SUNW,Sun-Fire-T200 > > > > --sk > > Stuart Kendrick > FHCRC > > P.S. The box is slow at receiving files ... I can see TCP Receive Window > size dropping to 0 regularly ... > http://vishnu.fhcrc.org/fred/comparing-tcp-window-size-io-graphs.pdf > This might, of course, stem from slow storage or some other cause, such > that the box cannot drain the TCP buffer fast enough. But then again, > this is a 1GigE environment, with fast clients, and by my BDP > calculation, I need at least a 64K window size in order to keep up with > them, possibly closer to 128K. Ergo my efforts to fiddle with window size. _______________________________________________ sunmanagers mailing list sunmanagers at sunmanagers.org http://www.sunmanagers.org/mailman/listinfo/sunmanagers From warren.liang at cox.net Wed Aug 11 12:47:06 2010 From: warren.liang at cox.net (Warren Liang) Date: Wed, 11 Aug 2010 9:47:06 -0700 Subject: SUMMARY: One SPARC jumpstart server for SPARC and x86 clients Message-ID: <20100811124706.CH7MP.394839.imail@fed1rmwml31> Hello: I have received many responses. Would like to post a great note from R. Anderson: http://www.sun.com/bigadmin/content/submitted/setup_dhcp.jsp -----Original Message----- Hello: I have Solaris Jumpstart server on a SPARC machine. Can I use the same SPARC for jumpstart x86 client? I have download Solaris 10 x86 DVD ISO to the SPARC. Should I run setup_install_server to build jumpstart for x86? Thanks. Warren _______________________________________________ sunmanagers mailing list sunmanagers at sunmanagers.org http://www.sunmanagers.org/mailman/listinfo/sunmanagers From aad at dreamsnake.net Wed Aug 11 14:49:05 2010 From: aad at dreamsnake.net (Anthony D'Atri) Date: Wed, 11 Aug 2010 11:49:05 -0700 Subject: SUMMARY: Sun resellers actually able to quote on new products? In-Reply-To: <41951A05-B1B9-4AFC-9DEF-649E56A404C1@dreamsnake.net> References: <41951A05-B1B9-4AFC-9DEF-649E56A404C1@dreamsnake.net> Message-ID: My query: > [ I hesitated sending this to the list, but as I read the charter, this should be tolerable - apologies if it seems marginal ] > We're trying to quote/order a number of X4270M2's, which have been announced for a while now. > I'm told that our usual vendors now fall into two camps > #1: Waiting on Oracle, can't quote. Some give more detail about why, eg. Oracle hasn't given discount info on new models > #2: We don't offer good pricing on Sun anymore. How about HP, or IBM? > So, who out there is actually about to quote and accept orders for the newer models? I'll summarize responses appropriately. > (Aside: I demo'd an HP box and wasn't impressed with design or manageability. Haven't tried IBM. Thanks to all who responded. As usual, responses were the usual mixed bag, with a couple of on-target insights. Unfortunately there's little indication that Oracle, despite recently announcing new Sun products, will actually let them be bought. o Several people told me to try Dell (eg. R510) / IBM (x series) /HP gear -- none of which AFAICT has a usable serial console. Shipping a keyboard, monitor, and interpreter around the country/world to install systems isn't feasible for us, nor is DHCP. o A number of respondents supplied the names of various VARs saying that they'd been great in the past -- apparently with older x64 systems, or SPARC gear. o A number also said that they're moving away from Sun gear/OS to various flavors of Linux on various gear o A couple said to talk to our Sun/Oracle rep. I've tried that - no response at all. o Several said to order directly from Sun/Oracle. That'd be fine if we didn't mind losing the traditional 20-30% VAR discount. o There seems to be an indication that Oracle is favoring a direct-sales model, though they've made recent vague statements about how VARs are important to them. A couple of on-the-ball VARs wrote with more concrete information: it seems that Sun/Oracle hasn't given discounting information on Category U systems to VARs, which includes the X4270M2. VARs have to submit one-off RFQ's to Oracle right now for custom pricing. Many either don't know about this or feel that it's too much hassle. Those who are willing/able indicate that Oracle wants to know who the buyer is, where they are, what they do, what they want to run on the box, etc. There's some claim that this situation will be improved RSN, or "this winter". The respondent who asserted the former hinted about some big deal covered by NDA -- we'll see. I'm hoping that "this winter" comes sooner rather than later, as it's difficult to get purchases put through our finance people on either side of the year boundary. o One VAR offered, for some reason, to sell me SPARC CMT systems. o One respondent suggested his Sun/Oracle contact, who always gives instant quotes, but being military/government might be a factor there, and again it's not clear if that extends to the new Cat U systems. o Also, in the time since I sent the original message, it's come out that Oracle will be discontinuing sales of standalone J4000-series disk arrays, but will sell them as expansion for 7000-series NAS systems. I just don't understand a move Oracle's made. Why did they buy Sun if they don't want to let us buy product??? _______________________________________________ sunmanagers mailing list sunmanagers at sunmanagers.org http://www.sunmanagers.org/mailman/listinfo/sunmanagers From adamkurjewicz at yahoo.com Thu Aug 12 12:24:04 2010 From: adamkurjewicz at yahoo.com (Adam Kurjewicz) Date: Thu, 12 Aug 2010 09:24:04 -0700 (PDT) Subject: SUMMARY -Re: Logging commands being entered in the shell In-Reply-To: <384183.56583.qm@web33705.mail.mud.yahoo.com> References: <384183.56583.qm@web33705.mail.mud.yahoo.com> Message-ID: <913315.82598.qm@web33706.mail.mud.yahoo.com> Thanks for all the replies, Here are some of the suggestions that I am going to look further into: SolarisBSM auditing dtrace Putting the script procedure into the .shell file sudosh Thanks again for all your replies. Adam ________________________________ From: Adam Kurjewicz To: sunmanagers at sunmanagers.org Sent: Wed, August 11, 2010 2:37:45 PM Subject: Logging commands being entered in the shell Hi, I am wanting to know if there is a way of recording via a log file what a user enters into the shell. So if we have a user entering a cp, mv, or rm we would like to be able to record which user ran the command, what the date/time stamp were and a copy of what the user had entered in the shell window. Example if a user does: >$ rm file.txt I am wanting it to record the username, date/time, "rm file.txt" Does anyone have any suggestions on how to do this? Thanks, Adam _______________________________________________ sunmanagers mailing list sunmanagers at sunmanagers.org http://www.sunmanagers.org/mailman/listinfo/sunmanagers _______________________________________________ sunmanagers mailing list sunmanagers at sunmanagers.org http://www.sunmanagers.org/mailman/listinfo/sunmanagers From skendric at fhcrc.org Fri Aug 13 14:40:29 2010 From: skendric at fhcrc.org (Stuart Kendrick) Date: Fri, 13 Aug 2010 11:40:29 -0700 Subject: SUMMARY: Setting tcp_recv_hiwat but not seeing the result on the wire Message-ID: <4C65919D.7000803@fhcrc.org> OK, I've been doing this the hard way. Here's an easier way. If one sets tcp_recv_hiwat *prior* to Samba loading, then Samba does the right thing automatically, no need for anything special in smb.conf Add this to/etc/system and reboot to increase the maximum allowable TCP Receive Window. [Other applications may be able to take advantage of even larger windows, but SMBv1 has a ~64K application buffer and so cannot take advantage of anything larger.] set ndd:tcp_recv_hiwat=65535 /etc/samba/smb.conf [global] socket options = TCP_NODELAY --sk -------- Original Message -------- Subject: SUMMARY: Setting tcp_recv_hiwat but not seeing the result on the wire Date: Mon, 09 Aug 2010 15:59:05 -0700 From: Stuart Kendrick To: sunmanagers at sunmanagers.org Per several correspondents, setting the maximum possible TCP buffer is a good start, but the application may or may not take advantage of this. In Samba's case, one can tell Samba to grab a larger buffer: /etc/samba/smb.conf [global] socket options = SO_RCVBUF=65536 And in fact, I can see the Solaris box advertising a TCP Window size of 64,240 bytes now, when I examine packet traces of file copies over SMB. A more complete socket options line might look as follows: [global] socket options = TCP_NODELAY SO_SNDBUF=65536 SO_RCVBUF=65536 Thank you for your assistance, --sk On 8/8/2010 5:09 PM, Stuart Kendrick wrote: > Hi folks, > > I'm setting TCP Receive Window size (along with other parameters) in a > custom /etc/init.d script: > > /usr/sbin/ndd -set /dev/tcp tcp_max_buf 4096000 > /usr/sbin/ndd -set /dev/tcp tcp_xmit_hiwat 4096000 > /usr/sbin/ndd -set /dev/tcp tcp_recv_hiwat 4096000 > /usr/sbin/ndd -set /dev/tcp tcp_wscale_always 1 > /usr/sbin/ndd -set /dev/tcp tcp_tstamp_if_wscale 1 > /usr/sbin/ndd -set /dev/tcp tcp_cwnd_max 4096000 > > Seems successful. > > > /usr/sbin/ndd -get /dev/tcp tcp_recv_hiwat > 4096000 > > > > But, for grins, I reboot anyway. > > > /usr/sbin/ndd -get /dev/tcp tcp_recv_hiwat > 4096000 > > > > However, when I negotiate a TCP session with the box, I see TCP Receive > Window sizes ranging around 48-49K, as seen in a packet trace, same as I > what I saw prior to fiddling with tcp_recv_hiwat > > https://vishnu.fhcrc.org/fred/telnet-to-fred5.pcap > https://vishnu.fhcrc.org/fred/shiva-to-fred5-smb-negotiate.pcap > > > I would expect the box to advertise a TCP Receive Window size of > 4096000, not 49232 and 49202 (telnet/TCP negotiation) or 49680 and 49532 > and 48300 (SMB/TCP negotiation). And for it to use RFC1323 window > scaling to do so. > > Any ideas why not? > > > uname -a > SunOS fred5 5.10 Generic_142900-05 sun4v sparc SUNW,Sun-Fire-T200 > > > > --sk > > Stuart Kendrick > FHCRC > > P.S. The box is slow at receiving files ... I can see TCP Receive Window > size dropping to 0 regularly ... > http://vishnu.fhcrc.org/fred/comparing-tcp-window-size-io-graphs.pdf > This might, of course, stem from slow storage or some other cause, such > that the box cannot drain the TCP buffer fast enough. But then again, > this is a 1GigE environment, with fast clients, and by my BDP > calculation, I need at least a 64K window size in order to keep up with > them, possibly closer to 128K. Ergo my efforts to fiddle with window size. _______________________________________________ sunmanagers mailing list sunmanagers at sunmanagers.org http://www.sunmanagers.org/mailman/listinfo/sunmanagers From nevin.smgr at gmail.com Sat Aug 14 02:53:51 2010 From: nevin.smgr at gmail.com (Nevin) Date: Sat, 14 Aug 2010 12:23:51 +0530 Subject: SUMMARY: Interface Flags Numeric codes Message-ID: Thanks to all who responded. Special thanks to Michael Maciolek and Donald H Locker. Straight answer is : these codes are defined in /usr/include/net/if.h ~~~~~~~~~~~~~~~~ from Michael Maciolek toNevin dateFri, Aug 13, 2010 at 10:35 PM subjectRe: Interface Flags Numeric codes mailed-bynoop.org 10:35 PM (13 hours ago) The codes are listed and (briefly) explained in /usr/include/net/if.h starting around line 100. Excerpt: #define IFF_UP 0x0000000001 /* interface is up */ #define IFF_BROADCAST 0x0000000002 /* broadcast address valid */ #define IFF_DEBUG 0x0000000004 /* turn on debugging */ #define IFF_LOOPBACK 0x0000000008 /* is a loopback net */ The codes are listed and (briefly) explained in /usr/include/net/if.h starting around line 100. Excerpt: #define IFF_UP 0x0000000001 /* interface is up */ #define IFF_BROADCAST 0x0000000002 /* broadcast address valid */ #define IFF_DEBUG 0x0000000004 /* turn on debugging */ #define IFF_LOOPBACK 0x0000000008 /* is a loopback net */ ~~~~~~~~~~~~~~~ fromDonald H Locker toNevin dateSat, Aug 14, 2010 at 7:14 AM subjectRe: Interface Flags Numeric codes mailed-bycomcast.nefromDonald H Locker toNevin dateSat, Aug 14, 2010 at 7:14 AM subjectRe: Interface Flags Numeric codes mailed-bycomcast.ne I like puzzles. In all, there are seven unique bits set here: (bitwise OR of all network codes = 0x300084B = 0000 0011 0000 0000 0000 1000 0100 1011) Everyone has MULTICAST and everyone is RUNNING, and everyone have the 0x0000840 bits so each one of these bits must represent one of those states; no way to know from this evidence (and I'm not about to look at the documentation "We don't need no steenkin' documentation!") Of the remaining five bits, * 2000849 and 2000841 have IPV6 and high order 2 in common that no one else have; leading 2 is IPV6 (0x02000000 = IPV6) * first four listings are UP and lsNybble is odd (leading 2 and the 840 don't count anymore) so least significant 1 is UP (0x00000001 = UP) * 2000849 and 1000849 have least significant 8 and LOOPBACK in common that no one else has; least significant 8 is LOOPBACK (0x00000008) * 1000843 and 1000842 have least significant 2 and BROADCAST in common that no one else has; least significant 2 is BROADCAST (0x00000002) * 1000843, 1000849, 1000842 have IPV1 and high order 1 in common that no one else have; leading 1 is IPV4 (0x01000000) To verify, I searched for the definition of BROADCAST in my filesystem ~ $ (cd /; for m in `find . -fstype ufs -name '*.h' -print 2>/dev/null`; do grep BROADCAST $m /dev/null; done) turned up a bunch of #define ... IFF_BROADCAST, so I looked for a #define IFF_BROADCAST, then dug up /usr/include/net/if.h /* * NOTE : These flags are not directly used within IP. * ip_if.h has definitions derived from this which is used within IP. * If you define a flag here, you need to define one in ip_if.h before * using the new flag in IP. Don't use these flags directly in IP. */ #define IFF_UP 0x0000000001 /* interface is up */ #define IFF_BROADCAST 0x0000000002 /* broadcast address valid */ #define IFF_DEBUG 0x0000000004 /* turn on debugging */ #define IFF_LOOPBACK 0x0000000008 /* is a loopback net */ #define IFF_POINTOPOINT 0x0000000010 /* interface is point-to-point link */ #define IFF_NOTRAILERS 0x0000000020 /* avoid use of trailers */ #define IFF_RUNNING 0x0000000040 /* resources allocated */ #define IFF_NOARP 0x0000000080 /* no address resolution protocol */ #define IFF_PROMISC 0x0000000100 /* receive all packets */ #define IFF_ALLMULTI 0x0000000200 /* receive all multicast packets */ #define IFF_INTELLIGENT 0x0000000400 /* protocol code on board */ #define IFF_MULTICAST 0x0000000800 /* supports multicast */ #define IFF_MULTI_BCAST 0x0000001000 /* multicast using broadcast address */ #define IFF_UNNUMBERED 0x0000002000 /* non-unique address */ #define IFF_DHCPRUNNING 0x0000004000 /* DHCP controls this interface */ #define IFF_PRIVATE 0x0000008000 /* do not advertise */ /* * The following flags can't be grabbed or altered by SIOC[GS]IFFLAGS. * Should use SIOC[GS]LIFFLAGS which has a larger flags field. */ #define IFF_NOXMIT 0x0000010000 /* Do not transmit packets */ #define IFF_NOLOCAL 0x0000020000 /* No address - just on-link subnet */ #define IFF_DEPRECATED 0x0000040000 /* interface address deprecated */ #define IFF_ADDRCONF 0x0000080000 /* address from stateless addrconf */ #define IFF_ROUTER 0x0000100000 /* router on this interface */ #define IFF_NONUD 0x0000200000 /* No NUD on this interface */ #define IFF_ANYCAST 0x0000400000 /* Anycast address */ #define IFF_NORTEXCH 0x0000800000 /* Do not exchange routing info */ #define IFF_IPV4 0x0001000000 /* IPv4 interface */ #define IFF_IPV6 0x0002000000 /* IPv6 interface */ #define IFF_MIPRUNNING 0x0004000000 /* Mobile IP controls this interface */ #define IFF_NOFAILOVER 0x0008000000 /* Don't failover on NIC failure */ #define IFF_FAILED 0x0010000000 /* NIC has failed */ #define IFF_STANDBY 0x0020000000 /* Standby NIC to be used on failures */ #define IFF_INACTIVE 0x0040000000 /* NIC active or not ? */ /* Used for Standby NIC or */ /* when FAILBACK is disabled by user */ #define IFF_OFFLINE 0x0080000000 /* NIC has been offlined */ /* * The IFF_XRESOLV flag is an evolving interface and is subject * to change without notice. */ #define IFF_XRESOLV 0x0100000000 /* IPv6 external resolver */ #define IFF_COS_ENABLED 0x0200000000 /* If interface supports CoS marking */ #define IFF_PREFERRED 0x0400000000 /* Prefer as source address */ #define IFF_TEMPORARY 0x0800000000 /* RFC3041 */ #define IFF_FIXEDMTU 0x1000000000 /* MTU manually set with SIOCSLIFMTU */ #define IFF_VIRTUAL 0x2000000000 /* Does not send or receive packets */ #define IFF_DUPLICATE 0x4000000000 /* Local address already in use */ _______________________________________________ sunmanagers mailing list sunmanagers at sunmanagers.org http://www.sunmanagers.org/mailman/listinfo/sunmanagers From J.Xu at uws.edu.au Wed Aug 25 19:29:13 2010 From: J.Xu at uws.edu.au (Julie Xu) Date: Thu, 26 Aug 2010 09:29:13 +1000 Subject: summary: reboot problem after restore from backup and Solaris 9 device probelm after recovring from Logato Networkers In-Reply-To: <72A9ED8ED2341646BD2BC4D37162646A03D61A8551@VIOLA.AD.UWS.EDU.AU> References: <72A9ED8ED2341646BD2BC4D37162646A03D61A8551@VIOLA.AD.UWS.EDU.AU> Message-ID: <6E0883BE41FF5E4E92E4D57D66AB0F84042E1ECC@VIOLA.AD.UWS.EDU.AU> Just a summury for above questions. Thanks Joon Kim helped me went though the problem and fixed it. Also thanks all the replies I have got at the time. Your helps are important for me. Thanks very much. Just list what I did in case someone may go into same situation: 1. install system 2. recovery from backup server 3. run devfsadm -C 4. change /etc/vfstab for new disk setting 5. remove /etc/path_to_inst 6. reboot with -as julie > -----Original Message----- > From: Julie Xu > Sent: Friday, 13 August 2010 5:04 PM > To: sunmanagers at sunmanagers.org > Subject: reboot problem after restore from backup > > Greeting > > > > I have a sun fire v100 server has motherboard problem, and replaced. After > the hardware thing fixed, I have installed original solaris 9 system, > legato networker and restored the rest system from the lasted full backup > point. > > The result is: > > 39571:recover: ./nsr/run/.nsr: file exists, overwriting ./nsr/run/ ./nsr/ > Received 69143 matching file(s) from NSR server `lamarr' > > Recover completion time: Fri 13 Aug 2010 01:04:55 PM EST > > 67848:recover: Failed to recover save set(s): Failed to rebind to NSR > server: 71 > > 759 12 %s: %s - %s > > 3 24 47 RPC cannot make a procedure call: Create failed 11 23 352:Remote > system error 11 13 Timer expired > > > > After that, I have reboot system, and find the system can not be reboot. > And it is failed. I found also the dev is in different name. > > > > ok boot disk3 > > Boot device: /pci at 1f,0/ide at d/disk at 3,0 File and args: > > SunOS Release 5.9 Version Generic_122300-21 64-bit > > Copyright 1983-2003 Sun Microsystems, Inc. All rights reserved. > > Use is subject to license terms. > > configuring IPv4 interfaces: dmfe0. > > Hostname: xxxx > > /dev/dsk/c0t2d0s1: No such device or address > > The / file system (/dev/rdsk/c0t2d0s0) is being checked. > > Can't open /dev/rdsk/c0t2d0s0: No such device or address > > /dev/rdsk/c0t2d0s0: CAN'T CHECK FILE SYSTEM. > > /dev/rdsk/c0t2d0s0: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY. > > > > WARNING - Unable to repair the / filesystem. Run fsck > > manually (fsck -F ufs /dev/rdsk/c0t2d0s0). Exit the shell when > > done to continue the boot process. > > > > > > Type control-d to proceed with normal startup, > > (or give root password for system maintenance): NOTICE: dmfe1: PHY 1 link > down > > > > single-user privilege assigned to /dev/console. > > Entering System Maintenance Mode > > > > Aug 13 16:53:50 su: 'su root' succeeded for root on /dev/console > > Sun Microsystems Inc. SunOS 5.9 Generic May 2002 > > # > > # cat /etc/vfstab > > > > #device device mount FS fsck mount > mount > > > > #to mount to fsck point type pass at boot > options > > > > # > > > > fd - /dev/fd fd - no - > > > > /proc - /proc proc - no - > > > > /dev/dsk/c0t2d0s1 - - swap - no - > > > > /dev/dsk/c0t2d0s0 /dev/rdsk/c0t2d0s0 / ufs 1 no > logging > > > > swap - /tmp tmpfs - yes - > > > > #ls -l /dev/dsk/c0t2d0s0 > > lrwxrwxrwx 1 root root 38 Aug 13 12:52 c0t2d0s1 - > > ../../devices/pci at 1f,0/ide at d/dad at 2,0:b > > > > # df -k > > > > Filesystem kbytes used avail capacity Mounted on > > > > /pci at 1f,0/ide at d/disk at 3,0:a > > > > 75909177 2206602 72943484 3% / > > > > /proc 0 0 0 0% /proc > > > > mnttab 0 0 0 0% /etc/mnttab > > > > # > > > > > > in vfstab file (it is restored, so it should be the old one), root is > pci at 1f,0/ide at d/dad at 2,0:b and current system restore is on > /pci at 1f,0/ide at d/disk at 3,0:a. > > > > Could anyone advice me, what I can do to recover this problem? Can I > rename the dev? If so, how to? > > > > Any comments will be appreciated > > > > Thanks in advance > > > > > > Julie Xu > > Network Engineer > > Communication and Networking > > Information Technology Services > > University of Western Sydney > > > > Office phone: 46203098 > > Mobile: 0416179868 > > Email: j.xu at uws.edu.au _______________________________________________ sunmanagers mailing list sunmanagers at sunmanagers.org http://www.sunmanagers.org/mailman/listinfo/sunmanagers From Syed.Hosain at aeris.net Thu Aug 26 21:10:14 2010 From: Syed.Hosain at aeris.net (Syed Zaeem Hosain (Syed.Hosain@aeris.net)) Date: Thu, 26 Aug 2010 18:10:14 -0700 Subject: SUMMARY: I have a Solaris 10 DVD, but need to install on a machine that only has a CD-ROM References: Message-ID: Hi, all. Original problem is described below: RESPONSES: The suggestions ranged from: 1. Use JumpStart (from the JumpStart Enterprise Toolkit - JET - from Sun). Could not do. Looks like Oracle has removed this download from their site after the Sun acquisition! Argh. 2. Use the network install procedures (similar to JumpStart in the JET above really) as discussed in the Solaris install guides. I was working on doing this (got the Install Server going, etc.), and it looked like it would work from what I could tell - but I found a simpler solution (see below). 3. Create an ISO image from the DVD, transfer the file to the system, use lofiadm to mount the ISO image from the DVD and go from there. Unfortunately, could not do that - the system could not boot from the primary disk at all (would not bring up Solaris - even in Admin mode). I pretty much needed to do a clean full install, since the was drive was so hosed. 4. Find a DVD-ROM drive. This turned out to be the simplest solution. While I was working on suggestion 2 above (which I do believe would have worked), our IT guy found me a DVD drive from a PC and I was able to put this into the system (temporarily) in place of the CDROM and the install is running fine from it. Thanks all for the responses! Z P.S. A few people also said to avoid building a set of CD's ... too complex to figure out how and when to break the files and directories to find them. I have to agree - after I mounted the disk on a PC and looked at it, this process would have been a bit tortuous. -----Original Message----- From: Syed Zaeem Hosain (Syed.Hosain at aeris.net) Sent: Thursday, August 26, 2010 10:19 AM To: sunmanagers at sunmanagers.org Subject: I have a Solaris 10 DVD, but need to install on a machine that only has a CD-ROM As the subject says, I have a DVD of the Solaris 10 install disk, but need to do an installation on an old SunBlade system that, of all things, only has a CDROM drive on it! (argh!) I have access to other systems (a PC) with DVD/CD writers and could create a set of CD's ... if I knew what to do exactly! So, my question: is there a way to write a set of CD's from that DVD that would be (a) bootable and (b) allow a Solaris 10 installation? How would I go about doing this? In theory, I could do a "boot net" from the okay prompt too, but I am not sure what I need to set up on another Sun system on that network ... since I have never installed Solaris from a network before. (I looked at the Oracle/Sun site and did not see any CDROM ISO downloads, by the way). Thanks in advance! Z _______________________________________________ sunmanagers mailing list sunmanagers at sunmanagers.org http://www.sunmanagers.org/mailman/listinfo/sunmanagers From aaldrich at ihouseweb.com Fri Aug 27 10:25:07 2010 From: aaldrich at ihouseweb.com (Alan Aldrich) Date: Fri, 27 Aug 2010 07:25:07 -0700 Subject: [Summary] xntpd killing dovecot Message-ID: Got some good responses but the key one was with regard to vmware which pointed me to the fact that my esx hosts were not synced properly so the solaris vm in question had to keep setting the real time back from the hardware clock on the esx host thus killing dovecot. It was really as simple as setting all of the esx hosts to a proper ntp server and having the same time as the virtual solaris host so that small time adjustments would not kill dovecot. Thanks to everyone for their responses. particularly A Darren Dunham _______________________________________________ sunmanagers mailing list sunmanagers at sunmanagers.org http://www.sunmanagers.org/mailman/listinfo/sunmanagers