Bootable micro-SD-cards

I have a new 4GB Cloudisk micro-SD card onto which I wrote RISC OS 5.28 using the Imager accessory in Raspbian. When I inserted it into a Rpi3B+ and switched on I only got a black screen with a blinking cursor at the top left. However using an old 64GB card instead, the process worked fine. RISC OS only sees the first 4GB of it. Can I use !SystemDisc so that RISC OS can see more of the 64GB without disturbing the data on it?

I would like to be able to make backup clones of my micro-SD-cards but I only have one functioning card-holder. Can I use a memory stick as intermediate storage for the cloning operation? Can I use Raspbian’s SD card copier accessory or do I have to use something more savvy about RISC OS?

Can I use gparted, for example?

Sorry if these questions have come up before.

Can I use !SystemDisc so that RISC OS can see more of the 64GB without disturbing the data on it?

Short answer: No.

SystemDisc calls HForm to format the card, so will erase everything already on the card.

Can I use a memory stick as intermediate storage for the cloning operation?

Sort of. Cloning an 8GB SD card to an 8GB memory stick might work, but memory sticks tend to have slightly lower capacities than SD cards so you may find that the copy “fails” at about the 99% mark. Unless the card really was chock-full of files this may not matter, and cloning the memory stick to another SD card stands a good chance of producing a bootable card. You do have to use the same capacities at each stage (8GB > 8GB > 8GB).

Can I use Raspbian’s SD card copier accessory or do I have to use something more savvy about RISC OS?

I’ve not tried Raspbian’s copier, but a utility such as CloneDisc (RISC OS) or Etcher (Linux) should do the job.

Can I use gparted, for example?

No. Completely the wrong tool. Chances are it would spot something it didn’t like about the image and try to “fix” the “error”.

Thanks for that. I put the 64GB Samsung card with RO5.28 into the card-holder and used dd in Raspbian to copy it to a file ro528.img in Raspbian. Then I used dd to copy that image file to a new 4GB Cloudisk card. It failed to boot RISC OS. Just in case it was a faulty specimen I tried another 4GB Cloudisk card. Still no joy. The suspicion grows that the Cloudisk cards are no good as RO boot media, but it could still be me.

I’ve never heard of Cloudisk. I’d suggest downloading the official Pi image and flashing that onto the Cloudisk card; that’ll add another data point for your hypothesis.

Cloudisk are one of those made-for-Amazon no-brands. I would try one of those checkers that tests whether the card actually contains the storage it claims to – there’s h2testw on Windows, I’m not sure if there’s anything to do it on RISC OS.

Although it’s slightly surprising to find this on a 4GB card, rather than a ‘2TB’-yes-really-honest-would-we-lie-to-you? card.

It’s also possible they use a cheap and nasty flash controller and something in it doesn’t play well with RISC OS. I’ve not seen this before with SD cards though (only CompactFlash).

On the size issue, many manufacturers now lye outright on the specs of the size, even well known brands. They will call it 1GB when in actuality it is only 1000000000 bytes, and 1GB is 1073741824 bytes, they are cheating by using base ten numbers for a value that is supposed to be based on base 2 values.

No, DavidS, sorry, what you’re saying is not correct. 1k is 1000, 1M is 1000000 and 1G is 1000000000. That has always been the case. Many people started to treat them as being 2^10, 2^20 and 2^30 because they were “near enough”. They aren’t really, and the discrepancy is the basis of your argument. That’s why the “ki”, “Mi” and “Gi” units were introduced.

I recommend that you use the appropriate and correct multipliers.

That has always been the case.

When referring to SI units, yes, kilo and mega have clearly defined values.

However, when referring to memory capacities and addressing ranges (etc), these values were their base two equivalents for several decades until more recently some purists decided to create a strict “base 10 only” definition of kilo/mega/… and invent the measurements kibi/mebi/… to use for computer use.

I recommend that you use the appropriate and correct multipliers.

That would sound an awful lot more convincing if we weren’t using an OS that refers to KB and MB throughout (including pretty much all legacy documention).

Sorry, but whilst kilo for 1024 is technically wrong as an SI unit, you don’t get to retcon the past.

No, DavidS, sorry, what you’re saying is not correct.

And he does actually have a point in that storage media since antiquity has been measured in base 10 numbers. It’s bollocks given that (excepting ancient weird stuff like that processor with 36 bit words and the like), media will usually be offering to store eight bit values in sectors of 128, 256, 512 bytes… this is because it’s what most processors since the eight bit era actually used. There’s absolutely no base 10 about it, thus one can only conclude that media is measured in base 10 because it lets them print a bigger number on the packaging. THIS IS A 1 TERABYTE DRIVE! (small print: formats as ~930GiB).

It might be understandable for spinning rust discs, but for SSDs where they consist of memory chips it is definitely wrong. It’s no more than a marketing con, like when they used to count the hidden part of the screen around the fascia when spec’ing monitors.