No more available space?

I recently installed RODirect’s version of RO 5.26 on my Rpi3B+. With it came NetSurf 3.9. I already had NetSurf 3.10 (DEV CI #5041). Both of these give up when I try to download anything from https://ci.netsurf-browser.org/builds/riscos/
saying there is not enough memory. In fact my SD card has 5Gb free and my SCSI hard-disc has 248Gb free. There was no problem with RO 5.24. Can anyone suggest what has happened?

I wrote the above with NetSurf from RISC OS, having earlier tried to write it with Chromium from Raspbian. That would log me in to the forum alright but when I clicked Save Reply it would ask me to log in again. I am writing this with Firefox-ESR from Raspbian, as an experiment to see if that fares any better.

Answer – yes it does. It is not clear to me what setting is causing the problem with Chromium.

Both of these give up when I try to download anything from https://ci.netsurf-browser.org/builds/riscos/

I tried to replicate the issue (RISC OS Direct, Pi 3B, Netsurf 3.9) but a test download of NetSurf-gcc-5041.zip from the quoted URL went smoothly.

It is possible that NetSurf was complaining about lack of RAM rather than disc space. My machine only had NetSurf (and StrongEd) loaded so was swimming in free space and I hadn’t visited any other sites with NetSurf before attempting the download: perhaps NetSurf’s 7772k WimpSlot needs a tweak?

(Incidentally, RISC OS Direct uses RISC OS 5.27 not 5.26 but I expect that was a typo on your part…)

Sorry, I meant 5.27. Increasing NetSurf’s Wimpslot to 2 Mb and decreasing the size of the RAM disk appears to make no difference. The error message comes immediately after clicking on a zip file.

The error message comes immediately after clicking on a zip file.

That sounds a lot like the bug with old versions of SparkFS that was mentioned here (so far only reported on machines with 4GB of RAM, but maybe it’s not directly related to the amount of memory in the machine)

Upgrade SparkFS to the latest version if possible, or try loading SparkFS manually

Another difference I have noticed between 5.24 and 5.27. In my boot sequence I put the command

*Key$Red  insert my-email-address

That looks a little warped. It is not a *Key$Red command. If you use Configure → Keyboard you can define commands to run for those keys … and Config sets OS variables called Key$Red etc. The necessary Set commands are added to Boot.PreDesktop by Config.

Anyone know about their status these days?

Works here, configured as Martin says from Configure Keyboard.

Keypress problem solved! There was stuff in $.!Boot.Choices.Boot.PreDesk that was remapping keys. I have no idea how it got there.

I too have SparkFS 1.45 so I don’t think that has anything to do with NetSurf’s inability to load zip files. However, I do move ScrapDir to RAMFS in PreDesk, and NetSurf can create huge log files there.
To download anything I have to do it in Raspbian and then move it across to RISC OS on a memory stick..

Works here with 5.27! Can you try another keyboard?
Fred Graute’s StrongKey app displays codes produced when keys are pressed, which may help to narrow down the problem.

Keypress problem solved! There was stuff in $.!Boot.Choices.Boot.PreDesk that was remapping keys. I have no idea how it got there.

Chances are it’s one of the RISC OS Direct modifications.

Chances are it’s one of the RISC OS Direct modifications.

Confirmed: RISC OS Direct loads KeyMapper, maps the left flag and the Menu key to be mouse MENU, and also maps the right Alt key to be a £ sign.

Confirmed: RISC OS Direct loads KeyMapper, maps the left flag and the Menu key to be mouse MENU, and also maps the right Alt key to be a £ sign.

That is terrible – a nasty clash with keyboard configuration.

Meanwhile I am in a pickle with NetSurf refusing to download. Worst of all, I cannot download a working version of NetSurf unless I use my Raspbian computer. So for an experiment I downloaded NetSurf-gcc-5020.zip and NetSurf-gcc-5041.zip to Raspbian for comparison. I chose the versions at random. I transferred them across to my RO 5.27 computer on a memory stick. Then I extracted the two versions, using the readonly !SparkFS (v 1.44) provided on the ROOL website and tried them. Both gave Application may have gone wrong errors. Internal error: undefined instruction at &004C24E8 and &004C32D8 respectively. That suggests to me something funny in the decompression by !SparkFS.

And here is yet more weirdness (it never rains but … ). In my $.!Boot.Choices.Boot.PreDesktop file I add a couple of lines to define some aliases: CRun, CBoot, … . On more than one occasion bootup did not terminate properly, saying Cannot find File CRun . So I look at PreDesktop and, blow me, my extra definitions have disappeared! Evidently some part of the boot process rewrites a default PreDesktop file under some conditions. So now I have set the access permissions of PreDesktop to Protected . Touch wood, it has not happened again yet.

If any of this nonsense rings any bells please give me your advice. Maybe I should revert to RO 5.24?

Evidently some part of the boot process rewrites a default PreDesktop file under some conditions

I noticed recently (well, 40 minutes ago if you must know) that Configure > Keyboard modifies !Boot.Choices.Boot.PreDesktop to save the current keyboard setting. Other configuration (etc.) utilities could be pulling a similar trick, so it isn’t necessarily the boot-up process that is modifying the file.

Probably not relevant, but it does remind me of the way that the Risc PC had two startup routines: one for “VRAM” and one for “NoVRAM”. This wouldn’t confuse the user of a real Risc PC (they’d only notice anything if they physically inserted or removed VRAM memory modules, and then they may just take it as a quirk of the upgrade process) but someone running RPCEmu or VirtualRPC could be tripping over it time and again while trying to get a recalcitrant piece of software to work.

I have reverted to RO 5.24. There were just too many problems for me with RO 5.27.

I have reverted to RO 5.24. There were just too many problems for me with RO 5.27.

Do you mean that, or do you mean with RISC OS Direct? Because RISC OS Direct, which is what you’re using, is not plain RISC OS 5.27.

If there really are issues with 5.27, by the way, helping ROOL identify them ahead of the release of 5.28 might be a useful thing to do.

Sorry, I mean RISC OS Direct. I downloaded the distribution from their site to try out. I quite like their new switcher sprite. But I found so many things not working: Messenger Pro, NetSurf’s downloading, SparkFS, keyboard configuration, … that I retreated. From my point of view the main advantage of the experiment was that I was forced to come to grips with emailing and downloading with Linux.

You should not be manually altering the PreDesktop file – IIRC it specifically says as much in it! The file is built/maintained by different parts of Configure.

If you want to add your own changes, please add an obey file to PreDesk folder or to Tasks, or (better yet) drag it into the “run at startup”.

Keymappings are there to ensure that menu is possible if using a two button mouse, and to cope with keyboards with only windows keys and no menu keys, although it sounds like someone has just included a “stock” mappings file (sounds a bit like an ARMbook one).

If you have other issues, it is best to discuss them with us and we’ll try to help. We’ve certainly had no other, similar, reports, but that doesn’t mean they don’t exist.

PS, please note that I wasn’t involved in the actual assembly of final RISC OS Direct image – you’ll note it doesn’t look exactly like a usual R-Comp/RCI disc image (based on Acorn’s RiscPC layout). I am, however, intending to do a pass over it in the next month to fix a few gremlins that have been reported (eg. turn off networking by default for Pi zero etc), although nothing fatal.

You should not be manually altering the PreDesktop file

OK. Thanks for this advice. Line 4 of PreDesktop (!Boot 0.72) comments | When modifying the file by adding a section of lines … , which does not give quite the same message. In fact the user-modifiability of RISC OS now presents a problem, which has grown over the years without receiving sufficient attention, IMHO. In theory all the stuff belonging to the distributor, which the user should not touch, should be confined to !Boot, leaving the rest of the filing system to the whims of the user. Practice is rather different from theory, as the heat and smoke following the emergence of !Packman attested. There is a gamut of possible practice, between leaving the user completely free (thanks to the Obey$Dir mechanism) and tying the user down to specific names and directory structures, as Unixes do (though every distribution seems to make its own choices). Users come in different sizes – those who want complete freedom and those who could never use it – the technophiles and technophobes respectively.

!Boot has grown to a massive size, and I think it needs more thought and modularity, so that the user can more easily understand what its components do. RISC OS, being a child of its era, tends to prefer things flat (arrays rather than trees); witness modules, system variables, how SWIs expect data. Now that I have used Raspbian a bit, I have come to appreciate how sophisticated Debian’s package management system is. In my view RISC OS does not need all that complexity. It is !Boot.Resources that contains all the bloat. Stuff gets put in there by the distributor that may never get used. As more applications come along compiled with gcc more shared object libraries will be stuffed into SharedLibs, without any means of removing them when applications are deleted. Some mechanism of recording dependencies is needed.

I apologize if these remarks bring groans from ROD, ROOL and others. But I do think some clear thinking is needed about ownership of files, names, system variables, .. in a single user system like RISC OS, without going to the multi-user complexities of Unix.

!Boot is the reason I’m reluctant to upgrade systems that work. Having to download a new hard disc image and then rebuild all the stuff that is added to !Boot is a right pain in the proverbial. I have a stack of pi’s built into a case. It’s difficult to extract the SD cards as it means dismantling things. I really need to move them from RO5.23 to 5.24 or higher, but I haven’t found an understandable explanation of how to do this in place.

!Boot has grown to a massive size, and I think it needs more thought and modularity, so that the user can more easily understand what its components do.

Yup. This issue seems to come up every so often. Everyone seems to agree that !Boot has become sprawling, making upgrading a pain, but unpicking it all would doubtless be a complex job. I’m always surprised when I hear how much stuff people (including those putting together distributions of software) stick into Resources. Apps really don’t belong there at all, IMO – it’s a place for things like the Unicode resources and Fonts, and adding stuff to the folder should really be done via the Configure interface rather than dragged in. The more cruft there is in there, the harder it is to diagnose when something goes wrong. Still, some people like hiding stuff away, for some reason.

If !Boot were to be refashioned, I think it would be best to do it in baby steps. Two things I’d like to see are:

• Moving Configure back to being an app in its own right, sitting in the Apps directory. That wouldn’t make a massive dent in !Boot’s sprawl, but it would be more obvious to users where to find it, and it’d be a start.
• Moving Choices out of the !Boot folder and into its own !Choices folder, sitting next to it in the root directory. This would really help when upgrading, as you could replace your !Boot folder without worrying that all your prized settings will be lost.

That still leaves all the really thorny stuff in place, such as how to handle shared libraries etc, but I think more modest changes like this would chip away at the mountain. It would also clarify (in my head, anyway) the key conceptual scheme that’s currently a bit muddled: !Boot would be for essential OS resources and extensions (something that the average user shouldn’t ever really want to fiddle with), and !Choices would be for user settings, which would all be set via Configure and various Apps’ choices interfaces.

I really need to move them from RO5.23 to 5.24 or higher

It’s theoretically possible to go from 5.23 RC15 to 5.24 by using the InSituBootUpdate file in the 5.24 HardDisc archive, then copying the 5.24 ROM and firmware to !Boot.Loader, but no guarantees are offered.

Upgrading from builds older than RC15 (and/or upgrading to 5.27) will be more time-consuming. I put together a wiki page on this subject but it runs to several screenfuls of instructions: rather more than I originally envisaged.

Looking ahead, 5.28 (when it arrives) should have another InSituBootUpdate file, so upgrading from 5.24 to 5.28 should be relatively straightforward. There won’t be an easy way of going straight from 5.23 to 5.28, so you’ll have a choice of the difficult way (as mentioned on the wiki page previously mentioned) or doing two upgrades: first to 5.24, then to 5.28.

Splitting up !Boot (so that stuff like Choices – and perhaps !Scrap – live elsewhere) certainly gets my vote. Making that part of the 5.28 InSituBootUpdate would further simplify the upgrade process.

It’s theoretically possible to go from 5.23 RC15 to 5.24 by using the InSituBootUpdate file in the 5.24 HardDisc archive, then copying the 5.24 ROM and firmware to !Boot.Loader, but no guarantees are offered.

Thanks. I’ll give that a try.

What happened to 5.26?

What happened to 5.26?

The Pi version is available via NOOBS Lite but the only substantive¹ change from 5.24 was the switch of licence from Castle to Apache. A ROM download never appeared on the ROOL Downloads page.

¹ The only feature change was to add support for the Pi 3A+ (and thanks to another bug, Pi 3A+ owners are advised to use 5.27 anyway). In other respects it was essentially a rebuild of the 5.24 ROM.

then copying the 5.24 ROM and firmware to !Boot.Loader, but no guarantees are offered.

That’s sort of what I do, but I do it manually. I run 5.23 (normally), 5.25 (rarely), and from time to time a recent build of I want to test something.
I use the same !Boot stuff throughout.

What I do is create a directory called, say, “523”. Into that goes the 5.23 ROM image and the firmware. Then I upgrade the firmware (if necessary), install a new OS (as “RISCOS/523” or “RISCOS/525” etc, and tweak the config/txt file accordingly.
Once a selection are available, switching around is a matter of simply changing the configuration to point to a different ROM, then rebooting. Mine all appear happy with the same firmware.

I don’t upgrade !Boot. Because, as has been pointed out, it’s a pain in the proverbial. I may be wrong, but I think the only thing that doesn’t work is the detection of the USB network adaptor, but then my boot really hails from around 2017 or so with patches and kludges aplenty since then.

It’s important to have backups, because then it’s a simple matter to pop the card into an SD reader (PC, mobile phone, tablet…) and just copy stuff back to get it the way it was.

The more cruft there is in there, the harder it is to diagnose when something goes wrong.

Ah, but if you have a thirty year habit of messing with system boots and a useful tool that will allow the boot to complete rather than keeling over dead at the first hiccup, it’s actually pretty easy to diagnose problems because you tend to know where everything is and generally why it is there.

Still, some people like hiding stuff away, for some reason.

System resources (including user settings) are system resources and should be tidily away somewhere and not polluting the directory viewer.

Confused the hell out of a friend many years ago. My machine booted normally but there was no boot stuff, system stuff, none of it.
Actually it was all there, but I was using Thomas Ollsen’s Filer+ so I set it to be hidden. ;-)

Moving Configure back to being an app in its own right, sitting in the Apps directory.

Great. I really wish the Apps pseudo filing system supported directories so things could be better organised than “everything all lumped in together”.

That wouldn’t make a massive dent in !Boot’s sprawl,

They would barely make a tiny pock mark, never mind an actual dent.

but it would be more obvious to users where to find it, and it’d be a start.

Some of us have our systems set up so that a right click on Switcher starts up configure.

Moving Choices out of the !Boot folder and into its own !Choices folder, sitting next to it in the root directory.

That ought to be doable right now. Create !Choices, give it a pretty icon, then find whatever creates Choices: and Choices$Write (BootVars?) and tweak it.

That still leaves all the really thorny stuff in place,

The thorny stuff isn’t the shared libraries issue. The thorny stuff is that godforsaken mess of 310, 350, 360, 370, 400, 500, 510, and 520.
I think it would be useful if Boot had a way to build a simple process that is tailored to the machine in question, and then archive or discard all the other crap. It’s rather annoying to have to wade through a pile of hook directories to try to work out what gets run and when.