Resizing Partitions on a new APU1C Install

Stewart

We've begun experimenting with the PC Engines APU1C box and so far it's working well. We were a little concerned with heat with all of the reviews out there, but the bottom of the case only gets a little warm. The concern now is that the image file is only 4GB while we are using 8GB SD Cards. I'm really confused about what to do to resize the partitions.

If I do a "gpart show da0" I see:
da0 MBR (4.7GB)
1 freebsd (1.9GB)
2 freebsd [active] (1.9GB)
3 freebsd (50MB)

free - (3.7G)

Now, I'm assuming 1 is the restore in case the reset button is pressed and 2 is the active partition I'm working in. I'm not sure what 3 is.

If I do a "df -h" I see:
/dev/ufs/pfsense1…..1.8G.....638M.....1.0G...../
devfs.........................1.0k......1.0k.......0B......../dev
/dev/ufs/cf.................49M.......1.4M....44M....../cf
/dev/md0..................38M........74k.......35M...../tmp
/dev/md1..................57M........16M......36M...../var
devfs........................1.0k.........1.0k.....0B......./dhcpdev
(Sorry about the formatting. I don't have console access to copy and paste.)

57M seems awfully small for /var if it's going to have logs stored in it for snort, clamav, etc. Is there any way to expand to use the other 4GB and would I then be able to write it back so that it works on reset? I understand that since it was a 4GB image I used it is split into 2GB+2GB. I'd like to instead make that 4GB+4GB, if it's possible, so that it isn't so pressed for space. If I'm misreading it I'd love to know what I'm seeing wrong and what I can use that other 4GB for. Thanks for any help.

Stewart

New idea. What about just making the free 3.7GB space a new partition and point /var to it?

JeGr

Hi Stewart,

On a NanoBSD installation, Logs aren't stored in the file system but in a TMPfs in memory. That's to reduce write cycles on (especially older) CF or SD cards or even if you're paranoid about using small SSDs. So 50M for VAR ist perfectly fine. If you are going to run snort, squid and logging intensive services I'd either consider logging to a remote system (which is by far the better alternative, as you can even do fancy log analysis with stacks like logstash+kibana+elasticsearch) or to consider perhaps using a msata SSD with ~30G and do a complete install on this (and only reroute VGA to console). Then you'll have enough space for logging of all sorts, speed of SSD to browse them and IMHO a more reliable storage system then "cheap" SD cards (nothing wrong with them, but as a daily driver with logfiles re-written over and over again, I'd assume they wear out sooner then later).

Greets
Jens

hrts

Hi Stewart

I am also using APU1C4 but with ipFIRE!
I had the exact situation you face: how to resize the SD partitions (I also used nano version - but, as already mentioned, from another FW vendor).

My solution was simple: got de SD card out from APU1C4 box, put inside the laptop (or a PC), boot the laptop/PC with GParted and used Gparted to resize the SD. It's all graphical: use the mouse to drag the partition and hit apply. :)

If you are not familiar with Gparted, don't worry: here is a simple program that builds for you one USB with Gparted and you can boot it without messing with your usual OS installed in the laptop/PC.

The tool I used is Xboot: http://www.pendrivelinux.com/xboot-multiboot-iso-usb-creator/
As soon as you install the tool you can use it to:
1. Download GParted (the Xboot has an impressive collection of tools you can download for free! You can even put all tools in one large USB and select which one to boot from XBoot menu!)
2. Build an Bootable USB with Xboot - you can add more than one toot to this USB; XBoot will prompt you what tool you want to boot.

If you do not like USB boot and prefer CD, don't worry. Use Xboot to download GParted and burn the file to a CD (GParted is on ISO format that can be put on CD).

Have fun!

Stewart

@hrts:

Hi Stewart

I am also using APU1C4 but with ipFIRE!
I had the exact situation you face: how to resize the SD partitions (I also used nano version - but, as already mentioned, from another FW vendor).

My solution was simple: got de SD card out from APU1C4 box, put inside the laptop (or a PC), boot the laptop/PC with GParted and used Gparted to resize the SD. It's all graphical: use the mouse to drag the partition and hit apply. :)

If you are not familiar with Gparted, don't worry: here is a simple program that builds for you one USB with Gparted and you can boot it without messing with your usual OS installed in the laptop/PC.

The tool I used is Xboot: http://www.pendrivelinux.com/xboot-multiboot-iso-usb-creator/
As soon as you install the tool you can use it to:
1. Download GParted (the Xboot has an impressive collection of tools you can download for free! You can even put all tools in one large USB and select which one to boot from XBoot menu!)
2. Build an Bootable USB with Xboot - you can add more than one toot to this USB; XBoot will prompt you what tool you want to boot.

If you do not like USB boot and prefer CD, don't worry. Use Xboot to download GParted and burn the file to a CD (GParted is on ISO format that can be put on CD).

Have fun!

Unfortunately, gparted doesn't work with the UFS filesystem. It just sees them as unknown and won't do anything with them. What filesystems are you using?

Stewart

@JeGr:

Hi Stewart,

On a NanoBSD installation, Logs aren't stored in the file system but in a TMPfs in memory. That's to reduce write cycles on (especially older) CF or SD cards or even if you're paranoid about using small SSDs. So 50M for VAR is perfectly fine. If you are going to run snort, squid and logging intensive services I'd either consider logging to a remote system (which is by far the better alternative, as you can even do fancy log analysis with stacks like logstash+kibana+elasticsearch) or to consider perhaps using a msata SSD with ~30G and do a complete install on this (and only reroute VGA to console). Then you'll have enough space for logging of all sorts, speed of SSD to browse them and IMHO a more reliable storage system then "cheap" SD cards (nothing wrong with them, but as a daily driver with logfiles re-written over and over again, I'd assume they wear out sooner then later).

Greets
Jens

I guess for the most part we are looking at using Squid with the clamav tie-in, mostly for filtering and scanning and not caching. It should have plenty of power for a small offices of < 25 users as we've been doing it on a 1st gen atom that needs to handle a great deal more traffic and it hasn't had any problems. Would an SD Card really wear out that quickly? We've had very poor luck with SSDs that we've tried. We've had high failure rates with Supertalent, Intel, & Crucial so we figured that SD cards can't be any worse.

hrts

@Stewart:

Unfortunately, gparted doesn't work with the UFS filesystem. It just sees them as unknown and won't do anything with them. What filesystems are you using?

Hi,

Here is my fstab: looks like my FW uses a combination between ext4 and ext2.

cat /etc/fstab
#
# file system  mount-point  type     options         dump  fsck
#                                                        order
UUID=2e47db95-94de-4dec-8935-9b0caa651ca2       /boot   ext2    defaults       12
#DEVICE2         swap   swap    pri=1   0       0
UUID=dd0bc5ec-257d-4e2b-b5fc-a480f437c884       /       ext4    defaults       11
#DEVICE4        /var    ext4    defaults        1       1
none    /var/log/rrd    tmpfs   defaults,size=64M       0       0
none    /var/lock       tmpfs   defaults,size=8M        0       0
UUID=456B-B361  /Backup_Intern  auto    defaults        0       0

jasonlitka

You should not attempt to resize the partitions on a NanoBSD install. Assuming you're successful you'll likely end up in a situation where you can't update to a newer build without backing up your config, reflashing, resizing, and then restoring the config. If you need local logging, or on-disk caching with squid, then you should switch to a full install.

Ignore what hrts is saying about gparted. ipFire (based on Linux) and pfSense (based on FreeBSD) are nothing alike and what works on one will likely break the other.

Stewart

I was actually able to fix the problem, I think. Instead of resizing partitions, we are able to increase the size of the RAM drives. While this may result in the loss of virus definitions and such on a reboot, it only takes about 4 minutes to be fully operational.

jasonlitka

@Stewart:

I was actually able to fix the problem, I think. Instead of resizing partitions, we are able to increase the size of the RAM drives. While this may result in the loss of virus definitions and such on a reboot, it only takes about 4 minutes to be fully operational.

Ok, that would work too.