11/10/22 Pi ROM won't mount desktop

Raspberry Pi 4, ROM 11/10/2022

Error:Directory ‘!*’ not found (Error number &D6)

@ CLI. Repeatable. Reverting to 04/10/22 ROM is OK. Modules moved or summat? Not tried the BB -xM version.

Same here RPi 2 Model B.

Did *Desktop and reverted to last (reserved) version which is renamed rather than deleted in my upgrade process.

I think it is linked to the recent changes to AddApp in BootCmd.

The problem is the test at line 329 “if (!found) …”. Two problems here:
1) found is updated on each call xosgbpb_dir_entries() and be set to 0 on the last call of the loop
2) in the first place the original code does not report any error is no match is found

I can confirm that the same error also happens on a Titanium.

The problem is caused by the line in PreDesktop …
IfThere Boot:^.Apps then AddApp Boot:^.Apps.!*

Missed that when helping with testing, as I only had a module to test!

Can you check whether introducing Harinezumi from Rick Murray “fixes” it such that the boot completes?

If it does “fix” things to produce a completed boot sequence, then there is a case for building the feature into the standard boot.

It’s all about bringing things to a working state, with logging of any errors and notifying the user.
I’m sure !Reporter would probably do the same, but smallest, simplest solution is my thinking.

If it does “fix” things to produce a completed boot sequence, then there is a case for building the feature into the standard boot.

Yes, a nice Configure option for pre-desktop boot-logging would be much easier to use than having to install Harinezumi by hand. I have used it to great advantage in the past, but am loath to risk messing-up my current boot by user-error just at the moment. I am, though, prompted by this failure, preparing a “Revert” script to simplify further the reversion to a previous known-working ROM image.

It really is surprising how rare a failure to boot with development roms actually happens! A tribute to the developers!

then there is a case for building the feature into the standard boot.

Don’t hold your breath. Harinezumi just celebrated its tenth birthday. We’ve had this discussion plenty of times since then…

preparing a “Revert” script to simplify further the reversion to a previous known-working ROM image.

This assumes you can get to a working OS.

What I do is rename riscos.img to be riscos.old (and the previous one riscos.olx).
In this way, if there’s a problem I can copy the backup as the active version in RISC OS if it boots, or pop the µSD into a card reader and do it with my phone if it doesn’t boot.

But as you say, failures are rare. I think the last one was an incompatibility with firmware that affected video…or something. Updated firmware fixed it.

It really is surprising how rare a failure to boot with development roms actually happens!

The pigeons are just pecking at the keyboard, but just occasionally one gets its beak stuck. If you’re a Pi user hopefully this temporary ROM solves the problem with BootCommands, please give it a go if possible.

Don’t hold your breath. Harinezumi just celebrated its tenth birthday. We’ve had this discussion plenty of times since then…

Maybe¹ people are expecting to see an edit of the RO5 source? I mean, 10 years testing, and it broke nothing, so it has to be OK, yes?

¹ Hey laid back mood here, otherwise it could be you’re being ignored.

Returning to the actual topi.=c.

If you’re a Pi user hopefully this temporary ROM solves the problem with BootCommands, please give it a go if possible.

The temporary Pi ROM does fully boot to the desktop, but there does seem a be another issue a leaf after a path does not work..

*set test$dir SDFS::SD32gr.$.Apps
*set test$path SDFS::SD32gr.$.Apps.

*addapp <test$Dir>.!Speedo 
*
*addapp test:!Swipe
Directory '!Swipe' not found
*
*addapp test:^.Apps.!Swipe
*set test$dir SDFS::SD32gr.$.Apps
*

Maybe1 people are expecting to see an edit of the RO5 source? I mean, 10 years testing, and it broke nothing, so it has to be OK, yes?

Not aimed at any specific individual, but… anyone ‘expecting’ would be well-advised to take the time to learn how to: get the source code from GitLab, make the changes necessary, and submit a Merge Request. There is very little stopping people from doing this. It seems to me that the number of people who commit changes to the wiki or GitLab is dwarfed by the number who keep asking for things, or showing off private things.

Maybe I’ve read it wrong, but it’s a general feeling I pick up from these parts!

make the changes necessary, and submit a Merge Request.

There isn’t really any one thing to modify. What Harinezumi does is to hijack the boot script and perform the actions itself logging whether or not it was successful. It’s more of an extension to current behaviour than a replacement of anything specific (given that various parts interact here).

It doesn’t bother with the post desktop stuff under the assumption that if you get that far, the important initial stuff has been done and something ought to be able to give sensible errors by that point.

Harinezumi’s sources are available. Feel free to use them however you like. They’re released under CDDL.
http://heyrick.ddns.net/files/harisrc009.zip

or showing off private things.

Yeah, that is a bit agitational, isn’t it?

I mean, 10 years testing, and it broke nothing

Actually, there has been some minor brokenness along the way. That’s why we’re at version 0.09. ;)

but there does seem a be another issue a leaf after a path does not work..

Recent change in the source for that kind of thing IIRC

*addapp test:!Swipe
Directory ‘!Swipe’ not found

I can confirm I have seen that here … but very similar commands work!
Now need to establish what difference is causing the problem.

anyone ‘expecting’ would be well-advised to take the time to learn how to: get the source code from GitLab, make the changes necessary, and submit a Merge Request. There is very little stopping people from doing this.

RISC OS client that is actually capable of doing this? (I don’t know the current state because I don’t remember hearing any more about it, but last time I checked it couldn’t actually do the full set of required actions.)

Also that git is absolutely incomprehensible, and I’ve not yet found a tutorial that simply shows check out, modify, check back in. And the names used for git operations are different from all other source control systems.

Also that git is absolutely incomprehensible

You’re not the only one. I don’t get it either, and this really fills me with confidence…

See also: https://twitter.com/agnoster/status/44636629423497217

The XKCD says it pretty accurately.

I’ve even had a RISC OS patch stalled using the web client because I didn’t assign it to the correct entity. I had no idea that I wasn’t doing it right.

This is into the territory of Wish Lists rather than bugs, but…

I’d like to see a RISC OS git client that allows a check out and a check in, simply, and with all the correct defaults already there.

If there’s a question about what any of the defaults needs to be, we’d need a place to find them. (Where would that be?)

This !* issue is present on other builds with the latest update to the BootUtils module. Reverting it to the previous version, hash 06b1ca4, resolves this. This is on ARM v8 using the RK3399 cpu.
What testing was actually done for this commit prior to the merge please?
and.. Rob… What are the plans to rectify the issue please

The temporary Pi ROM does fully boot to the desktop, but there does seem a be another issue a leaf after a path does not work..
*set test$dir SDFS::SD32gr.$.Apps
*set test$path SDFS::SD32gr.$.Apps.
*addapp test:!Swipe
Directory ‘!Swipe’ not found

An interesting case that didn’t turn up in earlier testing, a vital missing colon added to another Pi ROM here to try.

So what are the mods please, so I can also try?

a vital missing colon added to another Pi ROM … to try.

That sorts it. The bcm14Oct ROM fully boots and the test case above, addapp test:!Swipe, is fixed.

It booted to the desktop for me, not immediately, but following a further restart. The initial error message was boot device not ready.

@Sprow Any chance you could add the line editor fix? Thanks.

It seems that Sprow’s corrections of 14th Oct have not made it to the main ROM image, as today’s new build is displaying the original fault(s) described in this thread.