Beginners FAQ:Troubleshooting

This page gives you a few things to try if you find yourself stuck.

Please note: This page makes frequent reference to the BREAK key. On some keyboards, the BREAK key is marked PAUSE. If your keyboard has neither key, see The Break key for how to configure another key as BREAK.

Boot-up (or shutdown) problems

System unexpectedly boots to command line

This can happen for several reasons. A few examples:

• You pressed Shift-Break (or were holding down the Shift key as the system booted).
• The system couldn’t find the !Boot directory (e.g. it has been moved or deleted).
• You have installed !Boot on a USB-attached disc drive but are now booting up with yet another disc drive or memory stick attached via USB.
  Fix: Unplug any additional USB drives and reboot.
• The “NoBoot” configuration option has been set, or one of the other configuration options (e.g. “FileSystem” or “SCSIFSDrive”) now have incorrect values. Use the *Status command to display the CMOS RAM settings. If necessary, use the *LoadCMOS command to load a known-good CMOS settings file (if you have a Raspberry Pi, see CMOS RAM on the Raspberry Pi).
• The drive containing the !Boot directory isn’t marked as “bootable” (i.e. issuing *Cat on the drive produces the text “Option 00 (Off)” in its first line of output).
  Fix: Set the drive’s boot option by means of the *Opt 4,2 command. For example, on a machine with a USB-connected hard disc as drive 5, you might use:
  *SCSI
*Drive 5
*Opt 4,2
  A call to *Cat should now have “Option 02 (Run)” in its first line of output.

Boot-up stops with an error message

• “Drive not ready”
  Something inside !Boot is trying to access a file on another disc. The most likely reason is that the file is on a FAT32-formatted drive but it appears so early in the boot sequence that Fat32FS (needed to access FAT32-format drives) has not been loaded yet.
• “Program is not 32-bit compatible”
  Something recently added to !Boot was designed for use on RISC OS 3, not RISC OS 5. You will need to track down the failing component and remove it.
• “Waiting for boot drive to be ready”
  This is a special case of “Drive not ready” – it indicates that the system cannot get to !Boot itself. If you have a Raspberry Pi, you can sometimes fix this by using the boot_delay parameter in config.txt – see config.txt (Raspberry Pi). It may also indicate that you have additional disc drives connected (see next bullet point).
• System complains File not found on about 50% of reboots
  This can happen if you have multiple disc drives attached and the file in question is being referenced by drive number, not disc name. The problem is that disc drives won’t necessarily start up in the same order, so a given drive may not always get the same drive number.
  It is also a good idea to unplug other things (e.g. USB memory sticks, USB card readers) that might be mistaken for a disc drive at boot time.

Boot-up stalls at “Contacting DHCP server”

Boot-up can pause for 10-20 seconds when contacting the DHCP server: this is perfectly normal. A longer pause may indicate a network problem (e.g. Ethernet cable disconnected) but RISC OS should proceed to the desktop after 30-40 seconds.

If it stays stuck at that message, the most likely problem is that RISC OS has not detected an Ethernet interface. This can happen if you are using a device that doesn’t have one fitted (e.g. a Raspberry Pi Zero or Raspberry Pi 3A+).

Remedial action: Press the ESC key on the keyboard. This should take you to a desktop error box with “Cancel” and “Retry” buttons: click on “Cancel” to reach the desktop. If you find yourself at the command line, type *desktop to enter the desktop.

Once at the desktop, enter the configuration utility (e.g. by double-clicking on !Boot).

• If you have a Pi 3, Pi 4 or Pi Zero W and wish to use WiFi instead of a wired Ethernet connection, follow the instructions at Getting Connected Online.
• On devices without an Ethernet port, click on “Network” then click on “Internet”. Untick the box labelled “Enable TCP/IP protocol suite”, click on “Close” then click on “Save”. This will disable networking.

Problems at shutdown/reboot

• Shutdown hangs when a FAT32 drive is connected
  A bug in Fat32FS can cause a system lockup if you try to shut down with a FAT32 drive (e.g. a USB memory stick) still connected. The workaround is to dismount the drive before shutting down.

Mouse / keyboard issues

Some keys on keyboard won’t work

RISC OS is expecting a standard (105-key) keyboard. Keys over and above the standard set (e.g. multimedia keys) may not work, and other features like “intelligent touch strips” are right out.

If you’re using a wireless keyboard, you may want to try the tips listed in Intermittent keyboard/mouse problems below.

Also note that some standard-layout keyboards can be problematic (e.g. back-lit keyboards may draw too much current from the USB port). If you are having problems with a keyboard, try a different make/model of keyboard.

Pointer won’t move

If moving the mouse does not move the pointer (and pressing Ctrl-Break to reset the computer doesn’t clear the fault), try the following steps:

• Check that the mouse (or its receiver/dongle) is plugged in properly.
• If using a wireless mouse, try a fresh set of batteries.

You may also want to try the tips listed in Intermittent keyboard/mouse problems below.

Intermittent keyboard/mouse problems

Wireless mice (and keyboards) are susceptible to electromagnetic interference from badly-shielded USB3 ports/devices. This is a hardware issue, not a bug in RISC OS. If you are experiencing intermittent problems (e.g. mouse occasionally sluggish/unresponsive, some mouse clicks ignored, keys unexpectedly repeat) try the following steps:

• If you’re using a Pi 4, plug the receiver/dongle into a USB2 port (black connector) on the Pi. Using a USB3 port (blue connector) has been known to cause problems.
• Try using a shielded USB extension cable¹ to connect to the USB2 port, so that the receiver/dongle can be positioned closer to the keyboard/mouse.
• Some badly-shielded USB3 devices (e.g. external disc drives) can cause problems. Try positioning any such devices further away from the mouse/keyboard.

¹ Ironically, a USB3 extension cable is preferred (as it is likely to have better shielding than a USB2 extension cable).

Keyboard not responding / Mouse clicks ignored

If nothing happens when you press keys on the keyboard and/or click a mouse button (but the mouse pointer still moves) this may indicate that an application is misbehaving. Try each of the following in turn:

1. Press ALT-BREAK and quit the first-named application².
2. Press CTRL-BREAK to reset the machine.
3. Power off, then power on again.

² If you successfully use ALT-BREAK to quit the application, the system could still be unstable. Save as much work as you can, then shut down and restart.

Other problems

Computer “forgets” its configuration

You may discover that certain configuration settings are no longer as you set them (e.g. the Filer display format is different, the screen saver is unexpectedly active/inactive, or perhaps the CD-ROM drive has disappeared from the icon bar). These, and other problems, can happen if CMOS RAM contents have been lost or overwritten.

Possible reasons:

• The backup battery needs replacing (Risc PC, Iyonix etc.)
• The file !Boot.Loader.CMOS is damaged or missing (Raspberry Pi).
• A wayward application has overwritten CMOS RAM settings.
• You may have double-clicked on a “CMOS” file of unknown provenance, which has overwritten your chosen configuration settings.

The first thing to try is to restore your CMOS RAM settings. You can do this as follows:

• Click Menu over the Configuration window and choose CMOS > Load
• Alternatively, double-click on a known-good CMOS file
• If you’re stuck at the command line, use the *LoadCMOS command

After restoring the settings, check that they survive a power off / power on cycle. If there is still a problem, it may indicate that the backup battery needs replacing. Alternatively, if you have a Raspberry Pi, see CMOS RAM on the Raspberry Pi.

If you hadn’t saved your CMOS settings, reset them to factory defaults by doing a Delete power-on (i.e. hold down the Delete key while powering on the computer).

Game has crashed in a wonky mode

It is possible for an application (usually a game) to change the screen resolution such that when you return to the desktop the icon bar isn’t visible at all³, so you can’t get to Display Manager to change the screen resolution to something more sensible.

The easy fix is to press CTRL-BREAK to reboot, but you may not want to do that (e.g. you have unsaved work). In that case, proceed as follows:

• Press F12 to get to the command line⁴ and blind-type
  wimpmode 32
  then press RETURN twice. This should get you a full (if somewhat oddly-proportioned) desktop display, allowing you to reach Display Manager to select a screen resolution more to your liking.

³ For example, an “HD Ready” monitor may claim to support 1920×1080 but its maximum resolution is actually 1680×1050 so it “cheats” and displays only part of the picture.

⁴ You probably won’t see a command prompt, but you might notice the desktop display shift upwards slightly.

No picture / Monitor reports “Out of range”

This will typically happen if you’ve somehow managed to select a RISC OS monitor type that is unsuitable for your monitor.

• First get to a screen mode that the monitor can display. You might use CTRL-BREAK to reboot the machine, or you can press F12 and blind-type wimpmode 32 – as mentioned above
• Having got yourself to a desktop (of sorts) you can now use !Configure to set the monitor type to “Auto(your-monitor-name-here)” (e.g. “Auto(L225W)”) and the screen resolution to “Native”.

Files copied to a USB drive are incomplete (or missing)

This could be for one of two reasons:

• You didn’t dismount the drive and/or you didn’t wait the regulation 10-15 seconds before disconnecting.
• On a Raspberry Pi, you plugged your device into one of the built-in USB ports, overloading the Pi’s PSU and causing a voltage drop which interfered with the operation of the drive. This can be avoided by plugging the USB drive into a powered USB hub (i.e. a hub with its own power brick).