Partition Manager

233.57GB – Unallocated 223.57GB (This is a fully formatted 240GB filecore SSD)

I’ve taken a quick look at HForm to see what it’s doing. Line 2826 of PROCWriteDOSBootSec writes an MBR signature, but it doesn’t write a valid partition entry to &1BE.

Strictly speaking, my code is correctly reporting the drive as unallocated and HForm should either write a valid partition entry into the MBR – or not write the MBR signature. I’m not quite sure how to work around this, I’ll have to give it some thought.

Has a partition type been decided for RISC OS?

Yes, as Steve’s pointed out there’s an officially registered (I assume) MBR type (AD) and PartMan contains a GUID (656C6946-6F63-6572-5479-706530303031) for GPT we should use. The GPT GUID doesn’t need to be officially registered, the standard allows you to make it up.

The linked page for ADFS is horribly out of date, describing it as it was circa RISC OS 3.1!

Strictly speaking, my code is correctly reporting the drive as unallocated and HForm should either write a valid partition entry into the MBR – or not write the MBR signature. I’m not quite sure how to work around this, I’ll have to give it some thought.

Submit a fix for HFORM so the legacy utility doesn’t produce duff partition entries, and perhaps allow PartMan to perform a non-destructive “fix” for existing partition entries?

A SCSI pen partitioned with the ROOL PartMan gtptest tool as described here shows as unknown &EE

Try v0.15, I’ve corrected an issue with the protective MBR check.

It does, the two partitions are seen.

On the RPi4B the 120GB SCSI SSD shows as unallocated and the 2GB unpartitioned

Does the 120GB contain a partition table or is it fully FileCore?

It is fully filecore, verified with GParted which only shows one unallocated space.

Regarding the mock up, Any chance of removing the slabbing.

Might it be helpful, particularly during development, but also subsequently, to provide a text file output – useful for reporting back displayed results?

Regarding the mock up, Any chance of removing the slabbing.

Which part is not Style Guide compliant?

Using PartMgr 0.15 on ARMX6 5.29 and PartMan unplugged.

SCSI::4 224 GB SSD shows:
MBR 223.57GB and 223.57 Unallocated.

SCSI::1 64GB Stick shows:
MBR 58.41 GB and 58.41 Unallocated.

SDFS::0 128GB Micro SDCard
MBR 119.08 GB and 119.08 Unallocated.

SDFS::1
Does not display but is a 8GB Mcro SDCard in ADFS format to 7.21 GB.

Hope this helps.

v0.17 now up for testing. It now detects the FAT version using Microsoft’s approved method, finds the FAT volume name in the Root Dir, shows free space on FAT32 and supports full disc FileCore created with HForm.

Submit a fix for HFORM so the legacy utility doesn’t produce partition entries

That’s the problem. It needs to add a protective MBR that covers the whole disc.

Any chance of removing the slabbing

I’m not sure I understand what you’re asking.

Might it be helpful, particularly during development, but also subsequently, to provide a text file output – useful for reporting back displayed results?

It’s on my list of things to do.

… Does not display but is a 8GB Micro SDCard in ADFS format to 7.21 GB.

Hopefully all your drives will now report correctly under v0.17

Thank you for the update (v0.17), the following occured after giving it a quick test.

Parameters not recognised in “add_drives_SCSIFS” at line 81"

Using PartMgr 0.17 on the Titanium the ‘Capacities’ of unpartitioned SCSIFS and SDFS drives are wrong. SCSI::2 is a 16GB pen, SCSI::0 is a 128GB pen and SDFS0::0 is a 128GB card. The "Free’ values are correct. (SCSI::1 is the ROOL PartMan partitioned pen.)

On the RPi400, which uses a SystemDisc partitioned SD card, also the Fat partition does not appear.

Hope this helps, and with thanks.

The partition entry for the filecore part of an overlapping FAT/filecore partition pair will only show the exclusive bit of the filecore partition.

the ‘Capacities’ of unpartitioned SCSIFS and SDFS drives are wrong.

Isn’t most of that the difference between GB and GiB?

• A 16GB drive would be 14.9GiB
• A 128GB drive would be 119.2GiB

Isn’t most of that the difference between GB and GiB?

I am referring to the Capacity as shown in the Capacity column and the yellow bit of the display, not the value in the left hand icons.

Parameters not recognised in “add_drives_SCSIFS” at line 81"

Try v0.18, it’s failing whilst trawling the FAT Root Dir for the Volume name.

the ‘Capacities’ of unpartitioned SCSIFS and SDFS drives are wrong

That’s for the screenshot, very useful as I can immediately see there’s an issue with the FileCore partition sizes. See if v0.18 fixes that.

On the RPi400, which uses a SystemDisc partitioned SD card, also the Fat partition does not appear.

It wont appear if there’s no matching partition table entry. It will treat it as a full FileCore drive.

656C6946-6F63-6572-5479-706553303031

What are these partitions? I can’t find that GPT GUID to add a text description for it.

Thanks now with v0.18, it reports:
Disc not understood has it been formatted? in volume_info_FileCore drive no, partition at line 9

Disc not understood has it been formatted?

Odd, try v0.19. Its found a FileCore drive which doesn’t appear to be mounted. I’ve added a trap for that, but to figure out what’s failing it will have to wait until I add debug output.

656C6946-6F63-6572-5479-706553303031

What are these partitions? I can’t find that GPT GUID to add a text description for it.

The pen was partitioned with gpttest.

See RiscOS.Sources.FileSys.SCSIFS.PartMan.h.GPT

 //Defined Partition Type GUIDs (PTypeGUID)
//Unused Entry 00000000-0000-0000-0000-000000000000
//EFI System Partition C12A7328-F81F-11D2-BA4B-00A0C93EC93B
//Partition containing a legacy MBR 024DEE41-33E7-11D3-9D69-0008C781F39F
#define GUID_unused "00000000-0000-0000-0000-000000000000"
#define GUID_EFISysPartn "C12A7328-F81F-11D2-BA4B-00A0C93EC93B"
#define GUID_LegacyMBR "024DEE41-33E7-11D3-9D69-0008C781F39F"
// this below is a 'basic data partition'
#define GUID_WinNormal "EBD0A0A2-B9E5-4433-87C0-6866672699C7"
// 'INVENTED' Filecore type partition "FilecoreType0001"
#define GUID_Filecore "656C6946-6F63-6572-5479-706530303031"
typedef enum {GUIDNew,GUIDUnknown,GUIDUnused,GUIDEfi,GUIDMbr,GUIDWinNorm,GUIDFilecore} GUIDtype;

No luck with PartMgr 0.19, which fails to start with "Error from Partition Manager: Syntax error in “volume_info_FileCore(, )” at line 14".

It is probably the SD card tripping it up, I removed all the USB SCSI drives which left only the SD card on the Titanium, and the error still happened. I can’t easily remove the SD card, it is well buried inside the case.

P.S. Or not, the RPi4B reports ‘The disc drive is empty in “add_drives_SCSIFS” at line 79’.

HiJon,

PartMgr 0.19 gives:

The disc drive is empty in “add_drives_SCSIFS” at line 79.

ARMX6, 5.29, SCSIFS 1.36 (19 Aug 2020) with PartMan unplugged

I’m not sure I understand what you’re asking.

Personally I would get rid of all the slabs – but thats not going to happen. If you look at the yellow parts where it says Harddisk4, for example, they go down and down again like terraces in an open cast mine – I see David Pitt has the slabbing in the opposite direction.

Presumably selecting a partition will highlight the entry in the list below and vice versa so you need a way to highlight the partition in the upper section and lower section.

I would make the list look like a spreadsheet with pale lines separating at least the columns and the upper section a series of flat rectangles with a border which can be highlighted.

Just a thought.

Personally I would get rid of all the slabs – but thats not going to happen.

True. The samples in the style guide do “3D” as a hint to how the style is expected.

Of course for people who don’t want that level of fancy they would probably expect the 3D-window switch in Themes to apply to panes as well.

Not that I consider changing this utility to look like a spreadsheet to be a good idea.

PartMgr 0.19 gives:

The disc drive is empty in “add_drives_SCSIFS” at line 79.

ARMX6, 5.29, SCSIFS 1.36 (19 Aug 2020) with PartMan unplugged

Same thing here with 0.19 on my Pi 4 with a SCSIFS SSD. PartMgr 0.15 started up fine (although it had the same issue that andym reported above, with the SSD showing up as MBR Unallocated).

The pen was partitioned with gpttest

656C6946-6F63-6572-5479-706553303031 is not the same as PartMan’s GUID:
656C6946-6F63-6572-5479-706530303031

My guess is gpttest has a typo

Personally I would get rid of all the slabs

It’s an optical illusion, they’re borders! I would never have noticed unless you’d described it. If someone decided to change the definition from “flat border” to “3D slabs” without considering the consequences, its not my fault. I’ll have to write my own border code to fix it.

The disc drive is empty in “add_drives_SCSIFS” at line 79

Should be fixed on v0.21. I’d changed the code to use *_SectorDiscOp, which in hindsight was a bad idea as it can’t address large discs, I’ve switched it back to using *_DiscOp64