/tmp was full while updating, bricked my install?

So I guess my /tmp was full (which I guess by default lives on my RAM?) when running an update via `sudo pacman -Syu'. I saw many extraction errors during the update due to /tmp being full. I tried rebooting and am greeted with kernel panics. System won't boot. What gives? What did I do wrong? Seems weird that a full /tmp while running an update can ■■■■■ the system?

1 Like

Shouldnt have rebooted half-way through.
Heres some info on the thing: https://wiki.archlinux.org/index.php/tmpfs
As for now, I hope its as easy as:
-Hit 'e' at grub selection
-At boot options add a '3'
That might get you to command prompt, where we should try
sudo pacman -Syyu

Wouldn't it make sense for pacman to check for diskspace in /tmp before attempting to update/install packages, and fail?

Seems way too easy to make this mistake.

/tmp is cleared on every boot - it is usually not too common it would be full, especially if you arent building alot from source. That said, it can also be managed to have a larger size or even to clear in a set number of days, if you are someone who fills it up and does not reboot often enough.
And pacman did check, thats why your update failed. But, you had let it do partial things, did not clean up /tmp and then did not finish what was at hand before rebooting.

Please see the linked wiki article for how to manage it differently, if thats what you would like.
A similar arch thread here: https://bbs.archlinux.org/viewtopic.php?id=223858

It is probably because you exhausted your inodes rather than ran out of space. I used to encounter that error when building firefox-kde-opensuse on my old comp with limited ram. My solution was to disable tmpfs before starting the hours long build process.

Yes, it would be nice, but pacman doesn't know in advance how much temporary storage it will need.

When pacman runs out of space in /tmp (which is by default limited to half your RAM), I use yaourt instead, which allows me to specify an alternative location for temporary storage on my hard drive.

First, create your new temporary storage location:

mkdir ~/tmp

Next, update your system with yaourt, specifying the temporary storage location:

yaourt -Syu --tmp ~/tmp

Finally, delete your temporary storage:

rm -r ~/tmp

I suppose it would also help to point out that these 2 are not the same things. /tmp is mounted as tmpfs - as in /tmp is using the 'temporary filesystem' mount to run things in RAM. This is nice because it speeds up whatever needs /tmp alot. Its a feature with a default 'cap'.
As mentioned, you can change how it works, but you can always opt not to use it at all too.
Then everything that goes in /tmp will use your disk instead. It can balloon for as long as you have space left, with of course a performance hit.

Oh and again from the wiki, you can even temporarilly change the allocated size (as before large compiles) without the need for a reboot:
mount -o remount,size=8G,noatime /tmp
where size is whatever you choose ... [ok now I should clarify - probably not all of your RAM]

Never a good idea to do system updates with an AUR helper. :frowning:

1 Like

Does pacman use /tmp extensively?

yaourt, yes, but pacman ?

(Also, I'm pretty sure the term "■■■■■■■" is overused. I mean, the system is not a "■■■■■" now, given it boots and can be fixed.)

Edit:

No, pacman doesn't use /tmp at all.

So, OP is misleading by mentioning pacman -Syu.

1 Like

It cannot and bricking is something else than this. Your system is not booting because you interrupted a kernel update before it had time to rebuild initramfs. Just chroot to your installation and

 pacman -Syu
 mkinitcpio -P
 update-grub

See tutorial

1 Like

Pacman uses /Var/cache not temps as suggested it also checks disc space and will inform the user before upgrading. Now if you were ugrading with a helper or AUR packages then its nothing to do with pacman. so please give the true infomation and don't dramatise it does not help you or anybody trying to help.

2 Likes

I increased the volume of my /tmp directory by adding this line to the etc/fstab file:

tmpfs /tmp tmpfs nodev,nosuid,size=3G 0 0

So the /tmp directory is great enough for udates.

Regards
Steffen

So how much real ram have you got

sh-4.4$ inxi -I
Info:      ... Memory: 1778.9/3143.0MB ....

So... you've allowed the system to fill your RAM with package cache data?

Can you see why that might be a slightly bad idea? (Hint: what happens when you run out of memory?)

You'd be better off moving it off RAM to a temporary location on disk. Or, perform an update of repo packages first, then step through each AUR package in turn.

Its kinda edgy - but tmpfs will also use swap if necessary - so most conditions probably wont cause a full failure/lockup. Probably.

?
I increased my /tmp directory.
This works for me without any problem... :slight_smile:

You increased the amount of space /tmp - mounted as tmpfs - is allowed to take. tmpfs means using RAM. While it only takes up as much as is actually in-use, jonathon is pointing out that if you allocate it your full RAM you could run out of RAM and your system will lock up, so making this possible isnt exactly safe.

If you run out of ram space in tmpfs you will error out, and have to go through the whole process again (with likely the same result). As I said earlier I often encountered this when building the firefox-kde-opensuse version from the AUR. The solution was easy I simply commented out the tmpfs entry in my fstab before building. Once the build was finished I simply restored the tmpfs entry in fstab. Maybe not an elegant solution, but it worked every time.

The good thing is you have learned from this :grin:

Forum kindly sponsored by