RPI3 FreeBSD12.0-Current can't resize partition

T

T-Mac

Capture.PNG

I downloaded the RPI3 FreeBSD12.0-Current from the RaspBSD.org website and followed the instructions to use Win32DiskImager to flash the SD card. Everything worked great and it booted right up! But I quickly ran out of space in the partition, and can't get it to resize. I have googled for hours and tried everything I found, including a couple of threads that described my exact problem - but the solutions never worked. And tried reading all the relevant man pages. I will confess to being a bit of a newbie on BSD and am probably missing something simple. I believe the snip demonstrates the root of the problem.



Thanks in advance!
 
Phishfry - Thanks for the tip. (For some reason I can't see your responses in the Forum). I had something stuck in my head from some RPI/Raspbian documentation that was preventing me from seeing the real problem - my stupid error. The /tmp is only 29mb, which evidently is too small for pkg install ... to do much of anything. I will try to move it using a symlink. (And as soon as your response shows up in the Forum, I will give you a proper "Thanks".

All this "everything is a file" thing is new to me, despite way too many years using VMS, WIN and a bunch of RTOS stuff. My BSD Handbook is on order and should be here this week. Unfortunately "The Design and Implementation of the FreeBSD Operating System" wasn't much help on this one, despite having two tons of great information on internals.
 
Indeed, Phishfry's reply is invisible.

I had exactly the same problem: /tmp is too small for pkg to work. On the other hand, one can't just make it arbitrarily big, since it is a memory file system; and that makes sense: the root disk is an SD card (which are famously slow and have low write endurance), so putting /tmp on a "disk-backed" file system would be a bad choice. If you have an NFS server nearby, and are using a reasonably fast network (100BT), you are actually better of using an NFS mount for /tmp (that's pretty counter-intuitive).

Here is how I solved the problem on my RPi3 (which unfortunately, I haven't had time to work on in the last few weeks): I noticed that there were two 30MB memory-based file systems, namely /tmp and /var/tmp. But /var/tmp seems to be never used (nothing ever writes to it), so there is no point wasting memory for it. So I destroyed both memory file systems, and only recreated a 60GB for /tmp. Now the pkg command works great (writing to the root disk is still very slow, but that's to be expected on a RPi).

And if some application were to write to /var/tmp it would be slow, but that hasn't caused a problem yet. If I had more time, I would check whether /var/tmp actually has to be a separate directory, and whether it wouldn't be easier to just replace it with a soft-link to /tmp, so it also gets the benefit of the 60MB of memory.
 
ralphbsz - thanks for the info. I don't have an NFS server setup. I think I am going to try using a USB flash drive for /tmp. Seems like a reasonable solution and won't cost much to replace after a few million writes... :)
 
ralphbsz said:
Here is how I solved the problem on my RPi3 (which unfortunately, I haven't had time to work on in the last few weeks): I noticed that there were two 30MB memory-based file systems, namely /tmp and /var/tmp. But /var/tmp seems to be never used (nothing ever writes to it), so there is no point wasting memory for it. So I destroyed both memory file systems, and only recreated a 60GB for /tmp. Now the pkg command works great (writing to the root disk is still very slow, but that's to be expected on a RPi).

And if some application were to write to /var/tmp it would be slow, but that hasn't caused a problem yet. If I had more time, I would check whether /var/tmp actually has to be a separate directory, and whether it wouldn't be easier to just replace it with a soft-link to /tmp, so it also gets the benefit of the 60MB of memory.
Click to expand...

The /var/tmp is actually the "non-volatile" or "persistent" temporary storage - applications expect its content to be kept between reboots [1]. Therefore keeping it in RAM is actually wrong, and you did the correct thing to quit mounting it in RAM. I shall make a pull request to the Crochet, to quit provisioning such images.
 
T-Mac said:
View attachment 3741
I downloaded the RPI3 FreeBSD12.0-Current from the RaspBSD.org website and followed the instructions to use Win32DiskImager to flash the SD card. Everything worked great and it booted right up! But I quickly ran out of space in the partition, and can't get it to resize. I have googled for hours and tried everything I found, including a couple of threads that described my exact problem - but the solutions never worked. And tried reading all the relevant man pages. I will confess to being a bit of a newbie on BSD and am probably missing something simple. I believe the snip demonstrates the root of the problem.



Thanks in advance!
Click to expand...

What was "Phishfry" response? Doing a fresh/initial install and running into the same issue. Plenty of free space, but can't get partition expanded.

Thanks
 
If I go by the original picture, the reason the slice can't be removed is because it contains a partition. You can only delete slices when they're empty (unused). Remove the partition first, then remove the slice.
 
You must log in or register to reply here.
Back
Top