Backup Browsing, and Partition support?

So, I’ve been mucking about with backing up my current RISC OS Pi setup with the aim to migrate to 5.21 rather than my current 5.19.

I have ’dd’ed the current setup to a safe place and to another SD Card for easy checking.

I decided to start RISC OS again on the Pi with my USB SD Card reader (with an 8GB card inserted) still attached.

It got listed on the iconbar as :0 with a USB icon as you’d expect… and select-clicking revealed the contents of Fat32Fs::PiBoot.$

Hmm nothing odd here, so I menu clicked and found a Partitions entry with FAT 48 MB selected and then Empty, Empty and lastly ADFS 1827MB at the bottom. All three of these were greyed out.

I guess its only access to one partition at a time…

Dismout disc, no longer able to select any partitions; aaand curiousity runs away with me and I adjust-click… to reveal SCSI::RISCOSPi.$ ..!

I select-click again to remount the disc and Fat32Fs::PiBoot.$ turns up again and curiousity runs away with me again; Adjust-click with disc mounted made Fat32Fs::PiBoot.$ active. Which was weird but I can still read and write to both partitions.

I’m not sure whether this is the standard RISC OS way of reaching secondary partitions as I have only ever used multiple partition drives with IDEFS on my UniPod equipped RiscPC but it never ever managed to mount anything (/me shrugs) but is very cool nonetheless.

So, now that I have a couple of backups and can access the my backup natively on the Pi.. Is there a way to tweak the partition SCSI::RISCOSPi and format the disk so that I can claim those 6GBs on the end of the disk without interfering with the Fat32Fs::PiBoot.$? Just for experiments sake. Not fussed about retaining the data as I already have a backup(or 2).

Thoughts?

Yes the rules AIUI are:
For a dual partition SD card in a Card reader
Click ADJUST (RIGHT) mouse button to access the Filecore partition
Click SELECT (LEFT) mouse button to access the FAT partition

If you access first the FAT partition you have to dismount it to access the Filecore Partition but you can then Left click and have filer windows open for both at the same time and copy files between them!

The FAT32FS documents that it ignores ADJUST (RIGHT) clicks this then allows SDFS to access the drive.

Re expanding partitions see my other posting: https://www.riscosopen.org/forum/forums/4/topics/1983?page=1#posts-24874

Ok, thanks for the info Chris but seeing if I can manage this without buying Yet-Another-SD-Card.

So, I won’t trust this filesystem as far as I can throw it but this is what I’ve done to use the whole card.

First, format the whole card with !HForm (so I now have an unbootable card as far as the Pi is concerned).
Copy the contents of your current filesystem.
Then I used a linux box with GParted (which doesn’t currently recognise FileCore/ADFS so all you see is empty space) to reinstate the 50MB FAT partition as per the disk image.
Copy the contents of the 50MB FAT Partition to the disk.
Chuck in the Pi and watch it complain of broken pipes as it boots but still ends mostly as before…

you now have an ADFS partition that fills the whole card.

I assume this only works because of the nature of ADFS (If I remember correctly it fills from the middle of the disk since it was designed for rotating disks – which is why most of the data is still available?).
I’m going to copy the ADFS partition once again, overwriting everything just to see what happens to that boot partition. I assume it will get overwritten but hey – it was worth it for experiments sake.

I’ll let you know if it gets overwritten.

It should be easy to format an SD card using HForm to use almost all the available space for the filecore partition. Unfortunately this does not create a partition table to reserve this space as RISC OS filecore does not know much about partition tables, just knows enough to leave the space they would occupy untouched. Trying to add a FAT partition will then damage the filecore partition if it overlaps in any way.

If you create two partitions on the card, one large (non-FAT) and one small (FAT), with the large one first and then use HForm to create a filecore partition that is smaller than the non-FAT partition you created then you will have a card that has two separate, unlinked partitons – one filecore (for RISC OS) and one FAT (for firmware).

A better solution is to download the RC11 image (which is dual partition 2Gbyte) or purchase a 16Gbyte or 32Gbyte dual-partition SD card from CJE Micros or RComp. Then you can see the FAT partition from RISC OS (as SDFS::0.$.!Boot.Loader). The filecore partition on such cards is protected by a valid partition table.

While bodging in a FAT partition may work, you absolutely must create a fake file under RISC OS that represents the FAT partition, otherwise you have nothing stopping the RISC OS side from overwriting the data…

First, format the whole card with !HForm (so I now have an unbootable card as far as the Pi is concerned).

What you need to do is format the SD card leaving some space at the end for the FAT32 partition.
You can calculate the exact sizes by using gparted.
Create a new partion using gparted. Drag the slider towards the right until you get to say 128MB. Click on the newly created partition then select the ‘View→Device Information’. This will give you the values needed by !HForm.

eq. Heads 255, Sectors/track 63 and Cylinders 481.

It’s probably best to reduce the number of cylinders by a few just to make sure they don’t overlap.
Once you’ve formatted the card with !HForm use gparted to create the Fat32 partition in the remaining space. In this example 128MB.
The filecore partition shows up as empty space in gparted. You don’t need to worry about the filecore partition not being recognised by gparted as long as you end up with the same values in ‘View→Device Information’.

To access the Fat32 partition in RISC OS you need to install fat32fs.

Then create an obey file with the following which you can put in ‘PreDesk’.

fat32fs:mount -fp1 :16
addtinydir fat32fs::16

You should now have an icon on the iconbar which you can double click on to open the fat32 partition if you need to update the files.

I’m not sure if the newly made FAT partition will be covered, hence not trusting it as far as I can throw it…
…Sure enough, ‘Broken Directory’ repeatedly on copying the data over, so it wouldn’t overwrite it – it just refused to write at all. The old $.!Boot.loader didn’t cover it either.

So the Pi doesn’t care about where the PiBoot partition is (as long as its on the SD card if course :) )? that seems a lot safer, I will give that a whirl too.
I assumed it wanted the PiBoot to be first on the drive like PCs do (or rather, used to – I think the limit used to be bootable partitions had to be within 1024 cylinders of the start of the drive as that was as far as the BIOS could read) which how I came to trying this bodge-it solution :/

Thanks guys I’ll give the suggestions a try

The old $.!Boot.loader didn’t cover it either.

Of course not. You need to “build a file”. In other words, add an entry to the filing system table that “points” to the FAT partition, plus diddle the free space map to mark off that area as being used.
Once you have done that, your “file” (as with $.!Boot.Loader) will look and feel like a regular file – but only the original will have any value. If you don’t believe me – copy $.!Boot.Loader as something else, dump some files in the copy, then look at the FAT area on a PC – you’ll see no extra files, for the copy will be just another DOS format image filing system file and not “the real thing”.

So the Pi doesn’t care about where the PiBoot partition is

It seems a lot more flexible than the OMAP3’s loader, but the datasheet is lacking so how well will non-standard setups be handled. A primary DOS partition at the end of a 2GB card may work, but can the same be said of a 32GB card?

as that was as far as the BIOS could read

To be fair, the average early BIOS was exceedingly stupid. They had to improve in a hurry in the Pentium era when it became necessary to configure PCI hardware in-situ (instead of rows of links, switches, and jumpers), when users wanted the ability to boot from CD-ROM and such, and manufacturers started stealing harddisc space for recovery partitions and the like…