22nd Dec Disc build issues

The HardDisc image dated 22nd Dec 11, just like the 17th Dec one, trashes my !Boot set up and I get a ADFS is missing errors as it defaults in to the standard screen mode and number of folders created in a RAM Disc.

As it does not complete the boot sequence I lose networking etc as well.

Has someone being adding in changes for the Raspberry Pi or “live” RISC OS?

Doug

I assume it’s something to do with the changes made on December 12th to support booting from read-only file systems.
(For the OMAP3 Live build)

I’ve uploaded a zip file containing a build from December 11th.

HardDisc zip

Rob,

Your 11th Dec !Boot image works OK so I guess it does point to something in the changes made to introduce a OMAP3 live build.

Doug

Any chance you could be more specific about “trashes my !Boot set up” – do you see errors before the ADFS stuff? Have you tried narrowing-down the culprit file? I’m away from any RISC OS machines for a while so it’d be great to get some hints as to where the problem is. We were quite careful to not change behaviour of the various boot sequence components in non-read-only booting but something could easily have slipped through the net (and I’ve only tested on read-only booting recently!).

I’ve had a quick look at this.
It is something to do with the changes to !Boot for booting from read-only systems.

This change seems to break !Boot – https://www.riscosopen.org/viewer/revisions/logs?ident=1323713180-113201.html

If I replace:
!Boot.Utils.BootVars
!Boot.Utils.NetChoices
!Boot.Utils.SetChoices
with older versions, the latest harddisc4 image works as it should.

It looks like when booting from a read-write filesystem, !Boot seems to create a ramdisc, starts copying files, then failes as the ramdisc is too small.

looks like […] then fails as the ramdisc is too small

So if it could use an automatically resizing DA (like Memphis) wouldn’t that help? But then, if that "isn’t the best way of doing things" does that preclude binning RAMFS?

Trevor

The issue is not about the RAMdisc but why is the latest build broken in that it attempts to build a RAMDisc set of folders based on if the system had no read/write attached media.

The issue is seen when the latest HardDisc image is put on either a Beagleboard or Iyonix which both have suitable media i.e HardDiscs.

The “Live” solution should be able to sort out if there is a suitable media attached and act accordingly.

Doug

Thanks – note, sorry but I’ve not actually tried the build myself. If Boot$ReadOnly is 1 when it should be 0, doesn’t that mean the check for ability to write choices identified by Rob is tripping up?

What happens if Boot$ReadOnly is corrected to 0 before running of NetChoices and SetChoices?

I tried setting Boot$ReadOnly to 0 in both the Boot and Run files for !Boot,
This didn’t seem to have any effect :(

The next release of the HardDisc4 build should hopefully fix this (some time tonight).

Fixed and on the site.

Cheers Steve!