Boot sequence issues / improvements

I’m interested in trying to collect together a list of all the different problems or potential areas of improvement with the boot sequence, so that some brave soul may attempt to find solutions to them (whether that’s by patching them up one-by-one or making more drastic sweeping changes to the OS/boot sequence).

Topics I can think of include:

• Inconsistent error handling. Some boot errors will be reported when you enter the desktop, others won’t.
  • One cause of problems is the Repeat command. It has three ways of handling errors, so we have a few options available for how to improve things.
    • Default behaviour is to stop the enumeration, print the error message to stderr, and then exit with a return code of 1. However the default Sys$RCLimit of 255 means that the OS won’t consider the Repeat command to have errored. Since the boot sequence uses the default behaviour, this has the result that (for errors during PreDesk) you get a brief flash of an error message on the screen, some good parts of the boot sequence may be skipped (due to the enumeration stopping halfway through), but the system still continues on and into the desktop. Depending on the nature of the problem it might not be obvious that something has gone wrong (or why).
    • For Wimp tasks it will stop the enumeration and report the error via a Wimp error box
    • There’s also the ‘continue’ option, which is only supported for the single-tasking mode (i.e. ‘tasks’ option not specified). As the name implies, this will cause Repeat to continue after any error. Rather than displaying the error it will store it in the X$Error system variable. I’m not sure if the error will ever be displayed to the user (I thought the Desktop module would display it when the desktop is entered, but on closer inspection that only looks at Boot$Error)
• With regards error handling, we also need to decide whether errors should stop the boot or not.
  • If the boot sequence error is serious enough, the desktop may be in a non-functional state, so we’d probably want to support both modes. E.g. have a debug/single-step boot mode available via a keypress during startup.
• Once in the desktop, are Wimp error boxes an acceptable way of reporting errors?
  • Probably not, since they’ll pause any Wimp apps
  • There’s also the problem that the current Wimp error box doesn’t offer the user any way of saving the error message
• The current error reporting system doesn’t give much context (i.e. file/line within boot sequence), combined with the typical terseness of RISC OS error messages this can make it very hard to track down where any particular error is coming from
• Upgrading !Boot is troublesome / users can break things / etc. Potential solutions include:
  • Restructuring the boot sequence to allow it to be managed via PackMan: https://www.riscosopen.org/forum/forums/5/topics/3178, https://www.riscosopen.org/forum/forums/2/topics/3704
  • Storing Boot in ROM: https://www.riscosopen.org/forum/forums/2/topics/2589
  • Splitting Boot into different components based around usage: https://www.riscosopen.org/forum/forums/2/topics/9176
• Network initialisation is bad
  • DHCP is a blocking operation, ideally it should be asynchronous to avoid slowing down the boot
  • DHCP is only performed during the boot sequence, so if you don’t have a cable/network adapter plugged in then you’re unlikely to get correct networking later on (https://www.riscosopen.org/tracker/tickets/358)
  • If dynamic network configuration changes were supported properly then we’d no longer need to force users to reboot after making network changes in Configure
  • For systems which are reliant on NTP (i.e. no battery-backed RTC / RTC stopped), I don’t think there’s any guarantee that the time will have been synced prior to the desktop starting, potentially causing apps to get confused by seeing incorrect clock values. Making DHCP asynchronous will make the problem even worse.
    • Ideally we’d want to make the boot sequence smart enough to detect this kind of setup/situation and have it alter its behaviour so that DHCP + NTP is performed in a blocking manner early on in the boot sequence, to minimise the number of systems that are exposed to incorrect time values
• Network booting
  • As someone who has far too many development machines, keeping track of when disc images/boot sequences need updating is a bit of a pain. Some of the solutions proposed above (ROM !Boot, packman, etc.) may make this easier, but it may also be worth exploring network boot support. I’d imagine this would be useful in any situation where central administration of a network of computers is desirable (schools, offices, industry, etc.)
  • At minimum this would probably be a way to configure a system to use a disc image/boot sequence that’s stored on a RISC OS-friendly fileserver. Preferably this would support a completely discless boot (network boot configured via CMOS), but relying on a network boot script on the SD card would also be acceptable.
  • A key requirement would be that multiple machines can use the served boot sequence, with clear separation between shared settings and machine-specific settings (including control over whether the machine-specific bits are stored locally or on the fileserver)
  • Bonus points if it’s able to cache files locally so that you can still boot the machine using the previous settings if it’s not connected to the network
• Although the boot sequence is compatible with 3.x – 5.x, it can’t cope with dual-boot/softload setups where significantly different OS versions are in use (mainly due to the way the hook folders are used to configure the system on first boot)

Once in the desktop, are Wimp error boxes an acceptable way of reporting errors?

○ Probably not, since they’ll pause any Wimp apps
○ There’s also the problem that the current Wimp error box doesn’t offer the user any way of saving the error message

Some observations on that:

Modules such as ! NoError exist to cancel such error boxes after a short (pre-set) period – useful on headless/unattended machines.

The application WimpLog (which I see I have in Tasks itself – does it need to be earlier? Perhaps add-a-pling?) permits SysLog to record Wimp error messages – but can SysLog itself be invoked early enough – mine is in Resources?

Need to study sequence of booting! Now where is that chart showing it all?

Once in the desktop, are Wimp error boxes an acceptable way of reporting errors? Probably not, since they’ll pause any Wimp apps

One small contributor to a solution might be to add the facility for a multi-tasking Wimp error box. The concept has been suggested and discussed before. The Wimp would have to own these error boxes AFAICS because whatever raised them would likely no longer exist.

One cause of problems is the Repeat command.

Repeat ideally needs to be replaced with something that can report/log the error and then carry on. This was one of the main points behind Harinezumi – to go through replacing the behaviour of BootLoad/BootRun logging as it did so.

With regards error handling, we also need to decide whether errors should stop the boot or not.

No. No matter how serious the error, the reality is that the boot sequence is a hodge-podge of barely interacting things. It’s just a load of “do this at the start” activities. There may be things which depend upon earlier stuff having worked, one would expect these to error out in the case that the earlier part failed.
If we should throw in the towel, it risks having a ****load of potential issues further up the line. Want to start up Zap to look at the boot files? Has ZapFonts been ‘seen’? Has ZapUser? Has….?
Best to plough on ahead and hope for the best – at least one should end up with a sort of usable system.

are Wimp error boxes an acceptable way of reporting errors?

Yes. One should consider a boot error to be an important error that the user should be notified about. There are utilities to make error boxes go away – I think I emailed a copy of my NoError clone “ErrorCancel” (that also sends the error text to DADebug) to the code submissions (did I? or did I mean to? hmmm…!)

If anybody is interested, I’ve dropped a copy of the source here: http://heyrick.ddns.net/files/errorcancel.txt

There’s also the problem that the current Wimp error box doesn’t offer the user any way of saving the error message.

Pick up Service_WimpReportError. Registers R4+ are the same as those passed to Wimp_ReportError (R0→R4 etc) so you can pick up the message text from there. See above source. Tested in all versions of RISC OS that I have back to 3.50.

The current error reporting system doesn’t give much context

This is why Harinezumi logs everything and not just errors. It’s fairly clear what is going on if you know how the boot is supposed to run so can match up log to “things to do”. But if not, well, then you probably ought to leave it alone.
Think of !Boot like the Windows Registry. It isn’t scary, but it’s a bit of a complicated mess so wading in with little idea of how it actually works is ill advised.

Upgrading !Boot is troublesome / users can break things / etc.

If it is breakable, users will find a way. ;-)

Restructuring the boot sequence to allow it to be managed via PackMan
Storing Boot in ROM
Splitting Boot into different components based around usage

In response, I would offer:
1. PackMan should have a facility to “identify and claim” existent system resources that it wishes to manage. I have no problem with something looking after which AMPlayer I have. I do have a problem if it means restructuring the entire boot method to get that to work.
2. Boot is kinda big. And may be tweaked a lot by the user (consider the ability to add Harinezumi if Boot and the !Boot.Utils stuff was baked into ROM). The system is capable of booting without (sort of), so is this something that should be in ROM?
3. Would it not be better to have a set of install/manage/remove tools for “stuff to do at boot” and “stuff placed in BootResources” (think of MSCONFIG) that provide a pointy-clicky way to manage the things that happen at bootup. Then, the rest of the boot can be considered a black box except to power users. It may also be useful to stash in !Scrap someplace a list of “objects” for the past so-many boots (or days), so if the user notices something is not right, they can ask the nice UI to compare “what is different between this boot and the one I did yesterday?” and if it highlights EDID (or whatever), an untick will disable this (cause it to be moved to a different place so it isn’t run) and then rebooting to see if that fixed the problem.

DHCP is only performed during the boot sequence, so if you don’t have a cable/network adapter plugged in then you’re unlikely to get correct networking later on

That’s why I use static IP here. After a power cut (or power up after a thunderstorm), the Pi is ready in around 15 seconds. The Livebox takes at least ten times that.

For systems which are reliant on NTP

I have an RTC on my main machine, but that is indeed a very important problem. I’m not sure how best to deal with it, either, given the problem that RISC OS boots stupid-fast and domestic home routers, not so much…

Network booting

Can’t RISC OS boot from ShareFS?

One extra spanner to throw in the works – ROLtd bodged their boot sequence to support multiple users. I have no such version of Select/Adjust so I don’t know how it works and therefore Harinezumi simply doesn’t support such machines.
However, would this be a desired operation to have during boot? Even different user profiles might be useful for a single user machine – for instance my Pi boots up with my servers and the DDE loaded… but I know there is some sort of clash between the DDE and !Builder so it might be nice to have an option to boot up with !Builder started instead of my normal dev environment (with a different backdrop to so it’s really obvious!), or…. you get the idea.

One small contributor to a solution might be to add the facility for a multi-tasking Wimp error box.

What if there were multiple boot errors?

What if there were multiple boot errors?

Sorry, perhaps I should have made it clear that I expect the Wimp to be able to display lots, like ordinary multi-tasking windows.

When the error box is single-tasking, there’s no question, because, while one is displayed, no other Wimp task runs and therefore no other Wimp task can cause an error box to be displayed until the existing one has been dismissed. This limitation disappears as soon as the thing is defined as multi-tasking.

The only disadvantage I can see is that you might not know which came first. How important that is, I don’t know.

Apologies to anyone that gets bored or loses the will to live before the end of this.

There’s also the problem that the current Wimp error box doesn’t offer the user any way of saving the error message

Wrong viewpoint. Record the error then pop up a wimp message (if required – config option)

Upgrading !Boot is troublesome / users can break things / etc. Potential solutions include:

Option 1 and 3 seem prime changes. Option – store in ROM would have to go hand in hand with option 3 so that you’re looking at System boot vs. User boot
Likely to be a requirement to override / ignore the User boot by holding down a key or two during the boot.

The current error reporting system doesn’t give much context (i.e. file/line within boot sequence), combined with the typical terseness of RISC OS error messages this can make it very hard to track down where any particular error is coming from

Perhaps set a process identifier before running each process and print that identifier at the start of each recorded event (who said we only wanted to record the errors?)
NB. Never allow the error to stop the boot. Record the event via syslog and pop up a message at the end of the boot sequence that informs the user that an error occurred and the error log is here: SysLog$Dir.BootLog with a nice button to click to open the log.

Network initialisation is bad

No argument there, but I think updating the whole network stack is a bit of mountain to move and probably doesn’t fit well with the probable need for multiple iterations of alteration of the boot before it is satisfactory. You just know it won’t be perfect first time.

DHCP is a blocking operation, ideally it should be asynchronous to avoid slowing down the boot

Indeed, but possibly something to do as the next on the list after the boot changes

DHCP is only performed during the boot sequence, so if you don’t have a cable/network adapter plugged in then you’re unlikely to get correct networking later on (https://www.riscosopen.org/tracker/tickets/358)

Two consequences of alteration so it triggers of a network link detect:

If dynamic network configuration changes were supported properly then we’d no longer need to force users to reboot after making network changes in Configure

That and forgetting to connect your network cable doesn’t require you to reboot to pick up a working IP connection and Rick can have his router reboot and cause the Pi to initialise the network stack when the router decides to offer a live port.
Failure at that time should trigger an APIPA assignment and a recheck every 15 minutes or so.

For systems which are reliant on NTP (i.e. no battery-backed RTC / RTC stopped), I don’t think there’s any guarantee that the time will have been synced prior to the desktop starting, potentially causing apps to get confused by seeing incorrect clock values. Making DHCP asynchronous will make the problem even worse.

Two things:

1. Have the system assume the last saved time during last uptime plus a small margin is the “current” time and leave the NTP until (very) late in the boot with a check for the status of the network as a condition on running.

Ideally we’d want to make the boot sequence smart enough to detect this kind of setup/situation and have it alter its behaviour so that DHCP + NTP is performed in a blocking manner early on in the boot sequence, to minimise the number of systems that are exposed to incorrect time values

Don’t block, it’s a pain in various ways. Check for the network viability and default to a fallback value of last recorded time plus small margin. DO record the event as “probable date time inaccuracy” or “NTP time established” in our Boot SysLog

Network booting

Again, that’s more a network stack item. i.e. after the !boot has been amended to a more resilient form then it’s time to look at the network stack.

Really speaking network booting is two things:

1. PXE boot
2. A network share resident boot sequence

If you move the system boot into ROM then the logical thing to do is check for a CMOS setting for use of the PXE boot you have also embedded in the ROM (or possibly utilise U-boot facilities which I think include a network boot option)

At this point I realise that perhaps a PXE boot is something that would be useful in the process of developing a new boot sequence. It may however be a bit of a long development (unless the U-boot / NetBSD port PXE is a quick option)

###############

Want to start up Zap to look at the boot files? Has ZapFonts been ‘seen’? Has ZapUser? Has….?

Now you know Zap is broken :)

What if there were multiple boot errors?

The code in WimpLog pushes the text of the error to SysLog. Since SysLog has an archiving facility and control over the level of verbosity of the logged events I would say it is the way the bootlogs should be handled.
Currently pre-wimp the errors are sent to stderr (brief flash on screen as Jeffrey put it) then once the Wimp is active they present as Wimp error pop ups. This should be (pre-wimp) send to SysLog and possibly echo to screen, (wimp) send to SysLog and, optionally, echo to Wimp message (multi-tasking and auto-close after delay)

The only disadvantage I can see is that you might not know which came first.

Record it via SysLog then pop up the message. If the sequence is important then the sequence is recorded in SysLog.

Record it via SysLog then pop up the message. If the sequence is important then the sequence is recorded in SysLog.

So we incorporate SysLog in ROM to get it active from the very start? Seems logical.

forgetting to connect your network cable doesn’t require you to reboot to pick up a working IP connection

I tried to write a module once that would issue a new DHCP request when you connected the cable. I don’t remember the specifics, but the documented service call for connecting a cable didn’t actually happen so there was no event to listen for. Fixing that would be useful!

Although that has nothing to do with cleaning up Boot. I’m in favour of putting at least some of it into ROM. Once it’s in ROM there’s no need for it to be universal, so some of the “Hook” directories can disappear. I’d even question whether the disc-based Hooks need to be separated by OS anymore; if Boot isn’t universal then just dump everything into a single Hook directory rather than trying to separate it out by supported OS. Ideally a given module would terminate cleanly if it doesn’t work on the current OS anyway.

What is Boot.Library? I’ve never customised this but Rick said he had in one of the other threads.

I tried to write a module once that would issue a new DHCP request when you connected the cable. I don’t remember the specifics, but the documented service call for connecting a cable didn’t actually happen so there was no event to listen for. Fixing that would be useful!

I have a BASIC app which I use to do this, makes life much simpler. Not all Ether modules follow the spec, you’re right, I had to use various exceptions for different Ether modules.

Splitting Boot into different components based around usage

There is pre-Wimp (all that is needed to boot to Wimp) and Wimp (all that is post Wimp launch, and so will not block it).

IMHO, everything that is Wimp could be individual components (!Configure, !Desktop, !Fonts, !Trash, !Scrap, !Modules, etc.) placed in a !System directory, separated from the initial !Boot. When, all these components could get their own lifecycle. !Boot could be in ROM or not, but will be very simple. And not user configurable.

Sorry, perhaps I should have made it clear that I expect the Wimp to be able to display lots, like ordinary multi-tasking windows.

The other way that should have been obvious to me, but only occurred to me a few hours ago, is for there to be still only one multi-tasking error box, but to store all the info for all of the requests to open it in a list. So when you ack a box, it re-opens with the next message.

still only one multi-tasking error box, but to store all the info for all of the requests to open it in a list. So when you ack a box, it re-opens with the next message.

You mean a GUI reader for SysLog recorded messages.

I think most people would like a record of the messages for later use so record it and read it later. Later being a flexible interval after the event.

You mean a GUI reader for SysLog recorded messages.

No – I want to see the messages happen (if they do) when they happen, although it makes perfect sense to have them logged too.

No – I want to see the messages happen (if they do) when they happen, although it makes perfect sense to have them logged too.

As I said earlier, wrong viewpoint. It isn’t a case of log it too.
Log it, then display it.

The logging isn’t an afterthought or option, the real time display is an option.

Does this help at all?

If you’re offering the source code so that Jeffrey or someone can incorporate, some or all of, the features in the standard boot then it probably helps a lot.

If SysLog (not necessarily the existing 0.20) is in the ROM, or its functionality is in the ROM, then logging is available from that point onward.

It strikes me that an upload site for compressed error logs might be handy. Ticket based so it doesn’t present a site security hole or spam dump (Andrew H may care to comment on the viability of that)

If this is done, it’s probably best done with a means of making error logs available to developers for bug tracing without filling the forum with large log files.

The only disadvantage I can see is that you might not know which came first. How important that is, I don’t know.

Include the current time as part of the message.