Danke!
Also wenn ich das richtig verstanden habe, wäre das in meinem Sinne keine Korrektur der Konfiguration sondern eine andere Software.
Der Link zeigt auch kein Paket für Leap 42.2, sondern max 42.1.
Ich würde eine Korrektur der Konfiguration auch vorziehen, könnte ja sein, dass es mit ein paar Handgriffen erledigt ist.
Hallo,
ich setzte seit Jahren die Yast Funktionalität zur Remoteadministration ein. Hauptsächlich unter SLES, neuerdings unter OpenSuse 13.2 und nun unter Leap 42.2.
System: Dell PowerEdge R310
KDE Installation
Normalerweise war das für mich immer mit der Aktivierung unter Yast erledigt. (Auch wenn sich manchmal am Ende die x sessions aufgehängt haben)
Nun ist es so, dass ich auf dem Gerät keine Konfiguraiton hinbekomme, die wie gewohnt einfach funktioniert.
Unter Leap kann ich wahlweise one time session oder session persistent wählen, es macht für das (Fehl)verhalten aber keinen großen (erkennbaren) Unterschied.
Aus Anwendersicht erhalte ich beim Aufruf von VNC Viewer (UltraVNC) einfach einen schwarzen Bildschirm.
Ich habe nun etwas rumgekramt und kann aus dem System folgendes lesen.
Es bleiben X11 Session locks im tmp Verzeichnis liegen, die manuel entfernt werden müssen.
Wenn nicht, liefert systemctl status xinetd.service entsprechende Fehlermeldungen.
Ich kann manuel mit vncserver :port server starten- sofern in tmp kein Müll liegt, auf die ich dann (fast) wie gewohnt zugreifen kann.
Ich muss hier allerdings immer ein separates Passwort angeben, was m.E. darauf hindeutet, dass yast die Einstellungen aus "Remote administration" nicht sauber in einer Konfiguration überträgt. (auch ein Wechsel der Optionen ändert daran nichts)
Nach einem Logout aus einer VNC Viewer Sitzung kann ich nicht erneut auf den Port zugreifen, auch wenn vncserver -list die Sitzung noch anzeigt.
Gibt es eine Möglichkeit die VNC Remote Administration außerhalb von yast zu konfigurieren?
Unter OpenSuse 13.2 hatte ich auf diesem System auch Startschwierigkeiten, hab das allerdings nicht im Detail verfolgt, sondern Leap probiert. (siehe oben)
Ein 2. Gerät, auch R310, etwas neuer funktioniert unter OpenSuse 13.2 wie gewohnt.
Ich würde mich sehr über Hinweise freuen!
Ok, danke an alle!
Dann warte ich mal, dass es in Open Suse landet.
Mmh, so drastisch würde ich das nicht ausdrücken. Die Hardware ist alt, aber das ist für mich erstmal okay so.
Das was mir wichtig ist, soll ja ins LVM mit RAID. Wenn das OS auf dem RAID fratze ist, kann ich das neu installieren, ansonsten wird es nur zum Testen sein.
Ich seh das eigentlich so, dass ein Hardware RAID vor allem schneller sein soll(te) (wär mir auch noch egal in dem Fall) und im Fehlerfall am wenigsten Aufwand (Sorgen) bereitet. Neu Platte rein, Restore im BIOS starten und fertig. Aber vielleicht sehe ich das auch falsch.
Wenn der Controler im Eimer ist und kein baugleicher Ersatz da ist oder wenn der Controler ohne System nicht restauriert, ist das natürlich alles relativ. Ich bin ehrlich gesagt nicht auf die Idee gekommen, dass es solche Controler gibt, die das nicht allein können.
Und was das Script bzw. das Thema angeht, ich kann mir nicht vorstellen, dass es einen Unterschied macht, wann und wie ich das per Script aufrufe. Wenn ein manueller Restart nichts bringt, was soll da nach dem booten anders sein?
Wegen des Hardware RAID muss ich das wahrscheinlich eh neu aufsetzen, dann werde ich sehen, ob ich den Daemon mit reinnehme. Der Fehler scheint ja irgendwie auch nicht besonders populär zu sein, da würde ich nicht auf einen schnellen Fix hoffen. Ich dachte, man könnte nachvollziehen, dass ich etwas falsch aufgesetzt/konfiguiert habe oder so.
Danke für die vielen Tipps!
Also eigenwillig kann sein, ich hab noch nie mit LVM gearbeitet. Aber ich dachte auch, dass Bootsysteme mit LVM gar nicht gehen.
Ich befürchte auch, dass der Intelcontroler unter Linux gar nix kann, also eben kein echter. Hab heute mal eine Platte abgemacht und die wieder zugefügt. Dann kommt im RAID BIOS ne Meldung, dass das RAID ~"unter dem OS wieder hergestellt wird" so ungefähr.
Aber da gibt's nix von Intel für Linux.
P.S.: Ach, der Neustart macht ja keinen Unterschied, die Meldung bleibt immer gleich.
Mir ist aber auch nicht klar, was der Daemon macht, hatte kurz was mit journal oder so auf den verschiedenen devices gelesen. Aber da es offenbar ohne geht, kann er wohl wirklich weg.
Hallo nochmal und danke für die Hinweise, das Ziel ist erreicht. Das LV ist vergrößert.
Es war allerdings nicht resize sondern xfs_growfs (anderes Dateisystem)
df zeigt nun wie lvdisplay die 2.2 TiB an.
Also bleibt nur das Problem auf dem Weg zum Ziel, dass (manche) lv befehle diese Warnung werfen, statt output zu liefern.
Noch zum aktiven Controler, das ist laut lspci:
Intel Corporation 82801GR/GDH (ICH7R/ICH7DH) SATA Controller [RAID mode] (rev 01), läuft als Spiegel.
Falls das dafür relevant ist. Dieser Controler bedient zwar auch die Platten mit dem LV, aber arbeitet da aber im Normalbetrieb ohne RAID.
sb:~ # systemctl status lvm2-lvmetad.service
lvm2-lvmetad.service - LVM2 metadata daemon
Loaded: loaded (/usr/lib/systemd/system/lvm2-lvmetad.service; enabled)
Active: active (running) since Mon 2015-06-15 15:02:16 CEST; 3h 38min ago
Docs: man:lvmetad(8)
Process: 488 ExecStart=/sbin/lvmetad (code=exited, status=0/SUCCESS)
Main PID: 493 (lvmetad)
CGroup: /system.slice/lvm2-lvmetad.service
ââ493 /sbin/lvmetad
sb:~ #
sb:~ # systemctl status lvm2-lvmetad.socket
lvm2-lvmetad.socket - LVM2 metadata daemon socket
Loaded: loaded (/usr/lib/systemd/system/lvm2-lvmetad.socket; enabled)
Active: active (running) since Mon 2015-06-15 15:02:15 CEST; 3h 39min ago
Docs: man:lvmetad(8)
Listen: /run/lvm/lvmetad.socket (Stream)Die angegebene Laufzeit stammt wohl von meinem letzten Neustart des Service.
Ah, paste Fehler, sorry:
sb:~ # lvdisplay
WARNING: lvmetad is running but disabled. Restart lvmetad before enabling it!
--- Logical volume ---
LV Path /dev/vg1/lv1
LV Name lv1
VG Name vg1
LV UUID tsONC3-8Oz6-8gxK-5OQn-q2Jx-PfGO-sTbJxq
LV Write Access read/write
LV Creation host, time (none), 2015-06-10 17:03:18 +0200
LV Status available
# open 1
LV Size 2.20 TiB
Current LE 575488
Segments 1
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 254:0
Wahrscheinlich bedeutet nur, dass mir nicht klar, ist was echte oder unechte RAID Controler sind oder sein sollen.
Du meinst mit "BIOS RAID" einen echten RAID Controller?
Wahrscheinlich nicht, ein Onboard Intelcontroler.
Und paste bitte ein "lvdisplay", sowie ein "mount"
sb:~ # mount
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
devtmpfs on /dev type devtmpfs (rw,nosuid,size=1986316k,nr_inodes=496579,mode=755)
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755)
tmpfs on /sys/fs/cgroup type tmpfs (rw,nosuid,nodev,noexec,mode=755)
cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/usr/lib/systemd/systemd-cgroups-agent,name=systemd)
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct)
cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory)
cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices)
cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer)
cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls,net_prio)
cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio)
cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event)
cgroup on /sys/fs/cgroup/hugetlb type cgroup (rw,nosuid,nodev,noexec,relatime,hugetlb)
/dev/sdc1 on / type ext4 (rw,relatime,data=ordered)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=28,pgrp=1,timeout=300,minproto=5,maxproto=5,direct)
debugfs on /sys/kernel/debug type debugfs (rw,relatime)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime)
mqueue on /dev/mqueue type mqueue (rw,relatime)
/dev/sdc3 on /boot type ext3 (rw,relatime,data=ordered)
/dev/sdc5 on /boot/efi type ext3 (rw,relatime,data=ordered)
/dev/sdc6 on /tmp type ext4 (rw,relatime,data=ordered)
/dev/sdc8 on /home type ext4 (rw,relatime,data=ordered)
/dev/mapper/vg1-lv1 on /data type xfs (rw,relatime,attr2,inode64,noquota)
/dev/sdc7 on /var type ext4 (rw,relatime,data=ordered)
tmpfs on /var/run type tmpfs (rw,nosuid,nodev,mode=755)
sb:~ #Das sieht schon mal interessant aus, danke! lvscan bringt nur die Warnung, lvdisplay bringt auch output. Das habe ich bis jetzt nicht benutzt.
Da die Größe mit 2.2 Tib angezeigt wird, bedeutet das, das 2 Vergrößerungen eigentlich schon funktioniert haben. Initial waren es 1TiB. Fehlt vielleicht nur resizefs. Ich habe mich geärgert, dass diese "Warning" scheinbar die Ausführung des Befehls verhindert. Bei rvscan z.B. scheint das so zu sein, aber das extent hat wahrscheinlich garkeinen output. Hab ich zum ersten mal benutzt.
Dann müsste ich jetzt nur noch resizefs ausführen und "alles ist toll"? Also bis auf das "Warning"?
Hallo Gemeinde,
beim Ändern der der Größe eines LVM Volumes erhalte ich immer diese Meldung:
"WARNING: lvmetad is running but disabled. Restart lvmetad before enabling it!"
Das geschieht bei verschiedenen Befehlen wie lvextend, lvscan usw.
Ich habe hier etwas gefunden, dass aber wohl veraltet ist bzw. nicht passend scheint. Den genannten Eintrag kann ich nicht finden in der Datei:
http://lists.opensuse.org/arch…ugs/2014-11/msg03759.html
Ein Neustart mit
service lvm2-lvmetad restart
hat keine Auswirkung.
Im System sind 4 Platten, 2 mit BIOS Raid für das OS. 2 für LVM Raid.
Vielleicht kann mir dazu jemand Hinweise geben.
Gruß, Tar Zahn