OT: SCO/Patchck

[Brian K. White]

On 6/15/2011 12:47 PM, Jay Ashworth wrote:
> Has anyone here used Patchck to update a SCO system?
>
> Successfully?
>
> I blew about 4 hours yesterday because, as nearly as I could tell, it
> downloaded 2 patches to my 5.0.6 system (which already had rs506a) which
> had files that did not match the package manifest in size or checksum...
>
> and installed the patches anyway, and left them installed even after it
> detected the error (and it *did* detect the error).
>
> One of the files was libc.so.
>
> I don't have to explain how poorly things went after that, right?  Happily,
> they apparently build custom(1m) with static libraries, so *it* could tell
> me it thought those patches were only partially installed, and back them
> out (though I had to ignore precisely the errors that caused the problem
> in the first place).
>
> But... really?
>
> We really *have* a manifest, and we don't appear to actually *check* it
> until *after* we install the bad packages?  And, more to the point: there
> *were* bad patch packages on their server?
>
> I reinstalled the two problematic ones: oss646 and 648 (processor and
> execution environment supplements, probably not respectively), each
> separately... and each failed again.  Failed the entire system, I mean;
> you know what happens when libc gets borken.
>
> So: was this just me?  Has anyone else seen this?  Is there actually
> a contact channel to complain up?

I have only used patchck once or twice and decided it was too scary. I 
just pore over the patch list manually. I made a convenience script that 
does the download, unpack, install, cleanup automatically, but I run 
that script manually, just "myscript url", once per patch, and determine 
the patches manually by looking over the updates page on the sco web site.

I have seen corrupt package files only in a case where the files were 
not in fact corrupt, instead the OS was too old for the machine and 
failed to uncompress some VOL files correctly if hyperthreading were 
enabled in the bios. This was 5.0.7 initial install before mp1.
For initial install, at least on some machines, you have to ensure 
hyperthreading is disabled at least until mp1 is installed (only today 
you wouldn't install mp1 you'd install mp5, but just for completeness 
the fix came with mp1, possibly in a separate patch before mp1 but at 
_least_ in mp1 and all later)

Since that was 5.0.7, I'm guessing the same applies to 5.0.6 at least up 
until that same date as when the fix came to 5.0.7.

To be clear, this looked exactly like a bad download, and the machine 
seemed to run fine in most other ways, at least in so far as it managed 
to do all the things to get installed up to that point, so you would 
have long since seemed to have "proven" that the box, cpu, ram, etc, was 
sound in general. But it was absolutely repeatable, always affected the 
same vol files no matter what means were used to deliver them to the 
box, and the same exact files worked fine after disabling 
hyperthreading, and broke again after reenabling hyperthreading.

-- 
bkw

>
> Cheers,
> -- jra