ShareFS with headless RPi 3 on RC15

I have a nice new RPi 3 which I am using as a headless file server.

If I start it up with an HDMI monitor attached (no keyboard and no mouse), it works fine as a file server and if I then disconnect the monitor it continues to serve files. !WebJames also works OK. (and I can telnet into it or connect a monitor and mouse to shut it down).

If I start it up with no monitor, then the shareFS, !Webjames and !telnet server do not work; making it useless as a file server.

I have not noticed this before on any other RISCOS hardware with any previous versions of RISCOS. Is this intentional or have I got something wrong somewhere.

The shareFS, !Webjames and !Igor are all started in !Boot.Choices.Boot.Desktop.

This post edited on 10th July to say that the answer is to remove the new App !DBSRscs added to !Boot.Resources in the 13-Apr-2017 RC15 build (ie it was not in RC14). Headless boots will then work once more.

Aaaaand did anyone test the behaviour of EDID/Auto with no monitor connected? ;-)

Try Harinezumi, see if it tells you what is going on (it’ll also complete the boot regardless of error).

Thanks. It does look like you are correct about the testing of RC15 EDID/Auto with no monitor.

With a bit more investigation, I can now say that I get the same thing on a RasPi 2 and on the newer 2.2. Perhaps, using Configuration to manually set a monitor type may work. But, I need to create a test SDcard for that as last time I played with monitor types, I could not get back to a working ‘auto’.

My other headless file/webjames servers are still running RC14 and they work OK.

If I get time, I will look at Harinezumi.

Will it work if you use !Boot.Loader.CMDLINE/TXT with disable_mode_changes ?

If I get time, I will look at Harinezumi.

Since your problem is a failure to complete the boot because of an EDID related ‘event’ which is probably a single tasking error message waiting for a keypress continue¹ then Harinezumi is likely to “fix” things and it logs the events so then you know for sure what the issue was. It’s probably the EDID code doing something like looping looking for a connected display unit but without logs who knows?

I don’t think the retrograde step suggested by Rob is a good step as it doesn’t really fix the issue, it just covers it up.

It’s now time for me to repeat the comment that Harinezumi type functionality needs to be built in to the standard boot.
Rick, time to bounce the source in the direction of Jeffrey or something.

¹ Anyone else reminded of the old PeeCee error “bad or missing keyboard, press F1 to continue” ?

I don’t think that this is a retrograde step it’s the steps that Jeffery talked about to restore previous behavior if EDID failed on you system.
It’s should only be used as a stop gap until the problem is fixed.

Rob, I disagree. I used the word retrograde quite deliberately as “going back” is exactly what restoring previous behaviour is.

The suggestion of using Harinezumi to collect logs of the sequence was to provide information to move forward with a fix for the problem.
Remember the release is a beta and avoiding a problem rather than doing something to collect data describing the problem doesn’t help fix it.

My suggestion that the Harinezumi functionality should be in the default build is so that people can collect and submit fault data more easily.
I really do believe the RISC OS desperately needs that functionality. It’s a fact that there will always be new things in the boot sequence on each persons machine and those may generate a fault that, without Harinezumi style functionality, will stop the boot and leave the machine in a less than perfect operating state and possibly not working at all.

I have tried Harinezumi, but it fails with error message:
File ’ a’ not found. Error Number D6

I will leave this to experts as I am quite happy with the workaround of starting it up with a monitor attached and then disconnecting. This also allows a more controlled shutdown with the monitor re-attached.

File ’ a’ not found. Error Number D6

Was this Harinezumi failing, or an error during startup? Are you running Harinezumi directly, or calling the _harikick file? You need the kick file on RISC OS 5.

Try Harinezumi, see if it tells you what is going on (it’ll also complete the boot regardless of error).

I revisited that, prompted by this thread. The colours are pretty, but whizz past a bit fast on this over-clocked ARM v7 Pi2.

Which makes me wonder, could someone make a special mode for StrongED to reflect these colours in the BootLog produced.

I guess it would have to identify the necessary mode by the filename or the first word (or both?), as it’s a plain text file.

Of course, Rick would need consulting on their significance, but I believe he is a Zap user (am I right?) so it would need a competent StrongED aficionado to make the mode (and I am not he – the competent bit!).

Please excuse sexist language, female enthusiasts welcome. Aficionadas?

If I start it up with an HDMI monitor attached (no keyboard and no mouse), it works fine as a file server and if I then disconnect the monitor it continues to serve files.

I noticed that! Never quite worked out exactly why! Anyway …

The lines below in CONFIG/TXT work around the issue, both the RPi1 and RPi3 start headless, and Share.

hdmi_cvt=1680 1050 60 5
hdmi_group=2
hdmi_mode=87
hdmi_ignore_edid 0xa5000080

P.S. It also side stepped a similar issue where the two Pi’s shared a monitor via an HDMI switch and only the Pi selected would start up.

P.S. It also side stepped a similar issue where the two Pi’s shared a monitor via an HDMI switch and only the Pi selected would start up.

So, would someone, with one of these nice reproducible error situations, like to run their setup with Harinezumi in place and without the retrograde settings so that a log file or two can be obtained to give people chance to look for the offending code?
I think it’s easier for someone like Jeffrey to fix a clearly identified code chunk than sit experimenting with guesses at what the fault reproduction is before starting on examining code.

John:

The colours are pretty, but whizz past a bit fast on this over-clocked ARM v7 Pi2.

You aren’t supposed to read that rubbish. If there’s green, that’s good. If there’s red, that’s not good. Cyan/white are other messages.

You might prefer to append “-q” to he harikick file where it runs harinezumi ? This switches to quiet mode, where there’s a little slider-thingy that goes across the screen (and all that text is muted). That’s what I use as I don’t care what goes right, only what goes wrong.

Which makes me wonder, could someone make a special mode for StrongED to reflect these colours in the BootLog produced.

Any line beginning “Okay:” is green. Any line beginning “FAIL:” or “--->:” is red. “ERR!:” is magenta. “    :” (four spaces) is a continuation of the previous message with whatever colours that involved.
Anything else is informational and can be cyan or white as preferred.

That said, just search for “FAIL”. If there are no matches, nothing went wrong.

I guess it would have to identify the necessary mode by the filename or the first word (or both?), as it’s a plain text file.

Unless you change things, it is $.!Boot.BootLog.
The file has a header ID which is currently:

harinezumi v0.06*alpha* (2012/10/16) initialised
================================================

So you can assume the first word will be “harinezumi” – though best to do a case insensitive search as that probably ought to be a capital ‘H’ there. ;-)

Of course, Rick would need consulting on their significance,

Or just, you know, read the help file and look at the log file? ;-)

There’s detail in the comments the top of the function “do_log()” in the C source. This was already considered a long time ago (2012!).

Steve:

Rick, time to bounce the source in the direction of Jeffrey or something.

I disagree – Harinezumi is a hack exactly because of deficiencies in how the boot system works. What we really need is for the Obey module to have an option where errors will be sent to SysLog or a log file and not propagated up where it’ll abort the boot. In this respect, Harimezumi might seem “better” because it logs everything, but in reality nobody cares much about what worked, we just want to know what failed.

However, if it helps, I have dropped the source code at http://heyrick.ddns.net/files/harisrc006.zip
You will need to find h.SWINames yourself. It’s in the DDE Examples at …Sources.DDE-Examples.ObjAsm.AsmHdrs.h.
I’ve chosen to licence it as CDDL so it will be compatible with RISC OS, but not GPL. ;-)

Rick, time to bounce the source in the direction of Jeffrey or something.

I disagree – Harinezumi is a hack exactly because of deficiencies in how the boot system works. What we really need is for the Obey module to have an option where errors will be sent to SysLog or a log file and not propagated up where it’ll abort the boot.

You missed the bit where I said

It’s now time for me to repeat the comment that Harinezumi type functionality needs to be built in to the standard boot.

Where logging all errors is the default and logging everything is a “verbose” option.
The logging level element of SysLog is probably the control there.
A more recent version of SysLog would be nice too.

I’ve chosen to licence it as CDDL so it will be compatible with RISC OS, but not GPL. ;-)

That’s nice. Really nice ;-)

PS:

There’s detail in the comments the top of the function “do_log()” in the C source. This was already considered a long time ago (2012!).

2012?, dear me have I been advocating it’s functionality in the OS for that long?

2012?, dear me have I been advocating it’s functionality in the OS for that long?

That’s sort of what I thought when I put the source archive together. I mean… half a decade! Jeez. At this rate I’ll be waving my arms in the air and going whooooo! in the blink of an eye. :-/

You will need to find h.SWINames yourself. It’s in the DDE Examples at …Sources.DDE-Examples.ObjAsm.AsmHdrs.h.

A thought surfaced: Why is it there?

No idea. ;-)

I’ve been using one I auto-built for DeskLib in more recent projects. Since I created that one myself, there’s no issues regarding (re)distribution. However older projects use SWINames which is part of the DDE…

You can pick up a copy of my DeskLib one here: http://heyrick.ddns.net/desklib/source/h/SwiNos... though the conventions are different – SWI names are prefixed SWI_ and there are no X form SWIs (you OR in XOS_Bit).

Is there an ‘append’ option for the Bootlog file?

With a monitor, I see coloured text flashing up the sceen and I can look at the Bootlog file which says everything os “OK”.

Without a monitor, the Pi hangs. And, of course, I haven’t seen anything and still can not read the file. ShareFS has not started, so I can not look at thhe file that way, either.

With a monitor now re-attached, a re-boot works fine and the (now overwitten) Bootlog tells me everything was “OK”.

Now what?

Without a monitor, the Pi hangs. And, of course, I haven’t seen anything and still can not read the file. ShareFS has not started, so I can not look at thhe file that way, either.

It should finish, maybe Harinezumi is sulking because it can’t display the error text…

No option to append logs IIRC, that said perhaps the result of a fail anywhere in the sequence should be to copy the log to failure log file so you can look at it on the next good.

Without a monitor, the Pi hangs. And, of course, I haven’t seen anything and still can not read the file. ShareFS has not started, so I can not look at thhe file that way, either.

Try your luck writing the file to the FAT partition then after a stalled start read it in something else. I spool the boot start up messages to a file which revealed the issue was to do with an EDID0 file which probably does not exist on the grounds that in a no monitor situation no EDID means no EDID! OTOH one can’t help feeling that the thing should have failed to a default 640×480 rather than death.

The original issue goes away on using a ‘proper’ MDF. No added lines are then required in CONFIG/TXT.

I spool the boot start up messages to a file which revealed the issue was to do with an EDID0 file which probably does not exist on the grounds that in a no monitor situation no EDID means no EDID! OTOH one can’t help feeling that the thing should have failed to a default 640×480 rather than death.

Seems sensible, fail to a bog basic resolution that at least displays something and doesn’t halt the boot in a headless setup.

OK. I now have some more info.

I gave up on Harinezumi and edited some debug entries into the Choices PreDesk and Dektop files.

The fault lies somewhere in the Choices Desktop block of code labelled “!Boot 0.72 Auto Tasks”. Remove all those lines and the headless boot then works. File Sharing, WebJames, Igor, etc.

Shouldn’t be too difficult to track down which line is the culprit, but I have run out of time tonight.

Interesting what those lines do that I have not missed – headless or otherwise :)

The fault lies somewhere in the Choices Desktop block of code labelled “!Boot 0.72 Auto Tasks”. Remove all those lines and the headless boot then works. File Sharing, WebJames, Igor, etc.

and

Interesting what those lines do that I have not missed – headless or otherwise :)

Lots of Filer boot actions (unlikely to glitch things) and one line of filer Run

The question that comes to my mind is why the block starting Resolver comes after all that stuff. Will it work with that block moved before the Auto Tasks block?

No option to append logs IIRC, that said perhaps the result of a fail anywhere in the sequence should be to copy the log to failure log file so you can look at it on the next good.

Seems like a logical plan, though I’d never encountered the issue of a headless display before.

That said, I’d await boot up.
Then I would press F12 and ^G. It should beep.
Then *Copy $.!Boot.BootLog $.Failed
Then reboot with monitor and read the text. Or, if some sort of server started, pull the file onto another machine. Whatever.

You can blind type, right? Was a useful skill to learn in the early days with all the monitor types and sync options…

Rick – is there any mileage in opening a second file (perhaps in Root?) with a name derived from the time/date to duplicate the LogFile – might cope with the unfortunate situations described above! … juste une idée !