Posts by remote

Quote from porrier

Das mit dem "feature" kann aber nur ironisch gemeint sein. Lustig ist das nämlich nicht, jedesmal vor einem reboot die Angst zu haben, den bootloader reparieren zu müssen.

Stimmt... deswegen läuft auf dem neuen vServer nun auch Red Hat, nicht SUSE.
Schade drum, aber ist mir das Frickeln nicht wert

It's not a bug, it's a feature.

1. vServer mit openSUSE Leap 42.1 minimal image provisionieren
2. zypper update -y && shutdown -r now
3. bootet nicht mehr (GRUB _)

… reproduzierbar.
Hätte jetzt gedacht, dass man bei obigem setup noch nicht viel falsch machen kann, aber so täuscht man sich

Ich betreibe ähnliches auf einem Root L v5 (Jira und Gitlab hinter Apache) und würde sagen, dass die Performance ok ist. Bottleneck ist die CPU obwohl es beim L ja dedizierte cores sind und keine vCores. Bei Jira kommt es sicher auch darauf an, wie komplex die Permissions sind und um wie viele Tickets es geht (das zieht die Leistung eher in den Keller als 1–2 zusätzliche Sessions).
Auf welcher Hardware läuft der Kram denn momentan?

Der Support hat die Quota des neuen Servers nachjustiert, anschließend war ein Import problemlos möglich.
Besten Dank.

Quote from Skulduggery

Also ich weiß nicht wie du das siehst, aber mir sagt diese Fehlermeldung folgendes: …

Danke für die Übersetzung der Fehlermeldung.
Vielleicht war ich etwas undeutlich – mein Problem ist nicht das Verständnis der englischen Sprache, sondern die Frage, weshalb diese Fehlermeldung geworfen wird.
Das sich der Support mit der eigenen Software auskennt ist naheliegend. Dass man in einem Forum mit dem Namen "VCP (vServer Control Panel)" Fragen zu Problemen mit selbigem System stellt aber eigentlich auch.
Falls also jemand Vorschläge zur Eingrenzung des Problems hat, freue ich mich über Hilfe.

Hier noch als Nachtrag die Übersicht der Volumes auf der Snapshot Quelle:

Filesystem      Size  Used Avail Use% Mounted on
/dev/vda2       154G   21G  125G  15% /
tmpfs           3,9G     0  3,9G   0% /dev/shm
/dev/vda1       190M  107M   73M  60% /boot

Ich versuche gerade einen Snapshot von einem alten vServer auf einen neuen vServer einzuspielen (beide mit 160 GB quota gem. Vertrag).
Der Import schlägt allerdings fehl:

Quote

Source file too large. Cannot copy to disk.

In der Annahme, dass ggf. vor Import des Snapshots die Partition vergrößert werden muss, habe ich dies wie im wiki beschrieben ausgeführt:

rescue:~# fdisk /dev/vda




Command (m for help): u
Changing display/entry units to cylinders (DEPRECATED!)




Command (m for help): c
DOS Compatibility flag is set (DEPRECATED!)




Command (m for help): d
Partition number (1-4): 2




Command (m for help): n
Partition type:
   p   primary (1 primary, 0 extended, 3 free)
   e   extended
Select (default p): p
Partition number (1-4, default 2): 2
First cylinder (1-324559, default 1):
Using default value 1
Last cylinder, +cylinders or +size{K,M,G} (1-2, default 2):
Using default value 2




Command (m for help): w
The partition table has been altered!




Calling ioctl() to re-read partition table.
Syncing disks.

Hier wird eine Cylinder Range von 1 bis 2 vorgeschlagen … das erscheint mir etwas knapp.
Werte >2 werden als "out of range" abgelehnt.

Kann mir jemand erklären was hier falsch läuft?

Vielen Dank für die Antwort.

Quote from [netcup] Felix

Allerdings fehlen auch zwei CPU-Cores

In dem Punkt kann ich nicht ganz folgen, da ich davon ausging, dass 2 "echte" Cores ebenfalls 4 parallele Threads bieten würden, nur etwas näher an der Hardware?

Bezüglich des Aufwands:
Gehe ich recht in der Annahme, dass es möglich sein sollte ein Image zu exportieren und im neuen Server zu importieren (für den Umzug von Saturn KVM auf Root-L 5 oder Root XL 5)?

SaturnKVM Datenblatt: netcup.de - Produktdetails
Root Server L 5 Datenblatt: netcup.de - Produktdetails

Im Saturn ist wohl eine E5645 / 2.40GHz verbaut (behauptet jedenfalls der Host), während es bei den neuen Server ein E5-2620 / 2.0 Ghz ist.
Von der Leistung erstmal recht ähnlich (E5-2620 hat trotz niedrigerem Takt leicht die Nase vorn: PassMark - CPU Performance Comparison )

Ich kann hier keinen richtigen Nachteil entdecken, ausser, dass ein Upgrade vermutlich nicht möglich und der Umweg über Kündigung und Neuvertrag samt IP-Wechsel anfallen würde.
Übersehe ich da etwas?

Quote from Mordor

Gibt es die /etc/rc.d/rc.sysinit.vserver bei Dir?

Ja, die gibt es:

#! /bin/sh




rm -f /var/lock/subsys/* /var/run/* /var/run/*/* 2>/dev/null
true

edit:

Ich habe nun probeweise mal die frühen "console output" Statements die ich im init Ablauf finden konnte auskommentiert
(primär /etc/init/rc.conf):

# rc - System V runlevel compatibility
#
# This task runs the old sysv-rc runlevel scripts.  It
# is usually started by the telinit compatibility wrapper.




start on runlevel [0123456]




stop on runlevel [!$RUNLEVEL]




task




export RUNLEVEL
# console output
exec /etc/rc.d/rc $RUNLEVEL

Nun wird nicht mehr versucht auf eine nicht initialisierte(?) console zuzugreifen und der init Vorgang läuft wieder vollständig ab.
Soviel zum "was" - das "warum" gibt mir noch Rätsel auf

edit 2:

Nach wie vor besteht allerdings das Problem, dass mingetty nicht auf die Beine kommt - das messages log wächst schnell:

Mar 11 23:55:18 vserver /sbin/mingetty[28818]: tty[1-6]: No such file or directory
Mar 11 23:55:23 vserver init: tty (/dev/tty[1-6]) main process (28818) terminated with status 1
Mar 11 23:55:23 vserver init: tty (/dev/tty[1-6]) main process ended, respawning
Mar 11 23:55:23 vserver /sbin/mingetty[28927]: tty[1-6]: No such file or directory
Mar 11 23:55:28 vserver init: tty (/dev/tty[1-6]) main process (28927) terminated with status 1
Mar 11 23:55:28 vserver init: tty (/dev/tty[1-6]) main process ended, respawning

Nachdem ich bereits eine andere Centos 6.3 Installation problemlos auf
6.4 aktualisiert habe, war ich leichtsinnig genug den zweiten vServer
dann ohne vollständiges Backup zu updaten. Murphy hat aufgepasst und nun
kommt der vServer beim init nicht auf die Beine:

# process listing
USER   	PID %CPU %MEM	VSZ   RSS TTY  	STAT START   TIME COMMAND
root     	1  0.0  0.1  19276  1476 ?    	Ss	2012   0:00 /sbin/init
root 	18550  0.0  0.1 110224  1160 ?    	R 	2012   0:00 ps aux







# tail /var/log/messages
Mar 11 17:46:36 vserver init: Failed to spawn splash-manager main process: unable to open console: No such file or directory
Mar 11 17:46:36 vserver init: Failed to spawn rc main process: unable to open console: No such file or directory
Mar 11 17:47:34 vserver init: Failed to spawn splash-manager main process: unable to open console: No such file or directory
Mar 11 17:47:34 vserver init: Failed to spawn rc main process: unable to open console: No such file or directory

Der
inline code funktioniert (zumindest in meinem browser) leider nicht so
recht, daher Prozessliste und messages log auch via pastebin:
http://pastebin.com/0HuHLJ7Q

Im
inittab ist runlevel 3 als default gesetzt, insofern wundert mich das
auftauchen des splash-manager ein wenig. Ich nahm eigentlich der wird
für das GUI benötigt.

Wenn mir jemand eine Tipp geben kann wie
man den init process nun sinnvollerweise debugged oder einen
entsprechenden Link zu hilfreichen mans parat hätte, wäre mir sehr
geholfen.

Vielen Dank