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 at .
>
> On Fri, Jul 15, 2016 at 5:09 AM, Filippo Moretti via freebsd-stable <
> freebsd-stable at 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: rkoberman at 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
karl at denninger.net <mailto:karl at denninger.net>
/The Market Ticker/
/[S/MIME encrypted email preferred]/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2996 bytes
Desc: S/MIME Cryptographic Signature
URL:
<http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20160715/ad38d2aa/attachment.bin>