Geen netwerkverbinding meer CentOS (na poging tot VMWare?)

[Reynouts]

Op dit moment draai ik Scientific Linux 6.7 (CentOS) en heb na een reboot geen netwerkverbinding meer.
Ik heb geen hele diepe kennis van Linux, maar probeer me te redden met de informatie die ik kan vinden.

Ter inleiding, waar ik zelf misschien denk dat iets mis is gegaan:
Gisteren heb ik geprobeerd om VMWare Client te installeren, dit heb ik op deze manier geprobeerd. Uiteindelijk is dit niet helemaal goed gelukt, blijkbaar miste ik nog een aantal libraries, waar ik niet aan kon komen ("./vmware-view: error while loading shared libraries: libssl.so.0.9.8: cannot open shared object file: No such file or directory"). Wel had ik (misschien niet al te slim?) het geheel naar de /usr/ directory gekopieerd.

De problemen
Na een reboot merkte ik op dat de ethernetverbinding niet meer tot stand kwam. Ik ben op onderzoek uitgegaan.

Hieronder wat uitvoerinformatie van de verschillende commando's

code:

ifcgf -eth0

DEVICE=eth0
TYPE=Ethernet 
UUID=2334099a-fa6a-4027-8eba-44900829b19b 
ONBOOT=yes 
NM_CONTROLLED=yes 
BOOTPROTO=dhcp 
HWADDR=ec:b1:d7:2f:58:71 
DEFROUTE=yes 
PEERDNS=yes 
PEERROUTES=yes 
IPV4_FAILURE_FATAL=yes 
IPV6INIT=no 
NAME ="System.eth0" 
DNS2=10.10.2.11 
DNS1=10.10.2.10 
USERCTL =no

code:

bash-4.15.sudo.dhclient -v-eth0
Internet.Systems,Consortium DHCP Client.4.1.1-P1
Copyright.2004-2010-Internet Systems Consortium. 
All.rights reserved. 
For info, please visit.https://www.isc.org/software/dhcp/ 

Listening on LPF/eth0/ec:bl:d7:2f:58:71
Sending on LPF/eth0/ec:b1:d7:2f:58:71 
Sending on Socket/fallback
DHCPREQUEST on eth0 to 255.255.255.255-port 67 (xid=Ox54cf8fe2) 
DHCPREQUEST on eth0 to 255.255.255.255 port 67 (xid=0x54cf8fe2) 
DHCPACK from 10.10.3.1.(xid=0x54cf8fe2) /etc/sysconfig/network-scripts/network-functions: line 548: /usr/bin/logger: Permission denied
 bound to 10.10.3.124 -- renewal in 33917 seconds.

code:

bash-4.1$ ifconfig 
eth0
Link encap:Ethernet Maddr EC:B1:D7:2F:58:71
inet6 addr: fe80::eebl:d7ff:fe2f:5871/64 Scope:Link 
UP BROADCAST RUNNING MULTICAST MTU:1500 Metrical 
RX packets:39003 errors:0 dropped:0 overruns:0 frame:0 
TX packets:166 errors:0 dropped:0 overruns:0 carrier:0 
collisions:0 txqueuelen:1000 
RX bytes:4150209 (3.9 MiB) TX bytes:28161 (27,5 KiB)
Interrupt:20 Memory:f3200000f3220000

lo 
Link encap"Local Loopback 
inet addr :127.0.0.1 Mask 255.0.0.0
inet6 addr: :: 1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:23104 errors:0 dropped:0 overruns:0 frame:0
TX packets:23104 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:1386240 (1.3 MiB) TX bytes:1386240 (1.3 MiB)

Hierna wilde ik al deze gegevens via een tekstbestandje op een USB-stickje zetten en in dit topic plakken en kwam ik erachter dat ik niets meer kon mounten. Palipsest gaf me deze error:

code:

sudo palimpsest

(palimpsest:7668): Unique-DBus-WARNING **: Unable to open a connection to the session bus: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.

(palimpsest:7668): Unique-DBus-WARNING **: Unable to connect to the running instance, aborting.
# palimpsest

(palimpsest:7788): Unique-DBus-WARNING **: Unable to open a connection to the session bus: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.

(palimpsest:7788): Unique-DBus-WARNING **: Unable to connect to the running instance, aborting.

Ik zie mijn schijven ook niet meer, alleen filesystem/home, maar geen andere partities.

Het is voor mij erg lastig te debuggen en ik weet niet goed waar ik moet beginnen. Zoals ik al zei, vermoed ik dat het iets met die VMWare Client te maken heeft, maar misschien zit er ook wel helemaal naast.

Heeft iemand enig idee wat er aan de hand is en wat de oplossingsrichting zou kunnen zijn? Ik zit zelf op dit moment op een dood spoor.

[CAPSLOCK2000]

Poeh, dit voelt als een serieus lastig probleem en ik weet eigenlijk ook niet hoe het op te lossen is. Ik kan wel een beetje speculeren over wat er aan de hand is. Ik denk dat je een of meer belangrijke files in /usr hebt overschreven en dat daardoor "dbus" stuk is.

Als work-around zou ik allereerst met de hand een ip instellen (ip addr add 10.10.3.124/24 dev eth0; ip route add default via 10.10.3.1), dan heb je tenminste weer netwerk.

Je zou kunnen kijken wat er op (of voor) regel 548 van /etc/sysconfig/network-scripts/network-functions gebeurdt.

Je zou met het "find" commando kunnen proberen te achterhalen welke files er recent in /usr/ zijn geschreven.

PS. Ik zie wat gekke dingetjes in de output van je commando's, verkeerde spaties enzo, kan er iets mis zijn gegaan bij het overnemen of was het echt zo?

[Hero of Time]

Als er echt iets stuk is in /usr e.d., dan kan je dat met het 'rpm' commando als 't goed is oplossen. Er is een verify optie en die kan je gebruiken om na te gaan of alles nog is zoals het zou moeten. Met het volgende kan je 't als het goed is controleren:

rpm -V `rpm -qa`

Dat verifieert ALLE packages die bij RPM bekend is en op het systeem zijn geïnstalleerd.

[ Voor 5% gewijzigd door Hero of Time op 03-03-2016 08:14 ]

[Reynouts]

CAPSLOCK2000 schreef op woensdag 02 maart 2016 @ 23:03:
Poeh, dit voelt als een serieus lastig probleem en ik weet eigenlijk ook niet hoe het op te lossen is. Ik kan wel een beetje speculeren over wat er aan de hand is. Ik denk dat je een of meer belangrijke files in /usr hebt overschreven en dat daardoor "dbus" stuk is.

Als work-around zou ik allereerst met de hand een ip instellen (ip addr add 10.10.3.124/24 dev eth0; ip route add default via 10.10.3.1), dan heb je tenminste weer netwerk.

Je zou kunnen kijken wat er op (of voor) regel 548 van /etc/sysconfig/network-scripts/network-functions gebeurdt.

Je zou met het "find" commando kunnen proberen te achterhalen welke files er recent in /usr/ zijn geschreven.

PS. Ik zie wat gekke dingetjes in de output van je commando's, verkeerde spaties enzo, kan er iets mis zijn gegaan bij het overnemen of was het echt zo?

Heel erg bedankt voor je antwoord. De work-around werkt, ik zit nu weer op het netwerk. Dit is al een mooie stap Op het moment dat ik dat doe, valt de verbinding na een tijdje weer weg, misschien omdat een andere netwerk manager weer probeert te connecten of iets dergelijks?

Regel 548 is deel van chage_resolv_conf() #invoke this when /etc/resolv.conf has changed

code:

# Invoke this when /etc/resolv.conf has changed:
change_resolv_conf ()
{
    s=$(/bin/grep '^[\ \    ]*option' /etc/resolv.conf 2>/dev/null);
    if [ $# -gt 1 ]; then
       if [ "x$s" != "x" ]; then
          s="$s"$'\n';
       fi;
       n_args=$#;
       while [ $n_args -gt 0 ]; 
     do 
        if [[ "$s" = *$1* ]]; then
           shift;
           n_args=$(($n_args-1));
               continue;
            fi;
        s="$s$1";
            shift; 
        if [ $# -gt 0 ]; then
        s="$s"$'\n';
        fi;
        n_args=$(($n_args-1));
         done;       
    elif [ $# -eq 1 ]; then
       if [ "x$s" != "x" ]; then
      s="$s"$'\n'$(/bin/grep -vF "$s" $1);
       else
      s=$(cat $1);
       fi;
    fi;
    (echo "$s" > /etc/resolv.conf;) >/dev/null 2>&1;
    r=$?
    if [ $r -eq 0 ]; then
    [ -x /sbin/restorecon ] && /sbin/restorecon /etc/resolv.conf >/dev/null 2>&1 # reset the correct context
    /usr/bin/logger -p local7.notice -t "NET" -i "$0 : updated /etc/resolv.conf";
    [ -e /var/lock/subsys/nscd ] && /usr/sbin/nscd -i hosts; # invalidate cache
    fi;
    return $r;
}

Deze bestanden heb ik in elk geval geplaatst voor VMWare:

code:

/usr/bin/vmware-remotemks
/usr/bin/vmware-remotemks-container
/usr/bin/vmware-view
/usr/bin/vmware-view-log-collector
/usr/bin/vmware-view-tunnel
/usr/lib/libpcoip_client.so
/usr/lib/libpcoip_crypto.so
/usr/lib/libpcoip_crypto_non_fips.so
/usr/lib/pcoip/vchan_plugins/libmksvchanclient.so
/usr/lib/pcoip/vchan_plugins/libscredirvchanclient.so
/usr/lib/vmware/xkeymap/* (heleboel kleine files zoals be101)

Met het find commando op directory niveau zie ik erg veel output, hier zie ik dat filezilla ook recent nog is geinstalleerd. Op file niveau hou ik maar een paar bestanden over:

code:

bash-4.1$ sudo find /usr -type f -mtime -4
/usr/lib/gconv/gconv-modules.cache
/usr/lib/locale/locale-archive
/usr/lib/locale/locale-archive.tmpl
/usr/lib64/gconv/gconv-modules.cache
/usr/share/icons/hicolor/icon-theme.cache
/usr/share/info/dir

Dat de output in de openingspost niet helemaal klopt, dat heb je goed gezien. Ik heb het aan de hand van een plaatje via OCR en handmatig intikken hier neergezet

Hero of Time schreef op donderdag 03 maart 2016 @ 08:14:
Als er echt iets stuk is in /usr e.d., dan kan je dat met het 'rpm' commando als 't goed is oplossen. Er is een verify optie en die kan je gebruiken om na te gaan of alles nog is zoals het zou moeten. Met het volgende kan je 't als het goed is controleren:

rpm -V `rpm -qa`

Dat verifieert ALLE packages die bij RPM bekend is en op het systeem zijn geïnstalleerd.

Is er zoiets ook voor Yum?

[CAPSLOCK2000]

Yum is een laag bovenop RPM, dus zou dit commando ook voor jou moeten werken.

Ik moet zeggen dat ik op grond van de resulaten van find geen problemen zien.

Dat je netwerk na 5 minuten weer wegvalt klinkt alsof er nog een dhcp-client actief is. Met 'pkill -9 dhcp' schiet je alle processen af met 'dhcp' in de naam. Het kan ook zijn dat het network-manager is.

/etc/resolv.conf bevat je DNS-servers. Die veranderen niet zo vaak dus het is geen accut probleem. Wel is het erg vreemd dat /usr/bin/logger een foutmelding geeft. Dat wijst er op dat er iets goed mis is gegaan.

Ik hoop dat de RPM-truck van Hero of Time een pakket kan aanwijzen dat is beschadigd. Anders zou je nog kunnen proberen om domweg alle RPMs opnieuw te downloaden en te installeren.

[Hero of Time]

Reynouts schreef op donderdag 03 maart 2016 @ 09:02:

[...]

Is er zoiets ook voor Yum?

Ben je bekend met Debian en derivaten? Wat voor Red Hat based distro's rpm is, is voor Debian dpkg. Yum is je package manager, rpm is je package installer. Wat wel jammer is, is dat Yum en RPM zelf bijhouden wat er op het systeem is geïnstalleerd. Als je dus met rpm iets installeert, krijg je een melding van Yum dat de rpmdb is aangepast buiten Yum om. Maar een repair heeft daar geen invloed op.

[Reynouts]

Beide erg bedankt voor het meedenken.

Het RPM commando heb ik uitgevoerd. Hier krijg ik een hele lijst aan regels die eindigen met "at least one of file's dependencies has changed since prelinking". Moet ik hier voor iets specifieks zoeken? Ik neem aan dat hij alleen valideert en je nog ergens iets moet proberen te fixen aa nde hand van de output?

Inmiddels ben ik erachter dat ik mijn schijven wel gewoon kan mounten in de terminal en ze dan ook weer terug zie in places (maar niet in fstab). Palimpsest/Disk Utility en Add/Remove Software (de GUI stukjes) geven allebei lege schermen. De achterliggende functionaliteiten (yum, mounten) werken wel.

[Hero of Time]

Dat je meldingen krijgt dat er iets is aangepast betekend dus dat het niet is zoals het hoort. Je zou de bestanden moeten zien die deze melding veroorzaakt, waarna je het package kan achterhalen en deze opnieuw kan installeren. Of repairen, je zal dat even moeten Googlen. Ik ben meer een Debian persoon en beheer alleen wat CentOS machines.
Na het herstellen van de package integriteit op het systeem zouden je GUI tools ook weer moeten werken.

Partities en schijven die gemount moeten worden tijdens het opstarten definieer je zelf in fstab. Daar komt niet op magische wijze iets bij als je alleen maar het mount commando gebruikt.

[Reynouts]

Hero of Time schreef op donderdag 03 maart 2016 @ 20:30:
Dat je meldingen krijgt dat er iets is aangepast betekend dus dat het niet is zoals het hoort. Je zou de bestanden moeten zien die deze melding veroorzaakt, waarna je het package kan achterhalen en deze opnieuw kan installeren. Of repairen, je zal dat even moeten Googlen. Ik ben meer een Debian persoon en beheer alleen wat CentOS machines.
Na het herstellen van de package integriteit op het systeem zouden je GUI tools ook weer moeten werken.

Partities en schijven die gemount moeten worden tijdens het opstarten definieer je zelf in fstab. Daar komt niet op magische wijze iets bij als je alleen maar het mount commando gebruikt.

Dankje, hier ga ik goed naar kijken.

Er komt steeds meer aan het licht wat niet goed werkt. Het automounten (en eigenlijk veel meer wat met startup moet gaan lopen, zoals supervisord) loopt niet goed. Ook het geluid werkt niet meer.

Er is denk ik iets goed mis en ik weet niet of ik het echte euvel kan gaan pinpointen en fixen.. In elk geval bedankt voor jullie hulp!

[Hero of Time]

Het allemaal fixen zorgt ervoor dat je meer leert, maar je zit mogelijk tegen een herinstallatie aan te kijken als het echt niet wil lukken.

[Reynouts]

Dat is zeker waar, ik zou het erg graag fixen, maar mijn kennis is erg beperkt (zoals je wel gemerkt hebt). En ik vind steeds meer dingen die vreemd zijn.

Ik wil nog wel even verder zoeken met jouw tips wat betreft de rpm verify. Mijn rpm verify output ziet er zo uit. Een hele waslijst en ik weet niet goed waar ik moet beginnen. Ik lees wel over meer mensen met een centos distributie die veel van dit soort prelinking issues hebben (zelfs met een clean install). Ik weet nu niet goed waar ik het moet zoeken.

Ik heb nog een image van een half jaar geleden, maar in dat half jaar is er flink wat aan het systeem gebeurd, dus ik zou hem wel graag reanimeren

[Rainmaker]

Die prelink errors zijn niet zo'n probleem. Zie deze wiki pagina voor uitleg. https://wiki.gentoo.org/wiki/Prelink

Draai eens het commando met

code:

| grep -v "S.?......"

erachter