On 7/15/2016 11:17, Kevin Oberman wrote: > 11.0 has not been released. You are much more likely to get a useful > response from current@. > > On Fri, Jul 15, 2016 at 5:09 AM, Filippo Moretti via freebsd-stable < > freebsd-stable@freebsd.org> wrote: > >> I have the following problem when I start the system: > > >> Unknown user name "avahi" in message bus >> configuration fileUnknown user name "polkitd" in message >> bus configuration file >> Unknown user name "polkitd" in message bus >> configuration fileUnknown user name "colord" in message >> bus configuration file >> Unknown user name "pulse" in message bus >> configuration fileUnknown user name "polkit" in >> message bus configuration file > Unknown user name "haldaemon" in message bus configuration file > > Failed to start message bus: > > Could not get VID and GID for username "messagebus" > > /etc/rc:Warning:failed to start dbus > > On the same computer I have a disk with 10.3_STABLE with the same >> configuration files and everything is working properly.When in X I launch >> firefox I get the following errorLibGL error: > failed to open drm device:Permission denied > > LibGL error :failed to load driver: r 300 > > This is very likely due to failure to start dbus > > sincerely > > Filippo > > > Note: I have tried to recover the mail format above. Whatever mail tool you > used totally garbled things by removing line breaks. > > First, how did 11.0Beta-1 get installed? How sis your ports (X11, dbus, > pulseaudio, etc.) get installed? When moving from one major release to > another (10 to 11), you need to reinstall all ports/packages. The > installation process is what creates these"users". > > It looks like you are just trying to run the things in /usr/local from your > 10.3 system. This simply will not work. > -- > Kevin Oberman, Part time kid herder and retired Network Engineer > E-mail: rkober...@gmail.com > PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
Actually it SHOULD work unless you deleted the old libraries (in which case it definitely won't!); the dynamic loader is smart enough to do the right thing and load the correct (older) version of the shared libraries required. If this has been broken in recent releases IMHO that's not so good. There *are* instances where an older binary is all there is for a given application (e.g. from a vendor!) and thus backward compatibility when you roll forward the operating system is something that a lot of people (myself included) have both used and relied on for a very long time. Yes, I understand that you can't *count* on that working, particularly if the app in question makes explicit reference to things in the kernel environment. But absent that they certainly should run. One instance where they didn't was with the armv6/armv6hf case where the floating point format changed, but that happened in the -CURRENT environment where ABI breakage is a known (and thus accepted) risk of running -CURRENT. (That particular one manifested in some nasty ways too in that going the "wrong way" would result in a binary that executed, did not produce any exceptions or traps, but produced incorrect floating-point results! I have code "in the wild" that checks for this specific circumstance on startup "just in case"....) Now if you do perform a merge and only accept part of it you can get in a lot of trouble with user and group IDs and similar, which is what appears to have happened here. It's pretty easy to get bit by that if you have local changes in your passwd and group files (and most people do), "leave them for later" and then don't go back and merge the new entries by hand. That sounds like what's occurred here; check in /var/tmp, assuming you told mergemaster to keep it when done. Since the svn repo for stable/11 is now there and when checked out builds BETA1 this IMHO appears to be the right place to discuss it. -- Karl Denninger k...@denninger.net <mailto:k...@denninger.net> /The Market Ticker/ /[S/MIME encrypted email preferred]/
smime.p7s
Description: S/MIME Cryptographic Signature
