All FYI, According to message 5 there is a new dependency on SUNWisntalladm-tools pkg and it appears that this pkg "SUNWauto-install-common" is currently not in the IPS repository as of yet.
We will continue to test the older bits but cannot update to latest due to pkg dependency checks in our test code until this pkg has been added to IPS. -Rich caiman-discuss-request at opensolaris.org wrote: > Send caiman-discuss mailing list submissions to > caiman-discuss at opensolaris.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://mail.opensolaris.org/mailman/listinfo/caiman-discuss > or, via email, send a message with subject or body 'help' to > caiman-discuss-request at opensolaris.org > > You can reach the person managing the list at > caiman-discuss-owner at opensolaris.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of caiman-discuss digest..." > > > Today's Topics: > > 1. Re: AI - tftp access violation (mary ding) > 2. Re: code review for bugs (Sanjay Nadkarni) > 3. Which sun4u systems should be able to use AI? (Andre Molyneux) > 4. Re: Which sun4u systems should be able to use AI? (mary ding) > 5. FLAG DAY: SUNWauto-install-common required for AI clients and > servers (Clay Baenziger) > 6. Re: FLAG DAY: SUNWauto-install-common required for AI clients > and servers (Clay Baenziger) > 7. Re: code review for bugs (Dina) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 11 Mar 2009 17:11:24 -0700 > From: mary ding <mary.ding at Sun.COM> > To: Jan Hlodan <Jan.Hlodan at Sun.COM> > Cc: caiman-discuss at opensolaris.org > Subject: Re: [caiman-discuss] AI - tftp access violation > Message-ID: <49B8532C.6020005 at Sun.COM> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Jan: > > For SUN internal users,you can find BIOS and OBP updates from here: > > http://sunsolve.central.sun.com/handbook_internal/ > > For the W1100Z, there will be link to FLASH PROMPT and instructions on > how to download the supplement CD iso and update the BIOS from that. > > > External is available here: > > http://sunsolve.sun.com/handbook_pub/ > > Jan Hlodan wrote: > >> Hi Sundar, >> >> Thanks for the answer. >> I am sure tftp is working correctly. I can easy install machines. >> Anyway, here is the output: >> >> On the AI server machine (lepra.czech) >> >> lepra# tftp >> tftp> connect 10.16.22.13 >> tftp> get menu.lst.x86_global_108 >> Received 311 bytes in 0.1 seconds >> tftp> >> >> >> On erebos.czech: >> >> -bash-3.2$ tftp >> tftp> connect 10.16.22.13 >> tftp> get menu.lst.x86_global_108 >> Received 311 bytes in 5.0 seconds >> tftp> >> >> I'll try to find the latest BIOS version for this machine and upgrade it. >> >> Regards, >> >> Jan Hlodan >> >> >> Sundar Yamunachari wrote: >> >>> Jan: >>> You are getting DHCP response and it is trying to get the boot >>> program (Defined by BootFile in DHCP macro). Can you check whether >>> tftp is working on your install server? Please do the following on the >>> install server. >>> >>> # tftp >>> tftp> connect 10.16.22.13 >>> tftp> get menu.lst.x86_global_108 >>> >>> If you see it not successful, the your tftp setup has issues. >>> >>> - Sundar >>> >>> >>> Jan Hlodan wrote: >>> >>>> Hello Mary, >>>> >>>> thanks for your interest! >>>> I'll check the BIOS and network driver tomorrow. >>>> >>>> Regards, >>>> >>>> Jan Hlodan >>>> >>>> mary ding wrote: >>>> >>>>> Jan: >>>>> >>>>> I did not have any problem with installing AI on the W2100Z. Can >>>>> you check whether the BIOS is the latest updated one. >>>>> >>>>> However, I did see this error on a dell450 and mpc375 machine. I >>>>> need to talk to boot team since this might be grub related. Stay tuned. >>>>> >>>>> >>>>> >>>>> mary ding wrote: >>>>> >>>>>> Jan: >>>>>> >>>>>> Let me go and check this out on our W1100Z. BTW, is the W1100Z >>>>>> BIOS up to date ???? >>>>>> >>>>>> >>>>>> >>>>>> Jan Hlodan wrote: >>>>>> >>>>>>> output: >>>>>>> >>>>>>> DHCP MAC ADDR: 00 04 76 8E B8 4C >>>>>>> CLIENT IP: 10.16.22.205 >>>>>>> MASK: 255.255.255.0 >>>>>>> DHCP IP: 10.16.22.13 >>>>>>> GATEWAY IP: 10.16.22.1 >>>>>>> TFTP. >>>>>>> PXE-TO2: Access violation >>>>>>> TFTP. >>>>>>> PXE-TO2: Access violation >>>>>>> PXE-TO2: TFTP Error - Access violation >>>>>>> Network boot aborted. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Macro: >>>>>>> >>>>>>> sudo pntadm -P 10.16.22.0 | grep 10.16.22.205 >>>>>>> 010004768EB84C 01 10.16.22.205 10.16.22.10 >>>>>>> Forever 010004768EB84C jihlava >>>>>>> >>>>>>> sudo dhtadm -P | grep 010004768EB84C >>>>>>> 010004768EB84C Macro >>>>>>> :Subnet=255.255.255.0:Router=10.16.22.1:Broadcst=10.16.22.255:BootSrvA=10.16.22.13:BootFile=x86_global_108:GrubMenu=menu.lst.x86_global_108:Timeserv=10.16.22.13:LeaseTim=86400:LeaseNeg:DNSdmain=czech.sun.com:DNSserv=10.16.22.11:UTCoffst=3600: >>>>>>> >>>>>>> >>>>>>> >>>>>>> Any ideas? >>>>>>> >>>>>>> Thank you. >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Jan Hlodan >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 03/10/09 20:07, Jan Hlodan wrote: >>>>>>> >>>>>>>> Hello, >>>>>>>> >>>>>>>> It seems that the problem is with validating within the TFTP >>>>>>>> protocol >>>>>>>> when machine boots from net (via PXE protocol) and tries to get >>>>>>>> macro >>>>>>>> from DHCP server. >>>>>>>> >>>>>>>> It's just typical for Sun W1100z machine. All other x86 machines >>>>>>>> in our >>>>>>>> lab (more than 10) can validate TFTP and get macro. >>>>>>>> The macro is correct for 100%. >>>>>>>> >>>>>>>> Did anybody successfully install Sun W1100z? >>>>>>>> >>>>>>>> Thank you. >>>>>>>> >>>>>>>> >>>>>>>> Regards, >>>>>>>> >>>>>>>> Jan Hlodan >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> caiman-discuss mailing list >>>>>>>> caiman-discuss at opensolaris.org >>>>>>>> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss >>>>>>>> >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> caiman-discuss mailing list >>>>>>> caiman-discuss at opensolaris.org >>>>>>> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss >>>>>>> >>>>>> _______________________________________________ >>>>>> caiman-discuss mailing list >>>>>> caiman-discuss at opensolaris.org >>>>>> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss >>>>>> >>>> _______________________________________________ >>>> caiman-discuss mailing list >>>> caiman-discuss at opensolaris.org >>>> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss >>>> > > > > ------------------------------ > > Message: 2 > Date: Wed, 11 Mar 2009 18:15:17 -0600 > From: Sanjay Nadkarni <Sanjay.Nadkarni at Sun.COM> > To: Dina <dina.nimeh at Sun.COM> > Cc: caiman-discuss <caiman-discuss at opensolaris.org>, Moinak Ghosh > <moinakg at belenix.org>, Juergen Keil <jrgn.keil at googlemail.com> > Subject: Re: [caiman-discuss] code review for bugs > Message-ID: <49B85415.5050601 at sun.com> > Content-Type: text/plain; format=flowed; charset=ISO-8859-1 > > On 03/11/09 14:44, Dina wrote: > >> Juergen Keil wrote: >> >>> 2009/3/11 Dina <dina.nimeh at sun.com>: >>> >> ... >> >>>> Now you turn it back on by setting the value back to 1. The segment >>>> that is already cached is still sitting there. What happens to it? >>>> >>> It will be reused, in case the next lofi read will result in a cache >>> hit. >>> >>> Since compressed lofi only works in read/only mode, the cached >>> uncompressed data is still valid. >>> >>> >> Ah, it's read-only, ok. >> >> >>> # lofiadm -a `pwd`/solaris.zlib /dev/lofi/5 >>> # dd if=/dev/zero of=/dev/rlofi/5 count=2 >>> write: Read-only file system >>> 1+0 records in >>> 1+0 records out >>> >>> >>> Hmm, but why does the following work using the lofi block device? >>> Seems to be another bug... I'd expect that this get s a EROFS error, >>> too. >>> >>> # dd if=/dev/zero of=/dev/lofi/5 count=2 >>> 2+0 records in >>> 2+0 records out >>> >>> >> I don't know if this is related to an existing bug: >> 6717722 lofi must not write to R/O file systems >> >> >>>> It releases the memory at unmap time, is unmapping the file a >>>> guaranteed >>>> event at this point? If not, then does this lead to a stale segment in >>>> the cache? >>>> >>> No, patching / changing the lofi_max_comp_cache variable doesn't >>> result in unmapping the file (that is calling lofi_free_handle(()). >>> You would have to use lofiadm -d and close all references to the >>> /dev/lofi/N file to get the cache memory released. >>> >>> >> Did not mean that changing lofi_max_comp_cache unmaps the file, I know >> that. Rephrasing: "Lofi releases the memory at unmap time, ok, however >> what guarantees that an unmap happens between the time the caching is >> disabled and the time the caching is re-enabled?" >> >> It seems the answer is related to the compressed lofi being read-only. >> Inconsistency is not an issue, is that correct? >> >> >>> Hmm, you could construct a case with attaching a compressed lofi file, >>> and write to the underlying vnode. >>> >>> >>>>> Do we really need code to shrink the lofi decompress cache at runtime? >>>>> >>>> I think I understand that 1 cached segment gives a nice boost. And >>>> that >>>> the improvement is probably not linear. At some point it doesn't matter >>>> if you have 5 or 10 for your max cache size, the incremental >>>> performance >>>> improvement may no longer be noticeable. >>>> >>>> That's why I asked what would happen if I set it 10240. Would it >>>> really >>>> grow to 10240, or would it cut me off somewhere and not grow >>>> anymore, to >>>> prevent running out of heap? >>>> >>> It would grow to 10240 cached segments. >>> >> Is there any value to put a hard limit on how big lofi_max_comp_cache >> can ever be? >> > Juergen: I believe what Dina is asking for is to limit the size of the > cache to prevent tunable from sucking up all the heap. > > -Sanjay > > >> D. >> > > > > ------------------------------ > > Message: 3 > Date: Wed, 11 Mar 2009 20:02:28 -0600 > From: Andre Molyneux <Andre.Molyneux at Sun.COM> > To: caiman-discuss at opensolaris.org > Subject: [caiman-discuss] Which sun4u systems should be able to use > AI? > Message-ID: <49B86D34.2080009 at sun.com> > Content-Type: text/plain; format=flowed; charset=ISO-8859-1 > > I understand that only certain sun4u systems are capable of > using the WAN-boot that's necessary in order to boot off of > an AI server. Is this correct, and if so does this mean > that we need to lay hands on specific machine types (e.g. > Ultra 45) or are there workarounds than can be used with > sun4u machines in general? > > Andre > > > ------------------------------ > > Message: 4 > Date: Wed, 11 Mar 2009 19:16:31 -0700 > From: mary ding <mary.ding at Sun.COM> > To: Andre Molyneux <Andre.Molyneux at Sun.COM> > Cc: caiman-discuss at opensolaris.org > Subject: Re: [caiman-discuss] Which sun4u systems should be able to > use AI? > Message-ID: <49B8707F.1040702 at Sun.COM> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Andre: > > Currently we only support sun4u systems that are capable of using > wanboot with network-boot-arguments arguments. YOu can find out by > running eeprom. This is supported on all sun4v. For sun4u, I know they > are supported on ultra45, sb2500, sb100, sb150, v215, v245, v480, v240 > ... etc. As long as the OBP is 4.17.1 or higher, they will work. > > For other sun4u systems that is not capable of doing wanboot from > network, there are bugs in wanboot itself. After the wanboot bugs are > fixed, we will need to try to see whether it is possible to get those > other sun4u machine to work with AI. This will not be ready for 2009.1H. > > 6797441 - wanboot fails to configure network device when booted from media > 6805094 - wanboot install from snv and s10u6/s10u7_04 fails after > loading miniroot. > > I will suggest that you add yourself to the bug interest lists. There > will be bug fixes available later and then we can try to come up with > some workaround to see whether they will work. > > Andre Molyneux wrote: > >> I understand that only certain sun4u systems are capable of >> using the WAN-boot that's necessary in order to boot off of >> an AI server. Is this correct, and if so does this mean >> that we need to lay hands on specific machine types (e.g. >> Ultra 45) or are there workarounds than can be used with >> sun4u machines in general? >> >> Andre >> _______________________________________________ >> caiman-discuss mailing list >> caiman-discuss at opensolaris.org >> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss >> > > > > ------------------------------ > > Message: 5 > Date: Wed, 11 Mar 2009 21:33:34 -0600 (MDT) > From: Clay Baenziger <clayb at sun.com> > To: caiman-discuss at opensolaris.org > Subject: [caiman-discuss] FLAG DAY: SUNWauto-install-common required > for AI clients and servers > Message-ID: <Pine.SOC.4.64.0903112113440.5170 at xsplat> > Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII > > Hi all, > For those of you building AI images based on the latest > slim_source or updating your AI servers with the latest > SUNWinstalladm-tools, you will hit an issue due to bug ID 7305. Everyone > else can ignore this. > > The impact of not having SUNWauto-install-common installed is > breaking installadm(1) for an AI server, or breaking the AI install > process for an AI client. The signature for a broken AI client is the AI > service failing and in the SMF log a Python ImportError: > ImportError: No module named auto_install.ai_get_manifest > > The work around for an AI server, is to ensure > SUNWauto-install-common is installed when using any SUNWinstalladm-tools > made after 03/09 19:05 MT or changeset 467. > > The work around for generating an AI image, is to ensure > SUNWauto-install-common is installed on the image. This can be done with a > finalizer script in the DC manifest which installs the SysV version of > SUNWauto-install-common. > > Steps: > > Download the finalizer script from: > > http://opensolaris.org/os/project/frosug/meetings/frosug-090226-SysVFinalizer.sh > > Create the finalizer's config file: > echo 'PKG_PATH=<absolute path to slim_source>/packages/i386/nightly-nd/\ > SUNWauto-install-common' > /tmp/pkgs_to_add > > Add this block into your DC manifest as the first finalizer script > (right below the <finalizer> XML section): > <script name="<absolute path to pkg_finalizer.ksh script>"> > <checkpoint > name="sysV_pkg_add" > message="Add sysV packages"/> > </script> > > Thank you, > Clay > > > ------------------------------ > > Message: 6 > Date: Wed, 11 Mar 2009 21:35:18 -0600 (MDT) > From: Clay Baenziger <clayb at sun.com> > To: caiman-discuss at opensolaris.org > Subject: Re: [caiman-discuss] FLAG DAY: SUNWauto-install-common > required for AI clients and servers > Message-ID: <Pine.SOC.4.64.0903112134450.5170 at xsplat> > Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII > > My apologies, the bug ID tracking this issue is 7266, not 7305. > Thank you, > Clay > > On Wed, 11 Mar 2009, Clay Baenziger wrote: > > >> Hi all, >> For those of you building AI images based on the latest slim_source >> or updating your AI servers with the latest SUNWinstalladm-tools, you will >> hit an issue due to bug ID 7305. Everyone else can ignore this. >> >> The impact of not having SUNWauto-install-common installed is >> breaking installadm(1) for an AI server, or breaking the AI install process >> for an AI client. The signature for a broken AI client is the AI service >> failing and in the SMF log a Python ImportError: >> ImportError: No module named auto_install.ai_get_manifest >> >> The work around for an AI server, is to ensure >> SUNWauto-install-common is installed when using any SUNWinstalladm-tools >> made >> after 03/09 19:05 MT or changeset 467. >> >> The work around for generating an AI image, is to ensure >> SUNWauto-install-common is installed on the image. This can be done with a >> finalizer script in the DC manifest which installs the SysV version of >> SUNWauto-install-common. >> >> Steps: >> >> Download the finalizer script from: >> >> http://opensolaris.org/os/project/frosug/meetings/frosug-090226-SysVFinalizer.sh >> >> Create the finalizer's config file: >> echo 'PKG_PATH=<absolute path to >> slim_source>/packages/i386/nightly-nd/\ >> SUNWauto-install-common' > /tmp/pkgs_to_add >> >> Add this block into your DC manifest as the first finalizer script >> (right below the <finalizer> XML section): >> <script name="<absolute path to pkg_finalizer.ksh script>"> >> <checkpoint >> name="sysV_pkg_add" >> message="Add sysV packages"/> >> </script> >> >> Thank you, >> Clay >> >> > > > ------------------------------ > > Message: 7 > Date: Wed, 11 Mar 2009 13:44:57 -0700 > From: Dina <dina.nimeh at sun.com> > To: Juergen Keil <jrgn.keil at googlemail.com> > Cc: caiman-discuss <caiman-discuss at opensolaris.org>, Moinak Ghosh > <moinakg at belenix.org> > Subject: Re: [caiman-discuss] code review for bugs > Message-ID: <49B822C9.9080900 at sun.com> > Content-Type: text/plain; format=flowed; charset=ISO-8859-1 > > > > Juergen Keil wrote: > >> 2009/3/11 Dina <dina.nimeh at sun.com>: >> > ... > >>> Now you turn it back on by setting the value back to 1. The segment >>> that is already cached is still sitting there. What happens to it? >>> >> It will be reused, in case the next lofi read will result in a cache hit. >> >> Since compressed lofi only works in read/only mode, the cached >> uncompressed data is still valid. >> >> > > Ah, it's read-only, ok. > > >> # lofiadm -a `pwd`/solaris.zlib /dev/lofi/5 >> # dd if=/dev/zero of=/dev/rlofi/5 count=2 >> write: Read-only file system >> 1+0 records in >> 1+0 records out >> >> >> Hmm, but why does the following work using the lofi block device? >> Seems to be another bug... I'd expect that this get s a EROFS error, too. >> >> # dd if=/dev/zero of=/dev/lofi/5 count=2 >> 2+0 records in >> 2+0 records out >> >> > > I don't know if this is related to an existing bug: > 6717722 lofi must not write to R/O file systems > > >>> It releases the memory at unmap time, is unmapping the file a guaranteed >>> event at this point? If not, then does this lead to a stale segment in >>> the cache? >>> >> No, patching / changing the lofi_max_comp_cache variable doesn't >> result in unmapping the file (that is calling lofi_free_handle(()). >> You would have to use lofiadm -d and close all references to the >> /dev/lofi/N file to get the cache memory released. >> >> > > Did not mean that changing lofi_max_comp_cache unmaps the file, I know > that. Rephrasing: "Lofi releases the memory at unmap time, ok, however > what guarantees that an unmap happens between the time the caching is > disabled and the time the caching is re-enabled?" > > It seems the answer is related to the compressed lofi being read-only. > Inconsistency is not an issue, is that correct? > > >> Hmm, you could construct a case with attaching a compressed lofi file, >> and write to the underlying vnode. >> >> >>>> Do we really need code to shrink the lofi decompress cache at runtime? >>>> >>> I think I understand that 1 cached segment gives a nice boost. And that >>> the improvement is probably not linear. At some point it doesn't matter >>> if you have 5 or 10 for your max cache size, the incremental performance >>> improvement may no longer be noticeable. >>> >>> That's why I asked what would happen if I set it 10240. Would it really >>> grow to 10240, or would it cut me off somewhere and not grow anymore, to >>> prevent running out of heap? >>> >> It would grow to 10240 cached segments. >> > > Is there any value to put a hard limit on how big lofi_max_comp_cache > can ever be? > > D. > > > ------------------------------ > > _______________________________________________ > caiman-discuss mailing list > caiman-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/caiman-discuss > > > End of caiman-discuss Digest, Vol 26, Issue 69 > ********************************************** >
