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... -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... _______________________________________________ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
