Limiting the capacity of SD cards for the pi

Ah. You must be a New Socialist. To preface a personal preference with 'should'

"c. 1200, from Old English sceolde, past tense of sceal (see shall). Preserves the original notion of "obligation" that has all but dropped from shall"

'Should' implies a debt or moral obligation. I do not feel morally obliged to leave root's password unset nor do I feel you have any legal right or moral authority to lay that trip on me!

df -h presents the information in a more digestible form

Good suggestion. I seem to remember that this used to be the default display format.

I always set up a root password as a backstop to prevent miscreants from getting into systems on my LAN if they manage to sneak through my firewall. Similarly, I encrypt a small partition as a way of preventing a stolen machine from being booted (and as a depository for storing passwords for internal user logins and external applications).

Yes, I know this isn't totally secure, but its probably good enough to prevent a common or garden thief from using the machine or selling it to anybody who doesn't know enough to reformat the disk and install Winders on it.

Ok, how about don't have a Linux desktop PC.

Yes, thanks. Somehow managed a typo on the news post.

I'm sure you're correct but once again I've reached the limits of understanding. :-) I read back on the whole thread and see if I can work out how resize a partition, no idea at the moment.

Thanks for that.

I just did what I wrote so very probably not. I've now got to work out how to do it.

Thanks.

Bob.

Have you got a desKtop or laptop with either

- a built-in CD drive

- a reasonably fast USB socket and either a portable USB hard disk or a 40GB USB stick.

If so, download a bootable Linux image onto it. Most PCs and laptops can find and boot the Linux image you just downloaded and run it damaging the existing OS (probably Windows) and associated filing system.

Now you can boot the PC from the Linux image, stick the SD card containing the Pi's filing system into a vacant USB slot on the PC and it should show up on your desktop, ready to be mounted and its contents inspected and altered as needed.

Once you've finished with it, remember to unmount the PI's SD card before you pull it out of its slot on the PC, close down Linux, disconnect the device containing the Linux image and reboot from the PC as usual.

Yeah. That image file is now like a half empty bag of sugar with the top cut off. It is not a half sized bag. The partition is in a sense a container, and if you have left the part of it that defines how big it is,but removed half of it, then the computer will try and access parts that no longer exist.

This is (as the Book says) a Bad Thing.

I've spent a few days looking at this trying to understand what you're telling me and i just don't get it. Would someone please explain to me where i'm going wrong both in procedure and understanding.

One of my problems is clearly understanding terminology used.

Druck talks about resizing the 'partition file'. I thought this was the image containing two partitions used to burn onto an SD card. I now don't think that's the case, so what is it and where is it?

Is any of the following correct?

My problem is that I end up with an SD card image with two partitions, the second one is usually at least half empty. I presume there is no point messing with the very small first partition?

I need to end the second partition earlier/shorter and change the last part of the image file to unallocated.

When I've done that I can chop the end of the image file off.

So the bit Druck described the other day using "truncate <imagefile> -s <size>"

Is that the bit that chops off the newly unallocated end of the file?

If so, (and if it isn't I'm really lost), then what I've not done is end the second partition earlier creating an unallocated area?

I'm dreading asking this but is that the bit Ian described and he and TNP patiently talked/coached me through last week?

I build images a lot and I need whatever system I use to be reasonably quick to perform. Ian's procedure is very time consuming and if that's needed then this isn't really practical for my needs.

It's all been very worth it from a learning POV at the very least.

Thanks.

Cheers,

Bob.

A very common problem.

I think that is sloppy semantics. The thing is to resize the partiton in the *image* file to allow the image file to be shrunk

Not really.

Or delete it entirely

Oh I see. Yes. exactly so ]

Probably Its a bit like a chainsaw, is truncate

Probably. You need 'parted' to do that. Or an equivalent windows program.

And it all gets fairly messy

That's why I am investigating using a file based backup system rather than imaging the entire card. Sadly its very slow

I didnt touch on parted. I am not very good with it anyway, and if the blind lead the blind, they both shall fall into the ditch...

And parted will only work ON the Pi..or another linux system, but that does suggest another approach,

1. START with parted to shrink the partition on the PI to a bit more than it needs to run
2. Then dd the entire card to an image file
3. Then truncate it.

Actually within Linux I found this

"If you wish to shrink an ext2 partition, first use resize2fs to shrink the size of filesystem. Then you may use fdisk(8) to shrink the size of the partition. When shrinking the size of the partition, make sure you do not make it smaller than the new size of the ext2 filesystem! "

This is probably a way to go, to start with a smaller partition before dd-ing. THEN you can truncate reasonably safely.

But I personally don't find *any* of these methods easy, or quick.

Remind me again what you are trying to achieve...is it to replicate safely onto SD cards of varying sizes the exact same image? If so, time taken to prepare the image is not so serious. And my system of copying the files over, then creating a smaller 'virtual disk image' which will expand to fill the card on booting, may serve.

How this would/will work is this:

It will take a long time to prepare this image, but once you have it, installing it will be very fast..

I had another thought on this. I am not sure if it would work, or not. Let's say you have a clone image of the whole SD card on a desktop computer.

You should be able to mount its two partitions on that computer. You then create a small empty disk image file and partition that with whatever tools your OS has, labelling the new partitions to have the

And you have a new image file smaller than any SD card you ever intend to use.

This should be scriptable.

Yes, I think I'm with that.

:-) I got something right !

Wow, I think I understand that, it makes sense to me.

Building something from scratch is time consuming. So when I build a music player I do it in stages:

1. OS
2. OS + SAMBA
3. OS + SAMBA + mpd
4. all the above plus Media player.

After building each stage I save the image to hard disc so that should I wish to test a beta version of media player I install level

Much faster and mistakes are fewer as stages have been proven.

The problem now is image size. I have several 4GB sd cards and they all seem to be slightly different sizes. I have to build on the smallest of the cards to get an image small enough to go onto any of my cards. That means I'm fixed on one card.

My need is to make any the stages fit onto any of the 4GB cards and even better if I could reduce the enormous amount of disc space these images take up. Especially true as these images are 30% - 50% empty.

Yes, I suppose.

OK.

Principle OK, doing it no chance.

Struggle.

No understanding of loopback, I thought that was 128.0.0.1 or something like that. :-)

Is this some sort of format procedure?

I'm lost!

It is ample demonstration of how little I know.

Thanks.

Bob.

Can you edit a file in the ext4 partition of the SD card after burning with raw image but before you put it in the SD slot of the Pi for first boot? If so, edit the firstboot file in usr/lib/raspberrypi-sys-mods/ directory of the second (ext4) partition. Edit the line TARGET_END=$((ROOT_DEV_SIZE - 1)) Change the 1 to 1048576 That will make the automatic expansion of the root file system at first boot to leave approx. 512Mb (0.5Gb) space at the end on the SD card. I.e reduce the 4Gb down to 3.5Gb

Alternatively, do you have access to machine with a full version of Raspbian? I.e. with graphical desktop. Install gparted (using apt). Put target SD card in USB adapter and insert into USB port. It will show as /dev/sda if no other disks in USB. Run gparted as root to shrink the second partition (ext4) of the SD card (sda).

The only way I could think of to be able to read/write files on the SD card without the card running was possibly by plugging the card into my Synology NAS (linux) via usb. It does list something but I strongly suspect it's the first partition.

Even if I could I don't understand because the card has to have been run to be created and saved but I'm sure I don't really understand it.

I'm afraid I do not.

Thanks for the ideas.

Bob.

That is the case, but it is step 2 of a 2 part process.

Step 1 is to use a partition editor (gparted or parted) to resize the ext4 partition in the image file, as described earlier in the thread.

That's step 2

Yes

Yes

---druck

Thanks druck that is encouraging.

So I need to use either gparted or parted. Do they operate on an image file (ready to be burnt to an sd card) or do they work on a drive with working partitions (but obviously not the OS drive)?

Hope my terminology is good enough to be understood.

Thanks.

Bob.

Both.

I think you need to 'loop mount' the image to operate on it

You do need a working linux machine to utilise them though - they are not windows tools

Booting a live CD/DVD/USB drive linux system will net you all you need for the duration.

If you have an old machine you can install linux on it might help a lot learning your way around the tools, or a Pi with a screen and keyboard is just as good, ifd a tad slower

It is.

loop mount ??????

I'm sure you're right, it would help if I had a Linux machine proper.

I'll look into a disc boot device of some sort. There's an old XP machine upstairs which my wife has decided should go to the tip. If I start using it now .......

Trying to get my head around all of this, I have this morning gone through Ian's procedure again. It was easy the second time and knowing what to expect. I was hoping I could see how Druck's chain saw suggestion would help but I don't see it yet.

Interesting though.. Before Ian's procedure partition 2 was

After Ian's procedure P2 was

I don't see how all the data can be there?

To say I don't understand would be a big understatement.

Would the procedure be any faster if the files were just copied from part2 to safe area and copied back to the new partition rather than using Tar?

It's the tar up and down and the saving of the new image which is so slow it makes it impractical.

Thanks.

Bob.

Probably not, sadly

Indeed. I let my rsync* backup run overnight.

Take a look at eBay for used laptops, especially Lenovo ones: all Lenovos will run Linux and have USB sockets and their Thinkpad series are solid and well made machines:

- my first laptop was a Lenovo R61i which served me well for 12 years, until its hard disk died in 2017. Its still usable as well as faster since I replaced the dead disk with a 120GB SSD (by 2017 you couldn't buy hard drives smaller than 500GB but the R61i hardware can't handle disks bigger than 220GB, hence the small SSD which is still big enough to holds everything that was on the dead disk.(spread sheet and word processing programs, GIMP image editor, C and Java compilation systems, Evolution mail client, Google Earth, ...

- Currently I'm using a Lenovo T440 that's at least 7 years old (I bought it off eBay in 2017 (400GB HDD, 8GB RAM) and it is running Fedora Linux. It also boots happily from a USB-connected HDD or CD disk. It does everything I need and is fairly rugged 1600x900 with a decent screen, SD card socket and a couple of USB sockets.

eBay has 'em from GBP 40.00 to GBP 120.00 as well as

Most modern desktops and laptops should boot from a USB CD drive, and if the CD drive isn't read-only, most PCs should should download a bootable Linux disk image and write it to a CD or USB stick, which should be at least 30-40GB.

I hope the above gives you some useful ideas.