No room left on primary partition

I am running my asl3 on a 32 gig micro sd card. I t seems that on the installation, it created 2 partitions. The first is out of space and I am not sure what to do about it. Can I move stuff to the secondary partition?
Thanks,
Dave
N8EPF


The /tmp/ filesystem is ram-backed and limited in size. What kind of device are you on and how much RAM does it have?

I am running asl3 on a raspberry pi 5 with 8 gigs or ram. The system doesn’t seem to be short on resources. It usually only uses like 5 percent of the ram and only like 2 or 3 percent of cpu. I thought I saw somewhere about an app that allowed you to change drive sizes.
Thanks,
Dave
N8EPF

Please provide the output of df -h.

I am really interested in fixing this. Does this screen capture tell you anything?
Dave
N8EPF

Interesting. I wonder why your system is out of space like that. Anyway, edit the file /etc/fstab and change this line:

tmpfs   /tmp            tmpfs   defaults,noatime,nosuid,nodev,noexec,mode=1777,size=128M 0 0

to this:

tmpfs   /tmp            tmpfs   defaults,noatime,nosuid,nodev,noexec,mode=1777,size=512M 0 0

Then you need to reboot the system.

This does nothing to solve the problem of running out of memory to run reports. I made the change and rebooted but it didnt help. Exacly what is changing that 128M to 512M do?
Dave
N8EPF

As @N8EI wrote, our default ASL3 appliance configures the “/tmp” (and “/var/tmp”) filesystem to be backed by RAM. We do this to reduce the wear on the SD card. With many of the RPi’s having a limited amount of RAM we set a small but reasonable limit (based on typical ASL3 usage) on the size we set aside.

The suggested change was to bump the allocation from 128M to 512M but that does not appear to be enough for whatever report you are generating.

Since your device has lots of RAM you can increase the size a bit more. You can also comment out the line in the /etc/fstab file. That will have any files created in /tmp going to the SD card.

Something else is broken if an sosreport is consuming even 128M of /tmp, let alone 512M. Have you looked at the output of dmesg for errors?

Why are you running a Diagnostics SOS report? I’m not sure that’s ever been tested with the Pi Appliance. That’s usually for generating diagnostics for OS support cases and that probably does take up a lot of space.