Howdy -
> From: Christian Groessler <cpg(a)aladdin.de>
> I just last week installed v6 from tape image. I have to admit, I like
> working boot images more :-) (Since I only have an emulator and not
An emualtor of course would use an emulated tape image ;) That's
how I typically install. There are instructions and sources to
the program to create the 'virtual tape' from the dump and tar files.
> the real thing, I don't have the need to physically transfer the stuff.)
I keep forgetting that not everyone has a SCSI<->Qbus adaptor :)
(it was _expensive_ at the time but gosh, after 10 years the initial
$ pain is long long gone and I've gotten a lot of use out of it)
> Hmm, I just did this now, but I have to admit, I only browsed the
> instructions of most of them. I followed the instructions of 412/413
> because I feared I'd forget to update init before rebooting the new kernel.
Yes, screwing up 'init' is, to put it mildly, catastrophic. During
the development and testing of that set of updates I did render my
system unbootable. Thankfully I had a spare OS installed on the
SCSI Zip drive - I just booted from "DU 1" and put back a working
'init' (turns out that a 100MB Zip disk can contain a *full* 2.11BSD
system - not a lot of space left, but it includes all sources and
will boot).
> But otherwise I applied all patches to 442, and then rebuilt the
> kernel, rebooted, and did "make build; make installsrc". Seemed to work.
That's fantastic to hear!
> I noticed 2 patches, which patched /usr/src/sys/GENERIC/Makefile, but
> this is a generated file I think. At least it wasn't present, because
Yes and No. YES - it is generated by running './config' in /sys/conf.
NO - it's an integral part of the OS as distributed.
> I removed /usr/src/sys/GENERIC.
You really didn't want to do that ;)
The Make* files for custom kernels will (100% guaranteed) diverge
from the defaults. That's expected. The GENERIC kernel is a special
case though. When changes are made to the Make* files (overlay sizes
change for example) the patches will not attempt to find and "fix"
any locally created kernels - but the guarantee has always been that
the GENERIC kernel _will_ build, thus the patches presume that the
/sys/GENERIC directory hasn't been removed. Indeed the kernel patches
usually suggest rebuilding GENERIC.
It is a Good Idea (saved my system a couple times) to keep a known
good working _non_networking kernel (i.e. GENERIC) in /genunix. That
way if you are tinkering around (or a bad patch ends up in /unix) you
have something to boot. Many is the time (during development, testing
of course) that I've had to rely on a /genunix to get the system
back alive.
Glad to hear you're current and are not seeing 'df' weirdness. You
may want to upgrade P11 to 2.9 though - that would, I think, have
fixed that problem before you saw it ;)
Cheers,
Steven Schultz
sms(a)2bsd.com
Hi,
On 02/28/2002 08:53:34 AM PST "Steven M. Schultz" wrote:
>
>> From: Christian Groessler <cpg(a)aladdin.de>
>> > Look at the /VERSION file. The first or second line will have
>> > the patchlevel. That file's updated by each patch.
>>
>> I have 400. I assume www.2bsd.com contains the newest patches? So 442
>> is the latest?
>
> It _might_ be easier to create an install tape from the files in
> the 2.11 portion of the PUPS archive - I think that was updated
> to about patchlevel 432 or so. There is documentation on how to
> create a boot tape, etc from the compressed files.
I just last week installed v6 from tape image. I have to admit, I like
working boot images more :-) (Since I only have an emulator and not
the real thing, I don't have the need to physically transfer the
stuff.)
> On the other hand it might be instructive/interesting/whatever to
> apply the 42 updates manually - just be sure to read the instructions
> that come with each one :)
Hmm, I just did this now, but I have to admit, I only browsed the
instructions of most of them. I followed the instructions of 412/413
because I feared I'd forget to update init before rebooting the new
kernel.
But otherwise I applied all patches to 442, and then rebuilt the
kernel, rebooted, and did "make build; make installsrc". Seemed to
work.
I noticed 2 patches, which patched /usr/src/sys/GENERIC/Makefile, but
this is a generated file I think. At least it wasn't present, because
I removed /usr/src/sys/GENERIC.
regards,
chris
> From: Nutech <repro(a)nutechgroup.net>
> To: pups(a)minnie.tuhs.org
> Subject: [pups] PDP 11
> Date: Sun, 24 Feb 2002 01:27:40 +0530
>
> I post this message with hope that someone out there can help me with a
> problem I have at hand.
>
> My company recently bought a preowned printing machine, which uses a
> PDP11/73 BA23
> connected to a VT240 terminal to control the functions of the machine.
> Needless to say that we are unable to make the PDP run since we have no
> knowledge of the machine and have no one to look upto for guidance..
>
> While we are able to power on the PDP, the VT240 is dead.
Problems like this are much more easily solved in person than by email
correspondence. Why not tell everyone where you are physically located,
and perhaps someone nearby can help.
The VT240 could be replaced by any of several terminals, or even by a PC
running a terminal emulation program.
carl
carl lowenstein marine physical lab u.c. san diego
clowenstein(a)ucsd.edu
This must be a FAQ but I couldn't find the answer anywhere.
I have some 2.11BSD disk images that I want to copy large files onto on a
NetBSD box. Can someone please point me to a tool that can do it?
These are disk images that I use with p11. For various reasons, using p11
simulated tape drive isn't an option. I use kermit to inject small files into
the running p11 + 2.11BSD. It takes many minutes to 300KB. It takes much,
much more time to copy 12MB.
David Talmage
Hi -
> From: Christian Groessler <cpg(a)aladdin.de>
> > Look at the /VERSION file. The first or second line will have
> > the patchlevel. That file's updated by each patch.
>
> I have 400. I assume www.2bsd.com contains the newest patches? So 442
> is the latest?
Wow, that is quite old.
A faster link is at FTP.TO.GD-ES.COM (that's a T-1 vs the ISDL
link I have at home).
It _might_ be easier to create an install tape from the files in
the 2.11 portion of the PUPS archive - I think that was updated
to about patchlevel 432 or so. There is documentation on how to
create a boot tape, etc from the compressed files.
On the other hand it might be instructive/interesting/whatever to
apply the 42 updates manually - just be sure to read the instructions
that come with each one :)
Cheers,
Steven
Warren,
Does the archive contain any Venix images that are not in "tdo" format? I
have been unsuccessful in creating the floppies using that method. If I
could get an image from "dd", I could use my VAX or PDP to create images for
my Pro-380.
Thanks,
-Steve Davidson
Hi,
On 02/27/2002 03:25:22 PM PST "Steven M. Schultz" wrote:
>
>Hello again -
>
>> From: Christian Groessler <cpg(a)aladdin.de>
>> Regarding the patchlevels, how do I find out which patchlevel my
>> system is at?
>
> Look at the /VERSION file. The first or second line will have
> the patchlevel. That file's updated by each patch.
I have 400. I assume www.2bsd.com contains the newest patches? So 442
is the latest?
regards,
chris
Hello again -
> From: Christian Groessler <cpg(a)aladdin.de>
> > Mmmm, I wonder if the problems you were having were caused by
> > /dev not being correctly populated.
>
> Maybe. I noticed they're missing and recreated them by hand. Perhaps I
> made a mistake there.
It would be easy enough to do - or perhaps a critical one was
left out. Filesystems without device nodes can be moved
with a 'tar' pipeline but the root filesystem is special.
> It's a problem of the p11 emulator I use. I got a patch off-list which
> fixed it. It was some signed/unsigned thing.
Ah ha!
> Regarding the patchlevels, how do I find out which patchlevel my
> system is at?
Look at the /VERSION file. The first or second line will have
the patchlevel. That file's updated by each patch.
Cheers,
Steven
Hi,
On 02/26/2002 03:29:07 PM PST "Steven M. Schultz" wrote:
>
> Mmmm, I wonder if the problems you were having were caused by
> /dev not being correctly populated.
Maybe. I noticed they're missing and recreated them by hand. Perhaps I
made a mistake there.
>> $ df
>> Filesystem 1K-blocks Used Avail Capacity Mounted on
>> /dev/xp0a 7816 2658 5158 04% /
>> /dev/xp0g 151625 117599 34026 08% /usr
>> $
>>
>> Btw, the capacity values look a bit strange?
>
> Yes, they do look (more than a little bit) strange.
>
> On my system here (a P11 based emulated PDP-11 - I have a real 11/73
> but it is only powered up when I'm actively testing):
>
>Filesystem 1K-blocks Used Avail Capacity Mounted on
>/dev/xp0a 8228 3163 5065 38% /
>/dev/xp0h 155328 84188 71140 54% /usr
>
> What patchlevel did you mention the system was at? There were a lot
> of patches issued after the ' 2.11_rp_unknown' image was created.
> One thing, which probably will not make any difference, to try would
> be to recompile 'df' (and possibly 'libc') and see if the problem
> changes. Looks like it's a math error of some kind so either
> the compiler/libraries are broken or P11's having a problem doing
> arithmetic.
It's a problem of the p11 emulator I use. I got a patch off-list which
fixed it. It was some signed/unsigned thing.
Regarding the patchlevels, how do I find out which patchlevel my
system is at?
regards,
chris
I've uploaded version 0.0.2 of "v7upgrade" to my Web site:
http://www.southern-storm.com.au/v7upgrade.html
It is now possible to run a stripped-down v7 userland
environment on top of a Linux/i386 kernel, using the
v7 Bourne shell.
A good chunk of the "shellutils" programs have now been
upgraded, including all of your usual favourites (cat, chmod,
cp, date, dd, diff, echo, kill, ls, mkdir, mv, od, rm, rmdir,
among others).
Getting the Bourne shell to work on top of Linux was quite
the adventure, to say the least. S.R. did some very naughty
things in that code. :-)
The code also compiles cleanly for the bcc/8086 target,
although I don't yet have a v7 kernel to run it on yet.
Cheers,
Rhys.
