Software install did not work - help

[Mark Bellon]

I have a 1000x600HDMI touch screen and USB mouse and keyboard attached to a RP 4.

I installed the latest 64-bit image. It booted and ran fine. I set it up to auto login to the command line and that works fine too.

I followed the option 2 instuctions, even trying the methods presented in different videos and always land up with the same result. All the software installed work fine. Yes, I did the symbolic link from version 8 to 7 of the one library.

After the final step I do a reboot and land up at the command line, not the PDP-11 simh data. What I see before the command line comes up is the pdp.sh script run automatically and output a "0".

What am I missing? All of the videos show it PDP-11 simh output upon reboot.

HELP!

mark

 

[Clem Cole]

If you have a display on the PI, then make sure X11 or Wayland is starting [I find fewer issues with X11 - so you may want to use the "advanced Options" in raspi-config to set which window manager].

But assuming you're running a window manager, create a terminal window and then type: sudo screen -D -r

This will put you inside the simh session's console and leave you typing whatever system you booted.

If, for instance, you started a traditional V7 session using the pidp11 switchers, then the next thing to type after you get to the simh console from the screen command is:  boot<cr>

Which will load the V7 standard lone system and leave you at a colon : prompt.   To actually load V7 unix from it, type: hp(0,0)unix<cr>

Which completes the boot sequence for V7 and leave you at the single user: # prompt 

To that type ^D and V7 will enter multi-user mode and you will get a login prompt.

This is because the boot.ini file that Oscar distributes only loads UNIX boot block, which is now awaiting to you to tell the simh PDP-11 instance to load the V7 Standalone system - i.e., boot<cr>

Note the bootblock does not give you a prompt - it just waits for input from the PDP-11 console.  But after the standalone system is memory, it will prompt with the its : prompt.

When you get the octothorpe prompt (i.e., # ) V7 is now what is running, but not yet multiuser.  Sending the ^D to the single user console shell, terminates it which tells process 1 (a.k.a., /etc/init - the parent process of everything)  to start forking off the login/getty prompts per the rules in the UNIX documentation.

Note that some people (like me) have used the expect/send sequence handler in simh to automate that so when you reboot the RPI, and it starts up the background PDP-11 simh instance, to go all the way to the multi-user prompt.  Which I can offer to anyone who might be interested (pls email off list)..

Note: I believe that Oscar's default boot.ini file for the V7, system includes theses lines also.

set dci enable
set dci lines=8
att dci 2323

Assuming that I remember that correctly (as I said my boot.ini is not the default one), you can also type: telnet localhost 2323 from another terminal window on the RPI, and you should see a standard Unix login prompt there also.

FWIW: particularly if you are new to any of the ancient Unix flavors, there is no "sudo" command by default, which you may have seen with macOS or Linux.  Logging in and running as root is dangerous (which is why priv(1) and sudo(1) were created back in the day). So the first time you log into the system as root, I strongly recommend that you immediately create a mortal user for yourself, then log out of root and log back in as the mortal.  If you are not familiar with how to create a mortal user on any of these old Unices, feel free to send me an email off-list, and I will try to work with you.

Good luck,

Clem

--
You received this message because you are subscribed to the Google Groups "[PiDP-11]" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pidp-11+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/pidp-11/785ce0a4-80a7-4952-a42c-812b7268f864n%40googlegroups.com.

[Bert Driehuis]

The pdp.sh script returning just "0" means that it did not find a screen(1) session that runs the simulator. I've seen a number of scenarios that might cause this:

One is starting the screen session from a startup script during boot, in which case the simulator will run as root and be invisible to the "pi" user.

Another is when simh and/or the pidp1170_blinkenlightd are built against libtirpc, and /etc/services does not contain "sunrpc" (this is the case on piCore, it causes client and server processes to not communicate).

Another is the startup script keeling over for different reasons. Look around using ps(1) if you see simh, pidp1170_blinkenlightd, server11 and/or client11 processes around, and try to deduce what could be up from there.

With kind regards,

Bert Driehuis

--