Partition Manager

Is not an 4k drive. A normally 500GB SSD.
I have not initialized anything. I have try to format direct.
Now second try.
Have initialized MBR. Then I have try to format 256000MB as FileCore. I get an unknown partition. The size was correct, the rest unallocated.
At the end of the morning I format with HForm and wrote the MBR for the second FAT partition with PartiFC and format the second FAT partition with PartMgr. Now all is working fine.

initialized MBR. Then I have try to format 256000MB as FileCore. I get an unknown partition

I suspect the partition size was just over FileCore’s limit, so it probably initialised it correctly, but FileCore couldn’t subsequently read it. When you created with HForm, it will have capped the size down to the FileCore limit.

I’ll add a menu toggle and prompt when current FileCore limits are going to be exceeded.

I suspect the partition size was just over FileCore’s limit, so it probably initialised it correctly, but FileCore couldn’t subsequently read it.

I think not. 256000MB are 250GB (was a deliberately chosen value) and was correct displayed bie PartMgr but the partition itself was not usable.
HForm format the partition with 256GB = 262144MB.
What are the correct steps to format 256GB filecore on a 500GB device with PartMgr? Maybe “my way” is not the right one.

HForm format the partition with 256GB = 262144MB.
What are the correct steps to format 256GB filecore on a 500GB device

Question: Should the values be 255GB and 511GB?
Usual binary rollover issues.

and are we talking decimal or binary versions here? 10^3 != 2^10, although they are close.

and are we talking decimal or binary versions here? 10^3 != 2^10, although they are close

Raik quoted 256GB = 262144MB – so 256 × 1024

I think not. 256000MB are 250GB (was a deliberately chosen value) and was correct displayed bie PartMgr but the partition itself was not usable.
HForm format the partition with 256GB = 262144MB.
What are the correct steps to format 256GB filecore on a 500GB device with PartMgr? Maybe “my way” is not the right one.

In that case we have a bug, the odd thing is the FileCore code is lifted straight from HForm, so they should behave the same.

The correct steps to initialise a disk straight out of its box would be:

1. Right-click on the drive, which is in the left of the display, select Initialise and use GPT
2. Right-click on the unpartitioned area of the drive and select New volume, set the size and FileCore

As that’s resulted in an unusable partition, it sounds like the partition table was okay, but FileCore didn’t recognise the partition, so possibly wasn’t initialised correctly.

This however appears to be different to what you posted previously, where you ended up with a full disc FileCore drive. Without screenshots or debug logs, I can only go on the description of the issue and guess at the underlying problem.

I think we have any mussunderstandings. Sorry for my bad English.

GPT formatting was working without problems.
In this case in the first step I would create a normally, not GPT, Filecore partition like HForm do.
Max.256GB, the rest unused. This gives me the complete drive or an unusable Partition (without or with initialize (MBR) before formatting). The settings of this unusable Partition are not accept by HForm (unusable shape) and HForm set other. HForm works …
In second step I would use the rest of the drive as FAT. I initialize with PartiFC and format with PartMgr. Works.
Thanks a lot for your work.

In this case in the first step I would create a normally, not GPT, Filecore partition like HForm

In that case, I believe the repro steps are:

1. Right-click on the drive, select Initialise and use None
2. Right-click on the unpartitioned area of the drive and select New volume, set the size and use FileCore

0.70 now available, which includes some changes to the way full-disc FileCore drives are handled. The min size is now 32MB and the max size is set based on FileCore supporting 64-bit (which is currently doesn’t), the size of the drive and the LBA size.

Note that it does not support adding additional partitions to full-disc FileCore, as that isn’t possible. Partitioning like the Pi uses an MBR partition table that’s marked out of FileCore. I’ve not yet decided if I’m going to implement that as there’s obviously an in-development bounty to add GPT to the OS, which would make it redundant.

I’ve not yet decided if I’m going to implement that as there’s obviously an in-development bounty to add GPT to the OS, which would make it redundant.

You’re doing a brilliant job Jon, and I’m sure you have much better things to do with your time than implementing something to support an item where someone else is developing a change that consigns the feature to history.

Perhaps the person doing the development could contact you and assure you that it will be “sometime soon”

The JASPP site appears to be down. Does anyone know if partmgr070 available anywhere else?

The JASPP site appears to be down

Seems to have been down for a couple of days.

Anyone got a contact for Jon?

The JASPP site appears to be down

Seems to have been down for a couple of days

Don’t panic Linux decided to have a Kernel panic last night, I’m working on getting it back up

Thanks for the update, Jon. Good luck!

The site appears to be back up :)

Jon, when you have a chance, can you please create/include some licensing information? At present I have no idea whether it’s permitted to redistribute this utility.

For those not following the development progress of Partition Manager, I’ve uploaded Partition Manager v0.96 for testing.

Most of the past year has been spent reverse engineering all the IDEFS Modules I could get hold of, to figure out low-level access and their partitioning schemes. Not much has changed for RISC OS 5 users except Backup/Restore of partition tables and finishing off the Wimp interface.

Don’t use on a live system without a backup, or at minimum taking a backup of the Partition table to another disc via the Menu option over the physical drive on the top-left of the GUI. Preferably test on a clean drive or a newly build OS drive.

Except for a few IDE Podules I’ve yet to get my hands on, this should replace all existing Format and Partitioning tools for ADFS, IDEFS, SCSIFS, SDFS, ZIDEFS, HDFFS.

I’m working on adding the ability to create Pi boot drives, with the embedded PiBoot FAT partition and a FileCore partition size of your choice.

I’ve uploaded Partition Manager v0.96

Hi Jon,

Thanks for the update which works on my old RiscPC with Unipod, IDEFS, and RISCOS 6.20 as far as seeing the disc and FileCore setup.

I’ve not tried setting up a new drive on it.

I’ve uploaded Partition Manager v0.96 for testing.

Hi Jon,

thanks for your work and the update and sorry for my “spezial” Ti configuration.
For me, any things are better with an older Version.

ADFS5 has an 256GB FileCore partition at first and a second 220GB Fat32 one, mounting and working with FAT32FS without problems.
ADFS6 is an 2TB FileCore device like Elesar offer.

All the best.

Thank-you both for the feedback.

ADFS5 has an 256GB FileCore partition at first and a second 220GB Fat32 one, mounting and working with FAT32FS without problems.

The size discrepancy is easily explained, I changed GB/TB to be displayed in decimal 1000’s whilst I was checking drive sizes matched up and forgot to change it back.

The red FAT32 partition tells me it tried to read it and failed, although it should have shown it as FAT, which I’ll check.

ADFS6 is an 2TB FileCore device

Probably the same issue as your FAT32 partition. 0.70 uses OS calls to identify Filecore, where 0.96 performs DiscOp’s to read the FileCore structure and doesn’t use the OS at all, except to request freespace if the partition is mounted. The middle Zone on that drive is beyond the FileCore 2^29-1 sector limit, so I expect the DiscOp to read the middle Zone failed.

This makes me think your OS implements FileCore_DiscOp64 fully. Open !RunImage, change line 11 FileCore_64bit%=FALSE to TRUE and see if the FAT32 partition and ADFS 6 then show up. If they do, that then begs the question of how to determine if FileCore_DiscOp64 supports a 64bit address.

Open !RunImage, change line 11 FileCore_64bit%=FALSE to TRUE

The only difference I see…
The errormessage (sorry, I forgot yesterday)…

…, while the progress window is open, is gone.
The Partition Manager window is the same.

ADFS5 has an 256GB FileCore partition at first and a second 220GB Fat32 one, mounting and working with FAT32FS without problems.

ADFS 5: I wondering that it looks like in “inlay”.

SSD_ADFS:

SSD_FAT: I mount with fat32fs:mount -p2 :13 { > null: }
(Device 8-15 are for ADFS; 8-11 = ADFS floppy; 12 = ADFS 4; 13 = ADFS 5)

Edit:
If I use an >500GB FAT32 device via USB, I get SCSI 0:0 MBR 458GB Unallocated.
The OS use it as an 447GB Fat32fs device.

Raik, to support the Titanium I’ll need to identify ADFS4 hosted drives and switch them to use ATA Op’s instead of ADFS_DiscOp. I’ll let you know when I have something you could test.

Partition Manager 0.97 is now up for testing.

I’ve added support for ADFS4 although its untested as I don’t have an appropriate machine. As per the note on the download post, I would try it with test drives before using it on a working machine.

I pieced together ADFS4 support from the source code and added accompanying documentation on the Wiki (ADFS_IDEUserOp / ADFS_IDEDeviceInfo ), although I can’t be 100% sure it’s completely accurate.

PartMan 0.97 fails on Titanium with ADFS 4.04 (08 Aug 2017)

add_partitions_GPT
======
ADFS 5 checking for GPT partition table

Error: FNIDEUserOp_ADFS only supports full sectors

at this drive:

ADFS::5 - SATA drive

DiscOp 3/IDENTIFY response:

Word   :    0    1    2    3    4    5    6    7    8    9

000000 : 0C5A 3FFF C837 0010 0000 0000 003F 0000 0000 0000 Z..?7…….?…….

000010 : 2020 2020 2020 2020 2020 2020 5A43 3232 5437 5A4E             CZ227TNZ

000020 : 0000 0000 0000 4E4E 3035 2020 2020 5354 3230 3030 ……NN50    TS0200

000030 : 4E4D 3031 3035 2D31 5959 3130 3420 2020 2020 2020 MN10501-YY01 4      

000040 : 2020 2020 2020 2020 2020 2020 2020 8002 4000 2F00               …./
000050 : 4000 0200 0200 0007 3FFF 0010 003F FC10 00FB 5C02 .…….?..?……\

000060 : FFFF 0FFF 0000 0407 0003 0078 0078 0078 0078 0008 ….......×.×.x.×...

000070 : 0000 0000 0000 0000 0000 001F 8D0E 0042 08CC 0040 …………..B….
000080 : 07F0 006D 306B 7561 6173 3069 B441 6173 007F 0067 ..m.k0ausai0A.sa..g.
000090 : 0067 0000 FFFE 0000 FE00 0200 0000 0000 2710 0000 g................'..
000100 : 1116 1D1C 0000 0000 0000 0000 5000 0000 5000 C500 .............P...P..
000110 : B452 4DBD 0000 0000 0000 0000 0000 0800 0000 41DE R..M...............A
000120 : 409C 0000 0000 0000 0000 0000 0000 0000 0021 1116 .…………..!…

000130 : 1D1C 1116 1D1C 2020 0002 0140 0108 5000 3C06 3C0A ……  ......P.<.<
000140 : 0000 003C 0000 0008 0000 0000 FDFF 0280 0000 0170 ..<...............p.
000150 : 0008 0000 0000 0423 0000 8000 0000 01E7 9100 8068 ......#...........h.
000160 : 0000 0000 0000 0000 0000 0000 0000 0000 0002 0000 ....................
000170 : 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 ....................
000180 : 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 ....................
000190 : 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 ....................
000200 : 0000 0000 0000 0000 0000 0000 50BD 0000 0000 4000 .............P.....

000210 : 0000 0000 0000 0000 0000 0000 0000 1C20 0000 0000 ………….. …..

000220 : 0000 0000 107F 0000 0000 0000 0000 0000 0000 0000 ………………..

000230 : 1116 1D1C 0000 0000 0000 0000 0000 0000 0000 0000 ………………..

000240 : 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 ………………..

000250 : 0000 0000 0000 0000 0000 7FA5                     …………
Magnetic media drive

Geometry in words 54-58 are reported as valid

  Cylinders=16383 Heads=16 Sectors=63

Drive using 48-bit LBA addressing

Drive reports it has 4096 byte sectors

Physical drive is ADFS 1

Model      =ST2000NM0105-1YY104

LBA Size   =4096

Size in LBA=&01D1C1116

Removable  =0
  

4096 byte sectors

I thought 4K sectors might cause an issue. I’ll fix and let you know when there’s an updated version to try.