ShareFS with headless RPi 3 on RC15

*Copy $.!Boot.BootLog $.Failed
You can blind type, right?

*Configure NoBoot would save on typing if necessary (revert with *Configure Boot).

The ‘culprit’ to the headless boot problem is the !DBSRscs app added to the !Boot.Resources directory in the 13-Apr-2017 RC15 build (ie was not in RC14)

I assume that this App was added to the build at a late stage in the development without full testing.

Remove it (or hide it away) and headless boot works fine once more.

What a waste of time that this (third party?) app was added to the build without being properly tested!

the !DBSRscs app added to the !Boot.Resources directory in the RC15 build

Uh, so what’s this then?

What a waste of time that this (third party?) app was added to the build without being properly tested!

In some respects yes, however it’s demonstrated a slight hole in the Harinezumi use case.

Uh, so what’s this then?

A test application for Harinezumi use in headless install use cases :)

Edit: Actually it appears to be a software library utility for non-essential software so it has no place in the boot sequence.

What a waste of time that this (third party?) app was added to the build without being properly tested!

You’re aware that on odd numbered builds, the releases are “unstable” and made available precisely so that users like you and I can do that testing? Many of us use such builds every day without issue, but sometimes new changes can cause problems.

Now that you’ve found a problem in the free OS that you’re using on your Pi, how about submitting a useful bug report to ROOL by way of saying “thanks”…?

:-)

Where can I say “thanks” to ROOL for this “unstable” R15 release that hasn’t crashed for me once yet…I’m not exploring many of its avenues, but I’m remorselessly thrashing those avenues I do venture down (if you’ll excuse my mixed metaphors)

Where can I say “thanks” to ROOL for this “unstable” R15 release that hasn’t crashed for me once yet

Unknown stability status vs. tested known stability status. The former may fail to run (and has once or twice) the latter has no known stability issues but lacks some bleeding edge features.
Examine not the dentition of the complimentary equine. :)

Point taken about the free OS that I am using.

the new App !DBSRscs added to !Boot.Resources in the RC15 build

I don’t seem to have this, and neither does the latest HD download. What is it and where did it come from?

The ‘culprit’ to the headless boot problem is the !DBSRscs app added to the !Boot.Resources directory in the RC15 build

Hmm!! I have just had a session with a new RC15 installation and !DBSRscs was not an issue at all. To get it to run headless, and Share, the default EDID setup had to be replaced with a MDF, and that was all.

What is it and where did it come from?

I asked this earlier – it was described as: a software library utility for non-essential software so it has no place in the boot sequence

the new App !DBSRscs added to !Boot.Resources in the RC15 build

I don’t seem to have this, and neither does the latest HD download. What is it and where did it come from?

SDFS::RISCOSpi.$.!Boot.Resources.!DBSRscs

Its purpose is somewhat obscure but it should be entirely passive.

“!DBSRscs (Common Resources for DynaByte Software Applications)”

A test application for Harinezumi use in headless install use cases :)

It was good to revisit this, because Harinezumi was very broken (as in “did not work”) in more recent incarnations of the boot sequence.

Why?

Because some smart ass decided to replace this:

Repeat BootLoad <Boot$ToBeLoaded> -files <Boot$ProgressLoad>
Repeat BootRun  <Boot$ToBeLoaded> -directories <Boot$ProgressRun>

with this:

Do Repeat BootLoad <Boot$ToBeLoaded> -files <Boot$ProgressLoad>
Do Repeat BootRun  <Boot$ToBeLoaded> -directories <Boot$ProgressRun>

Why? The “Do” command says that it passes the argument to the command interpreter, exactly like not invoking Do at all. Is this something largely pointless like the “LET” keyword in BASIC?

Anyway, about twenty minutes of hacking (sorry, I used the inline assembler as I couldn’t be bothered to write veneer code in the other source file, declare function prototypes and all that rubbish when a couple of lines wrapped in __asm { ... } would do the job) and there’s a shiny new version of Harinezumi for the world to enjoy. :-)

Maybe the <cough>fixed version of Harinezumi might help diagnose what is happening?

Something in Boot Resources won’t be affecting the system boot. There’ll be something in PreDesk (which might use the indicated resource…) that is misbehaving.

To get it to run headless, and Share, the default EDID setup had to be replaced with a MDF, and that was all.

That’s a workaround. Not a fix. The fix is for RISC OS (or whatever extension is choking) to be smart enough to recognise that NO monitor is connected and then either:
a. Start up in the previous resolution (if this is remembered anywhere)
or:
b. Start up in a safe default resolution such as 800×600 or so

That’s a workaround. Not a fix.

Obviously. The point I was making is that !DBSRscs is not part of the problem, here at least.

The EDID and headless invisible error is :-

Boot:Choices.Boot.PreDesk.!!ZeroPain
Boot:Choices.Boot.PreDesk.Configure
Repeat: Keyword file_format was expected at line 1 of file Resources:$.Resources.ScreenMode.Monitors.EDID0

Aaaaand there we go.

Repeat: Keyword file_format was expected at line 1 of file Resources:$.Resources.ScreenMode.Monitors.EDID0

What is it, an empty file?

What is necessary is for the EDID code to have a safety callback where it will output a generic emergency MDF with some default sizes (really only need 640×480 and 800×600 – and in headless cases that’s just to placate the rest of the system) in cases where an EDID was expected but none was actually read.

What is it, an empty file?

Who knows? Headless with no display and the machine apparently stuffed makes that a bit difficult. No sharing, no VNC, no idea.

Uh, so what’s this then?

The !Help file describes it as “Common Resources for DynaByte Software Applications”, which, at least to me, doesn’t explain much!

[Edit: Oops, already answered, and the Delete button still doesn’t work]

I don’t seem to have this, and neither does the latest HD download. What is it and where did it come from?

So, what is it seems to have been answered, but not how it got into Boot:Resources!

I was confused because John S said it was part of RC15, but, perhaps thankfully if he’s right in his diagnosis, I don’t have it.

What have the rest of you been doing which has made it appear? Google just tells me about “retro games” – is this it?

If it’s a shared resource library, then Boot:Resources is indeed where it should be, but is it actually broken?

About !DBSRscs

but not how it got into Boot:Resources!

It was part of RC15 as downloaded here yesterday.

If it’s a shared resource library, then Boot:Resources is indeed where it should be, but is it actually broken?

DBSRscs’s !Boot file only sets up a couple of system variables and loads some icon sprites. Nothing unusual. Perhaps something which depends on DBSRscs is broken, but more than likely the problem is a zero-byte EDID file (and the general lack of error tolerance within the boot sequence)

Examine not the dentition of the complimentary equine. :)

I’m not. I’m extremely grateful for it. I’ve met none of the unknown “unknown stability status”, and at least one of the “bleeding edge features” is a godsend for me. !Draw & StrongEd spread out all over a glorious 4K desktop…

(!FontEd too, but I’ve not actually had occasion to use that in anger since getting the Pi, and may never do so again. No plan to at present. Just had a poke around to see if it was working.)

Repeat: Keyword file_format was expected at line 1 of file Resources:$.Resources.ScreenMode.Monitors.EDID0

What is it, an empty file?

128 null bytes.

I’ve fixed the most egregious errors, so booting an EDID-enabled Pi without a monitor should now leave you at a functioning mode 28 desktop (previously it would get stuck in mode 0 with an illegible error box on screen). However the boot sequence will still fail halfway through – one of the Repeat commands will fail, but it won’t actually be caught as an error by the boot sequence, so the user will only find out about it when they (e.g.) notice that Fat32FS hasn’t been loaded. So some changes to the boot sequence and/or Repeat are definitely needed to improve its robustness.

more than likely the problem is a zero-byte EDID file (and the general lack of error tolerance within the boot sequence)

I notice the new code in CVS (which should play through in the build overnight) that fixes part of the issue in this thread:

“Booting an EDID-enabled Pi without a monitor (and with the broken BCMVideo 0.47) no longer results in an (unintelligible) error box on entry to the desktop + system stuck in mode 0”

The next comment suggests that a “fix” for the slightly fragile boot is still required:

“However, note that other issues in the boot sequence mean that booting with EDID enabled and no monitor still isn’t 100% working (PreDesk Repeat will terminate early, potentially skipping some directories)”

So, in the meantime, it would seem installing Harinezumi is a good idea. At least until the boot is a little more robust…

I’ve fixed the most egregious errors, so booting an EDID-enabled Pi without a monitor should now leave you at a functioning mode 28 desktop

Many thanks, that is much better. A more sensible MDF choice can now be made with VNC.