Support stellt sich quer: Drive could not be changed. Please try again with server powered off.

  • Hallo zusammen,


    gestern wollte ich ein Boot-Image in meinen (ausgeschalteten) vServer einlegen:

    Drive could not be changed. Please try again with server powered off.


    Das Image hatte ich früher x-Mal problemlos laden können.


    Image gelöscht, erneut hochgeladen -> gleicher Fehler.

    Zwei andere Images hochgeladen -> gleicher Fehler.


    Ich wende mich an den Support und kriege eine Belehrung darüber, dass man natürlich nicht jedes einzelne Image prüfen kann und ich für den Server verantwortlich bin: :thumbdown:

    Das ich das Laufwerk über das CCP gar nicht nutzen kann entgeht dem Mitarbeiter wohl:


    Zitat

    Selbstverständlich können wir Ihre eigenen Images nicht prüfen. Das würde jeden Rahmen sprengen.


    Sie besitzen bei uns einen virtuellen Server. Wir stellen Ihnen die Laufzeitumgebung bereit. Zu individueller Software und zur Einrichtung können wir keinen Support geben. Nach Einrichtung haben wir keinen Zugriff mehr auf Ihr System. Die Einrichtung und Konfiguration Ihrer Dienste und Pflege obliegt Ihrer Verantwortung.

    Hat jemand noch einen Tipp von Euch bevor ich dem Mitarbeiter was "passendes" zurück schreibe?


    Vielen Dank Euch!

  • Liest sich, als könnte der Host die Boot-Reihenfolge nicht ändern (geraten, ich hab die Fehlermeldung noch nie gesehen).

    Für's Rettungssystem wird es auf "Netzwerk" gesetzt. Funktioniert das?

    CentOS 7 / nginx / php-fpm / postfix / rspamd / clamav / dovecot / nextcloud running on RS 1000 SSDx4 G8 / VPS 500 G8 / VPS 2000 G8 Plus

  • Bootreihenfolge habe ich schon manuell versucht zu ändern auf:

    Code
    CD-ROM
    Network
    Hard-Disk


    Die "vorgefertigten" ISOs lassen sich alle einlegen. Nur eigene Images nicht.


    Hänge gerade in der Warteschleife, vielleicht erreiche ich per Telefon noch etwas... 30 Minuten (Update: bis jetzt 45 Minuten (!)). :rolleyes:


    Boot in die Rettungsumgebung klappt.

  • Eventuell war dem Mitarbeiter nicht gleich ersichtlich, dass es sich um eine Fehlermeldung aus dem SCP, und nicht aus deinem Betriebssystem handelt?


    Eventuell dein ISO in einem lokalen KVM System testen - mit libvirt recht fix erledigt:

    Code
          <disk type='file' device='cdrom'>
            <driver name='qemu' type='raw'/>
            <source file='/mnt/isostore/archlinux-2021.09.10-x86_64.iso'/>
            <target dev='sda' bus='sata'/>
            <readonly/>
          </disk>
  • AutoYaST DBAN war nur ein versuch nachdem meine eigentlichen Images (Acronis Boot CD) nicht eingebunden werden konnten.


    netcup1.png


    Genau das will ich auch erreichen :D


    Aber ich glaube langsam es gibt keinen Telefonsupport mehr. Bin mittlerweile bei 52 Minuten. 8|

    Früher war das eigentlich immer eine Angelegenheit von unter 5 Minuten. Oft viiiiel kürzer..

  • ist mir schon klar :D mit meinem Gegentest und dem positivem Ergebnis wollte ich dir nur eine bessere Verhandlungsgrundlage am Telefon verschaffen - also sofern du jemanden erreichst. :)

    Ich weiß, dass ist nett von Dir. Danke :)


    Nach 1 Stunde und 10 Minuten Wartezeit in der Schleife habe ich es aufgegeben. :thumbdown:

    Der Support kriegt von mir nun eine Email.

  • Hallo zusammen,


    meinen alten Beitrag kann ich leider nicht mehr editieren.

    Netcup hat sich gemeldet. Die Antwort

    Zitat

    Wenn Sie sicher sind, dass Ihre eigenen Images fehlerfrei sind - das werden wir auch mit einer Beschwerde nicht püfen aus genannten Gründen, [...] senden Sie uns doch bitte, was genau passiert und wobei. Gern auch als Screenshot im Anhang. Beachten Sie bitte, wir müssen es nachvollziehen können. Gern sehen wir es uns dann nochmals an.

    Dies habe ich erledigt.


    Ich habe noch weiter getestet und nun wird es interessant.


    Image BF17 RS 1000 Plus / VPS 50 G7 Freund von mir mit VPS 200 G8
    Acronis nein unbekannt
    dban-2.3.0_i586.iso nein ja
    Macrium Free nein unbekannt
    shredos-2021.08.2_20_x86-64_0.32.014_20211130.iso ja
    ja


    nein = Drive could not be changed. Please try again with server powered off.


    Es scheint wohl also Images zu geben die funktionieren - warum auch immer.

    Eventuell gibt es einen Zusammenhang mit dem alter des Servers? Vielleicht wurde ja irgendwas geändert.. Denn früher konnte ich alle meine ISOs problemlos mounten.


    DerRené und AutoYaST könnt Ihr mir bitte sagen bei welchem Produkt Ihr die "dban"-ISO einlegen konntet?

  • gemeint ist das hier:

    Wenn er gar nicht läuft, kann (bzw. sollte) auch kein (KVM/Qemu) Prozess am Hostsystem laufen. Dementsprechend würde ich mal davon ausgehen, dass es keinen Unterschied macht, wenn man die VM extra zum killen startet. ;)

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

  • So sieht das bei mir aus.


    n1.png


    n2.png


    @All: Gibt es hier jemanden der einen Server hat der älter als die aktuelle 8. Generation ist um das dban-ISO zu testen?


    Image BF17 RS 1000 Plus / VPS 50 G7 Freund von mir mit VPS 200 G8 VPS 200 G8 BF (DerRené)
    Acronis nein unbekannt unbekannt
    dban-2.3.0_i586.iso nein ja ja
    Macrium Free nein unbekannt unbekannt
    shredos-2021.08.2_20_x86-64_0.32.014_20211130.iso ja

    ja unbekannt


    Das ist sehr nett, vielen Dank. Das Acronis-Image ist nicht kostenlos. Das Macrium "Free" ist zwar kostenlos aber Du musst erst die Software installieren, dann kannst das ISO erstellen. Viel zu umständlich :) Meine Behauptung ist aber: Wird das dban-Image funktionieren, funktioniert auch der Rest. Ich danke Dir dennoch vielmals. :thumbup:


    Mal schauen ob sich jemand mit einem älteren Server findet um es zu testen.

  • Gibt es hier jemanden der einen Server hat der älter als die aktuelle 8. Generation ist um das dban-ISO zu testen?

    Ich habe einen RS X-Mas und einen VPS 20 G7, beide aus dem Jahr 2016.


    Ich starte mal schnell einen Test :)

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

    Danke 2