Page MenuHomeFreeBSD

freebsd-update upgrade fails if /var is a tmpfs

Authored by feld on Nov 14 2014, 4:41 PM.



This is my lame attempt at fixing the issue documented in

It's not going to be bulletproof as anyone could use another different non-persistent filesystem we aren't aware of, but this should help...

Diff Detail

Lint Skipped
Unit Tests Skipped

Event Timeline

feld updated this revision to Diff 2405.Nov 14 2014, 4:41 PM
feld retitled this revision from to freebsd-update upgrade fails if /var is a tmpfs.
feld updated this object.
feld edited the test plan for this revision. (Show Details)
feld added a reviewer: cperciva.
feld set the repository for this revision to rS FreeBSD src repository.
cperciva edited edge metadata.Nov 14 2014, 8:28 PM

Looks good. I don't know what sort of crazy it takes to put /var on a tmpfs, but this is definitely the right way to respond to that situation.

feld updated this revision to Diff 2436.Nov 17 2014, 9:55 PM
feld edited edge metadata.
feld added a subscriber: ian.

@ian noticed an issue with the way mfs was being detected and suggested we use a case and df -T instead. Turns out that mfs masquerades as ufs when mounted, so we need to check for the /dev/md* string

Previous patch was committed but doesn't break anything; just won't actually detect mfs.

ian accepted this revision.Nov 17 2014, 10:13 PM
ian added a reviewer: ian.

The sort of crazy I am that leads to /var on an mfs is an embedded systems person. :) I'm always having to deal with readonly root issues. Of course, I'd never use freebsd-update to update a readonly root type system.


Now that I see the wider context, I think it might be good to use df -T ${WORKDIR} rather than the $(...) construct I suggested. They are equivelent but it makes sense to use consistant style within the script.

This revision is now accepted and ready to land.Nov 17 2014, 10:13 PM
feld closed this revision.Nov 18 2014, 1:39 PM

Thanks @ian for catching that mistake and suggesting a better way. :-)