Port update hosed entire system
freebsd at edvax.de
Tue Oct 2 07:16:52 UTC 2012
On Tue, 2 Oct 2012 06:20:45 -0400, Rod Person wrote:
> It would never have occured to me that updating a port that
> has to do with audio and video containers would totally leave me unable
> to login into my system or issue and shell commands without getting
> a segmentation fault.
I find it very hard to see a correlation here. Coincidence? Yes,
but I cannot imagine a way a port can dmage the system in that
way so not even shell commands keep working...
> I did discover that my / file system had run out of space -131MB.
That could show that some part of important content on / has
not been written yet - it's still held in "write buffers"
pending. So you could first check what takes up space in /
that is not required to be there, and remove it, then the
"write buffers" will be written properly. A "sync" command
could do this on request.
Check with "df -h" for _no_ negative values before rebooting
the system into SUM. I'm not sure if the "write buffers" can
survive a shutdown.
> I'm still able to issue sudo, so using sudo rm -r I was able to free up
> 25GB...but still, /bin/sh, ls, clear all seg fault and su doesn't work
> and switching consoles doesn't let me log in.
That sounds that somehow calling programs (executing / forking)
is not working properly anymore. As this is one of the most
fundamental mechanisms of the systems, it's hard to believe
that this can be triggered through a port update...
> I maybe be left with attempting a single user boot, but I'm still not
> that comfortable at attempting such as I don't want to have a totally
> useless box.
You'd have to find out the exact problem first, maybe the
solution is simple. However, how is a ports update supposed
to change stuff on /? I assume you have a partitioned system
with functional separation, e. g. /, /var, /tmp and /usr
(where /usr/local and maybe /usr/home are located). When
updating a port, data in /var/db, /usr/ports and /usr/local
will be dealt with. Nothing of that should happen on /, or
even touch system shells...
I assume you have no script of what happened during the
port's upgrade? Using "script" (see "man script" for details)
is a convenient solution if you want to run upgrades while
not being able to monitor them constantly.
On Tue, 2 Oct 2012 06:12:27 -0400, Rod Person wrote:
> This is the default shell. I didn't try that yet, because I don't want
> to be left with no way to login at all if something is really messed up.
You have a stand-alone emergency shell in /rescue/sh (which is
on the / partition, so it can even be started in single-user
mode with / mounted read-only).
> Since I could not even switch to a no console (ctrl+alt+f2...) and
> login I'm not really wanting to reboot at this point.
>From within X, you need Ctrl+Alt+PF2; from text mode, only Alt+PF2
is needed (even though I checked... Ctrl+Alt+ also works in text
mode). So you can't even switch VTs? Interesting, makes the problem
much more strange...
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...
More information about the freebsd-questions