ShareFS with headless RPi 3 on RC15

Having kicked up a bit of a fuss about the new !DBSRscs app in the 13th April RC15 build causing a headless boot to fail, I decided to see why as the concensus above is that it should do no harm as it only tries to load an IconSprite.

The actual problem is that it tries to load a Sprite file which does not exist. Give it a Sprite file to load and everything is fine; the headless boot then works (although what it might do with the contents of that file is another matter).

The actual problem is that it tries to load a Sprite file which does not exist.

Ah, it has a !Sprites22, but when running in a low res mode, the OS will want the !Sprites file (which doesn’t exist) rather than !Sprites22 (which does). Surprised that one got through ROOL’s testing before being accepted!

Following on from my investigations as to why my 13th April copy of RC15 did not complete a headless boot, I have been looking at what else is in the boot sequence which has been described above as ‘fragile’ and ‘in need of being more robust’.

It is mostly just a question to help improve my understanding – but, why do we need all of the ROnnnHook hook directories? I have removed them all except the latest (RO520Hook) on this system I am using now and everything which I need still works (Internet, WebJames, File Sharing, Netsurf, VNC Server, Avalanche, Igor, Nettle, RDPclient, etc, etc).

Obviously I needed to delete the corresponding Filer_Boot lines in !Boot.Choices.Desktop. But very little other editing. My file now only has 16 lines (ignoring comments) with only 3 ‘Repeats’ needed and I am confident it could be simplified even futher. Over 200 files deleted, saving 20 Mbytes and giving a noticeable improvement in desktop boot time.

Am I missing something fundamental?

It is mostly just a question to help improve my understanding

[snip]

Am I missing something fundamental?

Yes and no!

The whole raison d’être of the “universal boot” is – that it is just that – universal!

Once you remove bits that “aren’t necessary” it ceases to be, well, universal – and becomes a sub-genus locked to a particular machine.

In these modern days of gigantic storage, isn’t it worth the waste to maintain universal transferability?

In the “olden days”, to which I find myself referring increasingly frequently, when I had a 25MB HD on an A3000, it might have been more of an issue! But now … ? Really?

PS Well done, tho’, for identifying the problem!

With that said, does it still “need” to be universal? Bear in mind that there’s already a separate System app that needs to be installed into Boot if you’re not running OS 5 – would it make sense to move all the pre-OS 5 stuff into the System download so that Boot is pared down on modern computers?

Of course, as noted, it doesn’t really matter much with today’s storage capacities.

when I had a 25MB HD on an A3000, it might have been more of an issue!

On reflection, I think it was 20MB, which I see is what John S saved by “rationalising” his Boot.

Boot used to be (floppy days) a single file of type Desktop in which you could place the Run paths of things you needed to boot/have running, the Desktop file not halting if something “barfed”.

When things became too complicated, with some stuff needing loading before the desktop was entered, some after, the “new” Boot was conceived, and eventually developed into the Universal Boot, something which will work on any RISC OS machine that has a hard disc within its physical limitations.

there’s already a separate System app that needs to be installed into Boot if you’re not running OS 5

I don’t follow this – the System app is in Resources in the Universal Boot.

We used to need a separate System app on a floppy in olden times, but no longer!

Most of the stuff in System is redundant as well, but, once again, there for compatibility on/with earlier systems.

I don’t follow this – the System app is in Resources in the Universal Boot.

Yes, but it doesn’t contain everything needed for pre-OS 5 systems. For example, it doesn’t include CLib. There is a separate “System resources” zip containing the rest of the System app.

Ah – the PlingSystem archive – I’d forgotten about that!

So the universality is already compromised! Perhaps you have a point, then.

Perhaps you have a point, then.

Given the age of the older machines, one wonders if it’s coming time to take a snapshot of the universal boot, and then begin to strip out the older 26 bit realm stuff and look if the boot method could be improved…

OK… Oops!! Just been made aware of the issue by Andrew Conroy… Been hellishly busy so haven’t had time to read forum posts. Have already bodged a fix to my local copy this evening. When I’m happy with the icon, I’ll re-post the !DBSRscs archive to my DropBox account. Probably in the next couple of days.

Sorry again for the cock-up!

OK… Have generated the missing !Sprites icon. However, the SD Card in my Pi is currently flakey and in need of !DiskKnight’s attention, an update is req’d as my version from 2013 ish can’t repair bootable Pi SD Cards. It’s currently 10:45pm as I type this, so using the phone is probably not a wise idea (My serial No. appears not to be recognised by the web based automated system). Will continue with this in the morning and push an update to !DBSRscs sometime tomorrow. Additionally I will be at the ROUGOL show in person at the end of next month and will be happy to redistribute this update to all who ask for it.

… And yeah… I know a couple of days has turned into over a month, but I’ve been hellishly busy at work and just haven’t had the time to devote to RO lately.

Right… Finally I can provide this link to the updated copy…

https://www.dropbox.com/s/5jy6zvpx9xbkbc3/DBSRscs.zip?dl=0

Just extract the contents of the ZIP file over your existing copy and all will be fixed.

I tried a recent “Beta RPi ROM” (2018-01-28) and it also fixed the problem.

Going back to the original problem, where the Harinezumi log of the stalled boot was overwritten before it could be read – how about starting it something like:
Check if a log exists
If so rename it
Start Harinezumi

Even if this were not built in to Harinezumi, it doesn’t take much to add it to an obey file. Creating a rotating set of files is a little more work, and only needed if you wanted several prior logs to be available.

Even if this were not built in to Harinezumi,

<sigh>

This was fixed over half a year ago. If your logfile keeps getting overwritten, nothing is wrong. Your logfile will be renamed with a time suffix, then something did go wrong.
http://heyrick.co.uk/software/harinezumi/Versions.txt