[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference noted::hackers_v1

Title:-={ H A C K E R S }=-
Notice:Write locked - see NOTED::HACKERS
Moderator:DIEHRD::MORRIS
Created:Thu Feb 20 1986
Last Modified:Mon Aug 03 1992
Last Successful Update:Fri Jun 06 1997
Number of topics:680
Total number of notes:5456

307.0. "Psuedo initing a system pack." by POTARU::QUODLING (Technocrats of the world... Unite!) Mon Sep 08 1986 22:50

        On a slightly related point to 306.*, a while back we were
        `disabling' a system pack after it had been used by us at DECUS
        and before it went to a customer. (Biggest laugh was it ended
        up coming in house and I had to re-install the SW).
        
        After much discussion, it was thought that the easiest way
        of making a system pack unreadable was to rename the MFD.
        
        
        Any other bright ideas.
        
        q
        
T.RTitleUserPersonal
Name
DateLines
307.1It is rumored that, ...REGENT::MINOWMartin Minow -- DECtalk EngineeringTue Sep 09 1986 13:2410
When the 780 was first released, the pack that came with the
system was the one used by manufacturing during final test.
It contained a copy of the VMS development system pack.  Customers
put it on the shelf and used one of their own packs for installation
testing.

They managed to keep this a secret from Dec for a few years!

Martin.

307.2PASTIS::MONAHANTue Sep 09 1986 15:4911
    	For a competent disk scavenger a simple change like that suggested
    in .0 is not too effective. For last year at European DECUS we used
    a F.S. diagnostic to erase one pack on a system, and then did image
    backups of this to others. I expect this year we might be able to
    do shadow set catchups instead of image backups for some systems,
    but some microvax systems can be a problem.
    
    	If anyone has any really good ideas I would welcome them since
    we will need to do this again this year after DECville.
    
    		Dave
307.3qio writelbnIOSG::BAILEYWed Sep 10 1986 08:414
    Start at LBN 0 and write blank blocks up to disk max block
    
    
    
307.4not quite so easy..PASTIS::MONAHANMon Sep 15 1986 07:4014
    	For a non-system disk almost any simple system will work. For
    the system disk it is a little more of a problem, since there are
    a number of critical system files that may be accessed at almost
    any time. If this happens the system will crash, and the disk will
    not be rebootable, although it will still probably have many of
    the files untouched.
    
    	A programme doing logical block QIOs would have first to build
    up a table of block numbers that must not be touched. Something
    that runs without VMS, such as an HSC utility is simpler and faster,
    but not all microvaxen have HSCs.
    
    	It is almost Catch-22, like the memory clearing programme that
    prints out the checksum of zero to prove that memory has been cleared.
307.5Maybe one of these will work ...52362::COWANKen CowanSun Sep 28 1986 17:3224
    At first I thought ANAL/MEDIA/EXERCISE would be useful, but
    that doesn't quite work on the system device while the system
    is running.
    
    If you are in to hacking, it might be possible to get ANAL/
    MEDIA to run standalone.    Off hand, I'm not sure what needs
    to be done.
    
    An alternative is to fill up an appropriate sized disk with
    trash, do am image backup and then use standalone backup to 
    write to the system disk.     Note that getting standalone backup
    to initialize the disk is a marginal solution.   After the
    disk is initialized, it can be recovered [with appropriate
    hacking.]
    
    Maybe use the FS diagnostic to reformat the disk?
    
    Just thinking ...
    
    	KC
    
    
    
    
307.6IO$_WRITELBLK kinda worked for meMDVAX3::COARA wretched hive of bugs and flamers.Tue Nov 24 1987 01:4315
    I wrote a program to do this when I had to return a system pack
    to the site we had borrowed it from.  The program started at LBN
    <maxblock>, and zeroed it, then n-1, n-2, and so on.  It printed
    out little status reports every 100 blocks; after a while, I got
    concerned, since it was running along merrily and the system remained
    up, so I typed CTRL/Y - and the system crashed and remained unbootable.
    Apparently, it had already gotten to the point of something that
    would get invoked at image rundown.  Oh, yeah - it did a $LCKPAG
    to lock the entire working set into physical memory.  Unfortunately,
    the program was on the disk being wiped - so I lost it.  I've sometimes
    wondered what would have happened if I had left it alone...  ;-)
    Maybe I'll try it again sometime - `Coming to a System Near YOU!'
    This was back under VMS Version 3.n.
    
    #ken	:-)}