pgd@bbt.se (P.Garbha) (07/19/90)
Yesterday i got my upgrade (new version) of xenix. It seems like it does not give you any easy way of upgrading -- you have to reinstall. But i thought that i could handle it anyway. So i just copied over all the new system files, unto the old (running) version of xenix, installed the new link kit, re-linked the kernel, and thought that that was it. Now what happend was that Xenix suddenly was unbootable. I could not even boot the old kernel any more. They all gave variations of error messages, one of: *) Bad magic number, and returning the the boot prompt *) Illegal segment 32767, (or something), and return to the boot prompt *) bn 1, bn 2, .... bn256, and blank screen and cold reboot Note, there is NOTHING wrong with the kernel files, since one of the errors come, even if i copy a kernel from an old, bootable, "emergency boot" floppy. Fortunately i managed to boot one version of the kernel. Not the old one, but one that was mistakenly generated when i installed my multiple-port serial board. It gave messages like "bn 1, bn 2, ... bn 127", but it booted. After that i just had to surrender, copy the whole system with tar to a set of backup tapes, install the new version the "real" way, and copy back the tapes. Now it works again. My suspicion is that this trouble all comes from serialization. My old version of xenix had a different serial number than the new one, and somehow or another it detects that the file system was installed with another serial number, and therefore did not work. I still get one "bn 2" (or something) message at boot time, and would very much like to know what it means. (After this i fell a string itch in my fingers, to hack away the serialization code from the kernel. It for sure does not give me anything but trouble.)
rogerk@sco.COM (Roger Knopf 5502) (07/21/90)
In article <1990Jul19.101125.245@bbt.se> pgd@bbt.se (P.Garbha) writes: [various symptoms deleted] I agree with Ross, it sounds like your Xenix partition extends beyond 1024 cylinders. Since there is no standard way of handling >1024 cylinders in the BIOS (some do, some don't), and our boot code uses the BIOS, when either /boot (I suspect in this case) or /xenix ends up all or partly on cylinders >1024, things will behave very oddly when booting. The high-order bits of the cylinder number are essentially masked off so you are reading /boot from somewhere other than where it _really_ resides. Most controllers and disks that have >1024 cylinders have a format option that will remap the disk to less cylinders, more heads and sectors. I suggest you either look into that option (for long term satisfaction). Making sure that /boot and /xenix are within 1024 cylinders can only (easily) be guaranteed by making your root file system within the first 1024 cylinders of the hard disk. >After that i just had to surrender, copy the whole system with tar to >a set of backup tapes, install the new version the "real" way, and >copy back the tapes. Now it works again. > >My suspicion is that this trouble all comes from serialization. My >old version of xenix had a different serial number than the new one, >and somehow or another it detects that the file system was installed >with another serial number, and therefore did not work. Actually, this has nothing to do with serialization and we do not do anything like write the serial number on the file system. -- Roger Knopf <standard disclaimer applies> SCO Consulting Services "The True Believers will...formulate uunet!sco!rogerk or rogerk@sco.com a message that even a monkey could 408-425-7222 (voice) 408-458-4227 (fax) understand." --Jeff Tye
pgd@bbt.se (P.Garbha) (07/21/90)
In article <8227@scorn.sco.COM> rogerk@sco.COM (Roger Knopf 5502) writes: > >I agree with Ross, it sounds like your Xenix partition extends >beyond 1024 cylinders. Since there is no standard way of handling My root Xenix partition does extend beyond 1024 cylinders, and your explanation is probably completely right. The solution is just seeing to that /xenix (and /boot) always fit within the first 1024 cylinders. >Actually, this has nothing to do with serialization and we do not >do anything like write the serial number on the file system. Good, that my suspicion was wrong. It is also nice to hear that the serial number is not written to the file system. (Although i still wonder how it enters into the kernel after a re-link.)
rogerk@sco.COM (Roger Knopf 5502) (07/25/90)
In article <1990Jul21.103829.12316@bbt.se> pgd@bbt.se (P.Garbha) writes: > >It is also nice to hear that the serial number is not written to the >file system. (Although i still wonder how it enters into the kernel >after a re-link.) Easy: we brand not only the kernel but the OS library as well (libos.a for Xenix, I forget what it is on Unix). Since it has to be included when the kernel is relinked, the new kernel is always branded and the user is spared the necessity of rebranding it. Files to be serialized are listed in the perm lists (/etc/perms/*) on a line that starts: #ser= -- Roger Knopf <standard disclaimer applies> SCO Consulting Services "The True Believers will...formulate uunet!sco!rogerk or rogerk@sco.com a message that even a monkey could 408-425-7222 (voice) 408-458-4227 (fax) understand." --Jeff Tye
jim@applix.com (Jim Morton) (07/25/90)
In article <1990Jul21.103829.12316@bbt.se>, pgd@bbt.se (P.Garbha) writes: > It is also nice to hear that the serial number is not written to the > file system. (Although i still wonder how it enters into the kernel > after a re-link.) Simple - one of the kernel libraries, /usr/sys/mdep/libmdep.a gets "branded" when you install the LINK kit, and so the serialization gets linked into the kernel on every kernel build... Do a "grep '#ser' /etc/perms/*" to see other things that get serialized. -- Jim Morton, APPLiX Inc., Westboro, MA ...uunet!applix!jim jim@applix.com