Partition Manager feedback

[JonAbbott]

I'll be formally releasing v1.01 at the end of next week, at which point I don't plan on making any further changes for the forceable future as I need to move on to phase 2.

Now is the last chance to get any changes/bug-fixes raised and tested.

[JonAbbott]

v1.02 23/11/23 beta attached. now released

It should now support both SCSI and SDFS as the Pi boot device, but I've yet to figure out how to switch the boot device to SCSI on first boot.

Changes:

• SCSIFS will now fall back to scanning every LUN if REPORT LUNs returns zero
• Pi Boot drive now adds Hook files into all RO5*Hook folders
• Fixed a potential buffer overrun when extracting ZIP contents
• Fixed a buffer overflow caused when a bad CD is mounted under CDFS
• Modified Hook files to support SCSI or SDFS as the Pi boot device
• Resolved an issue where Pi Boot files were being created in the wrong folders (bug introduced with the change above)
• When formatting a FileCore E layout, it wasn't warning if the requested volume size is >= the FileCore limit (512MB - 1 LBA)
• Added Hardware specific settings to the debug output for FileCore volumes
• Added additional FileCore layouts when formatting a volume on a FileCore partitioned drive, to allow the drive to be moved to ADFS (allows RISC OS 3.x drives to be formatted under RISC OS 5)
• RISC iX partitions will now be retained when reformatting a FileCore volume that is hosting RISC iX
• Now shows an uninitialized RISC iX area if a drive has been partitioned with SCSIDM but hasn't had RISC iX installed yet
• Active RISC iX Unix partitions are now determined by their length
• ST506 drives were not being detected correctly
• DiscOp reads were failing on ST506 drives because an alternative DiscRec was not being used
• Fixed an issue that was causing ST506 Boot records to be read incorrectly
• ST506 geometry is now worked out by testing the heads first, followed by the sectors per track and finally the disc size
• Formatting a volume as FileCore now sets the hardware specific parameters required for ADFS to work. These are only overridden if the partitioning scheme is Simtec or HCCS
• Three FileCore format layouts are now available: E. E, Risc PC. E+
• When formatting a partition as FileCore, the partition size is now checked to be within the size supported by both the host system and the limits of the chosen layout. If the size exceeds either, it will prompt to reduce to the maximum size supported. E=512MB. E, Risc PC=4GB. E+=256GB (512n) / 2TB (4Kn)
• Reduced the list of available FileCore Allocation unit sizes to 3 values
• The Allocation unit size list is now updated whenever the format or layout are changed
• FAT12/16 now support more than 1 reserved sector
• Replaced all information dialogues related to download errors with retry dialogues
• Added checks for disconnects after every attempt to download from a stream
• Added keep alive's during downloads when no data is received within one sec
• Now scrapes the ROOL and NetSurf websites to retrieve the available versions of RISC OS, HardDisc4 and NerSurf
• Unwanted directories were not being skipped when extracting streamed ZIP's
• FileCore size limit check now accounts for the start LBA. ie a partition that starts 64GB into the disc will be restricted to 192GB
• Corrected FileCore version check for idlen 21 support to 3.75
• New FileCore partitions are now capped within the current FileCore limit
• IDE Op's are now used for all IDE drives hosted under ADFS
• If a connect to a URL failed when trying to extract a streamed ZIP file, it was reporting a ZIP contents error, instead of reporting it failed to connect
• Now downloads the relevant package lists to obtain the URLs for the Pi Boot packages
• Corrected FileCore version check for idlen 19 support to 3.16
• Removed unsupported layouts on FileCore versions below 2.91 (RO 3.60)
• ADFS drives now track the Controller type they're hosted on
• When identifying FileCore it wasn't using the LBA size to read the defect list, which generated an error with 4Kn drives
• Resolved an issue with DNS on the initial Internet config on Pi Boot Drives

[paintings]

I've yet to figure out how to switch the boot device to SCSI on first boot.

That could be tricky as you won't necessarily know which drive number the SCSI device will have.

You have two options: (1) ask the user, or (2) make an educated guess based on the drive number PartMgr is currently writing to (if it's writing to drive 0, 1, 2 or 3 assume the SCSI device will be drive 0 on boot; if it's 4-7 assume drive 4 on boot).

Once you've settled on a drive number you can copy a suitably-adjusted CMOS file to the boot partition. For drive 0, CMOS would need the following commands applied:
*Configure FileSystem SCSI
*Configure SCSIFSDrive 0
For drive 4, you would need:
*Configure FileSystem SCSI
*Configure SCSIFSDrive 4
You could have these pre-saved (e.g. as "drive0.CMOS" and "drive4.CMOS") ready to be copied over CMOS in the boot partition.

Don't forget you also need an Obey file in !Boot.Choices.Boot.PostDesk (create the directory if necessary) to *SaveCMOS <Boot$Dir>.Loader.CMOS on every tidy shutdown, as RISC OS will still be trying to update the CMOS file in the "wrong" place (i.e. on the SD card).

[JonAbbott]

I've yet to figure out how to switch the boot device to SCSI on first boot.

That could be tricky as you won't necessarily know which drive number the SCSI device will have.

It's not really a problem I need to solve with PM...the OS needs to detect and choose the boot drive itself.

I don't like any of the hacks I've had to inject into !Boot to work around OS shortcomings (NIC detection, setting the Time, creating a default CMOS file) and I certainly don't want to get into creating the CMOS file outside of the OS.

The simple option is to just cover the manual steps to switch to SCSI in the !Help and a KB.

[JonAbbott]

I've updated the v1.02 build above as it was creating Pi Boot files in the wrong folders.

[IanJeffray]

I've updated the v1.02 build above as it was creating Pi Boot files in the wrong folders.

With 1.02, trying to format as E throws a "restricted to 512MB" warning. Surely this should only be for RISC OS 3.1 ? Previous PMs didn't have this limitation. (Using ADFS/RO 3.70 just now...)

[JonAbbott]

With 1.02, trying to format as E throws a "restricted to 512MB" warning. Surely this should only be for RISC OS 3.1 ? Previous PMs didn't have this limitation. (Using ADFS/RO 3.70 just now...)

Thanks for the report.

I'm still messing with that particular piece of code which is to cover people moving drives between machines. Regardless, it should be asking if you want to restrict the size for compatibility with pre RO3.6 instead of assuming.

[IanJeffray]

it should be asking if you want to restrict the size for compatibility with pre RO3.6 instead of assuming.

May also be useful to actually disable E+ as an option if it's not running on at least RISC OS 3.8 ? Or at least a warning that it won't be readable on the OS you're running on.

[IanJeffray]

Having all manner of weird issues with PM with a 1GB DOM in a RiscPC, using ADFS. Yes, I know ADFS is cack, but I'm trying to find a cheap solution for 'something' to offer as a RiscPC storage solution without using a podule.

Anyway, PM barks all manner of disc errors during format. Format with HForm and it's fine. Go back and re-init and re-format with PM and get "The disc write succeeded, but the data did not match when verified" error from PM. Then "Write failed ADFS 4 00000000". Oh great. But the disc -seems- to be ok after that - it verifies. I don't know if I should risk using it after this, or go back to HForm. Rerunning HForm gets "This drive does not currently have a valid ADFS format" warning in HForm and asks me to select the shape. Something's not sitting equally between what HForm does and what PM does, it seems.

I should add, I've tried multiple DOMs - it's not faulty DOM hardware (works fine with ZIDEFS / ArcIn32)

[JonAbbott]

PM barks all manner of disc errors during format. Format with HForm and it's fine.

PM validates all writes, HForm doesn't. If PM is reporting disc errors, then there's an issue.

Go back and re-init and re-format with PM and get "The disc write succeeded, but the data did not match when verified" error from PM. Then "Write failed ADFS 4 00000000". Oh great.

Sounds like ADFS needs patching to work with that DM. Either the write or read didn't work...which sounds suspiciously like DRQ timing issues.

Have you tried live-patching ADFS with the RiscPC patcher in my Stardot post prior to formatting?

But the disc -seems- to be ok after that - it verifies.

A verify simply checks for sector errors. I probably wouldn't trust a verify if it wasn't done immediately after a write to confirm the write was successful.

I don't know if I should risk using it after this, or go back to HForm.

I wouldn't use it myself. HForm is giving you a false sense of security.

Rerunning HForm gets "This drive does not currently have a valid ADFS format" warning in HForm and asks me to select the shape. Something's not sitting equally between what HForm does and what PM does, it seems.

HForm is somewhat archaic in that if the drive is already formatted, it attempts to read the geometry from contents its previously written to the drive - not the drive IDENTIFY. It's a throw-back to ST506 where the geometry isn't defined by the drive, so it's written during a format.

The format code in PM is the HForm code with bug-fixes and some tweaks to support partitions, so in theory a FileCore partitioning/FileCore format drive created using PM should be identical to an HForm format.

I don't recall what I did with the code that writes the HForm geometry to the drive - its probably still there, although its also possible I removed it as it's not relevant with modern drives - or its only written to ST506 drives.

As there's an open request to support moving drives to ADFS, I have heavily modified the code that writes the FileCore Boot record - perhaps wait for me to release that to see if this problem still occurs. It is specific to HForm though and does not affect using the drive.

I should add, I've tried multiple DOMs - it's not faulty DOM hardware (works fine with ZIDEFS / ArcIn32)

I wouldn't suspect the drive as faulty - I'd suspect ADFS as the cause of the issues.