[Laubie]

Ja, das ist die richtige Partition...

Aber warum verstellt sich sowas?
Da war ich ja nie dran

Grüße
Laubie

[Felix]

Laubie wrote:
> Aber komisch ist das schon, oder?

Das deutet fuer mich eigentlich alles auf die beschriebene Moeglichkeit hin,
das der "root=" Parameter falsch eingestellt war. Wenn du es nochmal versuchen
willst, wie folgt vorgehen:

- im Manager einloggen, Server auswaehlen
- Dienstleistungen
- netboot
- netboot expert
- gewuenschten kernel auswaehlen, und
- "Root Device:" auf /dev/sda1 setzen (falls das deine /-Partition ist)

Felix

[Laubie]

Hi Felix,

Server#: 77078

Der erste Eingriff endete dann mit dem rescueModus und diesem Hinweis:

The server gets stuck during the boot phase, with the
message:
(Kernel panic?- not syncing?: VFS?:Unable to mount root fs
on unknow-block)
A restart on the standard OVH kernel ('netboot') does not
correct the
situation.

Habe es dann noch mal probiert, dann kam dieser Hinweis:

Software diagnosis
Date 2013-05-17 22:53:34, ludovic.calin made Software
diagnosis:
 server don't boot on bzimage (kernel panic error)
server put on hard disk
boot on login screen, ping ok, services ok

Problem war dann, da ich den Kernel auf dem Server nie geändert hatte, dass dieser natürlich sehr alt war... aber das läuft nun auch wieder.

Aber komisch ist das schon, oder?

Grüße
Laubie

[Felix]

Laubie wrote:
> Hier zu Hause habe ich ja kein Netboot - Was ist da schief gegangen?

Das kann viele gruende haben - ohne servername oder -nummer kann ich nur
spekulieren:

Haeufig ist der "root=" Parameter falsch eingestellt, es kann z.B. sein dass
deine / - Partition auf /dev/sda2 oder /dev/md2 liegt, und im Manager noch
etwas anderes eingestellt ist.

[Laubie]

ok.... google ist mein Freund

Habe ein paar schöne Seiten dazu gefunden. Trotzdem Danke!

[Laubie]

vKVM nutzen und schauen wo der Kernel stehen bleibt. Das sollte doch bekannt sein.

Habe nur 1,5 eigene Server, welche eigentlich auch immer weitgehend funktioniert haben.

Dadurch habe ich mit vKVM keinerlei Erfahrung. Gibt es da eine gute Hilfe-Seite zu?

Grüße
Laubie

[strex]

vKVM nutzen und schauen wo der Kernel stehen bleibt. Das sollte doch bekannt sein.

[Laubie]

soo... mal wieder ein paar Stunden vor dem PC verbracht

Nachdem ich das hier gelesen habe, dachte ich, geh ich besser sicher, dass der letzte Kernel geladen ist und gab meinen Isgenug um 20.14 mit einem reboot den Todesstoß

Nach 10 Minuten bekam ich dann rescue-Zugang um festzustellen, dass kein Log vom Bootvorgang zu finden war.

Hier zu Hause habe ich ja kein Netboot - Was ist da schief gegangen?

Nach einigem hin und her und mehreren Reboots hat der Service den Server nun von Platte booten lassen... Jetzt läuft ein alter Kernel, der bei Installation des Servers installiert wurde.

Wie komm ich denn jetzt an den neusten Kernel? Gerne über netboot?

Grüße
Laubie

[Felix]

Caddy wrote:
> im 3.8.13 von gestern. Aus der Kernel config:
> # CONFIG_NETFILTER_XT_TARGET_LOG is not set
>
> Seit heute morgen ca. 5 Uhr liegt dort im Verzeichnis 3.8.13-2 eine
> Version, bei der u.A. genau das geändert ist:
> CONFIG_NETFILTER_XT_TARGET_LOG=y
>
> Ist Ding soweit stable ? Ich würde dann nämlich gerne mein rückgängig
> gemachtes Update von gestern wieder rückgängig machen

Ja, ist jetzt zwischenzeitlich auch für die Netboots und Reinstallationen
aktiv.

[Caddy]

log level info requires log target in your kernel and iptables

im 3.8.13 von gestern. Aus der Kernel config:
# CONFIG_NETFILTER_XT_TARGET_LOG is not set

Seit heute morgen ca. 5 Uhr liegt dort im Verzeichnis 3.8.13-2 eine Version, bei der u.A. genau das geändert ist:
CONFIG_NETFILTER_XT_TARGET_LOG=y

Ist Ding soweit stable ? Ich würde dann nämlich gerne mein rückgängig gemachtes Update von gestern wieder rückgängig machen

Gruß, Klaus

[strex]

Oder eben ksplice nutzen Fix schon enthalten und das ohne reboot.

[Peter]

Guten Tag,

vor Kurzem wurde ein Exploit veröffentlicht, der es einem Benutzer ermöglicht, Root-Rechte zu
erlangen.

Obwohl wir den Exploit mit einem GRSEC Kernel nicht voll ausnutzen konnten kann dieser unter
bestimmten Umständen zu einem Absturz des Servers führen.

Deshalb haben wir heute den Kernel 3.8.13 veröffentlicht. Alle Distributionen die den OVH
Kernel verwenden werden ab sofort mit dieser neuen Kernel-Version ausgeliefert.

Wenn Sie Ihren Server mit unserem Netboot System nutzen, dann müssen Sie lediglich einen
Reboot des Servers durchführen. Ansonsten müssen Sie den neuen Kernel von Hand installieren.
Sie finden den neuen Kernel hier:

[GRS] ftp://ftp.ovh.net/made-in-ovh/bzImag...xx-grs-ipv6-64
[STD] ftp://ftp.ovh.net/made-in-ovh/bzImag...xx-std-ipv6-64

Für die VM:

[GRS] ftp://ftp.ovh.net/made-in-ovh/bzImag...ps-grs-ipv6-64
[STD] ftp://ftp.ovh.net/made-in-ovh/bzImag...ps-std-ipv6-64

Der neuen Kernel schliesst die Sicherheitslücke und bringt darüber hinaus auch eine bessere
Performance, insbesondere bei den Netzwerk-Funktionen.

Redhat RHEL 6.0 (5.0 ist nicht betroffen) sowie die Mehrzahl der Distributions-Kernel sind von
dieser Sicherheitslücke betroffen und angreifbar.

*** Hotfix ***

Anscheinend funktioniert der Exploit nach einer Änderung des Kernel-Parameters
kernel.perf_event_paranoid nicht mehr:

# sysctl kernel.perf_event_paranoid=2

Dadurch wird die zugrundeliegende Sicherheitslücke jedoch nicht geschlossen.

M. Peter
OVH Support