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 >> >
