Partitioning

Hello again. I would like to set up partitions on Risc OS. I have a 16384MB (16GB) SD card with Risc OS on it. Is there a way I can expand the partition to fill the full SD card?

Firstly: It’s “RISC OS”, not “Risc OS”.

Secondly: You don’t mention what hardware you’re using. Raspberry Pi?

Assuming you are using a Pi, increasing the size of the RISC OS partition on the SD card is technically almost impossible. Not because of any limitation inherent to RISC OS, but because of the ‘hidden’ FAT32 partition in !Boot.Loader, which was manually hacked into the disc image to compensate for RISC OS’s lack of support for true partitions.

That’s why the image is only available in one size – producing each one is a dirty and difficult job, which would have to be replicated for each different size. That’s also why, although there’s nothing technically stopping you from reformatting the SD card to use the full 16GB, you would render it unbootable in the process.

So, in summary, perhaps not.

You can try this at your own risk.
https://www.riscosopen.org/forum/forums/8/topics/1085#posts-12734
or
https://www.riscosopen.org/forum/forums/6/topics/1094?page=1#posts-12721

Thanks for the replies. Sorry, I should of specified the hardware I was using. Yes, I’m using a Raspberry PI. How do I partition the unused space in RISC OS? Could I used a partitioner on another operating system?

I’ve had a look at the linked descriptions and… given that we are looking at partition tables and FAT/FileCore structure tables… I am surprised somebody hasn’t come up with a BASIC program to create a blank image which could be written to an SD card of the appropriate size, and then populated by draggy-droppy.
It would surely be more flexible than making the images manually each time, no?

The latest versions of FAT32fs support partitions so you could using another computer fill up the extra space with a FAT32 partition and, using an obey file, access the partition on the card.

No idea – I should really get around to having a look at this as it could make life easier for those who want to make full use of their SD-Cards…

And, of course, makes ROM updates nice and easy too!

Ben Avison was the guy who created the magic SD card image(s) – we went though a few size combinations – and he had managed to partially automate the process. I don’t know why it wasn’t fully automated – there were some complicated edge cases that I can’t recall. The intention has always been to write a more flexible tool for doing this sort of thing, but that’s only going to happen when time permits. Ben could probably add more useful info here than I…

FileCore is actually a considerably more complicated format than FAT – a more elaborate allocation scheme that allows much finer granularity of space allocation, and lots more checksumming, making it more robust. These are generally speaking good things to have. But it does have the side-effect of making resizing them hard; it was never designed with that in mind. In fact, in some problematic cases, making a FileCore partition larger can paradoxically mean that the files no longer fit (due to a reduction in allocation efficiency)! Any generic partition resizer would at least have to know how to backtrack in such cases, to ensure no data loss.

The SD card images were initially created as disc image files by a new FileCore formatter I’ve been writing. This was partly written with an eye to some of the upcoming improvements to FileCore, since the limitations of BASIC (mainly it only supporting signed 32-bit integers) meant that HForm will need replacing soon anyway. The edge cases that Steve refers to are actually edge cases in the layout of these FileCore partitions that I haven’t sorted out yet, so when I was creating these, I needed to check the parameters manually to ensure that various limits hadn’t been exceeded (ultimately the plan is to automate this).

However, a replacement for HForm is of limited use to most people until FileCore is updated, of course, and you’re not the first person to have asked about making a larger version of the dual-format image. While I’m not initially proposing something to resize an existing disc, I am currently writing an application which will enable someone to take a whole disc which has already been formatted to an arbitrary-size FileCore format using HForm, and insert a boot partition within it. I’m planning that it will also be able to diagnose and fix a number of common ways in which the boot partition may have been damaged, too.

Sorry it’s been a long time coming folks; I’ve just been rather busy of late (though I am still making progress).

I’ve just been rather busy of late (though I am still making progress).

It’s some kind of seasonal thing blown in on the wind or something like that.
Even my tried and trusted phrase “a failure to plan on your part does not constitute a crisis on my part” seems to be failing just at the moment.
Sadly although the split personality is coming along fine, the split body hasn’t developed and I can’t be in two places at once.

Is there any point in supporting more than the current image? (i.e until there is a proper partitioner and installer)

FAT32FS can read other partitions anyway. I’m pretty sure that the Pi doesn’t need the loader FAT partition to be physically the first partition.

If that is the case, then in the short term, all that is needed is a filecore formatter that also creates a partition table and entry for the ADFS area it has formatted. (The format would obviously be in the same location as it is currently, you would need the choice of sensible pre-set sizes or entering your own. And choice of which partition number is assigned.)

Anyone who wanted to customize a Pi image size would use this formatter, and then add a FAT partition, and then manually copy everything over.

Not what I suggested. Use FAT32 to access the FAT partition the Pi Boots from. Have a new formatter that adds partition information, so that the area is protected and an tool can be used on another system.

Then using the tool plus a partitioner on another system you could create what you wanted.

That’s a partial solution, as long as you’re happy to manage the contents of your boot partition manually. However, it’s not so good for software that needs to reliably be able to locate files in the boot partition of the disc you booted from – I’m thinking of package managers that handle ROM upgrades, the CMOS emulator, etc. At the moment, these can just go to the directory Boot:Loader and it’ll work even if the user has renamed their drive; I doubt it’s as easy to ask FAT32FS for the first FAT partition on the disc containing Boot$Dir.

Apart from that, there’s something to be said for keeping the contents of the boot partition relatively inaccessible, as it’s quite easy for a naive user to trash their installation by fiddling with it. Also, I’m resistant to introducing a dependency on external software, and GPL-licensed software at that, into the core OS.

I’m thinking of package managers that handle ROM upgrades, the CMOS emulator, etc.

Couldn’t there be a system variable? Putting a non-standard arrangement on would not be for those unfamiliar with partitioning.

It wouldn’t be putting GPLinto the core OS, because what I am suggesting is a way forward for those of us who wish to fiddle. Until there is a proper installer (i.e partition, format and copy) the default would be the current system.

The thing that stops people rolling their own, is the lack of a Filecore formatter and partitioner. (Obviously currently only a partition at the start of the drive would work).

@ DavidS:

Grand, lets use a poorly designed FS (FAT32) […] While FAT32 is useful for transfering files to other OSes on verious media, it is a poor choice of FS for regular use.

While I would agree that FAT is a less than attractive filing system, it has the benefit of being fairly easy to handle and not requiring complications or a ton of metadata to be constructed. It is also fairly universal. This makes it a good choice for booting these little ARM boards (the code to read from “disc” doesn’t need to be overwhelmingly complicated); plus it is useful for digital cameras etc (same reason – simple filesystem).

I’m sure I could point to a better filing system. And so could you. Problem is, we’d probably point to different filing systems…so maybe FAT is, for the time being, a worthwhile compromise. Even if that does make it a crappy filing system for a half-terabyte harddisc!

@ Ben:

as long as you’re happy to manage the contents of your boot partition manually.

Would it not be a possibility to construct an appropriate type of FileCore partition for the SD card in question, and then block-write a predefined FAT partition (like how Argo’s Zip disc formatter did it)? This would make it possible to create customised bootable devices without the necessity to maually build a DOS partition.

While you seen to be against external program for licence reasons – and worthy it is, I too prefer to avoid GPL when possible; I have a different story to tell which explains why multiple programs are a pain.

I have a DVD of Steins;Gate. I have a computer with no optical media. The obvious solution is to rip the DVDs. My ripping software makes XviD. This isn’t bad, and I love XviD’s flexibility; however the downside of AVI is that it doesn’t do subtitles so subs need to be burned into the image. So, I thought, why don’t I look for a way to make MKVs like the fansub animé releases?
Yeah… It is doable. There’s a program called MakeMKV which, astonishingly enough, will make an MKV from a DVD (which may or may not work, you may need something else to get around CSS protection and/or zone issues). MakeMKV is fast because it just yanks the video/audio/subtitle streams from the DVD to harddisc as a packaged MKV file. Expect DVD sized files (5GiB – 9GiB). To then make it something a little more friendly, we need a program called handbrake to transcode the video from MPEG2 to XviD (or H.264, blah blah). This is the hard part so takes a while. Unfortunately handbrake doesn’t cope with embedded subtitles so you need something else to extract the subtitles from the original MKV and add them to the transcoded MKV. I can’t name this program as I gave up and am ripping the episodes to AVI.
Too many pieces, to much trouble.
This is my worry if the disc builder/formatter if it isn’t capable of at least copying over a pre-saved FAT partition [if nothing else, you’d need to diddle the FileCore free space so the FAT part isn’t later trampled upon, this is out of the skill set of most people (myself included!)]

FWIW, I think an optional support for FAT boot loaders is viable in a modern FileCore formatter given that this is how modern ARM boards boot. Obviously it can remain hidden if “not a known ARM board” and “not SDFS”.

Just my €0,02345678 [given to ridiculous precision because that really IS the current rate today! It’s 1:0,852 the other way]

I have a Image from my 16GB RPi card. It is a “unchanged” copy from the Distro but with a bigger ADFS-partition. Im not sure if it works stable. The short tests are working fine.
If someone has interest, I can upload it tomorrow morning and provide a link. You need Windows and USBit to use this.

@ Raik
If you could upload your Image, that would be great!

Not the right place ;-) but you find it here:

http://riscos.openpandora.org/RPi16GBADFS.imz

Thank you!

@ Raik
Can you please post the MD5sum of your image, as I’ve written your image to a 16GB card, neither RISC OS or Windows recognise the card once the image has been written. I just want to check it’s not getting corrupted during downloading.

Sorry, at this time I have no access. I will check this Monday morning.
Have you use USBit? When the Software USBit say its finished, is it often not realy finished.
See that your Card Reader end the writing(blinking)
The Problem is that USBit is not ready but nothing is displayed. Click the device… I hope this is not to confused ;-)

I am using USBit, I don’t think it’s showing any message when it finishes writing. The progress bar gets to 100% the disappears!

I’ll write the image again and leave it after it gets to 100%
The card reader doesn’t have a light on it, as it’s an internal one built into a netbook. I’ll dig out a USB one, so I can see when it’s really finished.

Thanks for all your help!

I hope they are no missunderstandings. If you see the 100% blue progress bar before it grey out, all things seems to be ok.
If I write a Image on my laptop via USBit after 20% (round about) the progress bar is grey out and it looks like the writing process is ready but it is not. If I click to the device Icon in USBit the progress bar is back.
My internal reader also doesn’t have a light on it and so the first Image I wrote to a card doesn’t work.
Sorry that I can not more help at the weekend. Weekend is family time and computer are forbidden.
I will check the image tomorrow morning. The upload is very very slow (16h) and so I hope the Image is ok.

I’ve written the image again using an external card reader, it took a very long time to write, but RISC OS recognises the card!

Looks like the image is ok, so no need to upload another copy.

Thanks again!

@ Raik
Check your Email ASAP!