Partition Manager

Hi Jon,

Using 1.01 build on my iMX6 I see two instances of the main drive:

One is SCSI 0:0.0 (SCSI::4) 223.56 GB capacity and the other,

SCSI 0:0.8 (SCSI::4).

Version 1.00 23/7/23 shows things correctly.

Some good news, using the v1.01 29/07, I no longer experience the drive re-ordering I’d seen before. I’ve emailed the debug file, forgetting that despite a desktop dismount of the newly created image on Shutdown, I get a message to reinsert the drive.

1. PM now creates a Pi Boot disc on a SD card in a USB stick, although I had to skip quite a few ‘Failed to connect’ or similar errors. Eventually, there’s a !Boot directory with Choices, Recourses, RO520Hook, RO530Hook and Loader. The latter just contains CMDLINE/TXT and CONFIG/TXT. No Elf files and such. There’s an Apps directory and a Utitlities directory too. I’ll send you the debug file.

By the way, I noticed that when starting PM with CTRL held down, it does NOT recognise the stick.

Using 1.01 build on my iMX6 I see two instances of the main drive

Should be fixed in today’s build

I no longer experience the drive re-ordering I’d seen before

If you’re referring to the order of Filer icons on the taskbar – that’s down to the individual filers. IF PM has to reinitialise a filesystem, the order might change depending on how the filesystem filer works.

despite a desktop dismount of the newly created image on Shutdown, I get a message to reinsert the drive

Did you build a Pi Boot drive with the same discname as an existing drive (itself included)? I’m wondering if RISCOS has cached a previous version of the drive. I’m assuming it was the Filecore partition on the new SD that RISCOS was asking to be reinserted?

I had to skip quite a few ‘Failed to connect’

That sounds like it couldn’t connect to any of the download servers to pull down the required files.

I noticed that when starting PM with CTRL held down, it does NOT recognise the stick.

I want to say that’s just coincidence as CTRL only alters scanning of ATAFS, IDEFS and ZIDEFS. If you select “Refresh drives” once PM’s loaded its equivalent to holding CTRL – does the drive then disappear?

That sounds like it couldn’t connect to any of the download servers to pull down the required files.

Fair enough, and I can copy the necessary files from backups. But new users will probably be left with a not working system, won’t they?

I noticed that when starting PM with CTRL held down, it does NOT recognise the stick.

I can’t repeat this. PM now seems to work as intended. Don’t know what I did wrong the first time.

Question: when I just do an Initialise, with either of the options, it inevitably leads to a ‘Disc not understood. Is it formatted’ error. Is this supposed to be normal?

Question 2: When I created an Pi Boot disc on a SD card, it will always show 2 icons, one of which yields a ‘The disc drive is empty’ error, while the other will only show the contents of Loader, unless it is opened with Adjust. Is this supposed to be normal too?

When I created an Pi Boot disc on a SD card, it will always show 2 icons

Are you using an SD card reader with 2 or more slots? These typically appear as separate drives under RISC OS.

the other will only show the contents of Loader, unless it is opened with Adjust

That is Fat32FS doing its thing, so is to be expected.

Are you using an SD card reader with 2 or more slots? These typically appear as separate drives under RISC OS.

That’s it. Problem solved.

That is Fat32FS doing its thing, so is to be expected.

Okay, but what should I do to get RISC OS with SELECT, as with all other discs?

Okay, but what should I do to get the RISC OS with SELECT, as all other discs?

The card will behave normally when inserted into the SD slot of the Pi. It’s only when it’s connected via an external card reader that Fat32FS gets in the way.

Well, that’s it indeed. I’m nearly feeling a genuine Pi user.

But new users will probably be left with a not working system, won’t they?

Creating a “Pi Boot drive” requires an Internet connection to download all the required files to the new drive. I can add a check for an Internet connection before the process starts, to warn the user its going to fail.

when I just do an Initialise … it inevitably leads to a ‘Disc not understood. … Is this supposed to be normal?

Initialising a drive erases the start of the drive and in the case of MBR/GPT creates an empty partition structure. Attempting to open the drive in RISC OS without first creating a volume on the drive, will result in a “Disc not understood” error.

Using 1.01 build on my iMX6 I see two instances of the main drive

Should be fixed in todays build

Hi Jon,

Thanks for the fix which I can confirm works here.

If I get time this week I will try the latest version on my RiscPC with a STD Unipod in it.

I will try the latest version on my RiscPC with a STD Unipod in it

STD Unipod is on the missing Modules list – so may or may not work. I think it uses Simtec IDEFS from the A9home, so depending on how bespoke its implementation is – it might get picked up as Simtec and work…the debug log details which IDEFS its been detected if you want to check.

I believe it uses MassFS for the USB, also similar to the A9home. I’ve implemented that based on conversations with the original author although its not been properly tested. It does some non-standard things to support both FAT and FileCore such as switching drives between MassFS: and MassFC: depending on the format, so without proper documentation, identifying the logical drive has its challenges.

I have an issue with the newer versions (1.01).

Version 1.00 worked with my system with two ADFS drives, scanned both drives, and displayed them appropriately.

All version 1.01s manage to scan the first drive, but on scanning the second ADFS drive, freezes the machine totally. Needs a reset to get going again – even a Ctrl-Break doesn’t work. Will the log files be stored anywhere?

All version 1.01s manage to scan the first drive, but on scanning the second ADFS drive, freezes the machine totally

Only SCSIFS support has changed between 1.00 and 1.01 – do you have a SCSI card fitted?

Will the log files be stored anywhere?

Refer to the app Help.

Ah. It was a multi-card USB card reader that map creating the issue. As soon as I unplugged that, it all worked again. It gets so little use, I’m not overly concerned about it.

It was a multi-card USB card reader

Could you email a debug log to me please as it should not hang. Its possible SCSIFS is in a long timeout whilst PM is checking the LUN’s.

Based on debug feedback and testing I’ve done myself with several USB multi-card readers, the current 1.01 build of PM should hopefully support them.

I’ve also removed most of the blocking dialogues when creating a Pi Boot drive, in favour of an infinite timeout loop and a button to manually cancel/retry the current download. The wimp poll period has also been reduced when waiting for stream data, so it should download quicker.

Hi. I have been playing with 1.01 and I like it, and have a couple of requests and a question.

1. Could you add an option for USB booting for the Pi disks?
2. WOuld it be possible to save the downloaded files locally after they are downloaded, for repeated images?

Does the Raspberry Pi need its boot partition physically at the start of the drive?

Thanks

Could you add an option for USB booting for the Pi disks?

Sure, what do I need to add? I’m assuming that’s a Pi4 thing as earlier Pi’s had to be “burned” to boot from USB.

Would it be possible to save the downloaded files locally after they are downloaded, for repeated images?

I need to write a full Package Manager to replace what’s currently in Partition Manager as it’s hard-coded links that need updating when ROOL change the builds. The Package Manager will include an option to cache packages.

Does the Raspberry Pi need its boot partition physically at the start of the drive?

It needs to be the first MBR partition so should logically come “before” the FileCore partition. As RISCOS doesn’t understand MBR partitions, it’s put inside the FileCore drive at the start of the disc, which also allows !Boot.Loader to both point to it and essentially map it out of the FileCore map.

>Sure, what do I need to add? I’m assuming that’s a Pi4 thing as earlier Pi’s had to be “burned” to boot from USB.

Thanks, it’s the default filesystem that needs to be changed.
Pi 4xx out of the box but some earlier models too, if they have been tweaked as mine have. (I think there will be a much bigger chance of someone trying RISC OS on their Pi if I give them an old memory stick they can boot from, especially since I’m unlikely to have old SD cards to give away).

>> Does the Raspberry Pi need its boot partition physically at the start of the drive?
> It needs to be the first MBR partition so should logically come “before” the FileCore partition.

It would be interesting to see if putting the details for the FC partition in the last partition slot, and the Pi Boot in the first slot, but physically after it would work and not cause problems. (Presumably the Pi Boot would have to be within some boundary.)

Thanks, it’s the default filesystem that needs to be changed.

As in Configure FileSystem?

I’m not totally sure how that would be implemented as the system needs to initially boot to create !Boot.Loader.CMOS. The CMOS file is created by an Obey file that PM drops into !Boot.RO520Hook.Boot.PreDesk called !!CMOSInit – which is currently hardcoded for SDFS.

If I can detect the boot drive, I can make !!CMOSInit create !Boot.Loader.CMOS on the correct drive and then configure FileSystem to the matching filesystem.

It would be interesting to see if putting the details for the FC partition in the last partition slot, and the Pi Boot in the first slot, but physically after it would work and not cause problems

Why would you want it moved? It’s a bootstrap partition that’s pretty much ignored once booted.

MBR is so old (pre Arthur) I’ve not managed to find a definitive specification, but reordering the partitions might break something as I think its generally accepted partitions are consecutive for gap detection.

> As in Configure FileSystem?

Yes. I managed to get a stick booting to desktop (but it had none of the ROOL customisations and looks like RO 3.7 etc) by following steps in various instructions I found that didn’t work on their own. But it did include configure filesystem scsi, manually running the !boot and then copying CMOS file manually.

I can do more experiments to see which steps actually did it, if that would help. (What is the smallest drive that will work?).

> Why would you want it moved? It’s a bootstrap partition that’s pretty much ignored once booted.

The overlapping partitions idea, although very clever is a bit horrid. But all the time you are talking about a drive that will only be used with RISC OS, it’s fine and will serve as protection if plugged into other systems. But I’m thinking in terms of when you are using multiple systems. (RISC OS is brilliant at some things, but useless at others, so if you want a single device, multiple booting is vital).

> MBR is so old (pre Arthur) I’ve not managed to find a definitive specification, but reordering the partitions might break something as I think its generally accepted partitions are consecutive for gap detection.

I’m pretty sure I have seen out of order partitions in the past, without issues. (However “without issues” would only be known on those specific old systems.)

As far as RISC OS goes, it would know nothing, apart from DOSFS? As far as the Pi loader goes, there has to be some limit within which the loader partition must be contained (eg within first 8GB).

If out of order partition are legal (and respected) it would give far more flexibility and interoperability.

it had none of the ROOL customisations

Those customisations are only found in the full SD image – they’re not in Harddisc4 or if they are, it doesn’t default to them.

The overlapping partitions idea, although very clever is a bit horrid. But all the time you are talking about a drive that will only be used with RISC OS

Although it’s not ideal, PM does create a drive that’s legal for other OS’s. A protective MBR partition is added to cover the region FileCore occupies so you can move the drive between OS and add additional partitions after the FileCore partition.

As far as RISC OS goes, it would know nothing, apart from DOSFS?

RISC OS sees a “full-disc” FileCore drive only. !Boot.Loader is a file within the FileCore drive, it’s not seen as a partition.

The Pi Firmware only sees the first MBR FAT partition as far as I’m aware. The limit of which is the MBR limit of 2^32-1 sectors or 2TB with 512 byte sectors.

If out of order partition are legal (and respected) it would give far more flexibility and interoperability.

I don’t believe moving the Bootstrap partition would add anything as its a partition that should really be ignored by all OS.

If you need interoperability, create a drive that has space at the end and add a FAT partition as a 3rd partition.

but reordering the partitions might break something

The filecore partition always resides at a fixed offset, just clear of the partition table. It knows its size from its own internals not from any partition table.

If you create a dual-partition image using !SystemDisc it will protect the filecore partition with a partition table entry (type=filecore) that extends to the end of the filecore partition. The DOSFS image file also has a partition table entry to protect its FAT partition but the space it reserves just ‘happens’ to be where the contents of the filecore file Boot:Loader reside.

The partitions overlap but I do not think the partition table entries actually overlap.

> If you need interoperability, create a drive that has space at the end and add a FAT partition as a 3rd partition.

I’ve already done that with your app. But the situation I was thinking of is using partition tools on a different system.
I’m pretty sure if someone who wasn’t aware the FC partition spread over the preceding partition too, tried to back it up or move it, they would end up with a bit of a mess.

I’m not suggesting a change of default behaviour, but if it works, it could could be an interesting use at your own peril option.