SCO 5.0.4/5 stops at boot: prompt on a fresh install in a VMwareworkstation - SCO

This is a discussion on SCO 5.0.4/5 stops at boot: prompt on a fresh install in a VMwareworkstation - SCO ; Hello, I'm a complete newbie with SCO, but not to UNIX. A client of mine has an old SCO 5.0.5 server running a very small Progress database and the hardware is finally dying. We're going to run it in a ...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 21

Thread: SCO 5.0.4/5 stops at boot: prompt on a fresh install in a VMwareworkstation

  1. SCO 5.0.4/5 stops at boot: prompt on a fresh install in a VMwareworkstation

    Hello,
    I'm a complete newbie with SCO, but not to UNIX. A client of mine has
    an old SCO 5.0.5 server running a very small Progress database and the
    hardware is finally dying. We're going to run it in a VMware
    workstation, at the moment, with IDE disks, which seems to be working
    after some simple hackery with 5.0.7 install floppy images... but it
    works.

    I've done a clean install into the VM, applied the licence keys, but
    every time I try and boot the VM it stops at the boot: prompt.
    Hitting return makes it boot, and it then asks to be licenced, and
    then asks for the root password or ^d to continue into normal mode. I
    can ^d in and it seems to run ok from then on.

    Can anyone here point me at what I need to do to get it to boot up
    multi user without needing user input on the (virtual) console?

    More background if it helps :

    I have a CPIO archive of the existing system that I want to restore on
    top of the VM once this is working, so I can get it working with a
    minimum of fuss in a hurry. Any tips or caveats to doing this? I
    expect the kernel might get upset, or maybe the licence will stop
    moaning?

    Thanks!

    Carl

  2. Re: SCO 5.0.4/5 stops at boot: prompt on a fresh install in a VMwareworkstation

    On 1 Jul, 03:22, Bleve wrote:
    > Hello,
    > I'm a complete newbie with SCO, but not to UNIX. *A client of mine has
    > an old SCO 5.0.5 server running a very small Progress database and the
    > hardware is finally dying. *We're going to run it in a VMware
    > workstation, at the moment, with IDE disks, which seems to be working
    > after some simple hackery with 5.0.7 install floppy images... but it
    > works.
    >
    > I've done a clean install into the VM, applied the licence keys, but
    > every time I try and boot the VM it stops at the boot: prompt.
    > Hitting return makes it boot, and it then asks to be licenced, and
    > then asks for the root password or ^d to continue into normal mode. I
    > can ^d in and it seems to run ok from then on.
    >
    > Can anyone here point me at what I need to do to get it to boot up
    > multi user without needing user input on the (virtual) console?


    What happens if you just *wait* for a few minutes? Under 5.0.6,
    there's a lengthy pause at that stage: I think that it's a legacy of
    what is basically a very antique operating system that thinks you
    should reboot only in emergencies, and threefore you *MUST* want a
    lengthy chance to have a talk with it at boot time.

    Be warned: that IDE based installation works fine iwth VMware
    Workstation, but VMware ESX doesn't support it. You have to use the
    Buslogic emulated SCSI and 5.0.7 boot floppy, described at AP
    Lawrence's website, to install on VMware ESX.

    > More background if it helps :
    >
    > I have a CPIO archive of the existing system that I want to restore on
    > top of the VM once this is working, so I can get it working with a
    > minimum of fuss in a hurry. *Any tips or caveats to doing this? *I
    > expect the kernel might get upset, or maybe the licence will stop
    > moaning?


    Restoring form cpio is begging for pain. It's likely to seriously
    screw up your kernel and configuration if you simply restore on top of
    it: this is AT&T SysV with SCO modifications on top of it, not Linux,
    and that nutty symlinking all over the file system of your installed
    software that OpenServer does is likely to present profound
    difficulties.


  3. Re: SCO 5.0.4/5 stops at boot: prompt on a fresh install in a VMwareworkstation

    On 1 Jul, 04:22, Bleve wrote:
    > Hello,
    > I'm a complete newbie with SCO, but not to UNIX. A client of mine has
    > an old SCO 5.0.5 server running a very small Progress database and the
    > hardware is finally dying. We're going to run it in a VMware
    > workstation, at the moment, with IDE disks, which seems to be working
    > after some simple hackery with 5.0.7 install floppy images... but it
    > works.
    >
    > I've done a clean install into the VM, applied the licence keys, but
    > every time I try and boot the VM it stops at the boot: prompt.
    > Hitting return makes it boot, and it then asks to be licenced, and
    > then asks for the root password or ^d to continue into normal mode. I
    > can ^d in and it seems to run ok from then on.
    >
    > Can anyone here point me at what I need to do to get it to boot up
    > multi user without needing user input on the (virtual) console?


    have a look at the man page for boot:

    http://osr507doc.sco.com/en/man/html.HW/boot.HW.html

    and specifically AUTOBOOT. Note that this may or may not
    work on VMware.

    John


  4. Re: SCO 5.0.4/5 stops at boot: prompt on a fresh install in a VMwareworkstation

    On Jul 1, 5:21*pm, Nico Kadel-Garcia wrote:
    > On 1 Jul, 03:22, Bleve wrote:
    >
    >
    >
    > > Hello,
    > > I'm a complete newbie with SCO, but not to UNIX. *A client of mine has
    > > an old SCO 5.0.5 server running a very small Progress database and the
    > > hardware is finally dying. *We're going to run it in a VMware
    > > workstation, at the moment, with IDE disks, which seems to be working
    > > after some simple hackery with 5.0.7 install floppy images... but it
    > > works.

    >
    > > I've done a clean install into the VM, applied the licence keys, but
    > > every time I try and boot the VM it stops at the boot: prompt.
    > > Hitting return makes it boot, and it then asks to be licenced, and
    > > then asks for the root password or ^d to continue into normal mode. I
    > > can ^d in and it seems to run ok from then on.

    >
    > > Can anyone here point me at what I need to do to get it to boot up
    > > multi user without needing user input on the (virtual) console?

    >
    > What happens if you just *wait* for a few minutes? Under 5.0.6,
    > there's a lengthy pause at that stage: I think that it's a legacy of
    > what is basically a very antique operating system that thinks you
    > should reboot only in emergencies, and threefore you *MUST* want a
    > lengthy chance to have a talk with it at boot time.


    I haven't tried that, but will do so once this server build is done,
    thankyou.

    > Be warned: that IDE based installation works fine iwth VMware
    > Workstation, but VMware ESX doesn't support it. You have to use the
    > Buslogic emulated SCSI and 5.0.7 boot floppy, described at AP
    > Lawrence's website, to install on VMware ESX.


    Understood, I think I can get away with workstation, running in a VNC
    session. It's kludgy but buys me time to fix the real problems.

    >
    > > More background if it helps :

    >
    > > I have a CPIO archive of the existing system that I want to restore on
    > > top of the VM once this is working, so I can get it working with a
    > > minimum of fuss in a hurry. *Any tips or caveats to doing this? *I
    > > expect the kernel might get upset, or maybe the licence will stop
    > > moaning?

    >
    > Restoring form cpio is begging for pain. It's likely to seriously
    > screw up your kernel and configuration if you simply restore on top of
    > it: this is AT&T SysV with SCO modifications on top of it, not Linux,
    > and that nutty symlinking all over the file system of your installed
    > software that OpenServer does is likely to present profound
    > difficulties.


    Yeah ... it's a mess alright, I think I can get away with just the
    progress database stuff and recreate the rest, but how do you activate
    the licence?



  5. Re: SCO 5.0.4/5 stops at boot: prompt on a fresh install in a VMwareworkstation

    On Jul 1, 5:57*pm, Bleve wrote:
    > On Jul 1, 5:21*pm, Nico Kadel-Garcia wrote:
    >
    >
    >
    > > On 1 Jul, 03:22, Bleve wrote:

    >
    > > > Hello,
    > > > I'm a complete newbie with SCO, but not to UNIX. *A client of mine has
    > > > an old SCO 5.0.5 server running a very small Progress database and the
    > > > hardware is finally dying. *We're going to run it in a VMware
    > > > workstation, at the moment, with IDE disks, which seems to be working
    > > > after some simple hackery with 5.0.7 install floppy images... but it
    > > > works.

    >
    > > > I've done a clean install into the VM, applied the licence keys, but
    > > > every time I try and boot the VM it stops at the boot: prompt.
    > > > Hitting return makes it boot, and it then asks to be licenced, and
    > > > then asks for the root password or ^d to continue into normal mode. I
    > > > can ^d in and it seems to run ok from then on.

    >
    > > > Can anyone here point me at what I need to do to get it to boot up
    > > > multi user without needing user input on the (virtual) console?

    >
    > > What happens if you just *wait* for a few minutes? Under 5.0.6,
    > > there's a lengthy pause at that stage: I think that it's a legacy of
    > > what is basically a very antique operating system that thinks you
    > > should reboot only in emergencies, and threefore you *MUST* want a
    > > lengthy chance to have a talk with it at boot time.

    >
    > I haven't tried that, but will do so once this server build is done,
    > thankyou.
    >
    > > Be warned: that IDE based installation works fine iwth VMware
    > > Workstation, but VMware ESX doesn't support it. You have to use the
    > > Buslogic emulated SCSI and 5.0.7 boot floppy, described at AP
    > > Lawrence's website, to install on VMware ESX.

    >
    > Understood, I think I can get away with workstation, running in a VNC
    > session. *It's kludgy but buys me time to fix the real problems.
    >
    >
    >
    > > > More background if it helps :

    >
    > > > I have a CPIO archive of the existing system that I want to restore on
    > > > top of the VM once this is working, so I can get it working with a
    > > > minimum of fuss in a hurry. *Any tips or caveats to doing this? *I
    > > > expect the kernel might get upset, or maybe the licence will stop
    > > > moaning?

    >
    > > Restoring form cpio is begging for pain. It's likely to seriously
    > > screw up your kernel and configuration if you simply restore on top of
    > > it: this is AT&T SysV with SCO modifications on top of it, not Linux,
    > > and that nutty symlinking all over the file system of your installed
    > > software that OpenServer does is likely to present profound
    > > difficulties.

    >
    > Yeah ... it's a mess alright, I think I can get away with just the
    > progress database stuff and recreate the rest, but how do you activate
    > the licence?


    It came up ok after a few moments, thankyou. My next dumb question,
    how do I get it to activate its licence? I have the key installed etc
    (required at install-time) but it's moaning in motd about a licence
    activation? Can I copy a file over from the existing server?


  6. Re: SCO 5.0.4/5 stops at boot: prompt on a fresh install in a VMwareworkstation



    Bleve wrote:

    > It came up ok after a few moments, thankyou. My next dumb question,
    > how do I get it to activate its licence? I have the key installed etc
    > (required at install-time) but it's moaning in motd about a licence
    > activation? Can I copy a file over from the existing server?


    You need to run the 'scoadmin' tool. The license should normally have
    been activated at installation time. Is it moaning about seeing a
    duplicate license (because your old system is still around), or
    moaning about registration?

  7. Re: SCO 5.0.4/5 stops at boot: prompt on a fresh install in a VMwareworkstation

    On Jul 2, 6:19*pm, Nico Kadel-Garcia wrote:
    > Bleve wrote:
    > > It came up ok after a few moments, thankyou. *My next dumb question,
    > > how do I get it to activate its licence? *I have the key installed etc
    > > (required at install-time) but it's moaning in motd about a licence
    > > activation? *Can I copy a file over from the existing server?

    >
    > You need to run the 'scoadmin' tool. The license should normally have
    > been activated at installation time. Is it moaning about seeing a
    > duplicate license (because your old system is still around), or
    > moaning about registration?


    Registration, I ran licenseMgr on both the new (virtual) box and the
    old one, and the old one isn't registered either. I think that means I
    can get away with not registering it?

  8. Re: SCO 5.0.4/5 stops at boot: prompt on a fresh install in a VMware workstation

    Nico Kadel-Garcia wrote:

    > What happens if you just *wait* for a few minutes? Under 5.0.6,
    > there's a lengthy pause at that stage: I think that it's a legacy of
    > what is basically a very antique operating system that thinks you
    > should reboot only in emergencies, and threefore you *MUST* want a
    > lengthy chance to have a talk with it at boot time.


    Wow, that's an interesting interpretation.

    It's a server OS. It should, in fact, only be rebooted in extraordinary
    circumstances. It is not a version of Windows where the first "cure"
    for any glitch is a drive-by rebooting. This has nothing to do with
    antiquity.

    Rebooting takes a while. Have you ever worked with a machine whose BIOS
    takes 3-4 minutes to initialize, but which gives you only a few seconds
    to tell it to go into BIOS setup? Pretty darn annoying, isn't it?
    You have to power cycle it, then watch carefully for several minutes,
    waiting to catch those crucial few seconds. The opportunity to get your
    Unix system into single-user mode is much like the opportunity to get a
    machine into BIOS setup. It is reasonable for it to delay a bit so you
    have a chance to catch it.

    And it's easily tuned.

    >Bela<


  9. Re: SCO 5.0.4/5 stops at boot: prompt on a fresh install in a VMware workstation


    "Bleve" wrote in message
    news:c0726254-7ab0-41c9-bb07-a8245fc2a7fd@a32g2000prf.googlegroups.com...
    On Jul 2, 6:19 pm, Nico Kadel-Garcia wrote:
    > Bleve wrote:
    > > It came up ok after a few moments, thankyou. My next dumb question,
    > > how do I get it to activate its licence? I have the key installed etc
    > > (required at install-time) but it's moaning in motd about a licence
    > > activation? Can I copy a file over from the existing server?

    >
    > You need to run the 'scoadmin' tool. The license should normally have
    > been activated at installation time. Is it moaning about seeing a
    > duplicate license (because your old system is still around), or
    > moaning about registration?


    Registration, I ran licenseMgr on both the new (virtual) box and the
    old one, and the old one isn't registered either. I think that means I
    can get away with not registering it?
    --------

    A few things:

    * There is activation and there is registration.
    Activation is necessary for any license to work. That merely means entering
    in a valid license number and activation code. Without that, the components
    you want to use don't even start to work, so, since your os is running, you
    have already done this at least for the base os license.
    Registration is not necessary. All it does is print that nag message to the
    console. I think it's even more specific, just to tty0.
    I think I've only registered maybe 3 machines out of hundreds. Users don't
    use the console.
    For the few times when you must use the console instead of telnet/ssh just
    flip to Alt-F2 or press Ctrl-L to redraw your screen when it does intrude.

    * The duplicate license check is easy to block.
    Just use ipf/iptables either in the host linux or right in the client sco
    unix to block all traffic in & out on udp port 488.
    I often put these 2 rules into /etc/ipf.conf on sco boxes:

    # block sco license manager from seeing new/old box
    block in quick on net0 proto udp from any to any port = 488
    block out quick on net0 proto udp from any to any port = 488

    If the sco unix is 5.0.6 or later then ipf is built in, if it's 5.0.4 or
    5.0.5 then ipf can be added via TLS709
    however docs & examples on configuring are pretty scarce. tls709 doesn't
    even include an rc script if I remember correctly.

    * the base os license and serial number can be obtained from the old machine
    but no other licenses that I know of, or at least not enough info to
    activate.
    Look for
    SERIAL_NUMBER
    ACTIVATION_KEY
    ANNOTATION_LINE
    in /var/adm/ISL/iqm_file
    Reference:
    http://aplawrence.com/Bofcusm/667.html
    http://aplawrence.com/SCOFAQ/FAQ_scotec1getserno.html

    --
    Brian K. White brian@aljex.com http://www.myspace.com/KEYofR
    +++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
    filePro BBx Linux SCO FreeBSD #callahans Satriani Filk!


  10. Re: SCO 5.0.4/5 stops at boot: prompt on a fresh install in a VMwareworkstation

    On Jul 4, 10:52*am, "Brian K. White" wrote:
    > "Bleve" wrote in message
    >


    > A few things:
    >
    > * There is activation and there is registration.
    > Activation is necessary for any license to work. That merely means entering
    > in a valid license number and activation code. Without that, the components
    > you want to use don't even start to work, so, since your os is running, you
    > have already done this at least for the base os license.
    > Registration is not necessary. All it does is print that nag message to the
    > console. I think it's even more specific, just to tty0.
    > I think I've only registered maybe 3 machines out of hundreds. Users don't
    > use the console.
    > For the few times when you must use the console instead of telnet/ssh just
    > flip to Alt-F2 or press Ctrl-L to redraw your screen when it does intrude..


    Great, thankyou.

    I have the original paper licenses, and the box is on a seperate LAN
    while I prepare it to replace the old hardware, so the license check
    thing won't be an issue.

    I have one last question (I promise!) :

    Printers.

    It's using svr4 printing, and I need to copy or replicate the printer
    setups, which aren't documented anywhere, and change them a tiny bit
    (different ttysX for the serial port printer they use)
    If it was BSD etc, I'd just grab /etc/printcap. This is obviously
    quite different. Is it possible to grab all the settings and config
    files for the printers on the old box and copy them to the new one?
    I've found where some of the printer definitions are, but google keeps
    pointing me at CUPS or Solaris's printing, which all changed a lot
    since the early days of SVR4 I think? (it's been a _long_ time since
    I've set up any printers on early SunOS 5.x boxes ...). Any doco on
    this anywhere, or even a pointer at the right keywords to feed google?


  11. Re: SCO 5.0.4/5 stops at boot: prompt on a fresh install in a VMwareworkstation

    Bela Lubkin wrote:
    > waiting to catch those crucial few seconds. The opportunity to get
    > your Unix system into single-user mode is much like the opportunity
    > to get a machine into BIOS setup. It is reasonable for it to delay a
    > bit so you have a chance to catch it.


    I don't think the analogy is quite so: if you missed the BIOS "del" key
    (or whatever), you have no recourse but another reboot; however, if you
    missed the OpenServer "Boot:" prompt (to tell the system to go into
    Single-User), you can always do an "init 1".

    > It's a server OS. It should, in fact, only be rebooted in
    > extraordinary circumstances.


    The system may be so, but the applications that it usually runs more
    often than not need a nightly reboot (Filepro, anyone?).

  12. Re: SCO 5.0.4/5 stops at boot: prompt on a fresh install in a

    Pepe typed (on Fri, Jul 04, 2008 at 05:03:32PM +0200):
    > Bela Lubkin wrote:
    >> waiting to catch those crucial few seconds. The opportunity to get
    >> your Unix system into single-user mode is much like the opportunity to
    >> get a machine into BIOS setup. It is reasonable for it to delay a
    >> bit so you have a chance to catch it.

    >
    > I don't think the analogy is quite so: if you missed the BIOS "del" key
    > (or whatever), you have no recourse but another reboot; however, if you
    > missed the OpenServer "Boot:" prompt (to tell the system to go into
    > Single-User), you can always do an "init 1".
    >
    >> It's a server OS. It should, in fact, only be rebooted in
    >> extraordinary circumstances.

    >
    > The system may be so, but the applications that it usually runs more
    > often than not need a nightly reboot (Filepro, anyone?).


    I have been using filePro for twenty years and I have never seen a site
    where filePro required nightly reboots, or for that matter where filePro
    ever required any reboot whatsoever.


    --
    JP

  13. Re: SCO 5.0.4/5 stops at boot: prompt on a fresh install in a VMware workstation


    ----- Original Message -----
    From: "Pepe"
    Newsgroups: comp.unix.sco.misc
    To:
    Sent: Friday, July 04, 2008 11:03 AM
    Subject: Re: SCO 5.0.4/5 stops at boot: prompt on a fresh install in a VMware workstation


    > Bela Lubkin wrote:
    >> waiting to catch those crucial few seconds. The opportunity to get
    >> your Unix system into single-user mode is much like the opportunity
    >> to get a machine into BIOS setup. It is reasonable for it to delay a
    >> bit so you have a chance to catch it.

    >
    > I don't think the analogy is quite so: if you missed the BIOS "del" key
    > (or whatever), you have no recourse but another reboot; however, if you
    > missed the OpenServer "Boot:" prompt (to tell the system to go into
    > Single-User), you can always do an "init 1".
    >
    >> It's a server OS. It should, in fact, only be rebooted in
    >> extraordinary circumstances.

    >
    > The system may be so, but the applications that it usually runs more
    > often than not need a nightly reboot (Filepro, anyone?).


    What about filePro?

    My current supported user count running filepro, not counting all the customers with their own servers, is around 1000, spread over 6 machines.

    All filePro.

    Lets see...

    nj4:~ # cd /u/global/appl/filepro
    nj4:/u/global/appl/filepro # ls |wc -l
    663
    nj4:/u/global/appl/filepro # find ./ -name 'prc.*' |wc -l
    9995
    nj4:/u/global/appl/filepro # find ./ -name 'index*' |wc -l
    92173

    nj4:/u/global/appl/filepro # find ./ -name 'key*' |wc -l
    22252
    nj4:/u/global/appl/filepro # find ./ -name 'prc.*' |xargs cat |wc -l
    1844564

    nj4:/u/global/appl/filepro # uptime
    11:45am up 166 days 11:20, 11 users, load average: 0.17, 0.16, 0.18
    nj4:/u/global/appl/filepro #

    The filepro licences are 256 user and we do bump into it once in a while, there is often 200 concurrent users most weekdays. Our smallest box is still bout 100 concurrent users. That's people, not filepro instances or login sessions, those numbers are even higher of course.

    663 filepro files
    10 thousand processing tables
    1.8 _million_ lines of code (granted, maybe 1/3 isn't used)
    22 _thousand_ key segments (we don't use any data segnments so all data is in the indexable keys)
    92 _thousand_ individual automatic index files. (we almost never use demand indexes, so this number does represent he number of auto indexes that filepro maintains without error for at least the last 166 days with 200 users pounding on it most of those days)

    Oh, I forgot, that box also hosts a couple of other filepro trees in addition to the one above, similar files and processing, just with only a few qualifiers. The directory above hosts about 40 qualifiers, which translates to about 40 companies, each with their own whole office full of employees all logged in with multiple windows all day every day.
    So add to above maybe 4 more qualifiers and 40 more users.

    And that's just one box, we ourselves have about 5 more just counting the live production boxes all with similar numbers.
    Then there are all the last 15 or so years worth of customers who each got their own server with most of those in the 10-30 user range, a few 50's and a couple 100's and a 150.

    With all that pounding, we almost never rebuild indexes or freechains or reboot or delete lockfiles or any of that crap that some people do.

    These are all opensuse 10.x linux boxes now, but things were if anything better on OSR5. the individual boxes couldn't handle as many users because of plain filesystem speed, but the uptimes were longer and in neither case have uptimes been shortened by filePro. In neither case have we ever had to rebuild indexes or reboot or build freechains etc except on specific occasions for a specific file as a result of some particular specific damage or merely as a part of programming and restructuring.

    Now, in the interest of full disclosure, we did have one mystery problem once a couple of years ago that we never tracked down, but, without changing the OS, the filepro binaries, the server hardware, or the server load & usage profile, but with constant filepro programming changes being made by 6 developers, a very rare lock-up problem occured that could only be fixed by a reboot (no amount of killing processes anf freeing file/record locks helped) it only happened maybe 3 or 4 times , all in a few month window about 2 or 3 years ago. Whatever it was somewhere in our code, it might have been technically legal, and thus a filepro bug. But this tells me it was both an extremely exotic bug, and possible to avoid, since we in fact no longer have it. I'm pretty sure it was programmer error somewhere that probably got fixed in the natural course of things without the fixer even realising they were fixing that problem as well as whatever they were intending to do. That was THE only time in 10 years and and somewhere around 200 filepro installations of just my own personal first hand experience that filepro necessitated a reboot. I have sco boxs out there in peoples offices with only 50 or fewer users generally, but they go years btween reboots, and then it's usually plain hardware failure or power or physical relocation. Several of those predate me joining the company and they never needed rebooting in all the years they were up before that either.

    Not counting the windows installations. They are as you might guess, a different stoy.

    Whatever problem you have that you think requires rebooting, it very probably doesn't. What it requires is someone who can spell unix to look things over and find the problems. Similarly for whatever language your main app is written in (filePro in your case apparently)

    In the face of how hard we pound on filepro and how perfect it performs, I say that proves that filePro is not a weak link and not the blame for anything you think can only be fixed by rebooting.

    Try again only try to find some other scapegoat. filePro sure isn't one.

    --
    Brian K. White brian@aljex.com http://www.myspace.com/KEYofR
    +++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
    filePro BBx Linux SCO FreeBSD #callahans Satriani Filk!


  14. Re: SCO 5.0.4/5 stops at boot: prompt on a fresh install in a

    Jean-Pierre Radley wrote (on Fri, Jul 04, 2008 at 12:03:08PM -0400):

    | Pepe typed (on Fri, Jul 04, 2008 at 05:03:32PM +0200):
    | > Bela Lubkin wrote:
    | >> waiting to catch those crucial few seconds. The opportunity to get
    | >> your Unix system into single-user mode is much like the opportunity to
    | >> get a machine into BIOS setup. It is reasonable for it to delay a
    | >> bit so you have a chance to catch it.
    | >
    | > I don't think the analogy is quite so: if you missed the BIOS "del" key
    | > (or whatever), you have no recourse but another reboot; however, if you
    | > missed the OpenServer "Boot:" prompt (to tell the system to go into
    | > Single-User), you can always do an "init 1".
    | >
    | >> It's a server OS. It should, in fact, only be rebooted in
    | >> extraordinary circumstances.
    | >
    | > The system may be so, but the applications that it usually runs more
    | > often than not need a nightly reboot (Filepro, anyone?).
    |
    | I have been using filePro for twenty years and I have never seen a site
    | where filePro required nightly reboots, or for that matter where filePro
    | ever required any reboot whatsoever.
    |
    | --
    | JP

    Me too . . . starting with PROFILE on TRSDOS and taking every
    step on the way until now with filePro 5.6.06D4 on SCO OSR 6,
    and no version of Profile/filePro ever required a reboot for
    any reason at any time on any of the various OS's [1].

    Bob

    [1] - OS's after TRSDOS were either Xenix or UNIX.

    --
    Bob Stockler +-+ bob@trebor.iglou.com +-+ http://members.iglou.com/trebor

  15. Re: SCO 5.0.4/5 stops at boot: prompt on a fresh install in a VMwareworkstation

    Brian K. White wrote:
    > ----- Original Message ----- From: "Pepe"
    > Newsgroups: comp.unix.sco.misc To: Sent: Friday,
    > July 04, 2008 11:03 AM Subject: Re: SCO 5.0.4/5 stops at boot: prompt
    > on a fresh install in a VMware workstation
    >
    >> Bela Lubkin wrote:
    >>
    >>> waiting to catch those crucial few seconds. The opportunity to
    >>> get your Unix system into single-user mode is much like the
    >>> opportunity to get a machine into BIOS setup. It is reasonable
    >>> for it to delay a bit so you have a chance to catch it.

    >>
    >> I don't think the analogy is quite so: if you missed the BIOS "del"
    >> key (or whatever), you have no recourse but another reboot;
    >> however, if you missed the OpenServer "Boot:" prompt (to tell the
    >> system to go into Single-User), you can always do an "init 1".
    >>
    >>> It's a server OS. It should, in fact, only be rebooted in
    >>> extraordinary circumstances.

    >>
    >> The system may be so, but the applications that it usually runs
    >> more often than not need a nightly reboot (Filepro, anyone?).

    >
    > What about filePro?
    >
    > My current supported user count running filepro, not counting all the
    > customers with their own servers, is around 1000, spread over 6
    > machines.


    I don't know how can it be so stable for you. In a trucking company,
    they had to reboot the OSR5 servers every night to get going the next
    day... they had Filepro until they changed to an Oracle backend on Linux
    and totally rewrote the application.

    It was vox populi then that the cause for that was Filepro in a
    multiuser concurrent environment. Maybe they were wrong.

  16. Re: SCO 5.0.4/5 stops at boot: prompt on a fresh install in a VMwareworkstation

    Bela Lubkin wrote:
    > Nico Kadel-Garcia wrote:
    >
    >> What happens if you just *wait* for a few minutes? Under 5.0.6,
    >> there's a lengthy pause at that stage: I think that it's a legacy of
    >> what is basically a very antique operating system that thinks you
    >> should reboot only in emergencies, and threefore you *MUST* want a
    >> lengthy chance to have a talk with it at boot time.

    >
    > Wow, that's an interesting interpretation.
    >
    > It's a server OS. It should, in fact, only be rebooted in extraordinary
    > circumstances. It is not a version of Windows where the first "cure"
    > for any glitch is a drive-by rebooting. This has nothing to do with
    > antiquity.


    I don't use "rock-stable" OS's as servers, because they turn out not to be.
    Lightweight, userland redundancy and duplication of servers is usually more
    reliable and gives flexibility for changing needs.

    And the SCO OpenServer 5.0.6 systems are far, far more likely to need
    rebooting than the other systems I deal with. The tendency of cpio tape
    backups to hang the tape drive and require a reboot is *nasty*. I haven't seen
    anything that bad in the server world in decades.

    > Rebooting takes a while. Have you ever worked with a machine whose BIOS
    > takes 3-4 minutes to initialize, but which gives you only a few seconds
    > to tell it to go into BIOS setup? Pretty darn annoying, isn't it?
    > You have to power cycle it, then watch carefully for several minutes,
    > waiting to catch those crucial few seconds. The opportunity to get your
    > Unix system into single-user mode is much like the opportunity to get a
    > machine into BIOS setup. It is reasonable for it to delay a bit so you
    > have a chance to catch it.
    >
    > And it's easily tuned.
    >
    >> Bela<


    I agree with the BIOS problem. It's aggravated with SCSI devices. Amazingly,
    it's eased by Linux BIOS's, which can be configured and don't spend ages
    scanning for non-existent and deprecated hardware: the OLPC project uses them.

    A delay is quite reasonable, I agree. But an additional line of text saying
    'will boot in 60 seconds' wouldn't kill anyone to have written into the boot
    loader.

  17. Re: SCO 5.0.4/5 stops at boot: prompt on a fresh install in a VMware workstation

    Nico Kadel-Garcia wrote:

    > Bela Lubkin wrote:
    > > Nico Kadel-Garcia wrote:
    > >
    > >> What happens if you just *wait* for a few minutes? Under 5.0.6,
    > >> there's a lengthy pause at that stage: I think that it's a legacy of
    > >> what is basically a very antique operating system that thinks you
    > >> should reboot only in emergencies, and threefore you *MUST* want a
    > >> lengthy chance to have a talk with it at boot time.

    > >
    > > Wow, that's an interesting interpretation.
    > >
    > > It's a server OS. It should, in fact, only be rebooted in extraordinary
    > > circumstances. It is not a version of Windows where the first "cure"
    > > for any glitch is a drive-by rebooting. This has nothing to do with
    > > antiquity.

    >
    > I don't use "rock-stable" OS's as servers, because they turn out not to be.
    > Lightweight, userland redundancy and duplication of servers is usually more
    > reliable and gives flexibility for changing needs.


    Hmmm, I believe this is called "Sweet Lemons". Yes, you can build
    something more or less reliable out of sufficiently redundant unreliable
    parts, if that's how you want to work.

    > And the SCO OpenServer 5.0.6 systems are far, far more likely to need
    > rebooting than the other systems I deal with. The tendency of cpio tape
    > backups to hang the tape drive and require a reboot is *nasty*. I haven't seen
    > anything that bad in the server world in decades.


    Use a different type of tape drive, different HBA, cabling, or
    whatever's causing the issue. Or use a different backup strategy.
    Certainly don't just live with the problem...

    > > Rebooting takes a while. Have you ever worked with a machine whose BIOS
    > > takes 3-4 minutes to initialize, but which gives you only a few seconds
    > > to tell it to go into BIOS setup? Pretty darn annoying, isn't it?
    > > You have to power cycle it, then watch carefully for several minutes,
    > > waiting to catch those crucial few seconds. The opportunity to get your
    > > Unix system into single-user mode is much like the opportunity to get a
    > > machine into BIOS setup. It is reasonable for it to delay a bit so you
    > > have a chance to catch it.

    >
    > I agree with the BIOS problem. It's aggravated with SCSI devices. Amazingly,
    > it's eased by Linux BIOS's, which can be configured and don't spend ages
    > scanning for non-existent and deprecated hardware: the OLPC project uses them.
    >
    > A delay is quite reasonable, I agree. But an additional line of text saying
    > 'will boot in 60 seconds' wouldn't kill anyone to have written into the boot
    > loader.


    Yeah, that's a long time deficiency of the OSR5 boot program.

    >Bela<


  18. Re: SCO 5.0.4/5 stops at boot: prompt on a fresh install in a VMwareworkstation

    Bela Lubkin wrote:
    > Nico Kadel-Garcia wrote:
    >
    >> Bela Lubkin wrote:
    >>> Nico Kadel-Garcia wrote:
    >>>
    >>>> What happens if you just *wait* for a few minutes? Under 5.0.6,
    >>>> there's a lengthy pause at that stage: I think that it's a legacy of
    >>>> what is basically a very antique operating system that thinks you
    >>>> should reboot only in emergencies, and threefore you *MUST* want a
    >>>> lengthy chance to have a talk with it at boot time.
    >>> Wow, that's an interesting interpretation.
    >>>
    >>> It's a server OS. It should, in fact, only be rebooted in extraordinary
    >>> circumstances. It is not a version of Windows where the first "cure"
    >>> for any glitch is a drive-by rebooting. This has nothing to do with
    >>> antiquity.

    >> I don't use "rock-stable" OS's as servers, because they turn out not to be.
    >> Lightweight, userland redundancy and duplication of servers is usually more
    >> reliable and gives flexibility for changing needs.

    >
    > Hmmm, I believe this is called "Sweet Lemons". Yes, you can build
    > something more or less reliable out of sufficiently redundant unreliable
    > parts, if that's how you want to work.


    I've built Beowulf clusters this way, and helped deploy thousands of machines
    worldwide. It's a viable strategy.

    >> And the SCO OpenServer 5.0.6 systems are far, far more likely to need
    >> rebooting than the other systems I deal with. The tendency of cpio tape
    >> backups to hang the tape drive and require a reboot is *nasty*. I haven't seen
    >> anything that bad in the server world in decades.

    >
    > Use a different type of tape drive, different HBA, cabling, or
    > whatever's causing the issue. Or use a different backup strategy.
    > Certainly don't just live with the problem...


    Right. That's why I'm using a Linux box to take rsnapshot backups and run the
    tapedrive. If I need more sophisticated tape management, or a tape library, or
    encrypted backup. I'll use Amanda software on top of it. The rsnapshot can run
    over a secure SSH tunnel, the rsnapshot server can serve NFS, SMB, or SSH
    tunneled rsync back to the SCO system, and it's all freeware. It takes some
    work to set up and configure, but that's true of anything. And the snapshot
    capability approaches that of a NetApp storage array.

    >>> Rebooting takes a while. Have you ever worked with a machine whose BIOS
    >>> takes 3-4 minutes to initialize, but which gives you only a few seconds
    >>> to tell it to go into BIOS setup? Pretty darn annoying, isn't it?
    >>> You have to power cycle it, then watch carefully for several minutes,
    >>> waiting to catch those crucial few seconds. The opportunity to get your
    >>> Unix system into single-user mode is much like the opportunity to get a
    >>> machine into BIOS setup. It is reasonable for it to delay a bit so you
    >>> have a chance to catch it.

    >> I agree with the BIOS problem. It's aggravated with SCSI devices. Amazingly,
    >> it's eased by Linux BIOS's, which can be configured and don't spend ages
    >> scanning for non-existent and deprecated hardware: the OLPC project uses them.
    >>
    >> A delay is quite reasonable, I agree. But an additional line of text saying
    >> 'will boot in 60 seconds' wouldn't kill anyone to have written into the boot
    >> loader.

    >
    > Yeah, that's a long time deficiency of the OSR5 boot program.
    >
    >> Bela<


  19. Re: SCO 5.0.4/5 stops at boot: prompt on a fresh install in a VMwareworkstation

    The accounting program "Synchronics" at one of my customers leaves
    enough stuff open that it runs out of internal storage somewhere
    around 2 weeks. I have it rebooting at 1 AM every Sunday. The side
    benefit is having a record that it happened so the customer can't
    complain that the package failure is because it didn't reboot.

    I have taken the boot timeout down to 5 seconds on several machines
    but mostly take them to 15 seconds. Gives me a pretty fast turnaround
    at a vet clinic chain that is required to reboot every night by their
    software supplier.

  20. Re: SCO 5.0.4/5 stops at boot: prompt on a fresh install in a VMwareworkstation

    ed wrote:
    > The accounting program "Synchronics" at one of my customers leaves
    > enough stuff open that it runs out of internal storage somewhere
    > around 2 weeks. I have it rebooting at 1 AM every Sunday. The side
    > benefit is having a record that it happened so the customer can't
    > complain that the package failure is because it didn't reboot.
    >
    > I have taken the boot timeout down to 5 seconds on several machines
    > but mostly take them to 15 seconds. Gives me a pretty fast turnaround
    > at a vet clinic chain that is required to reboot every night by their
    > software supplier.


    You know.....

    If you're not requiring high performance, virtualized OS's boot amazingly fast
    because the virtual BIOS is fast. This could heavily optimize a SCO boot overall.

    I'm using VMware, successfully, right now for many reasons on SCO OpenServer
    5.0.6, and it works well.

+ Reply to Thread
Page 1 of 2 1 2 LastLast