Beginners FAQ:Troubleshooting (Rev #6)

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

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

What may happen is that the RISC OS logo appears during the boot, but instead of the desktop you get 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.

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 said that, some models of “standard layout” keyboards won’t work with RISC OS. 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, check 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. If the mouse still isn’t working, try a different make/model of mouse¹.

¹ Some models of mouse won’t work with RISC OS. In general, a standard 3-button mouse is more likely to work than a 7-button “gaming” mouse.

Intermittent keyboard/mouse problems

If you’re using RISC OS 5.24/5.26 on a Raspberry Pi, you may run into problems if you mix USB1.1 devices (keyboard, mouse) with USB2 devices (disc drives, 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².

² This bug is fixed in RISC OS 5.27.

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 a CD-ROM drive has appeared on 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 and blind-type⁵
  wimpmode 32
  and then press RETURN twice. This should get you a full (if somewhat oddly-proportioned) desktop display, allowing you to reach Display Manager to set the screen resolution to something 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).