Re: Re: hacking SCO....
This may be a dumb question, but if you make a cpio tape archive from data on an SCO system (HTFS filesystem), you can still restore the data off the tape to another system, like FreeBSD with a UFS filesystem, right? This should work. If you run into any issues they will be incompatibilities between SCO's cpio and the GNU cpio that FreeBSD uses. Sometimes you have to not use the option -c on the GNU cpio when extracting an archive created on SysV (somehow GNU cpio has a different idea about the -c format but if left out, it will figure it out well automatically). And the followup, can FreeBSD run SCO binaries (SCO Unix 5.0.1)? I am going to try and convert these people from their SCO box over to a FreeBSD system. Just want to make sure the data will come off the tape. Yes, but support is really limited. You need to copy a bunch of core libraries onto the FreeBSD machine from the SCO machine to make things work. (We just emulate the syscall interface -- you need libc and friends from SCO.) And if you want to stay out of lawsuits, you will also need a separate license from SCO for these libraries (something like $700). It's kind of stupid but the SCO lawyers believe that if you've bought these libraries as a part of OpenServer, you can't run them on any other OS. The product is called something like SVLL which stands for System V Libraries for Linux. -SB not working for SCO any more ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: hacking SCO....
This may be a dumb question, but if you make a cpio tape archive from data on an SCO system (HTFS filesystem), you can still restore the data off the tape to another system, like FreeBSD with a UFS filesystem, right? And the followup, can FreeBSD run SCO binaries (SCO Unix 5.0.1)? I am going to try and convert these people from their SCO box over to a FreeBSD system. Just want to make sure the data will come off the tape. -John On Oct 9, 2004, at 6:51 AM, Doug Russell wrote: On Fri, 8 Oct 2004, Sergey Babkin wrote: Try to use the Verify menu from the Adaptec BIOS. It finds and tries to re-map the bad sectors (it tries to preserve data during this too, unless the sector is completely unreadable). The verify commands issued by the BIOS are virtually useless compared to the type of tests done my sformat. If you enable automatic read re-allocation, it is almost the same as simply reading your whole disk with dd. I do the full 14 pattern tests before I put a SCSI disk in service. When a disk starts losing blocks like this, usually they only multiply over time. The best thing you can do is replace the disk and move the data before you lost more of it. NO! Not necessarily! If a disk has simply grown a few new defects since it was new, it does not necessarily mean it is going to die. I have many disks that had minor bad spots on them that weren't even always found by the factory format routines, or had appeared since (due to transport, debris in the HDA, poor holding power for the magnetic fields in some area, etc). If the drive passes through a few full patern tests without problems and doesn't continue to grow new defects, it is likely just fine. I've got all kinds of old SCSI disks that were 'discarded' due to errors. Only a couple are truly dead... the rest have been running for years with no problems after making a real grown defect list from the pattern tests. This is something I learned many many years ago when running my old Miniscribe 3650s on a Perstor high density controller. It formated the drives to 31 sectors per track instead of 17. Hard on the disks, and the media, but a good drive, after being properly tested, would run flawlessly for years being hammered 24/7 on BBS machines. Got 78 megs per drive instead of 42.whatever it was. :) Later.. Doug John Von Essen ([EMAIL PROTECTED]) President, Essenz Consulting (www.essenz.com) Phone: (800) 248-1736 Fax: (800) 852-3387 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: hacking SCO....
This may be a dumb question, but if you make a cpio tape archive from data on an SCO system (HTFS filesystem), you can still restore the data off the tape to another system, like FreeBSD with a UFS filesystem, right? This should work. If you run into any issues they will be incompatibilities between SCO's cpio and the GNU cpio that FreeBSD uses. And the followup, can FreeBSD run SCO binaries (SCO Unix 5.0.1)? I am going to try and convert these people from their SCO box over to a FreeBSD system. Just want to make sure the data will come off the tape. Yes, but support is really limited. You need to copy a bunch of core libraries onto the FreeBSD machine from the SCO machine to make things work. (We just emulate the syscall interface -- you need libc and friends from SCO.) Matt -John On Oct 9, 2004, at 6:51 AM, Doug Russell wrote: On Fri, 8 Oct 2004, Sergey Babkin wrote: Try to use the Verify menu from the Adaptec BIOS. It finds and tries to re-map the bad sectors (it tries to preserve data during this too, unless the sector is completely unreadable). The verify commands issued by the BIOS are virtually useless compared to the type of tests done my sformat. If you enable automatic read re-allocation, it is almost the same as simply reading your whole disk with dd. I do the full 14 pattern tests before I put a SCSI disk in service. When a disk starts losing blocks like this, usually they only multiply over time. The best thing you can do is replace the disk and move the data before you lost more of it. NO! Not necessarily! If a disk has simply grown a few new defects since it was new, it does not necessarily mean it is going to die. I have many disks that had minor bad spots on them that weren't even always found by the factory format routines, or had appeared since (due to transport, debris in the HDA, poor holding power for the magnetic fields in some area, etc). If the drive passes through a few full patern tests without problems and doesn't continue to grow new defects, it is likely just fine. I've got all kinds of old SCSI disks that were 'discarded' due to errors. Only a couple are truly dead... the rest have been running for years with no problems after making a real grown defect list from the pattern tests. This is something I learned many many years ago when running my old Miniscribe 3650s on a Perstor high density controller. It formated the drives to 31 sectors per track instead of 17. Hard on the disks, and the media, but a good drive, after being properly tested, would run flawlessly for years being hammered 24/7 on BBS machines. Got 78 megs per drive instead of 42.whatever it was. :) Later.. Doug John Von Essen ([EMAIL PROTECTED]) President, Essenz Consulting (www.essenz.com) Phone: (800) 248-1736 Fax: (800) 852-3387 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: hacking SCO....
On Fri, 8 Oct 2004, Sergey Babkin wrote: Try to use the Verify menu from the Adaptec BIOS. It finds and tries to re-map the bad sectors (it tries to preserve data during this too, unless the sector is completely unreadable). The verify commands issued by the BIOS are virtually useless compared to the type of tests done my sformat. If you enable automatic read re-allocation, it is almost the same as simply reading your whole disk with dd. I do the full 14 pattern tests before I put a SCSI disk in service. When a disk starts losing blocks like this, usually they only multiply over time. The best thing you can do is replace the disk and move the data before you lost more of it. NO! Not necessarily! If a disk has simply grown a few new defects since it was new, it does not necessarily mean it is going to die. I have many disks that had minor bad spots on them that weren't even always found by the factory format routines, or had appeared since (due to transport, debris in the HDA, poor holding power for the magnetic fields in some area, etc). If the drive passes through a few full patern tests without problems and doesn't continue to grow new defects, it is likely just fine. I've got all kinds of old SCSI disks that were 'discarded' due to errors. Only a couple are truly dead... the rest have been running for years with no problems after making a real grown defect list from the pattern tests. This is something I learned many many years ago when running my old Miniscribe 3650s on a Perstor high density controller. It formated the drives to 31 sectors per track instead of 17. Hard on the disks, and the media, but a good drive, after being properly tested, would run flawlessly for years being hammered 24/7 on BBS machines. Got 78 megs per drive instead of 42.whatever it was. :) Later.. Doug ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: hacking SCO....
I was able to use the badtrk utility in SCO to identify bad blocks and put them in the bad block table. The SCSI card is an old Adaptec, AIC-7880 and I believe it does not support automatic bad block detection/redirection. This disk came from a spares kits, so even though it is new and never used, it is still 5-6 years old. There were 6 bad blocks, once they were put in the bad block table, everything was fine. Is sformat the freebsd equivalent of the badtrk utility. I have always used Ultra2 LVD SCSI and higher on FreeBSD and have never had this issue of bad blocks. Is that because those newer SCSI disks and controllers have better ECC handling and take care of the bad blocks internally without notifying the user? -john On Oct 9, 2004, at 6:51 AM, Doug Russell wrote: On Fri, 8 Oct 2004, Sergey Babkin wrote: Try to use the Verify menu from the Adaptec BIOS. It finds and tries to re-map the bad sectors (it tries to preserve data during this too, unless the sector is completely unreadable). The verify commands issued by the BIOS are virtually useless compared to the type of tests done my sformat. If you enable automatic read re-allocation, it is almost the same as simply reading your whole disk with dd. I do the full 14 pattern tests before I put a SCSI disk in service. When a disk starts losing blocks like this, usually they only multiply over time. The best thing you can do is replace the disk and move the data before you lost more of it. NO! Not necessarily! If a disk has simply grown a few new defects since it was new, it does not necessarily mean it is going to die. I have many disks that had minor bad spots on them that weren't even always found by the factory format routines, or had appeared since (due to transport, debris in the HDA, poor holding power for the magnetic fields in some area, etc). If the drive passes through a few full patern tests without problems and doesn't continue to grow new defects, it is likely just fine. I've got all kinds of old SCSI disks that were 'discarded' due to errors. Only a couple are truly dead... the rest have been running for years with no problems after making a real grown defect list from the pattern tests. This is something I learned many many years ago when running my old Miniscribe 3650s on a Perstor high density controller. It formated the drives to 31 sectors per track instead of 17. Hard on the disks, and the media, but a good drive, after being properly tested, would run flawlessly for years being hammered 24/7 on BBS machines. Got 78 megs per drive instead of 42.whatever it was. :) Later.. Doug ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: hacking SCO....
On Sat, 9 Oct 2004, John Von Essen wrote: The SCSI card is an old Adaptec, AIC-7880 and I believe it does not support automatic bad block detection/redirection. If it has a BIOS it should have the verify tool in there... All the verify tool does, though, is issue a verify command to each sector. You can do this yourself, even on a running system, also. This disk came from a spares kits, so even though it is new and never used, it is still 5-6 years old. There were 6 bad blocks, once they were put in the bad block table, everything was fine. Exactly. Most of my SCSI disks are old spares, or old surplus disks. They've likely been moved several times, bumped around, and time itself can make a marginal section of the magnetic coating stop holding data perfectly. Is sformat the freebsd equivalent of the badtrk utility. I have always No, I don't believe so. I think badtrk is probably like the old bad144 system that was abandoned because it is unnecessary on all modern disks. All modern IDE disks have built-in re-allocation tables, similar to the way SCSI disks work, but you can't manipulate them manually as easily as you can on a SCSI disk. sformat is a handy formatting utility written by Joerg Schilling. It has special options for partitioning disks on SUN machines, but the format routines and defect scans will run on virtually any platform. It has full patern testing abilities. First it writes and verifies every byte on the drive as all 's then all 's... then 01010101 and 10101010, etc. etc... stressing the media in every possible combination. (Many, many, errors won't show up if you just write all zeros or ones, for example. It is much harder to store a zero next to a one, so trying every combination pre-tests anything that might be written.) This kind of testing is done at the factory, and limited pattern testing is generally done by the built-in low-level format routine on most drives. used Ultra2 LVD SCSI and higher on FreeBSD and have never had this issue of bad blocks. Is that because those newer SCSI disks and controllers have better ECC handling and take care of the bad blocks internally without notifying the user? If you play with the SCSI modepages, you can tell the drive to post an error or not under various conditions (a correctible ECC error, an uncorrectible error, a re-allocated block, etc.) You've probably never seen errors before because the drives were set with Automatic (Write / Read) Reallocation Enable (AWRE and ARRE) set in modepage 1. This disk you're working with now obviously has ARRE and probably AWRE disabled, so it isn't trying to re-allocate the blocks when it finds an error. I'd check that and turn it on. Then, the next time you try to read the bad block, the drive should remap it on its own. The exact behavior varies by drive and by settings in the modepages. Some drives may have AWRE and ARRE enabled, but not re-allocate a certain block because they can't get the data off the sector in the retry time allowed. Cranking up the retry timer (when available) might work, or else you have to do it manually by sending the re-allocate block command. I sure love SCSI disks... They let you do virtually ANYTHING to them if you know the technical details of how to send the commands. (The technical manuals for the disks are very handy in this regard.) On FreeBSD, you can see what was in the defect table at the factory by doing a camcontrol defects daX -f phys -P (I like phys, as it shows the actual physical head and cylinder number with a byte offset -- you can actually 'see' the areas that are defective). You can see the GROWN defect list (rather than the primary) with -G. VERY often the grown defects are simply the next sector or two to the sides of an existing defect. If a series of defects span several cylinders on the same head at about the same offset, it's probably a media defect 'scratch' across the disk. If it is on the same cylinder on several heads at about the same place, it is probably from a mini-head-crash due to the disk getting bumped, etc, where it actually damaged spots on several disks at once when the heads touched (or almost touched). etc. etc. Interestingly enough, the way sformat sends the block format commands, some disks add the new defects found to their PRIMARY defect list, instead of the GROWN list, as if they had been re-tested at the factory. There is a command to clear the GROWN list, but not the PRIMARY. (Some cheesy drives re-do their primary table when you send them the single low-level-format command, but most just add to the table. If you ever have LESS primary defects after sending a LLF command, it would be a VERY good idea to use sformat to better pattern test the drive before service) Here are some examples from a couple of disks here: Script started on Sat Oct 9 13:13:01 2004 ROOT mxb:/home/drussell 101 camcontrol defects da0 -f phys -P /* This is the PRIMARY
Re: hacking SCO....
Gotta love when you reply to your own posts... :)
On Sat, 9 Oct 2004, Doug Russell wrote:
If it has a BIOS it should have the verify tool in there...
All the verify tool does, though, is issue a verify command to each
sector. You can do this yourself, even on a running system, also.
I meant to add a couple more notes about the modepages
The number (or maximum time -- it's drive dependent) of retries for
regular reads and writes are adjustable in modepage 1.
There are alternate settings for the VERIFY commands (like sent to the
drive in the BIOS verify utility) on the VERIFY page (modepage 7).
Reading the docs for the actual drive in question is the only way you can
tell EXACTLY what is done by each setting, and it does take a little
research to understand exactly what is going on, but there are LOTS of
nice knobs to twiddle on most disks.
You might have to add some things to /usr/src/share/misc/scsi_modes
(on freebsd) to be able to edit all the possible options on some disks
using the editor routines. For example, I created the following entry for
Seagate disks like all my ST19171WC (about 60) and ST15150W drives (20+)
that actually understands things like the cache segmentation size (how
many little chunks of cache it should hold, and therefore how big each
is, which is a VERY nice tuneable for a heavy-multi-user server versus
single user A/V RAID array disk tuning; multi-user, you want lots of
little cache segments... streaming use, you want a couple of huge
segments):
0x08 Caching Page {
{IC (Initiator Control enable)} t1
{ABPF (ABort Pre-Fetch on selection)} t1
{CAP (Caching Analysis Permitted)} t1
{DISC (DISContinuity)} t1
{SIZE (cache segmentation by SIZE enable)} t1
{WCE (Write Cache Enable)} t1
{MF (prefetch Multiplication Factor)} t1
{RCD (Read Cache Disable)} t1
{Demand Retention Priority} t4
{Write Retention Priority} t4
{Disable Pre-fetch Transfer Length} i2
{Minimum Pre-fetch} i2
{Maximum Pre-fetch} i2
{Maximum Pre-fetch Ceiling} i2
{FSW (Force Sequential Write)} t1
{LBCSS (Logical Block Cache Segment Size)} t1
{DRA (Disable Read-Ahead)} t1
{Reserved} *t5
{Number of Cache Segments} i1
{Cache Segment Size} i2
{Reserved} *i1
{Non-Cache Segment Size} i3
I turn off all retries, etc, and set the drive to do full error reporting
before I run any tests. (You don't want the drive correcting anything
itself, you want to report EVERYTHING...)
Modepages are fun. :)
Later.. Doug
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: hacking SCO....
Doug Russell wrote: On Thu, 7 Oct 2004, John Von Essen wrote: Well, I eventually got this SCO system working. But today, some errors appeared: 505k:unrecover error reading SCSI disk on 0 Dev - 1/42 cha = 0 id = 0 1 on = 0 Block 6578 medium error unrecovered read error HTFS i/o failure occurred while trying to upgrade 1 node 26302 on HTFS. Dev hd 1/42 Error log over flow block 6578 medium error unrecovered read error . Do these sound likes hardware errors for the drive or the adaptec card Drive errors. Did you do a new low-level format before you put it in service? sformat is your friend. Try to use the Verify menu from the Adaptec BIOS. It finds and tries to re-map the bad sectors (it tries to preserve data during this too, unless the sector is completely unreadable). I do the full 14 pattern tests before I put a SCSI disk in service. When a disk starts losing blocks like this, usually they only multiply over time. The best thing you can do is replace the disk and move the data before you lost more of it. -SB ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: hacking SCO....
Well, I eventually got this SCO system working. But today, some errors appeared: 505k:unrecover error reading SCSI disk on 0 Dev 1/42 cha = 0 id = 0 1 on = 0 Block 6578 medium error unrecovered read error HTFS i/o failure occurred while trying to upgrade 1 node 26302 on HTFS. Dev hd 1/42 Error log over flow block 6578 medium error unrecovered read error . Do these sound likes hardware errors for the drive or the adaptec card itself? The drive is brand new (well, its actually a replacement from acer with a date code on it from 1998 so it has been sitting in a box for awhile). However, the card is very old too. Any ideas? -john On Sep 27, 2004, at 7:24 PM, Julian H. Stacey wrote: John Von Essen wrote: Unfortunately, I have inherited a Intel P200 with SCO OpenServer 5.0.4 with a 4Gb SCSI drive. Condolences ! SCO is Horrible to work on, a waste of time, erase ASAP ! SCO is of no help, they cant provide replacement boot floppy, only sell me complete distribution version 5.0.7 for $100. Any ideas on how I should go about this. All I need to do is get that data from the tape onto the disk and I should good to go. SCO is of no help, they cant provide replacement boot floppy, only sell me complete distribution version 5.0.7 for $100. SCO used to give away licences free for 5.0.4 /or 5.0.5 for restricted use. One could legally download cdrom images burn them. Good denough to rescue data then erase SCO install BSD If you can't rescue the data while running FreeBSD, either: Non Commercial solution: Look around find someone near who has a 5.0.4 or 5 cdrom, (maybe even SCO site somewhere) get a copy, (cdrom contains floppy images too I recall), rescue data, delete SCO very quickly from your machine, (before you discover the pain of running SCO, ( if you really must run SCO then Do get their Skunkware CDROM too (yes that's it's real name! it's full of FSF/GNU stuff free makes using SCO rather less unpleasant (not unpleasant, just rather less). Commercial solution. Pay the $100, if its for a commercial job it's cheap. No point quibbling. SCO used to cost about 2000 German Deutschmarks, for end users, ( was the Unix I found most crippled. BSD is cheaper, but if it's for business, it's their legal right, cheap enough. There's SCO forums somewhere, but probably the wrong route. Their manuals used to just present work-rounds for obsolete old software everyone else wasn't using anymore eg at one stage they were SVR3 all other vendors were SVR4 based. Last time I was contracted to work on SCO, I just kept tossing more modern source eg X11R6 lesstif GNU src/ on top of the base obsolete SCO, till obsolete SCO libraries no longer broke my project. Reading SCO manuals was a waste of time, better to just to rip it out replace it with better software, either per utility that annoys, or per whole OS. - Julian Stacey. Unix,C,Net Sys. Eng. Consultant, Munich. http://berklix.com Mail in Ascii, Html dumped as Spam. Ihr Rauch = mein allergischer Kopfschmerz. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: hacking SCO....
Well, I eventually got this SCO system working. But today, some errors appeared: 505k:unrecover error reading SCSI disk on 0 Dev 1/42 cha = 0 id = 0 1 on = 0 Block 6578 medium error unrecovered read error HTFS i/o failure occurred while trying to upgrade 1 node 26302 on HTFS. Dev hd 1/42 Error log over flow block 6578 medium error unrecovered read error . Do these sound likes hardware errors for the drive or the adaptec card itself? The drive is brand new (well, its actually a replacement from acer with a date code on it from 1998 so it has been sitting in a box for awhile). However, the card is very old too. Any ideas? -john medium error unrecorvered read error really sounds like a phsycial medium (drive) error. If the controller was flaky, you'd get bus retries and stuff. -- Matt Emmerton ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: hacking SCO....
On Thu, 7 Oct 2004, John Von Essen wrote: Well, I eventually got this SCO system working. But today, some errors appeared: 505k:unrecover error reading SCSI disk on 0 Dev 1/42 cha = 0 id = 0 1 on = 0 Block 6578 medium error unrecovered read error HTFS i/o failure occurred while trying to upgrade 1 node 26302 on HTFS. Dev hd 1/42 Error log over flow block 6578 medium error unrecovered read error . Do these sound likes hardware errors for the drive or the adaptec card Drive errors. Did you do a new low-level format before you put it in service? sformat is your friend. I do the full 14 pattern tests before I put a SCSI disk in service. Later.. Doug ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: hacking SCO....
John Von Essen wrote: Unfortunately, I have inherited a Intel P200 with SCO OpenServer 5.0.4 with a 4Gb SCSI drive. Condolences ! SCO is Horrible to work on, a waste of time, erase ASAP ! SCO is of no help, they cant provide replacement boot floppy, only sell me complete distribution version 5.0.7 for $100. Any ideas on how I should go about this. All I need to do is get that data from the tape onto the disk and I should good to go. SCO is of no help, they cant provide replacement boot floppy, only sell me complete distribution version 5.0.7 for $100. SCO used to give away licences free for 5.0.4 /or 5.0.5 for restricted use. One could legally download cdrom images burn them. Good denough to rescue data then erase SCO install BSD If you can't rescue the data while running FreeBSD, either: Non Commercial solution: Look around find someone near who has a 5.0.4 or 5 cdrom, (maybe even SCO site somewhere) get a copy, (cdrom contains floppy images too I recall), rescue data, delete SCO very quickly from your machine, (before you discover the pain of running SCO, ( if you really must run SCO then Do get their Skunkware CDROM too (yes that's it's real name! it's full of FSF/GNU stuff free makes using SCO rather less unpleasant (not unpleasant, just rather less). Commercial solution. Pay the $100, if its for a commercial job it's cheap. No point quibbling. SCO used to cost about 2000 German Deutschmarks, for end users, ( was the Unix I found most crippled. BSD is cheaper, but if it's for business, it's their legal right, cheap enough. There's SCO forums somewhere, but probably the wrong route. Their manuals used to just present work-rounds for obsolete old software everyone else wasn't using anymore eg at one stage they were SVR3 all other vendors were SVR4 based. Last time I was contracted to work on SCO, I just kept tossing more modern source eg X11R6 lesstif GNU src/ on top of the base obsolete SCO, till obsolete SCO libraries no longer broke my project. Reading SCO manuals was a waste of time, better to just to rip it out replace it with better software, either per utility that annoys, or per whole OS. - Julian Stacey. Unix,C,Net Sys. Eng. Consultant, Munich. http://berklix.com Mail in Ascii, Html dumped as Spam. Ihr Rauch = mein allergischer Kopfschmerz. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
hacking SCO....
Unfortunately, I have inherited a Intel P200 with SCO OpenServer 5.0.4 with a 4Gb SCSI drive. I have to get the machine back up and running. Here is my dilemma and progress: I have a cpio archive on DDS-2 tape that is valid. I have been able to extract files onto a test disk with FreeBSD. The current 4Gb SCSI disk has a hardware problem. Not sure of where, but roughly 120Mb into the desk it starts making noise of fails. I have a new replacement 4Gb disk. With a FreeBSD boot CD I did a dd and was able to get the new disk setup with all of the old disks partition maps, boot data, etc.,. The new disk actually boots into SCO but fails because it only has 100Mb or so of data. The problem is I do not have any SCI media. According to docs, if I had a boot floppy or emergency repair disk, I could boot with that, then mount the partition and cpio extract the data. I tried doing this with a freebsd boot cd, but could mount the SCO filesystem. In fdisk, it comes up as type 99, and I know the SCO is htfs. Does freebsd support any of this? Any ideas on how I should go about this. All I need to do is get that data from the tape onto the disk and I should good to go. SCO is of no help, they cant provide replacement boot floppy, only sell me complete distribution version 5.0.7 for $100. Thanks john ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: hacking SCO....
On Mon, 27 Sep 2004, John Von Essen wrote: I have a new replacement 4Gb disk. With a FreeBSD boot CD I did a dd and was able to get the new disk setup with all of the old disks partition maps, boot data, etc.,. The new disk actually boots into SCO but fails because it only has 100Mb or so of data. Try addingconv=sync,noerrorto your dd line. If most of the data after the defect(s) can be read, you'll end up with an almost complete partition which will likely run. You can then fsck and restore from tape. for example, dd if=/dev/daX of=/dev/daY conv=sync,noerror bs=128k Later.. Doug ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: hacking SCO....
Oh, I love replying to my own posts :) On Mon, 27 Sep 2004, Doug Russell wrote: Try addingconv=sync,noerrorto your dd line. If most of the data after the defect(s) can be read, you'll end up with an almost complete partition which will likely run. You can then fsck and restore from tape. for example, dd if=/dev/daX of=/dev/daY conv=sync,noerror bs=128k Actually, remove the bs=128k from above (force of habit). When you're trying to recover a disk like this, you want the block size to be single sectors (bs=512, the default) so you get every sector that is readable. It's slower, but it'll get you a more complete copy if it only skips 1 sector on an error instead of 256. :) If you know the defects are only in a certain range, you can get creative with the skip directives to dd and copy most of the disk in larger blocks, and go back and do the bad part one sector at a time (very handy when recovering today's large IDE disks). See the dd(1) manpage for more info. Later.. Doug ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: hacking SCO....
Well, I was able to get a boot/install floppy made. Then install a fresh SCO. Then create recovery floppies, then boot with recovery floppy and try to cpio tape data to /mnt. However, in both the recover floppy and the real SCO system I have to configure the tape drive apparently. As of right now, I can not access the tape device. SCO's tape device builder asks what type of tape, is a DDS-2 considered DAT or 8mm? Anyway, I wish I would of thought of the dd args to skip the bad sectors and continue on. Now that SCO is installed (which took an hour and a half) I would hate to start over. The drive is really messed up, dd would copy a couple thousand records, then the drive would start making a horrendous noise and through an IO error stopping dd. You have no idea how much I hate SCO. I feel like I am cheating on my girlfriend every time I login to this damn box. -john On Sep 27, 2004, at 4:15 PM, Doug Russell wrote: On Mon, 27 Sep 2004, John Von Essen wrote: I have a new replacement 4Gb disk. With a FreeBSD boot CD I did a dd and was able to get the new disk setup with all of the old disks partition maps, boot data, etc.,. The new disk actually boots into SCO but fails because it only has 100Mb or so of data. Try addingconv=sync,noerrorto your dd line. If most of the data after the defect(s) can be read, you'll end up with an almost complete partition which will likely run. You can then fsck and restore from tape. for example, dd if=/dev/daX of=/dev/daY conv=sync,noerror bs=128k Later.. Doug ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: hacking SCO....
I believe DAT is what you want to tell SCO. -- Matt - Original Message - From: John Von Essen [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, September 27, 2004 6:33 PM Subject: Re: hacking SCO Well, I was able to get a boot/install floppy made. Then install a fresh SCO. Then create recovery floppies, then boot with recovery floppy and try to cpio tape data to /mnt. However, in both the recover floppy and the real SCO system I have to configure the tape drive apparently. As of right now, I can not access the tape device. SCO's tape device builder asks what type of tape, is a DDS-2 considered DAT or 8mm? Anyway, I wish I would of thought of the dd args to skip the bad sectors and continue on. Now that SCO is installed (which took an hour and a half) I would hate to start over. The drive is really messed up, dd would copy a couple thousand records, then the drive would start making a horrendous noise and through an IO error stopping dd. You have no idea how much I hate SCO. I feel like I am cheating on my girlfriend every time I login to this damn box. -john On Sep 27, 2004, at 4:15 PM, Doug Russell wrote: On Mon, 27 Sep 2004, John Von Essen wrote: I have a new replacement 4Gb disk. With a FreeBSD boot CD I did a dd and was able to get the new disk setup with all of the old disks partition maps, boot data, etc.,. The new disk actually boots into SCO but fails because it only has 100Mb or so of data. Try addingconv=sync,noerrorto your dd line. If most of the data after the defect(s) can be read, you'll end up with an almost complete partition which will likely run. You can then fsck and restore from tape. for example, dd if=/dev/daX of=/dev/daY conv=sync,noerror bs=128k Later.. Doug ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
