Boot menu

I’m writing a boot menu as a replacement for the “Machine startup failed” error box and I’d like to get some people trying it out.

You can download it in a zip file here.

To start it,

1. Copy the ‘BootUI’ module from the zip file to the root of your usual boot drive.
2. Shut down and restart your computer, holding down the shift key so that you get a Supervisor prompt
3. Type *BootUI, and press enter while holding down shift

You should then see the menu.
Rather than holding down shift, you could do *Configure NoBoot, and then set it back once you are finished.

N.B. This is not designed to be run from the desktop, so I do not recommend trying that.

Let me know what you think! I’m especially interested in if it works with the different monitor setups that people have.

Like.

Works in RPCEmu on a laptop with the display at 1360 × 680 (it fits between the windows iconbar and the top of screen)

Make it do a password check, and you’re on a winner.

Talk to Mr. Murray about “stealing” some code from Harinezumi and you can include some boot logging (and resilience)

My VirtualRPC always starts up in supervisor mode, with a “Module Toolbox too old” error. Typing ‘BootUI’ while holding down shift evokes the choices menu, but whether I choose 1. (Continue to desktop, booting from HostFS:$) or 3. → 5. (HostFS), the computer starts up while skipping most of the boot settings. Perhaps this is intentional. Anyhow, the monitor setting is kept (1920 × 1080 × 16M x 30Hz).

Typing BootUI without holding down shift miraculously starts the usual desktop. Well, miraculously to me, complete ignorant.

My VirtualRPC always starts up in supervisor mode, with a “Module Toolbox too old” error.

Interesting. Makes the efforts to produce a merged and modernised Toolbox more meaningful. Hopefully an updated Toolbox that can be used with all software on both forks will be with us sometime soonish.

but whether I choose 1. (Continue to desktop, booting from HostFS:$) or 3. → 5. (HostFS), the computer starts up while skipping most of the boot settings. Perhaps this is intentional.

Doesn’t do that on RPCEmu and RO5.29 – perhaps it’s a symptom of interaction of the different boot structure in RO4.3x? That one needs more testing by RO4.3x users.

Typing BootUI without holding down shift miraculously starts the usual desktop.

I’d imagine that’s because the BootUI module is looking for shift pressed as a trigger to enter the menu, otherwise just run Desktop

perhaps it’s a symptom of interaction of the different boot structure in RO4.3x?

ROL 4.xx/6.xx from 4.15 has the abilty to enter the boot menu on start up when the shift key is held.

Perhaps need to think about the key combination with BootUI to not interfer with that if it is to be universal?

My VirtualRPC always starts up in supervisor mode, with a “Module Toolbox too old” error.

After that what would you normally do to get to the desktop fully booted?

Typing ‘BootUI’ while holding down shift evokes the choices menu, but whether I choose 1. (Continue to desktop, booting from HostFS:$) or 3. → 5. (HostFS), the computer starts up while skipping most of the boot settings. Perhaps this is intentional.

It’s definitely not intentional! It should do exactly the same thing as if you’d held down shift, so I don’t know what’s happening there.

Can you try a few commands for me so I can see how your setup is?

*Status FileSystem
*Status Drive
*Status Boot
*FX 0

and post here what it says.

As I understand it, under VirtualRPC you’ve got your !Boot in HostFS::HardDisc4.$, and you’ve put BootUI in the same place?

ROL 4.xx/6.xx from 4.15 has the abilty to enter the boot menu on start up when the shift key is held.

Not a feature I had noted/remembered from general reading, but would definitely interfere with this test.

Perhaps need to think about the key combination with BootUI to not interfer with that if it is to be universal?

Perhaps this is intended to introduce that ROL feature into RO5.x? In which case we need to ask whether the menu should be the same. Or is this intended to move forward from that?
It does fit with the idea of choosing the boot type, so you could boot from an encrypted or non-encrypted partition for example. Or, more simplistically, boot from a development or non-development partition.

It’s definitely not intentional! It should do exactly the same thing as if you’d held down shift, so I don’t know what’s happening there.

Perhaps Doug’s info is the clue.

Perhaps this is intended to introduce that ROL feature into RO5.x?

That thought did cross my mind and perhaps it should follow the same menu and if it is intended to do more, like encrypted / non encrypted partition boot then they should be part of an extended menu over and above how ROL have it set out so not to confuse those moving between ROL/ROOL/ROD/Any other streams.

My VirtualRPC always starts up in supervisor mode, with a “Module Toolbox too old” error.

After that what would you normally do to get to the desktop fully booted?

Normally I type ‘run !boot’, or just ‘!boot’.

FileSystem HostFS
Drive 0
Boot
RISC OS 4.02 (10 Aug 1999)

And yes, I’ve put BootUI in the root directory, just like !Boot.
However, the choice menu suggests that it will boot from HostFS::$., rather than from HostFS::HardDisc4.$. Could that have something to do with it? (Still being completely ignorant.)

Thank you for BootUI. My set-up Pi4 USB (Boot) drive, SDCard (ROM) RISC OS 5.29 (23-Jan-21) Monitor native resolution 3840×1600.

After finally getting the timing right, with respect to holding down the shift key and finding out how to get the keyboard to work for this; see further keyboard comments below.

BootUI without holding down shift miraculously starts the usual desktop.

It does that for me as well. Although no boot issues.

Observation:

Holding down the shift key, whilst typing in BootUI, I see the options. I can’t select an option, Power-off and Rebooted.

PS. It might be worth dropping JF (Gerph) a line as Select had a BootUI. Nothing ventured, … He has offered to donate his zero network configuration code ;)

Observation for ROOL:
The boot message, Keyboard not present, only occurs when I have my USB hub plugged in; it doesn’t matter if the keyboard is plugged into a separate USB port or into the hub. Having the hub plugged in at start-up prevents the keyboard from working; message displayed. At the desktop everything works as expected. Addendum: Its a known issue

RISC OS 4.02 (10 Aug 1999)

Hmmm, are you on RO4.02 in VRPC or a later version?
If the latter then, if you think about it, you’re actually running RO4.02 and soft loading 4.3x and what BootUI is doing to that sequence is anyone’s guess.

The boot message, Keyboard not present, only occurs when I have my USB hub plugged in

This is a known issue and even gets a mention in the wiki.

Hmmm, are you on RO4.02 in VRPC or a later version?
If the latter then, if you think about it, you’re actually running RO4.02 and soft loading 4.3x and what BootUI is doing to that sequence is anyone’s guess.

No, it really is 4.02 from 1999 (I don’t use VRPC that much, especially since I have a 4té). As far as I know, the only OS thing that is softloaded, is font manager 3.66 from 2010.

Perhaps this is intended to introduce that ROL feature into RO5.x?

Exactly this. I saw it on The List and though about how often people turn up here with boot problems. I don’t feel bound to replicate the 4/6 version exactly, but my starting point is the screen shots in the user guide for those.

An advantage of the 4/6 layout is that you can choose to boot from any drive with only one keypress.

Exactly this. I saw it on The List and though about how often people turn up here with boot problems. I don’t feel bound to replicate the 4/6 version exactly, but my starting point is the screen shots in the user guide for those.

In that case, I really do encourage the use of the features of Rick Murray’s Harinezumi which would take in the item above in the list (at least for the initial boot)

Rick points out that if you dig through these forums there’s a link to the source, but you might want to chat about other ideas he’s had that aren’t in that.

OK, Tested on my ARMX6 , 5.29 3rd Nov 21 ROM.

It is a bit hit and miss as to if the shift is identified on start up from either a directly attached USB keyboard or my usual Logitech KS540 wireless keyboard/mouse.

Once i get the supervisor prompt the typing BootUI and holding the shift down as I enter then provides me with a menu but I am unable to select anything again using both direct USB keyboard and wireless.

I have tried both the rear and front usb sockets with the same effect.

Perhaps the BootUI module isn’t allowing the full keyboard parts of the HAL/ROM that deal with these to get initialised?

Update: Typing BootUI and just the enter key starts the standard boot sequence OK so it is just the menu options that can’t get select when invoking that element of the module.

Rick points out that if you dig through these forums there’s a link to the source

Source (latest version): http://heyrick.ddns.net/files/harisrc009.zip

Basically, it loads the Boot:Utils.BootRun file and parses the instructions, to implement some for itself (like [Do] Repeat Boot[Load|Run]), others it simply executes as given.
The difference is that it doesn’t fault errors, it logs them and carries on. So one thing wrong won’t bugger up the entire system boot.
Note: It only deals with the pre-desktop side of things. Firstly, because the Desktop side is handled differently (and within the Desktop environment), and secondly because pre-desktop is where show-stopping problems usually occur.

but you might want to chat about other ideas he’s had that aren’t in that.

Basically I’m happy with any solution that would allow the boot to make it to the Desktop even in the case of errors. It’s a very long-standing problem that has not been addressed because “here by dragons”.

NOTE: The Select boot menu and user profiles etc are NOT supported by Harinezumi. I would have no problem with testing and adding specific support for this ¹ if Aaron is willing to send me a copy of VRPC and an appropriate copy of the OS, so I can see what it’s actually doing…

¹ Though, honestly, I’d be surprised if Gerph hasn’t already added something to the OS to help make booting less prone to dropping dead at the slightest upset.

My set-up Pi4 USB (Boot) drive, SDCard (ROM) RISC OS 5.29 (23-Jan-21) Monitor native resolution 3840×1600.

Holding down the shift key, whilst typing in BootUI, I see the options. I can’t select an option, Power-off and Rebooted.

OK, Tested on my ARMX6 , 5.29 3rd Nov 21 ROM.

Once i get the supervisor prompt the typing BootUI and holding the shift down as i enter then provides me with a menu but I am unable to select anything again using both direct USB keyboard and wireless.

I couldn’t select options with the keyboard on my Pi 3 either – I had assumed when testing that it was a vncserver problem, but no, BootUI isn’t getting any keyboard input on the Pi and ARMX6 past the shift/asterisk detect.

After a bit of print-effing, I’ve found a bug in xos_readc in OSLib.

Here’s the assembly for xos_readc(char *c, bits *psr) :

  MOV R12,R14
  STMDB R13!,{R0}
  SWI XOS_ReadC
  BVS %f01
  LDR R14,[R13,#0]
  TEQ R14,#0
  STRNEB R0,[R14,#0]
  RSB R1,PC,PC
  MSR R1,CPSR
  TEQ R1,#0
  STRNE R1,[R1,#0]
  MOV R0,#0
01
  ADD R13,R13,#4
  MOV PC,R12

The pointer psr comes in in R1 and gets trashed before the STRNE, so the write ends up going to the zero page. The difference between RPCEmu, RPi and ARMX6 is that RPCEmu doesn’t abort these. I can work round it for now by usisng os_readc instead.

There’s a new version for RPi and ARMX6 users here here to make the keyboard options work.

edit: Don’t use this one, use the one below instead.

That worked well, its accepting key presses :)

Observation:

Option 4. Didn’t work, it briefly flashed up the standard large green image and then to a black screen will a flashing cursor, no prompt.

;-/ I didn’t try the option to point it at another drive. ;)

Try this one

Try this one

That fixes the blank screen on Option 4 at least on this ARMX6.

So if I select option 3 to boot from another filing system and say select ShareFS it defaulst to the first share it finds and then times out and returns to the main menu.

It has now changed Option 1 to continue to boot to Share.$ and hence you have to go back in to Option 3 first and select the correct drive i.e SCSI , again it luckly this time reverts to the first drive.

It perhaps needs you to be able to sub select a drive and perhaps should not retain that value if it times out or later Option 1?

However, the choice menu suggests that it will boot from HostFS::$., rather than from HostFS::HardDisc4.$. Could that have something to do with it?

I don’t know how HostFS chooses which disc to boot from, my guess is it is hard-wired to boot from HostFS::HardDisc4.$.

No, it really is 4.02 from 1999 (I don’t use VRPC that much, especially since I have a 4té). As far as I know, the only OS thing that is softloaded, is font manager 3.66 from 2010.

Whilst the final product won’t be relevant to 4/6 users, it’s a useful test of the code to see how well it runs on there; there really shouldn’t be a difference between letting BootUI go straight to booting and shift-ing into the menu and choosing 1, it calls the same function, all that has happened in the mean time in the second case is putting stuff on the screen and getting some keyboard input.

That worked well, its accepting key presses. I was able to return from the command line, back to the menu. :)

;-/ I didn’t try the option to point it at another drive. ;)