Hi Rich,
On 03/12/09 18:44, Rich Reinhard wrote: > 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. I assume that you are referring to either pkg.opensolaris.org/dev or ipkg.sfbay/dev IPS repo ? I think (I will let Clay correct me if I am wrong) that those changes are synchronized and will become available in IPS repo in build 110. That means that SUNWinstalladm-tools in build 109 don't require SUNWauto-install-common. Or have you already hit some problem in that area ? Cheers, Jan > > 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 >> ********************************************** >> > > _______________________________________________ > caiman-discuss mailing list > caiman-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
