Beginners FAQ:Troubleshooting (changes)

Showing changes from revision #10 to #11: Added | Removed | Changed

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 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+). It can also happen on a Pi 4 if you had previously used that SD card to boot a different model of Raspberry Pi.

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).

• On If the you Raspberry have a Pi 4, 3, click Pi on 4 “Network”, or click Pi on Zero “Internet”, W then click on “Interfaces” and choose wish to use WiFi instead of a wired Ethernet connection, follow the “Broadcom instructions atGENETGetting Connected Online ” . interface.
• On devices without an Ethernet port, click on “Network” then click on “Internet”. Untick the box labelled “Enable TCP /IP protocol suite”. 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.

Having If said you’re that, using some a models wireless of keyboard, standard-layout you keyboards may won’t want work to with try the tips listed inRISCIntermittent keyboard/mouse problems OS. below. 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, pointer check (and that the mouse is plugged in properly (with a wireless mouse, try fitting new batteries). If this fails, try pressing Ctrl-Break to reset the computer. computer If doesn’t clear the mouse fault), still isn’t working, try a the different following make/model steps: of mouse¹.

Intermittent keyboard/mouse problems

If Wireless you’re mice using (and keyboards) are susceptible to electromagnetic interference from badly-shielded USB3 ports/devices. This is ahardware issue, not a bug in RISC OS OS. 5.24 If or you are experiencing intermittent problems (e.g. mouse occasionally sluggish/unresponsive, some mouse clicks ignored, keys unexpectedly repeat) try the following steps:RISC OS 5.26 on a Raspberry Pi, you may run into problems if you mix USB1.1 devices (keyboard, mouse) with USB2 devices (e.g. memory sticks) on the built-in USB ports. Symptoms are that the USB1.1 devices misbehave (repeating/unresponsive keys, jerky pointer movement, “stuck” mouse buttons). Workaround is to connect the mouse (and keyboard) to an external USB hub instead of using the built-in ports.

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 ^{3 2}.
2. Press CTRL-BREAK to reset the machine.
3. Power off, then power on again.

^{3 2} 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 ^{4 3}, 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 and to blind-type get to the command line ^{5 4} and blind-type
  wimpmode 32
  and then pressRETURN twice. This should get you a full (if somewhat oddly-proportioned) desktop display, allowing you to reach Display Manager to set select the a screen resolution to something more to your liking.

^{4 3} 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.

^{5 4} 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).