Forum Linux.debian/ubuntu Wheezy sur serveur Kimsufi

Posté par . Licence CC by-sa
1
1
juin
2013

Bonjour,

J'essaie d'installer une Debian Wheezy en deboostrap depuis le mode rescue sur un serveur Kimsufi mKS 2G, et je bute sur la dernière étape lors de l'installation de grub. Quand je tape la commande

    grub-install --no-floppy --recheck /dev/sda

La commande reste figée, et je ne reprends jamais la main a moins de faire un CTRL-C. Qu'est ce qui peut poser problème ? Comment est ce que je peux débugguer le grub-install ?

  • # Kimsufi --> pas prêt

    Posté par (page perso) . Évalué à 4.

    Bonjour,

    il y a quelques semaines, j'avais aussi un Kimsufi, mais impossible de booter sur les iso en mode vKVM, etc.

    J'ai pris un serveur chez Online, il y a un vrai KVM, ça change tout.

    Plus besoin de faire ces reboot incessants en mode rescue ou vKVM comme chez OVH, pour essayer de comprendre ce qui bloque. Le principale problème chez OVH, c'est qu'en mode rescue ou vKVM, c'est virtuel, donc le matériel est mal reconnu, et en tout cas bien différent de ce qui correspond à ton serveur.

    Avec un vrai KVM, comme chez Online, le clavier est proprement reconnu, et tu es réellement sur ton serveur, donc tout baigne.

    A+

    • [^] # Re: Kimsufi --> pas prêt

      Posté par . Évalué à 0.

      Merci mais je préfère éviter Online suite à une mauvaise expérience avec eux. De plus je ne pense pas être sur du virtualisé, du moins rien ne le laisse paraitre sur le descriptif

      • [^] # Re: Kimsufi --> pas prêt

        Posté par (page perso) . Évalué à 3.

        J'aimerai bien connaître ta mauvaise expérience chez Online.

        En mode rescue et en mode vKVM, c'est du virtualisé, chez OVH. C'est écrit dans la doc.
        Si tu choisi de booter ton serveur avec un noyau par le réseau, ou sur le disque, alors ce ne sera pas du virtualisé.

        A un moment, quand j'avais plusieurs serveurs chez OVH, un serveur A ne pouvait pas voir un serveur B. Ils n'étaient pas dans le même data-center, mais cela n'aurait pas du arriver. J'ai fait un reverse ssh pour effectuer mes transferts de données et voilà.

        • [^] # Re: Kimsufi --> pas prêt

          Posté par . Évalué à 0.

          Ah ok, pour le mode rescue, c'est du virtualisé oui.

          Ma mauvaise expérience chez Online date un peu, j'avais pris une Dedibox en 2008, j'ai eu un problème hard (disque KO) la hotline était aux abonnés absent, et ne m'a répondu qu'au bout d'une dizaine de jours.

          Ca a peut-être changé depuis, mais je viens de regarder leur offre, pour le même prix que chez Ovh j'ai 340G de disque en moins, donc ça ne m'intéresse pas.

        • [^] # Re: Kimsufi --> pas prêt

          Posté par (page perso) . Évalué à 1.

          Expérience d’un amis :

          - Problème de RAM, lorsque le support est contacté, ils changent tout le dédier, sans prévenir de la date d’intervention ;
          - Demande d’un accès KVM, le KVM est connecté au mauvais serveur (celui d’un autre client), lorsque c’est signalé, il leur faut 3h pour faire la modification.

          Après, je n’ai pas d’avis personnel, je suis content de mon Kimsufi, je n’ai pas encore été voir par moi-même ce qui ce fait ailleurs.

  • # Pourquoi faire ?

    Posté par (page perso) . Évalué à 2.

    J'essaie d'installer une Debian Wheezy en deboostrap depuis le mode rescue

    Pourquoi faire ? (C’est une vrai question)

    OVH propose l’installation de Debian Wheezy de base dans le manager.

    • [^] # Re: Pourquoi faire ?

      Posté par . Évalué à 1.

      Sauf que ce n'est pas une "vraie" Debian, c'est une image bidouillée par leur soin et qui ne boote pas sur un noyau Debian standard, mais un noyau OVH patché. Cela ne me convient pas, et je préfère utiliser une Debian standard avec un kernel Debian.

      • [^] # Re: Pourquoi faire ?

        Posté par . Évalué à 2.

        laisse les installer leur debian
        puis tu changes les sources, tu installes le kernel de debian.

        c'est comme ca que je fais tourner les ubuntu, avec le noyau de la distrib

        • [^] # Re: Pourquoi faire ?

          Posté par (page perso) . Évalué à 2.

          Et si on veut installer du RAID (logiciel), puis par dessus du LVM, on ne peut pas, sauf à booter sur le mode rescue ou depuis le vKVM.

          Ils (OVH) viennent de virer effectivement le mode vKVM, sans prévenir…. sympaaa.

          Bien plus pénible à effectuer depuis le mode rescue… surtout que les disques sont vus différemment entre le mode rescue et le mode "normal" sur HD.

          Un des serveurs que j'avais chez OVH donnait toujours des signes inquiétant au niveau du disque dur, et parfois le serveur plantait. Les diagnostiques avec smartmontools n'ont rien montré d'anormal. C'est quand résigné je le rend que le support me dit qu'ils ont remplacés l'allim.

          Chacun sa mauvaise expérience…

          • [^] # Re: Pourquoi faire ?

            Posté par . Évalué à 0.

            Il y a des offre valables (à part OVH et Online) sur les dédiés à 12€ par mois ?

      • [^] # Re: Pourquoi faire ?

        Posté par (page perso) . Évalué à 2.

        Il y a deux choses qu’ils « bidouillent » :

        • ils posent salement un noyau à eux dans /boot ;
        • ils posent salement des scripts pour leur « real time monitoring » et une crontab.

        Alors ok, c’est pas propre mais ça se vire facilement.

        • [^] # Re: Pourquoi faire ?

          Posté par . Évalué à 0.

          Concernant les scripts RTM, ils se trouvent où ? Parce que j'avais vu pour le kernel dans /boot, mais concernant le monitoring il me semble qu'ils se contentent d'un ping.

          • [^] # Re: Pourquoi faire ?

            Posté par . Évalué à 2.

            ping,
            charge CPU/RAM/SWAP
            occupation disque dur

          • [^] # Re: Pourquoi faire ?

            Posté par (page perso) . Évalué à 4.

            Je ne me souviens plus du chemin exacte de tête, mais c'est quelque part dans /usr/local/bin/ un find suffit à le trouver. La tache cron, est dans /etc/cron.d/ si je dis pas de bêtise.

            • [^] # Re: Pourquoi faire ?

              Posté par . Évalué à 1.

              J'ai trouvé, merci beaucoup.
              C'est dans /usr/local/bin/rtm, et la tache cron est dans /etc/crontab

  • # Autre méthode

    Posté par (page perso) . Évalué à 2.

    J'utilise une méthode toute bête :
    1. installation de ma distribution préférée dans une machine virtuelle
    2. je lance mon serveur dédié en mode rescue
    3. dd if=mon_disque_virtuel bs=1M | bzip2 | ssh user@example.com "cat > /dev/sda"
    4. modifier quelques trucs pour que ça démarre correctement (sur Debian : /etc/udev/rules.d/70-persistent-net.rules)
    5. ?
    6. profit

  • # Problème résolu

    Posté par . Évalué à 0.

    J'ai fini par ouvrir un ticket au support (payant si il s'avère qu'un problème logiciel est à l'origine du problème). Un technicien est intervenu rapidement (la nuit qui a suivi l'ouverture du ticket) pour changer intégralement tous les composants du serveur à l'exception du disque dur.

    Tout est rentré dans l'ordre, le serveur boote sans problème sur le noyau Wheezy et je n'ai rien payé.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.