system hängt beim reboot

[Matthias Taube]

Hi,

ich versuche einen VServer bei Strato von Hand auf Debian 8 umzustellen
(da Strato noch kein Debian 8-Image für die Installation bereitstellt).

Die Umstellung auf systemd gelingt zwar, nur ist danach leider kein
Neustart des Systems mehr möglich. Der Befehl reboot beendet die
ssh-Session und danach ist kein Zugriff auf das System mehr möglich.

Ein Neustart über die Admin-Oberfläche von Strato funktioniert, also
vermute ich das dass System irgendwo beim herunterfahren hängt. Leider
gelingt es mir mangels Konsolen-Zugang nicht, irgendwelche
Fehlermeldungen zu sehen.

Die letzte Meldung beim Herunterfahren im Syslog ist:
> Sep 26 18:32:49 systemd[426]: Starting Shutdown.
> Sep 26 18:32:49 systemd[426]: Reached target Shutdown.
> Sep 26 18:32:49 systemd[426]: Starting Exit the Session...
> Sep 26 18:32:49 rsyslogd: [origin software="rsyslogd" swVersion="8.4.2" x-pid="336" x-info="http://www.rsyslog.com"] exiting on signal 15.

ein reboot -f zeigt auf der Konsole:
> # reboot -f
> Rebooting.
> Failed to reboot: Datei oder Verzeichnis nicht gefunden
> # Connection to xxx closed by remote host.

Wie bekomme ich da aussagefähigere Logs hin?
in /etc/systemd/system.conf habe ich schon
> LogLevel=debug
> LogTarget=syslog-or-kmsg


ein dmesg zeigt übrigens nur
> ioctl32((agetty):328440): Unknown cmd fd(3) cmd(00005437){t:'T';sz:0} arg(bfa40838) on /dev/console
> ioctl32(agetty:328440): Unknown cmd fd(0) cmd(00005457){t:'T';sz:0} arg(bf938bb4) on /dev/console
> ioctl32((agetty):328439): Unknown cmd fd(3) cmd(00005437){t:'T';sz:0} arg(bfa40838) on /dev/tty1

ansonsten sehe ich im syslog nur folgende Fehlermeldung:
> Sep 26 19:02:50 systemd[425]: Failed to make us a subreaper: Invalid argument
> Sep 26 19:02:50 systemd[425]: Perhaps the kernel version is too old (< 3.4?)

Einen aktuellen Kernel kann ich nicht installieren, da der Kernel durch
Strato vorgegeben ist.

Irgendwelche Hinweise?
LG
Matthias

[Dirk Finkeldey]

Am 26.09.2015 um 19:21 schrieb Matthias Taube:
> Hi,
>
> ich versuche einen VServer bei Strato von Hand auf Debian 8
> umzustellen (da Strato noch kein Debian 8-Image für die Installation
> bereitstellt).
>
>

~ Gewagte Sache auf einer unbekannten Umgebung ein OS installieren zu
wollen.

>
> Einen aktuellen Kernel kann ich nicht installieren, da der Kernel
> durch Strato vorgegeben ist.
>
> Irgendwelche Hinweise?
> LG
> Matthias
>

Dir sollte klar sein das der Kernel der dom0 mit der Version der domU
übereinstimmen muss damit der vServer richtig Funktioniert.

Probiere mal Strato zu bitten den Kernel vom Host zu aktualisieren, kann
mir zwar nicht vorstellen das Strato das tun wird - aber fragen bringt
weiter.


Gruß Dirk Finkeldey

[Matthias Taube]

Am 26.09.2015 um 19:47 schrieb Dirk Finkeldey:

> ~ Gewagte Sache auf einer unbekannten Umgebung ein OS installieren zu
> wollen.

Tja, die Aussage von Strato hierzu war:

> Bedauerlicherweise kann ich Ihnen hier noch keine Auskunft geben, aktuell erfolgt die Anpassung von einem Image für Debian 8. Wann diese Freigegeben wird, ist hierbei noch nicht bekannt.
> Alternativ können Sie auch über SSH eine Updates durchführen, hierfür können wir dann jedoch keinen Support übernehmen, da uns kein Zugriff auf das System möglich ist.

> Dir sollte klar sein das der Kernel der dom0 mit der Version der domU
> übereinstimmen muss damit der vServer richtig Funktioniert.

Strato bietet ja verschieden Images (centos, debian, ubuntu, opensuse)
für die Installation mit unterschiedlichen Kerneln an.Nur leider ist
Debian 8 noch nicht dabei.

mfg
Matthias

[Dirk Finkeldey]

Am 26.09.2015 um 19:58 schrieb Matthias Taube:
> Am 26.09.2015 um 19:47 schrieb Dirk Finkeldey:
>
>> ~ Gewagte Sache auf einer unbekannten Umgebung ein OS installieren zu
>> wollen.
>
> Tja, die Aussage von Strato hierzu war:
>
>> Bedauerlicherweise kann ich Ihnen hier noch keine Auskunft geben,
>> aktuell erfolgt die Anpassung von einem Image für Debian 8. Wann
>> diese Freigegeben wird, ist hierbei noch nicht bekannt.
>> Alternativ können Sie auch über SSH eine Updates durchführen, hierfür
>> können wir dann jedoch keinen Support übernehmen, da uns kein Zugriff
>> auf das System möglich ist.
>

> Strato bietet ja verschieden Images (centos, debian, ubuntu, opensuse)
> für die Installation mit unterschiedlichen Kerneln an.Nur leider ist
> Debian 8 noch nicht dabei.
>
> mfg
> Matthias

Stellt sich die Frage auf welcher Version der Kernel vom Host basiert,
diese Version muss ja bei allen angebotenen Images gleich sein, ist es
ein Kernel vor 3.16 dürfte das nicht so ganz einfach werden mit Debian 8.


Gruß Dirk Finkeldey

[Matthias Taube]

Am 26.09.2015 um 20:16 schrieb Dirk Finkeldey:

> Stellt sich die Frage auf welcher Version der Kernel vom Host basiert,
> diese Version muss ja bei allen angebotenen Images gleich sein, ist es
> ein Kernel vor 3.16 dürfte das nicht so ganz einfach werden mit Debian 8.

ein
> uname -r -v
> 3.2.41-042stab103.6 #1 SMP Wed Jan 21 13:07:39 MSK 2015

zeigt das der Client-Kernel jedenfalls 3.2 ist. Warum wird das dann
schwierig mit Debian 8?

Ein aptitude full-upgrade läuft jedenfalls durch und der Kernel bootet
danach. Schwierig wird es nur beim Versuch, upstart durch systemd zu
ersetzen, dann funktioniert reboot nicht mehr.

mfg
Matthias

[Hoshpak]

Am 26.09.2015 um 20:56 schrieb Matthias Taube:
> Am 26.09.2015 um 20:16 schrieb Dirk Finkeldey:
>
>> Stellt sich die Frage auf welcher Version der Kernel vom Host basiert,
>> diese Version muss ja bei allen angebotenen Images gleich sein, ist es
>> ein Kernel vor 3.16 dürfte das nicht so ganz einfach werden mit Debian 8.
>
> ein
>> uname -r -v
>> 3.2.41-042stab103.6 #1 SMP Wed Jan 21 13:07:39 MSK 2015
>
> zeigt das der Client-Kernel jedenfalls 3.2 ist. Warum wird das dann
> schwierig mit Debian 8?

Die Bezeichnung "*stab*" kenne ich eigentlich nur von Parallels. Das
heißt, dein Server wird höchstwahrscheinlich als Container in einer
paravirtualisierten Virtuozzo-Umgebung laufen. Die Kernel-Version "3.2"
wird dabei nur durch die Virtualisierung "vorgegaukelt". Effektiv läuft
auf dem Hostsystem ein 2.6.32er-Kernel, der auf dem für Red Hat
Enterprise Linux 6 basiert. Der enthält natürlich einige Backports und
VZ-spezifische Patches, damit auch aktuellere Distributionsversionen
funktionieren, ist aber nicht mit einem "3.2" vanilla oder Debian-Kernel
gleichzusetzen.

Auf jeden Fall sollte Strato das Hostsystem deines Servers mal wieder
updaten, aktuell ist meines Wissens eine Kernel-Version mit "stab111.x"
und zwischen den beiden Versionen lagen auch mehrere Sicherheitsupdates.

Offiziell unterstützt wird Debian 8 von Parallels seit 6.0 Update 9
Hotfix 7:

http://kb.odin.com/en/125578

Eine Kernelversion ist bei dem Update nicht angegebenen. Da der Kernel
am 26. Januar veröffentlicht wurde und das Update deutlich später kam,
würde ich davon ausgehen, dass das auf dem Hostsystem deines Servers
noch nicht installiert ist.

> Ein aptitude full-upgrade läuft jedenfalls durch und der Kernel bootet
> danach. Schwierig wird es nur beim Versuch, upstart durch systemd zu
> ersetzen, dann funktioniert reboot nicht mehr.

Das hätte dir imho gleich zu denken geben sollen. Debian mit upstart ist
eher exotisch und bei Debian 7 war noch sysvinit der Default. Aus einem
mir unbekannten Grund hat Parallels das Debian 7-Template für Virtuozzo
trotzdem mit upstart gebaut.

Generell würde ich aus eigener Erfahrung von einem Upgrade eines
bestehenden Containers auf die nächste Version eher abraten.
Erfahrungsgemäß führt das in fast jedem Fall zu Problemen, da die für
die Virtuozzo-Umgebung im Template vorgenommenen Änderungen nicht mit
dem Default-Setup der Distributoren kompatibel sind. Besser ist es im
Regefall, auf die Verfügbarkeit der aktuellen Version (in dem Fall
seitens des Hosters, Parallels selbst bietet schon Templates an) zu
warten und dann auf einen neuen Container zu migrieren.

Gruß
Helmut

[Matthias Taube]

Am 26.09.2015 um 21:22 schrieb Hoshpak:

> Generell würde ich aus eigener Erfahrung von einem Upgrade eines
> bestehenden Containers auf die nächste Version eher abraten.
> Erfahrungsgemäß führt das in fast jedem Fall zu Problemen, da die für
> die Virtuozzo-Umgebung im Template vorgenommenen Änderungen nicht mit
> dem Default-Setup der Distributoren kompatibel sind. Besser ist es im
> Regefall, auf die Verfügbarkeit der aktuellen Version (in dem Fall
> seitens des Hosters, Parallels selbst bietet schon Templates an) zu
> warten und dann auf einen neuen Container zu migrieren.

Vielen Dank für die sehr informative Erläuterungen. Ich wusste nicht,
dass eine Virtuozzo-Umgebung so von einer Standardinstallation abweicht.
Da werde ich an die Anpassung wohl etwas konservativer herangehen.

Zum Glück mache ich meine Versuche nicht auf dem Produktiv-System,
sondern auf einem extra für solche Tests angemieteten VServer - die
kosten ja pro Monat weniger als eine Maß auf der Wiesn.

LG
Matthias

[Sven Hartge]

Matthias Taube <no_html...@nurfuerspam.de> wrote:
> Am 26.09.2015 um 21:22 schrieb Hoshpak:

>> Generell würde ich aus eigener Erfahrung von einem Upgrade eines
>> bestehenden Containers auf die nächste Version eher abraten.
>> Erfahrungsgemäß führt das in fast jedem Fall zu Problemen, da die für
>> die Virtuozzo-Umgebung im Template vorgenommenen Änderungen nicht mit
>> dem Default-Setup der Distributoren kompatibel sind. Besser ist es im
>> Regefall, auf die Verfügbarkeit der aktuellen Version (in dem Fall
>> seitens des Hosters, Parallels selbst bietet schon Templates an) zu
>> warten und dann auf einen neuen Container zu migrieren.

> Vielen Dank für die sehr informative Erläuterungen. Ich wusste nicht,
> dass eine Virtuozzo-Umgebung so von einer Standardinstallation abweicht.

Alle Container-basierten VHosts (also solche, bei denen nur eine Instanz
des Host Kernels für alle VHosts benutzt wird) haben solche
Limitierungen.

Xen-, KVM-, und VMware-basierte VHosts dagegen haben eine jeweils eigene
Instanz eines Kernels und dort ist es auch oftmals möglich (bzw. nur so
möglich) einen eigenen Kernel zu nutzen, so dass hier auch Upgrades
einfacher möglich sind.

Als Nachteil für den Hoster ergibt sich bei letzteren, dass der Overhead
größer ist, man also nicht die gleiche Dichte an VHosts pro Server wie
bei Container-Lösungen (also OpenVZ, LXC, Virtuozzo, Docker) erreichen
kann.

S°

--
Sigmentation fault. Core dumped.

[Paul Muster]

On 27.09.2015 18:51, Sven Hartge wrote:

> Xen-, KVM-, und VMware-basierte VHosts dagegen haben eine jeweils eigene
> Instanz eines Kernels und dort ist es auch oftmals möglich (bzw. nur so
> möglich) einen eigenen Kernel zu nutzen, so dass hier auch Upgrades
> einfacher möglich sind.

Im Prinzip ja, aber selbst das ach so super-stabile und umfassend
getestete Debian bringt es fertig, hier die User auf die Nase zu schmeißen.

Man nehme einen Wheezy-Host mit Xen ("Dom0" genannt), der die VMs (bei
Xen "DomU" genannt) per pygrub bootet. Bei Wheezy-DomUs mit grub-pc
1.99-27+deb7u2 funktioniert das prima. Zieht man die aber auf Jessie
hoch, kann das Wheezy-pygrub der Dom0 die neumodische grub.cfg der DomU
nicht mehr lesen und die DomU kann nicht gebootet werden.

Abhilfe hier:
apt-get purge grub2-common grub-pc grub-pc-bin
apt-get install pv-grub-menu
(in der DomU, im chroot)

Damit hat man wieder eine normale menu.lst, die das pygrub der Dom0
lesen und booten kann.


mfG Paul