Re: su problem
On 9-6-2012 18:42, Eugene Grosbein wrote: > 09.06.2012 19:47, Sami Halabi пишет: >> %su - >> Password: >> load: 0.00 cmd: su 30588 [ttydcd] 0.91r 0.00u 0.00s 0% 2092k > > Perpaps, your system had no keyboard attached at boot time; > or for some other reason it booted with /dev/console being serial console > instead of vidconsole. su locks trying to access serial console > that is /dev/ttyd0 by default and has Carrier Detect flag enabled. > Hence, it waits for CD on the first serial port (miserably and hopelessly). > > You can check if it's true with "sysctl kern.console" command. > You could ask someone to boot the system with keyboard attached - > no need to type anything, though. The system should detect it > and assingn /dev/ttyv0 as /dev/console instead of /dev/ttyd0. > And "su" won't lock. Just to get this clear - are you connected via ssh and want to use su? If so, I fail to see why the keyboard would be in play as you need a pty, not a vty. Secondly, your logs mention a kbd2 that is disconnected, so where's kbd1. And finally, why did the person that connected and disconnected the keyboard leave a root login open? -- Mel ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Implications of pkgng, was Re: Why Are You NOT Using FreeBSD ?
On 3-6-2012 9:58, Matthew Seaman wrote: > On 03/06/2012 02:21, Erich wrote: >> I do not believe that much more would be needed. Of course, we have >> then a huge number of versions. Would it matter? Give the ports tree >> the major version number of the latest release. So, at the moment it >> would be 10. Increment then the minor every hour if you want. Just >> make sure that the ports tree can be downloaded for some time under >> this version number. > > What exactly is this supposed to solve? Simply attaching a number to > the ports tree won't do anything. There is already a promise that the > ports should work on all supported FreeBSD release branches. There's one problem that can never practically be solved and one that isn't being tested by maintainers because of Tinderbox. The first is that very fast the possible number of combinations introduced with options goes out of range of a human life time. This is especially true for GUI components. Other operating systems referenced here are no comparison, since they simply do not provide those kinds of choices for 3rd party software. The second issue is that Tinderbox processes each port stage separately, starting with a clean system. This hides bugs that only come out when the various stages are chained or when a ports management tool removes and tries to reinstall a port in the dependency chain. In a few cases there are hidden circular dependencies caused by runtime loading. Once the base system supports binary upgrades of packages through pkgng it should solve a lot of issues that people have with production systems now, though there are already people that are deploying custom built binary packages to their production systems using a "wipe and reload" approach. -- Mel ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Why Are You NOT Using FreeBSD ?
On 1-6-2012 20:57, Thomas David Rivers wrote: > We used to have FreeBSD exclusively on desktops... > > Now, we have migrated to other desktops (mac) with FreeBSD running > the build and file server... > > Why? > > Because - the mac updates itself! No pain, no installation, > no keeping-up with mailing lists/announcements, just and its done. Aren't PC-BSD's PBI's working the same way? I know it is their goal. Have you evaluated that? If so, what were your experiences? -- Mel ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: x11/nvidia-driver cannot obtain EDID under 8.0-BETA3/i386
On Friday 28 August 2009 15:50:30 Eugene Grosbein wrote: > Hi! > > Fresh install of 8.0-BETA2 upgraded to 8.0-BETA3 using source, > x.org installed from fresh ports tree. It cannot read EDID from > Samsung 959NF CRT monitor. The same time, it can read EDID under 7.2-STABLE > just fine. I've tried older nvidia-driver-180.60 (downgrading port) > and current port's version 185.18.29, no change. > > (WW) NVIDIA(GPU-0): Unable to read EDID for display device CRT-1 Can't reproduce this with FreeBSD 8.0-BETA2 #10 r196398M both 180.60 and 185.18.29 driver. World/kernel as of today is building, so I'll report back if I can reproduce it then. Different (laptop) monitor though. -- Mel ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: portmaster -R (Was: Re: HEADS-UP: Shared Library Versions bumped...)
On Wednesday 29 July 2009 10:48:33 Doug Barton wrote: > Alson van der Meulen wrote: > > * Doug Barton [2009-07-29 18:13]: > >> Mel Flynn wrote: > >>> Gotcha. Is there a reason the flags are removed if the options are not > >>> "-r or -f"? > >> > >> Yes, so we don't have stale flags sitting around forever to confuse > >> future runs. > > > > I have been bitten by this in the past. A run of portmaster -r > > some-lib-that-half-of-my-ports-depend-on aborted because of a shared > > library error in a dependency which was not recompiled before the > > dependent port. I recompiled the dependency with a manual portmaster > > $portname, after this portmaster -r had to start all over. I didn't > > expect portmaster to clear the PM_DONE flags during non-resumable > > operations like rebuilding a single port (and the manpage contains very > > little information about -R). My workaround is to use portupgrade for > > these manual fixes. > > Yes, I've been considering that exact scenario since atm I'm > rebuilding all my ports with -afR. > > How about this? When the user has -[rf] but not -R, and there are flag > files present, ask if they should be cleared before beginning to do > anything. Otherwise (no -[rf]) ignore them. Sound good? That's definitely "what you would expect it to do". -- Mel ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: HEADS-UP: Shared Library Versions bumped...
On Tuesday 28 July 2009 23:10:50 Doug Barton wrote: > Mel Flynn wrote: > > I wrapped portmaster, since -af has the same problem when something > > screws the build (mostly plist problems and $me wanting backup packages, > > but also classics like using sudo as PM_SU_CMD and trying to reinstall > > it). > > I hate to tell you but portmaster already has the ability to restart > after an interrupted -af. See the man page regarding the -R option. Maybe that can be cleared up: -R restart an update, skipping ports already up to date. Used with -r ^^ or -f options. Yes, I should've gathered what it meant when reading "or -f options", but I never read that far. Perhaps that could read "... already done in the previous run". > So > you can do this the first time: portmaster -Daf > > Then do this the second (or more) time: portmaster -DGRaf And with the above in EXAMPLES. > The one caveat is that you don't want to run any other portmaster > commands in between since it will remove all the flags when it exits > successfully. Gotcha. Is there a reason the flags are removed if the options are not "-r or -f"? -- Mel ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: HEADS-UP: Shared Library Versions bumped...
On Thursday 23 July 2009 22:55:07 Daniel O'Connor wrote:
> On Wed, 22 Jul 2009, John Baldwin wrote:
> > > How many of those 800 ports are actually necessary and used?
> > > It would be better to get generate a complete list of your
> > > installed ports, use pkg_deinstall or pkg_delete to remove
> > > all ports, and then selectively re-install ports that are
> > > actually used.
> >
> > Xorg takes up ~200 ports alone (not including dependencies like perl,
> > etc.) since the Xorg decided release engineering was too hard. Throw
> > in things like KDE, OOo, Firefox, etc. for a desktop and you can get
> > a fairly high package count. :-/
>
> Ooh I only have 1315 on mine, but a 1.4GHz Pentium-M is pretty slow
> these days :(
>
> Perhaps there needs to be a psuedo port for 'base' (or a few) so that
> you can easily determine if you have already upgraded something against
> the new base you installed.
>
> Certainly I find it difficult to leave my laptop on for long enough to
> recompile everything when I upgrade -current (since I actually use it
> for work), and portupgrade -fa has no way to tell if it's already done
> something. If there were pseudo base ports you could tell it to force
> upgrade everything that depends on the old base port and it would DTRT.
I wrapped portmaster, since -af has the same problem when something screws the
build (mostly plist problems and $me wanting backup packages, but also
classics like using sudo as PM_SU_CMD and trying to reinstall it).
Basically, I made a list of all the installed ports and sorted dep order, then
called portmaster -u for every port and if successful put an empty file
+PM_DONE in /var/db/pkg//. On a restart the ports containing a
+PM_DONE file are skipped.
If the entire process finishes successfully, all +PM_DONE files are removed. I
briefly looked into building it into portmaster, but that looked to take
longer then I had time for. The main loop is at the bottom, perhaps Doug likes
the idea and has the time to integrate it.
> I, of course, have no patches for such a thing :)
>
> I've deleted /usr/local & /var/db/pkg in the past, it can be very
> therapeutic :) However it is not so good when your mp3 collection is
> mounted on /usr/local/mp3 and you forgot to unmount it first.. :(
Or your websites in /usr/local/www, your database in /usr/local/pgsql or your
squid conf and cache in /usr/local/squid. Especially when pkg_delete -af does
the right thing and leaves all this in tact, I don't see the value of rm -rf
/usr/local, other then a few minutes on a process that's likely going to be
several hours or days.
--
Mel
mark_done()
{
local _name
_name=$1
if test -d ${PKG_DBDIR}/${_name}; then
${SUDO} ${TOUCH} ${PKG_DBDIR}/${_name}/+PM_DONE
else
return 1;
fi
return 0;
}
for origin in ${LIST}; do
pkgname=$(make -C ${PORTSDIR}/${origin} -V PKGNAME)
if test -f ${PKG_DBDIR}/${pkgname}/+PM_DONE; then
echo "Already done: ${pkgname} (${LOOP}/${TOTAL})"
else
echo "===> Building ${pkgname}"
portmaster -u ${PORTSDIR}/${origin}
if test $? -eq 0; then
mark_done ${pkgname} || safe_abort
else
FAILED=$((${FAILED} + 1))
echo "Failed, continue? [n]"
read CONT
case "${CONT}" in
[yY]|[yY][eE]|[yY][eE][sS])
echo "===> Marking state as done"
mark_done ${pkgname} || safe_abort
;;
*) break;;
esac
fi
fi
done
if test ${FAILED} -eq 0; then
echo "===> Removing state files"
for FILE in ${PKG_DBDIR}/*/+PM_DONE; do
${SUDO} /bin/rm ${FILE}
done
echo "===> Removing origin list"
/bin/rm ${LISTFILE}
fi
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
