Jan and Ethan: line1-hpdc5750 and line1-dellp350 hangs and install cannot continue. So we need swap for 768 MB and 1024 MB.
I will try to setup VB and get some data between 1.1 GB to 1.5 GB. mary ding wrote: > Jan and Ethan: > > These are the AI install results with 109 after deleting swap: > > line1-hpdc5750 - 768 MB - IPS download still in progress > line1-hpdx2300 - 896 MB - Isntall is sucessful and there is no > corruption of solaris.zlib > line1-hpdc5700 - 1016 MB - Install is successful and there is no > corruption of solaris.zlib > line1-acer6900 - 999 MB - Install is successful and there is no > corruption of solaris.zlib > line1-hpdc7600 - 1016 MB - Install is successful and there is no > corruption of solaris.zlib > line1-dellp350 - 1024 MB - IPS download still in progress > > > The line1-dellp350 had: > > The physical processor has 2 virtual processors (0 1) > x86 (GenuineIntel F27 family 15 model 2 step 7 clock 3050 MHz) > Intel(r) Pentium(r) 4 CPU 3.06GHz > > The line1-hpdc5750 had: > > The physical processor has 2 virtual processors (0 1) > x86 (AuthenticAMD 40FB2 family 15 model 75 step 2 clock 2000 MHz) > AMD Athlon(tm) 64 X2 Dual Core Processor 3800+ > > > > > jan damborsky wrote: >> Hi Mary, >> >> >> On 03/25/09 19:30, mary ding wrote: >>> Jan: >>> >>> I am doing AI Install on the following x86 machines now with b109: >>> >>> 768 MB, 896 MB, 999 MB, 1016 MB and 1024 MB >> >> I am curios about the results - based on my observations >> done when I tested fix for 4166 (around build 107) I assume >> that first two would fail. >> We will see how things changed :-) >> >> Thanks for trying this ! >> Jan >> >>> >>> I delete the zfs swap and now it is downloading IPS packages from the >>> repo. If I leave the zfs swap around, then corruption will occur. I >>> did the checksum after install to verify they are the same as the >>> solaris.zlib on the server to find out whether I run into 6804. >>> >>> >>> >>> >>> >>> jan damborsky wrote: >>>> Hi Mary, >>>> >>>> >>>> On 03/25/09 18:38, mary ding wrote: >>>>> Ethan and William: >>>>> >>>>> I agree with Ethan about this. We shouldn't require user to do >>>>> anything manual or customize manifest to workaround this ugly zfs bug. >>>>> >>>>> So far, this is what I found out for sparc and x86. I hit this bug >>>>> everytime when my system had more than 700 MB for sparc and x86. >>>>> With 512 MB, the install works but it is very slow. >>>>> >>>>> With system that had 1 GB of memory, if I delete zfs swap, IPS >>>>> install will fail and run out of memory. >>>> >>>> Do you happen to know if the behavior is the same >>>> for sparc & x86 systems with 1GB of memory ? >>>> >>>> I am asking, since after fix for 4166 bug was integrated, >>>> AI is supposed to work on x86 systems with 1GB of memory >>>> without swap device. If it fails for you, might I please >>>> take a look at x86 machine in question ? >>>> >>>> Thank you, >>>> Jan >>>> >>>>> >>>>> If I do this on system with 2 GB of memory and delete zfs swap, the >>>>> install works. >>>>> >>>>> If you need any help testing the workaround, I will be happy to try >>>>> them out since I had machines available for testing purpose. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Ethan Quach wrote: >>>>>> >>>>>> >>>>>> William Schumann wrote: >>>>>>> RE: Bugzilla bug 6084 AI fails due to solaris.zlib becoming >>>>>>> corrupt during install >>>>>>> http://defect.opensolaris.org/bz/show_bug.cgi?id=6804 >>>>>>> >>>>>>> 6817316 data corruption seen with swapping to a zvol >>>>>>> http://monaco.sfbay/detail.jsf?cr=6817316 >>>>>>> >>>>>>> The problem occurs when a ZFS volume is used for swap in the >>>>>>> Automated Installer. There is an alternative swap solution - to >>>>>>> use a slice for swap instead of a ZFS volume. >>>>>>> >>>>>>> Currently, AI follows the logic of creating swap on a ZFS volume >>>>>>> if there is enough space. If not, the target partition (x86) or >>>>>>> disk (SPARC) slice 1 will be used for swap if there is enough space. >>>>>>> >>>>>>> What I propose here to add a feature: a new AI manifest element >>>>>>> <target_device_swap_slice_number>, which would force the creation >>>>>>> of swap on an indicated slice instead of on a ZFS volume. >>>>>> >>>>>> This is a workaround, but this solution would seem to require that >>>>>> the user manually do something to work around the issue after hitting >>>>>> it. Could we devise a work around that works out of the box? Or at >>>>>> least works out of the box for most scenarios? >>>>>> >>>>>> For example, for systems with XX Gb memory, we could still create the >>>>>> swap zvol, and just not add it during the microroot. I think Mary's >>>>>> found that XX so far equals 2Gb, but she doesn't really have any >>>>>> systems with anything between 1Gb and 2Gb of memory. With some VBox >>>>>> testing perhaps we can find that number to be something smaller, and >>>>>> then our bug case would only be for systems with memory between >>>>>> 700Mb and XXGb --and only there would we institute some really >>>>>> ugly hack. For those cases we could resort to what you've described >>>>>> above, or just move our 700Mb number up to XXGb. >>>>>> >>>>>> >>>>>> thanks, >>>>>> -ethan >>>>>> >>>>>>> >>>>>>> An advantage of this approach is that, since we are as yet >>>>>>> uncertain of which configurations will exhibit bug 6084, there is >>>>>>> a simple manual configuration change to work around it. It would >>>>>>> also serve as an AI feature (although perhaps not a terribly >>>>>>> interesting one). >>>>>>> >>>>>>> I would estimate a day of work to code this and do unit testing. >>>>>>> The additional risk would be small. >>>>>>> >>>>>>> I will mention here that the swapping to a zvol bug needs to be >>>>>>> fixed, and that perhaps we shouldn't be thinking in terms of a >>>>>>> workaround, but a high priority fix. >>>>>>> >>>>>>> Any feedback would be appreciated, >>>>>>> William >>>>>>> _______________________________________________ >>>>>>> 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
