PC nicht mit Ubuntu kompatibel?
Hallo.
Hab mir vor drei Wochen einen neuen Intel NUC gekauft, weil mein alter nicht mehr die Leistung erbracht hat, die ich mir wünsche. Jedenfalls hab ich Ubuntu darauf installiert und es lief auch so weit. Nach ner Woche bin ich leider auf die blöde Idee gekommen, das BIOS zu updaten, weil ich eine Funktion nicht finden konnte und dachte, dass ich sie vielleicht durch ein Update bekomme. Naja, wahrscheinlich war sie am Ende doch da und ich hab nur falsch geguckt, aber egal, darum gehts nicht.
Jedenfalls hab ich mir durch das BIOS-Update irgendwie alles kaputt gemacht. Er hat dann noch einmal in Ubuntu gestartet und seitdem bootet er nicht mehr. Hab es nochmal versucht neu zu installieren. Auch mit der vorletzten BIOS Version (gibt leider nur die letzte und vorletzte zum Download) und auch ein Recovery-BIOS. Hat alles nicht geholfen. Hab ich also den Support angeschrieben und er hat mir noch ne andere Recovery-Methode vorgeschlagen. Eine, wo ich im Computer irgendeine Sicherung entfernen musste. Hab die Recovery durchgeführt und leider hat sich nichts geändert. Jetzt rät er mir, ich solle mal Windows ausprobieren, weil Ubuntu offiziell nicht supported wird. Außerdem soll ich nen anderen RAM ausprobieren (weil er beim booten was von Speicherfehler sagt).
Aber ich hatte ja jetzt eine Woche Ubuntu am laufen gehabt. Und ich hab zwei RAM drin, nicht nur einen. Ich kann mir daher schwer vorstellen, dass es an Ubuntu oder am RAM liegt. Kann es sein, dass die nur keine Ideen haben, sobald die Standardlösung nicht funktioniert? So kommt es mir nämlich vor.
Achja und dann hat er mir noch vorgeschlagen, dass ich den PC sonst umtauschen soll, weil ja die 30-Tage-Garantie noch läuft. Die Sache ist nur, ich hab ihn für 400 Euro gekauft und jetzt ist der günstigste Preis, den ich finden kann, 560. Ich hab Schiss, dass sie mir dann einfach nur das Geld zurückgeben anstatt einem neuen Gerät, womit ich nichts anfangen könnte. Zumal ich mir ja auch extra schon RAM und GPU für den neuen Nuc gekauft hab.
Geht übrigens um den NUC9i7QNX, falls es wen interessiert.
4 Antworten
- BIOS Batterie rausnehmen (für min. 15 Minuten)
- Secure Boot deaktivieren
- Legacy Mode (bzw. CSM Support) aktivieren
- Rufus oder Universal USB Installer verwenden
Das klingt danach, als ob es sich nur um ein Problem beim Booten handelt. Eventuell eine UEFI/Secure Boot Problematik, wofür du möglicherweise einen UEFI kompatiblen (signierten) bootstrap loader benötigt, in den du erst hineinbootest, und der dann dein Linux startet, oder du schaltest Secure Boot ganz aus - so wie es eventuell vorher auch schon eingestellt war.
Boote alternativ mal von einem Live USB stick, womit du dich davon überzeugen kannst, dass der Computer an sich noch Linux laufen lassen kann.
refind wäre ein solcher UEFI Bootstrap loader.
"... bootet das System immer in grub" - also es bootet. Jetzt muss grub also nur noch das richtige boot Image laden, was bei einer "richtigen" live CD statt dem installer konfiguriert wäre.
Wie auch immer, ich gehe stark davon aus, dass, wenn er grub starten kann, auch Linux kann, und das Problem ist, BIOS wissen zu lassen, dass dein boot loader auf der Platte - sei es grub oder refind - auch der ist, den es booten soll.
Das System bootet in welchen GRUB? Den von der Festplatte, oder den vom Stick?
Der Speicherfehler ist sowas wie "CMOS RAM checksum error", und die "Sicherung" war ein Jumper, also eine Brücke, die zwei Kontakte miteinander verbindet? Damit würde die Spannungsversorgung vom RAM, worin die BIOS-Einstellungen bewahrt werden, unterbrochen, um alle Einstellungen zurückzusetzen. Inklusive der boot-Konfiguration. Den Jumper hast du doch wieder zurückgesteckt, nehm ich an.
Der von der Festplatte, hab grad den USB Stick rausgezogen und er bootet in GNU GRUB version 2.06
ja genau, jumper hieß der. hab ich abgezogen, dann nach der anleitung, den nuc angestellt, er hat diese recovery durchgeführt, ich den jumper wieder dran gemacht, hochgefahren und nichts hat sich verändert. bzgl. dieses speicherfehlers kann ich mal nen screenshot hochladen https://imgur.com/a/WGHFw8j also wenn ich in GRUB auf Ubuntu drücke, kommt das erste bild in dem album. wenn ich ubuntu im recovery mode drücke, dann kommt das erste und das zweite bild. und von da an gehts nicht weiter. dann hilft nur noch power-button drücken
danke für den tipp mit der live cd. ich muss bis übermorgen noch ein wichtiges projekt fertigstellen, aber am wochenende werde ich das mal ausprobieren
Der Kernel findet seine root Partition nicht. Diese probiert er, über deren block id zu finden, aber diese ist aus irgend einem Grund nicht auffindbar.
Boote mit einem live system, führe als root darin aus: blkid , und schaue, ob du eine Partition findest, die die gleiche UUID hat wie im screenshot. So nein, besteht die Partition nicht mehr, oder der Kernel kann nicht auf das Speichergerät damit zugreifen.
Als live system würde ich GRML nehmen, wegen seinen diagnostischen Werkzeugen.
sorry, für die späte antwort, war die letzten tage nicht zuhause. also hab es vorhin mal mit grml probiert, aber bin nicht sicher, ob ich alles richtig gemacht hab. ich hab in der shell grml-live eingegeben. aber da tut sich irgendwie nur sehr langsam was. nach zwei stunden sieht es so https://i.imgur.com/uaw9Bmw.jpg und so https://i.imgur.com/c76O1iu.jpg aus. wenn ich in der vergangenheit knoppix genutzt hab, war das live os immer sofort da. ginge knoppix zur not auch?
Hehe ... du hast die installiert, was der Grund dafür ist. warum das dauerte. Die Idee wäre eigentlich gewesen, das live image auf USB stick zu schreiben, und davon dann zu booten. Schau, "Fully automatic installation", damit holt die Installation alle Pakete, woraus grml aufgebaut ist, aus dem Netz, und installiert diese. Im herunterladbaren Live image ist alles schon bootfertig drin und konfiguriert.
Keine Ahnung wohin das jetzt installiert wurde - vermutlich aber nicht auf, wie eigentlich angedacht, einen USB stick ...
Das Live image ist übrigens auch von grub startbar, wenn das auf der Platte steht - allerdings muss grub davon wissen, und um das bekannt zu machen, benötigst du erst ein lauffähiges und laufendes System.
Wie auch immer, ein GRML auf einem USB Stick zur Hand zu haben kann nix schaden.
oh mist, wie konnte das denn passieren. naja egal, hab es jetzt die ganze nacht durchlaufen lassen. aber der bildschirm sieht noch so aus, wie vor 10 stunden, deshalb denke ich, es passiert nichts mehr: https://i.imgur.com/Nz3Eff0.jpg hab jetzt deshalb mal auf enter gedrückt und dann erschien ein error :/ vielleicht war der auch vorher schon da, nur außerhalb des bildschirms und deshalb ging es nicht weiter https://i.imgur.com/2sJoCqx.jpg irgendwelche tipps, wie es jetzt weitergeht? :s
unten, das prompt mit dem #, zeigt dass er fertig ist. Worauf sich der critical error bezieht, ist nicht ersichtlich, aber ein anderes Problem zeigt sich: Einige Zeichen auf dem Schirm sind überschrieben mit anderen Zeichen, was üblicherweise ein Hinweis auf ein Hardware-Problem ist. Oft relatiert mit zu scharfem Timing von Signalen, Kannst du sehen, ob diese falschen Zeichen schon beim Ausgeben falsch erscheinen, oder ob die erst später die ursprünglich richtigen Zeichen überschreiben?
Jedenfalls hast du wieder ein Eingabeprompt, und das sollte von grml sein. Wie hast du das gebootet?
Ich würde da zunächst einmal den Schirminhalt löschen (Strg + L) und dann warten und schauen, ob da mit der Zeit irgendwelche ungewünschten Zeichen erscheinen.
also was ich ursprüglich gemacht hatte, war, dass ich grml vom usb stick gebootet habe, dann begann eine zeit des rumtestens, wo ich nicht so richtig wusste wo hin xD war dann mal grml x start, weil das nach nem fenstermanager klang, dann war ich bei grml default drin, wo dieser kasten mit verschiedenen shortcuts stand. dort hab ich q gedrückt, um in die shell zu kommen. dann hab ich auf der internetseite geguckt, wo ich eigentlich hin muss, hab den befehl mit grml-live entdeckt, hab den gemacht. dann gab es erstmal nen fehler über ne fehlende internetverbindung oder so. musste neustarten, hab das kabel angeschlossen, später nochmal probiert und 16 stunden später kam ich da raus, woher die letzten screenshots stammen. hab nun den schirminhaltlich gelöscht und es steht dort root@grml ~# ...jetzt warte ich, ob sich zeichen ändern oder hinzu kommen... wie lange etwa?
Vom USB Stick booten ist genau das, was du davon brauchst. Also booten, gewünschtes System (32 oder 64 bit), dann auf d für deutsches Tastaturlayout, und für eine Konsole dann Enter.
Sollte oder könnte relativ schnell gehen mit den falschen Zeichen. Wenn da nix passiert, wiederhole das ganze mit etwas Aktivität, z.B. Schirm erst mit Nullen füllen, und dann eine Uhr in die oberste Zeile setzen. Das könnte etwa so aussehen:
bash ( da läuft default zsh, deren flow control geht bissel anders)
und auf dem neuen Prompt dann:
printf "%09999d"; while sleep 0.1; do tput home; date; done
dann wieder ein paar Minuten schauen, ob die schirmfüllenden Nullen auch alle Nullen bleiben.
gibt es auch einen befehl, da wieder rauszukommen? :D ich hab etwas zu wenig nullen geschrieben, so dass jetzt nur ein viertel des bildschirms mit nullen gefüllt ist. in den 10 minuten hat sich da mit uhr auch nichts getan. ich hätt es jetzt nochmal mit mehr nullen probiert, aber weiß nicht, wie ich wieder in die eingabe komme
Strg + C
Zuwenig neunen. die 9999 steht für 9999 Einrückungen. Die 0 davor für "mit Nullen füllen". Also kannst auch 4000 oder was auch immer statt 9999
Danach willst du schauen, ob die gesuchte Partition mit der UUID e862...34c7 überhaupt besteht, durch Ausführen von lsblk -f
gesagt, getan! aber es sieht aus, als wäre die partition mit der UUID vorhanden https://imgur.com/HfLpOf1
tja hm. Eigentlich gut. Aber erklärt nicht, warum er die beim boot nicht einbinden kann.
Mach mal nen Filesystemtest auf der:
fsck.ext4 /dev/nvme0n1p2
Die Installation auf der SSD ist ja neu, also da lässt sich ja nix kaputtmachen, gell?
Da würd ich dann erstmal so vorgehen:
- ein Verzeichnis anlegen, was ich dann als chroot Verzeichnis verwenden würde
- Die Partition nvme0n1p2 dahin mounten
- Die Verzeichnisse /proc, /sys und /dev mittels bind mount da drin spiegeln
- die boot partition (das sollte die nvme0n1p1sein) ebenfalls da rein mounten (in .../boot)
- dann chroot da hinein
Jetzt sollte dein installiertes System "aktiv" sein, und maintenance kann mit und aus dem dann laufenden root system. Das mit dem Zweck, um mittels update-grub die boot konfiguration neu zu erzeugen, und zusätzlich würd ich noch das initrd neu schreiben (dafür wurde auch die boot partition gemounted)
danach mit sync eventuell noch Gepuffertes auf die Platte zwingen, und neuen boot versuch wagen (ohne USB Stick).
ja, inzwischen ist mir alles recht, hauptsache es läuft bald wieder :p hört sich aber ganz schön kompliziert an. also verzeichnis anlegen mit mkdir? und wohin? auf einen separaten leeren datenträger? und wie steuere ich einen anderen datenträger überhaupt an? so viele fragen, mir fehlen da leider die basics. hast du vielleicht eins, zwei links, die diese arbeitsschritte im detail erklären?
Das hier kommt dem nahe, insbesondere weil es auch die genannten bind mounts erwähnt und zeigt: https://www.linuxwiki.de/chroot
Das mit dem files kopieren und Bibliotheken kannst du ignorieren, weil du ja die komplette Partition mit allem schon drauf da mountest.
Ah ja, und noch ein Punkt - die aus Versehen ausgeführte Installation von grml dauerte mit beinahe 6 Stunden entschieden zu lange. Ich hätte da eher mit 15 bis evtl 30 Minuten gerechnet, also rund Faktor 15 rum schneller.
Lesegeschwindigkeit ließe sich so messen:
hdparm -t /dev/nvme0n1p2 und könnte sich bei SSD irgendwo im Bereich 500 MB ... 3 GB pro Sekunden wiederfinden. Ist das deutlich langsamer, stimmt da irgend etwas nicht, und auf die Liste mit Verwunderlichkeiten (wie auch das sporadische Überschreiben von Zeichen auf dem Schirm) setzen.
Lesegeschwindigkeit: https://i.imgur.com/ZWZ8BQk.jpg den rest, probier ich gleich nachm essen :D
So? Aber dann hätte ich die partitionen in dev zweimal drin, schätze, da stimmt was noch nicht
mkdir /mnt
mount /dev/nvme0n1p2 /mnt
mount -o bind /dev /mnt/dev
mount -o bind /proc /mnt/proc
mount -o bind /sys /mnt/sys
mount /dev/nvme0n1p1 /mnt/boot
chroot /mnt
Sieht richtig aus. Ich bin nicht sicher, was du mit "zwei mal drin" meinst.
/mnt bestand zwar schon, aber da ist nix passiert, dass du das nochmal anlegen wolltest.
Wie auch immer, du solltest dann das zuvor installierte System laufen haben
https://i.imgur.com/iyeG0w8.jpg chroot will noch nicht so richtig
Pfad der shell im chroot System angeben. Sollte /bin/bash oder /usr/bin/bash sein
Anders herum. chroot /mnt /bin/bash - ansonsten will er die gleiche shell starten, die schon läuft.
Also sollte auch mit erst bash starten, dann chroot gehen, aber so gibst du halt explizit an, welche es sein soll.
ok, wundervoll, das hat funktioniert :) ok, jetzt mit dem zweiten teil weiter. also neustarten und grub updaten? wo geb ich das grub-update ein?
Das einfachste an der Stelle wäre wohl, ein neues Kernel Image installieren, wenn vorhanden, oder das bestehende zu reinstallieren, weil dann sowohl grub Konfiguration als auch initrd neu angelegt werden.
Wird das Kernel-Image nicht über das OS installiert? Kann ich Ubuntu jetzt neuinstallieren? Ich häng immer noch in der Eingabe fest. "Reboot" funktioniert nicht. Er sagt "running in chroot, ignoring request". Einfach über den Powerschalter ausstellen?
"Über das OS"?
Du kannst Kernel Image wie andere Pakete entfernen und installierten. Bloß wenn es gerade das ist, welches gerade läuft, ist das keine gute Idee - aber das ist mit dem chroot nicht der Fall. Der Kernel, der läuft, ist der von grml, und der ubuntu Kernel liegt einfach nur passiv auf der Platte.
chroot kannst du mit exit oder Strg-D verlassen, wie eine subshell.
mit OS meinte ich das Betriebssystem Ubuntu. Aber geht immer noch nicht. Oder ich hab was missverstanden. Also ich hab jetzt grml verlassen und den PC wie vorher hochgefahren. Dann lande ich aber wieder in Grub, wo ich über advanced settings for ubuntu oder sowas auf den recovery mode der neuesten kernel version drücke. War das richtig, oder sollte ich was anderes machen? weil da lande ich wieder bei den fehlern, die ich schon am anfang hatte
Ich hab jetzt erstmal Knoppix gebootet und meine Daten gesichert, damit ich im Fall einer Neuinstallation nicht mehr alles neu einrichten muss. Was wäre, wenn ich Knoppix von der Live Disc in den internen Speicher schreibe. Vielleicht hätte ich dann wieder einen fehlerfreien Kernel und könnte im Anschluss wieder Ubuntu installieren?
Ich hab keine Ahnung ob das richtig war, weil ich ja nicht weiß, was du dazwischen noch gemacht hast. Irgendwas verändert? Oder bloss geguckt und beschlossen, dann wieder zu booten?
Neu installieren kannst du ja sowieso, da brauchst du keinen Kernel irgendwo hinzuschreiben für.
Nee, für dauerhaften Betrieb willst du den Kernel, der zu den Modulen, die auf der Platte stehen, passt, verwenden.
Also das letzte was ich gemacht hatte, war die sache mit chroot. dann mit exit verlassen, reboot und dann eben wieder in grub gelandet, wo alles noch aussieht wie vorher.
Ja von nichts ändern kommt natürlich auch keine Veränderung.
Kam jetzt nicht der Schritt, wo ich etwas updaten soll?
Ja, die Idee war, im chroot System mal grub config und initrd neu zu schreiben, mittels update oder reinstallation vom Kernel Image (womit als Folge davon beides gemacht wird)
achso, dachte das mach ich in ubuntu, weil es hieß dass jetzt das alte system wieder aktiv ist oder so. doch wieder was missverstanden. wenn ich aber nach kernel updaten google, kommen meist auch nur vorschläge, wie man das über apt macht. wo mache ich das jetzt, wenn nicht über ubuntu? auch über grml? bzw bash? und wenn ja, mit welchem befehl?
Du kannst doch da nicht rein booten, darum doch, dass es per chroot eingebunden wurde. Das war im chroot das installierte Ubuntu. Unterschied war bloss, dass nicht der Kernel aus Ubuntu, sondern von grml lief. Aldo damit Notwendigkeit vom boot umgangen wurde.
hm ok, aber mir ist noch nicht ganz klar, wie ich jetzt den kernel neuinstalliere
Per normalem Paketmanagement, das Kernel Image ist auch nur ein Paket, welches installiert, deinstalliert, reinstalliert werden kann, und von dem auch updates, so existierend, genau wie andere Programmpakete eingespielt werden können.
Bloss will man normalerweise nicht das Paket des gerade laufenden Kernels deinstallieren - aber das ist ja im chroot auch nicht der Fall.
sorry, aber ich komm nicht mehr mit :( das mit dem paketmanager hab ich gelesen, aber ich dachte, dafür muss ich in ubuntu booten. also kann ich pakete installieren, ohne in ubuntu oder ein anderes betriebssystem booten zu müssen? wie sieht das dann aus? wie gehabt in die eingabemaske von grml und dann: sudo apt-get install --reinstall linux-image-$(uname -r) ?
Das im chroot *ist* das installierte Ubuntu. Darum dass wir das ja ins chroot getan haben, um da dran zu kommen um z.B. Kernel Image neu zu installieren
Im chroot bist bzw. warst du doch schon superuser - welchen Sinn soll denn da das sudo machen?
weiß nicht, ich kenn mich nicht so gut damit aus. der befehl stand im ubuntu wiki. also ohne sudo. muss ich mich mit cd erst irgendwie in das chroot hinein navigieren? nein, oder? also muss ich jetzt wirklich nur wieder grml starten, d für das deutsche tastaturlayour, dann enter für die eingabemaske und den befehl ohne sudo eingeben. richtig?
Nein, nicht richtig. Du müsstest stattdessen das gleiche machen, was du zuvor auch gemacht hast, um ins chroot zu kommen. Sonst bist du ja bloss in grml, nicht im Ubuntu chroot
also erst nochmal die sachen mit mount und chroot:
mount /dev/nvme0n1p2 /mnt
mount -o bind /dev /mnt/dev
mount -o bind /proc /mnt/proc
mount -o bind /sys /mnt/sys
mount /dev/nvme0n1p1 /mnt/boot
chroot /mnt
und dann:
apt-get install --reinstall linux-image-$(uname -r)
Das sieht in Ordnung aus. Ich würde vor dem apt-get noch ein apt update zum Aktualisieren der Paketlisten ausführen lassen. Ehm nein, nicht ganz - der laufende Kernel ist nicht der, den du Reinstallieren möchtest.
ich glaube es hat nicht funktioniert https://i.imgur.com/YWCx3pn.jpg
1. Tippfehler
2. Lies das Ende meines vorigen Kommentars
Was du gerade siehst, ist das Resultat des Tippfehlers
achso.. also im wiki ist das der einzige befehl, der sich mit der neuinstallation des kernels befasst.
ich könnte noch einen kernel hinzufügen über linux-image-VERSION-ABINUMMER-VARIANTE
aber, dann weiß ich nicht welche version. ich muss gucken, welcher der LTS kernel von Ubuntu 22.04 ist, oder? wenn ich danach google, finde ich 5.15... oder 5.17. sind aber alles nur onlineartikel, keine offizielle quelle.
also vielleicht so etwas?
apt-get install linux-image-5.15-generic
Am besten den mit der höchsten Versionsnummer, mit dem Namen so wie er in der Paketliste steht.
Hab jetzt hier geguckt, das müsste doch richtig sein: https://packages.ubuntu.com/jammy/linux-image-5.15.0-56-generic
Ich glaube mich zu erinnern, dass mir Grub den auch angeboten hatte, im recovery mode zu starten. Zwei stück hatte er. Der andere war glaube ich 53. wobei keiner der beiden funktioniert hatte...
Keine Ahnung, wie wahrscheinlich es ist, dass beide kaputt sind.
Aber dann würde ich jetzt erstmal ausprobieren: apt-get install linux-image-5.15.0-56-generic
ok?
Da ich keinen Einblick in deine Paketlisten habe, müsste ich eher dich fragen, ob das ok wäre, als du mich :) Anders nimmst halt ein Paketverwaltungsfrontend, womit du von einer Liste auswählen kannst, wie z.B. aptitude.
dachte, diese internetseite wäre so etwas wie die paketliste. sonst weiß ich nicht, wie ich sie einsehen kann. hab es nun mit aptitude probiert und bekomme denselben fehler wie vorher https://i.imgur.com/GKH7vi6.jpg wo ist denn der tippfehler? ohne das -get vielleicht?
Vergleich die Fehler mal. Das sind verschiedene Fehler. Was du jetzt hast, ist ein Netzwerkproblem - ein Problem mit der Namensauflösung vom Hostnamen. Das steht doch auch in den Fehlermeldungen, wenn man die einfach mal liest.
Der Netzwerkfehler hat mit dem Tippfehler weiter oben nichts zu tun. Ich nehm an, dass du den Tippfehler bereits entdeckt hast, der springt ja geradezu ins Auge, wenn man da einfach mal kurz drüberschaut.
ja, im ersten Fall hab ich ein Leerzeichen vergessen.
Und in beiden Fällen ist die Rede von "Temporary failure resolving 'de.archive.ubuntu.com'"
Nun, wie ich das Netzwerkproblem lösen kann, weiß ich auch nicht. Ich hatte in der Vergangenheit bereits Netzwerkprobleme mit apt. Die gingen auf ein Problem mit ip4, ip6 zurück. Nach vielen Stunden hab ich dann einen Befehl gefunden, der das Problem behebt. Natürlich könnte ich den jetzt auch eingeben, aber die Fehlermeldung sah anders aus. Und eigentlich muss ich den nur einmal pro Installation eingeben, was ich in dem Fall schon getan hab.
Kann man das Kernel-Image auch von nem anderen PC herunterladen, auf nen USB-Stick packen und von da aus installieren?
Einfach nochmal, oder den Tip mit dem "--fix-missing" befolgen. Möglich, dass dein Provider gerade in dem Moment neu verbunden hat.
Und besser lesen, was die jeweilige Ausgabe tatsächlich sagt, statt gleich zu Konklusionen zu springen.
Und ja, von USB Stick installieren gänge auch, wäre aber den Aufwand nicht wert.
hab jetzt apt update, apt-get update, --fix missing probiert, ebenso wie das deaktivieren von ipv6, das in der vergangenheit geholfen hat. nichts funktioniert. --fixmissing sagt nach "failed to fetch ..." nun auch noch "internal error, ordering was unable to handle the media swap"
Das klingt ja ganz schön heftig für solch eine eigentlich recht problemlose Operation.
Wie sieht denn deine Befehlszeile mit fix-missing komplett aus? Genau bitte, ohne Tippfehler.
wenn ich "host de.archive.ubuntu.com" eingebe, springt er ohne weitere ausgabe direkt in die nächste zeile
das ist interessant - weil das sollte nicht. Der sollte einige Zeilen mit ip Adressen zeigen. Demnach kannst du den server auch nicht pingen, gell?
Bei mir sagt er da Temporary failure in name resolution... Nur waren die Netzwerkprobleme unter Ubuntu bei mir bisher nie nur temporär...
Das ist bloss die Namensauflösung, und sollte recht einfach zu verhelfen sein.
Zeig mir mal den Inhalt der Datei /etc/resolv.conf
Ich musste jetzt leider erstmal los, in die Stadt, Geschenke kaufen. Ich hoffe, ich bin in zwei Stunden zurück
mir wird der zugriff verweigert, wenn ich /etc/resolv.conf eingebe
Achso ich dachte, so zeigt es mir den Inhalt xD dann vielleicht mit print vornedran?
Au weia.
Muss ich jetzt echt einen Suchlink hier hinschreiben, der zeigt, wie das geht? Das wird sehr arg mühsam, dir jeden einzelnen Schritt vorzugeben. Das dein Foto nicht den Inhalt der Datei anzeigte, war dir aber deutlich?
Schau mal:
https://duckduckgo.com/?q=linux+inhalt+datei+anzeigen
Das ist eine Internet Suche, und sollte Resultate liefern, die eine der meist elementaren Operationen zeigen: den Inhalt einer Datei anzeigen.
Ich empfehle, erstmal die absoluten Basics von Linux erstmal anzueignen. Der nächste Schritt wäre nämlich dann viele Malen schwieriger gewesen, nämlich, eine minimale Veränderung an der Datei anzubringen. Les dich am besten erstmal ein,. wie man das macht.
Hab jetzt cat genutzt. Falsch? https://i.imgur.com/fe3Wtoc.jpg
Nein, das ist nicht falsch. Das ist der Inhalt, also was ich sehen wollte. Die Datei ist leer. Damit kann ich was anfangen. Aber mit deinem "eingegeben, geht nicht" kann ich dagegen nichts anfangen, genausowenig wie mit deinem Foto, das zeigt, warum es nicht ging. Weil das nicht der Inhalt war, den ich wollte.
Jedenfalls ist das ein Problem, dass die Datei leer ist. Und das ist auch das Problem mit der Namensauflösung. Das muss also anders:
Sorg dafür, also mache das so, dass in der Datei drinsteht:
nameserver 1.1.1.2
Wenn getan, wiederhole nochmal den host ...ubuntu... Befehl, der dann gehen sollte, und das ping ....ubuntu... sollte dann auch gehen.
Dann sollte weitere Installation auch gehen. also z.B. das aptitude, und reinstall vom kernel image. Falls nicht noch irgendwo ein Problem auftaucht.
ok, hab es mit echo in die datei geschrieben, host und ping war erfolgreich, die installation von aptitude ebenfalls. so sieht die kernel-liste der installierten pakete aus: https://i.imgur.com/oPWwQwO.jpg und die kernel-liste der uninstallierten pakete ist endlos lang. aber wenn ich das richtig sehe, ist die neueste kernel-version hier die über dem markierten: https://i.imgur.com/Mo2JTYU.jpg also sind die beiden installierten bereits die neuesten, oder? dann ist jetzt noch die frage, wie ich version 56 neuinstalliere. so? apt-get install --reinstall linux-image-5.15.0-56-generic
wenn die -56 eine neue, noch nicht installierte Version ist, dann reicht es, die zu installieren. Reinstallieren willst du nur die, die schon installiert sind, zum Zweck dass deren initrd neu geschrieben wird. Das neueste Image sollte aber reichen, denn beim Installieren wird damit ja ebenfalls ein neues initrd gebaut.
Doch, linux-image-5.15.0-56-generic steht unter den installierten Paketen. Oder was bedeutet das "A" vor dem Eintrag? (erster Link)
Sind diese Fehler schlimm? https://i.imgur.com/KiSxs9a.jpg
Das "A" steht für "automatisch installiert", d.h. Auswahl des Pakets erfolgte, weil es eine Abhängigkeit darstellte, und nicht, weil es manuell selektiert wurde. Diese beiden Fehler sind nicht tragisch. Erster Fehler sollte aber nicht auftreten mit /dev per bind mount vor dem chroot eingebunden. Grund für den zweiten Fehler ist mir nicht deutlich - da probiert der installerscript, Symlinks ins Wurzelverzeichnis zu setzen, die auf die jeweiligen Kernel Files zeigen. Grub braucht diese Symlinks aber nicht.
ok und wie gehts jetzt weiter? erstmal neustarten oder
"danach mit sync eventuell noch Gepuffertes auf die Platte zwingen, und neuen boot versuch wagen (ohne USB Stick)."
und wenn neustart, was soll ich nehmen, wenn grub wieder auftaucht? ubuntu oder dieses advanced mit dem recovery mode?
Hab ihn jetzt einmal neugestartet, weil ich für eine Woche verreise und den PC dafür sowieso herunterfahren musste. Hab in Grub den neuinstallierten Kernel im Recovery mode ausgewählt, aber die Fehlermeldung mit dem Speicher kommt leider immer noch
bootet er jetzt wenigstens - also findet er seine root partition?
Ich mache, wenn ich wieder da bin, nochmal ein Foto, aber auf den ersten Blick sah alles gleich aus.
Ich komme nächste Woche übrigens mit einem neuen RAM zurück. War schon als Weihnachtsgeschenk vereinbart, bevor das Problem auftrat...
Jetzt hab ich mich gefragt, wenn ich den RAM austausche und die SSD komplett formatiere. Dann ist es doch eigentlich wie neu, oder? Müsste ich dann nicht Ubuntu wieder ganz normal installieren können, wenn ich das Image auf einen USB-Stick ziehe?
Ganz frisch und neu schafft sicherlich kontrollierbare Voraussetzungen. Im BIOS dann vielleicht noch UEFI / Secure Boot ausschalten und auf ein neues - oder vielleicht auch mal mit einem alternativen Linux, eventuell Ubuntu ähnlich. Mint oder Debian oder sowas. Sollte es dann booten, dann kannst ja wenns unbedingt muss da dann nochmal Ubuntu drüber installieren. Oder gleich bei einem von denen bleiben.
Ich hab jetzt erstmal Knoppix gebootet und mit Gparted die Partitionen gelöscht und eine neue leere erstellt. https://i.imgur.com/IdkCUjk.jpg Was mich irritiert ist, dass dort steht, es seien noch knapp 2 gb belegt. Kann ich die auch irgendwie formatieren? Und wenn ich versuche Knoppix auf die Festplatte zu speichern, zeigt er mir die Platte nicht an: https://i.imgur.com/ZyzfGfK.jpg Den neuen RAM hab ich noch nicht eingesetzt, wenn ich versuche Linux Mint zu boote bekomme ich einen Memory Fehler. Also vermutlich noch dasselbe Problem. Hab mich bisher nicht getraut, den neuen RAM einzusetzen. Nicht, dass sich der Fehler dann irgendwie auch auf den neuen RAM überträgt. Mir ist nicht ganz klar, von wo aus er jetzt eigentlich GRUB bootet. Und wo dieser Fehler herkommt, wenn die Festplatte eigentlich leer sein sollte. Sind das die 2 gb belegter Speicher, der sich nicht formatieren lässt? Achja und hier noch die letzten Zeilen des Fehlerbildschirms (allerdings nachdem ich Ubuntu schon gelöscht hab): https://i.imgur.com/ZcDCkJ4.jpg
"Formatieren" nennt sich unter Linux "Dateisystem anlegen". Ja, das geht.
mkfs.xxxx sind die Befehle dafür, wobei xxxx für den Typ des anzulegenden Dateisystems steht.
mkfs steht für "make file system"
Aber hab ich das nicht gemacht? Ich hab ja in Gparted beide Partitionen auf der Festplatte gelöscht. Dann hab ich auf "Neu" geklickt und da hab ich ja dann die Größe der neuen Partition und das Dateisystem (hab ext4 genommen) gewählt. Aber danach waren dann halt laut Gparted immer noch 2 gb belegt. Ich hab mich gefragt ob das so etwas wie eine versteckte Partition ist, wo der Linux Kernel und so drauf liegt. Wenn ich jetzt in Grub boote, sagt er mir ja immer noch was von Ubuntu, obwohl ich alles, was mir Gparted auf der Platte angezeigt hat, gelöscht hab.
Wenn ich den mkfs Befehl ausführe, dann macht er das doch bestimmt nur auf die neue Partition, oder werden dabei auch wirklich diese 2 gb gelöscht die noch irgendwo belegt sind?
mit fdisk -l oder auch lsblk kannst du die für den Kernel sichtbaren Partitionen anzeigen lassen.
Sind diese ganzen RAM-Einträge bei fdisk -l normal?
https://i.imgur.com/g2PQqJ7.jpg
https://i.imgur.com/BiUYomP.jpg
Und lsblk zeigt mir auch keine separate Partition an:
https://i.imgur.com/e3n27qB.jpg
ok, hab den Speicher auf der SSD nun mit dem folgenden Befehl gelöscht
nvme format -s1 /dev/nvme0n1
den Arbeitsspeicher hab ich ebenfalls ausgetauscht. Der neue wird im Bios auch erkannt. Ich lande aber weiterhin in grub mit folgenden Optionen, wenn ich einen USB Stick mit Linux Mint angeschlossen hab:
https://i.imgur.com/NQXuZ6o.jpg
Wähle ich Linux Mint (Compatability mode) aus, bekomme ich "Error: Out of memory" und anschließend den Fehlerbildschirm aus meinem vorletzten Beitrag.
Die SSD ist leer, der Arbeitsspeicher ist neu und im Fehlerbildschirm sagt er immer noch was von Ubuntu. Ich weiß nicht, wo er die Information hernimmt, dass mal Ubuntu installiert war. Wo hat er die gespeichert?
Wenn dir jetzt auch nichts mehr einfällt, muss ich mir wohl Gedanken machen, wo ich das Gerät einsenden kann.
Der Bootstrap loader Teil von Grub steht auf den ersten Sektoren, hinter dem Bootsektor und der Partitionstabelle, also außerhalb der Partitionen. Auf Cylinder 0, bei Festplatten, auf den logischen Äquivalenten bei SSDs - die ja keine Cylinder wie Festplatten haben. Sollte dich aber zu dem Zeitpunkt nicht zu kümmern brauchen, denn ohne installiertem System macht Booten ja wenig Sinn - und nach Installation wird grub eh neu geschrieben, mit frischer Konfiguration.
Und nicht zu vergessen, der Bootsektor selbst, also die ersten 128 bzw 126 bytes, welche den Code enthalten, dass der auf die Partitionstabelle folgende Bootstrap code geladen und ausgeführt wird, also der MBR, der Master boot record. Den überschreiben mit dem Code, der beim Booten zuerst von der Platte gelesen und ausgeführt wird. Bei Installation von grub wird grub auch diesen an das Laden von sich selbst anpassen. Zwei bytes davon sind eine Kennung, dass es sich um gültigen boot code handelt - wird der überschrieben, wird BIOS sich beklagen, dass von dem Gerät nicht gebootet werden kann (da kein ausführbarer boot code gefunden)
Steht aber alles im Netz, z.B. https://de.wikipedia.org/wiki/Master_Boot_Record - ich bin nicht sicher, warum ich dir das alles erzählen muß, die Information gibts doch, und das schon länger als dass es Internet gibt.
Mit der Größe lag ich aber falsch. Nicht 126 sondern 440 bytes...
Also hat der Befehl doch nicht alles auf der Festplatte gelöscht, sondern nur die Partitionen? Die Partitionen hatte ich ja schon mit Gparted gelöscht, ich wollte die Festplatte möglichst auf Werkseinstellungen zurücksetzen... So als würde ich den PC zum ersten Mal in Betrieb nehmen.
Ich versteh nicht ganz, was mir die Hinweise nützen, dass Grub, MBR und Co. überschrieben werden, wenn ich das System neuinstalliere, ich aber erst gar nicht in die Situation komme, wo ich was Neues installieren könnte. Er bootet die USB-Sticks mit Ubuntu oder Linux-Mint ja nicht.
Dass der nicht die USB Sticks bootet, hat aber nichts mit dem bootloader auf der SSD zu tun. Schließlich willst du ja von USB booten *anstatt* von SSD. Sobald aber der boot loader von SSD geladen wird, findet ja eindeutig kein boot von USB statt. Was dann der SSD bootloader macht, ist dann auch egal, denn im Moment dass der geladen wurde, war das schon nicht richtig.
Achso.. ja gut, macht Sinn. Ach Mann, was mach ich denn jetzt?
Wenn das Problem sich mittlerweile hin zu "Ich krieg's nicht hin, von USB zu booten" verschoben hat, dann scheint mir, dass du dir eine Menge Mühe ersparen kannst, das herausfinden zu müssen, indem du den einfach zurück gibst.
Ich hab inzwischen den Überblick verloren, was das Problem ist. Ich dachte es liegt an dem Bootloader auf der Festplatte. Scheinbar nicht, weil der nichts mit dem Nicht-Booten von USB-Sticks zu tun hat. Wobei Live-Systeme ja funktionieren. Nur kann ich von denen kein neues System auf die Festplatte installieren. Aber ist die Festplatte überhaupt das Problem, wenn er keine USB-Sticks bootet? Der Arbeitsspeicher ist in Ordnung. Ich hab keine Ahnung, ob jetzt die Festplatte oder was anderes im PC das Problem ist. Ich weiß auch nicht, wie was funktioniert und ich kann ebenso wenig mal auf die Schnelle die komplette Arbeitsweise eines Computers erlernen. Ich versteh eh nur die Hälfte von dem, was ich hier oder in irgendwelchen Wikipediaartikeln lese. Also ja, scheinbar ist das Problem dann einfach zu kompliziert für mich und es macht keinen Sinn, sich weiter damit zu befassen.
Die Festplatte bzw die Installation auf der Festplatte war mal das Problem, als die die root Partition nicht einbinden konnte.
Das nicht booten können von USB ist ein davon unabhängiges Problem, und hat womöglich mit dem Gerät an sich nichts zu tun. Da dies im Prinzip ja geht, vermute ich, dass das damit zusammen hängt, wie du die USB sticks mit dem Installationsimage beschreibst.
Ich beschreibe die USB Sticks mit Rufus, so wie ich es in der Vergangenheit auch mit Lubuntu, Ubuntu, LibreElec und Co. gemacht hab. Da ich da nichts verändert habe, denke ich nicht, dass es daran liegt. Zumal er in beiden Fällen, SSD und USB, von Speicherproblemen spricht.
Gesehen, dass du anscheinend manche USB Sticks booten kannst, aber andere wiederum nicht, wäre es gut, zu wissen, was der Unterschied ist zwischen denen, die booten und denen, die nicht booten.
Die beiden, die booten, sind grml und Knoppix. Beides Live-Systeme. Die Images von Ubuntu und Linux-Mint booten nicht. In Rufus selbst nutze ich immer die Standardeinstellungen bzw. was er mir empfiehlt. Da mache ich nichts anderes, als das Image auszuwählen. Die Images hab ich vorher sogar auf die SHA checksum überprüft, also sind die an sich auch in Ordnung
Dann klingt es danach, als ob die beiden images von Mint und Ubuntu nicht die richtigen sind. Für falsche CPU-Architektur zum Beispiel. Ein Installationsimage ist, aus Sicht vom booten, genauso "live" wie ein live image. Lediglich nicht so komplett.
GRML *kann* übrigens Festplatteninstallation, das installierte System wird dann ein Debian.
Das kann es eigentlich auch nicht sein, weil das Ubuntu-Image dasselbe ist, das ich bereits eine Woche lang am Laufen hatte. Bis zum besagten Bios-Update, als das Trauma begann. Vielleicht ist was im Bios falsch eingestellt. Secure Boot ist jedenfalls disabled. Der Bootprozess ist sonst auch derselbe: F10 beim Boot-Logo -> USB-Stick auswählen. Dann kommen bei Grml und Knoppix deren Bootbildschirme, während bei Ubuntu und Linux-Mint Grub erscheint
Probier doch dann mal die Festplatteninstallation von Debian mittels GRML - welches ja bootet.
Mit diesem Befehl? grml-debootstrap --target /dev/nvme0n1
Kann ich später mal schauen, aber ich hab's einfacher in Erinnerung - entweder direkt aus dem Menu, oder mit einem einfacheren Befehl, evt. disk-install oder ähnlich
Im FAQ von grml steht:
Is it possible to install Grml to harddisk?
No. If you want to get a Debian system take a look at grml-debootstrap (or use the Debian Installer instead).
Ich muss aber auch gleich los und komme erst heute Nacht dazu, es auszuprobieren
Eventuell hatte ich jetzt eine Debian-Live in Erinnerung, in der Überzeugung, dass die Installation nach Festplatte die von GRML wäre.
debootstrap gänge zwar, ist aber zu aufwändig für erstmalige Benutzer, weil das kein komplett bootbares System in einem Rutsch erzeugt.
Ok, es gibt Neuigkeiten.
Gut: Ich konnte Debian-Live booten und auf die Festplatte installieren. Er bootet nun auch ohne den USB-Stick in Debian. Ich bin mir allerdings nicht sicher, ob der Boot-Prozess so aussehen soll. So erscheint während des Bootprozesses bspw. Grub. Und zwischenzeitlich steht mit weißer Schrift auf schwarzem Bildschirm etwas von "missing firmware". Ich muss aber nichts drücken, damit er vollständig hochfährt: https://imgur.com/eOKmq2s
Schlecht: Wenn ich nun einen USB-Stick mit einem Ubuntu-Image einstecke, ihn als Boot-Medium auswähle und in Grub "Try or install Ubuntu" auswähle, kommt wieder der Fehler "Out of memory": https://i.imgur.com/9v0pfxn.jpg
Ubuntu gibts ja gar ned mehr, das sollte dann auch aus dem boot menu verschwinden können - hätte eigentlich schon passieren sollen, aber womöglich hast du zwei grubs installiert, einmal das alte, und einmal das neue auf einer anderen Platte.
Missing firmware ist nur dann problematisch, wenn die benötigt wird für etwas, das du benutzen möchtest, und ohne die firmware nicht geht. Lösung ist, die firmware dafür zu installieren. Debian installiert automatisch lediglich offenen, freie Firmware. Für proprietäre Firmware wirst du das entsprechende Paket mit Unterstützung dafür aus non-free installieren wollen (oder gleich alles, per meta Paket "firmware-linux-nonfree" aber ich würde da selektiver vorgehen und lediglich das, was benötigt wird, hinzufügen. Für grub für den Moment entweder den Ubuntu-Eintrag ignorieren, oder mittels grub-install und update-grub grub auch auf die andere, und hoffentlich richtige, Platte installieren und dessen Konfiguration neu erzeugen.
Ubuntu und Mint bauen übrigens auf Debian auf - Debian ist da so etwas wie das Original.
Für non-free, also auch für non-free firmware, wirst du in der Liste der Paket repositories auch den Eintrag für non-free aktivieren oder zufügen wollen. Standard ist Debian so vorkonfiguriert, dass ausschließlich freie Software in der Auswahl ist. Möchte ein Anwender auch nicht-freie Software (wie z.B. firmware), muss er das ausdrücklich an Debian in dessen Paketlistenkonfiguration mitteilen.
Was genau meinst du, wenn du sagst, dass ich möglicherweise das alte grub und das neue grub auf einer anderen Platte installiert habe? Ich habe zwei SSDs verbaut, eine für das Betriebssystem und eine andere, wo aber nur Daten drauf sind (Spiele). Also ist Grub eigentlich nur auf einer Platte installiert. Oder gibt es noch ein Grub in dem Ubuntu-Image auf dem USB-Stick und die kommen sich in die Quere?
Bei Installation gibst du an, wohin grub installiert werden soll. Gesehen dass eine neue Installation von deinem alten Ubuntu keine Kenntnis mehr haben sollte, drängt sich die Idee auf, dass die grub Konfiguration noch ein Überbleibsel von vorher ist - also auch nicht überschrieben wurde. Und das geht, wenn neues grub auf anderes Laufwerk geschrieben wurde.
Wie kommst du darauf, dass das neue System noch Kenntnis von der alten Ubuntuinstallation hat? Er fragt ja "Try or install Ubuntu" nur, weil der USB-Stick mit dem Ubuntu-Image angeschlossen war. Sonst hab ich jetzt nirgends was von Ubuntu gelesen
Ich dachte, das gelesen zu haben, dass das noch im grub menu drin steckte. Hab dann wohl übersehen, dass das bloss mit USB Stick war. Aber dann ist die Lösung ja einfach: Den USB Stick beim boot nicht einstecken.
Warte, ich boote den PC ganz normal in Debian und kann dann, wenn er hochgefahren ist, immer noch Ubuntu-Live vom USB-Stick starten?
Nö, ausser wenn du in Debian eine VM startest, die dann von USB bootet.
Dann versteh ich nicht, wie ich Ubuntu sonst installieren soll
Warum würdest du ein System installieren wollen, welches auf der Machine nicht mal bootet?
Ich dachte, ich bin hier, um es wieder zum Laufen zu bekommen
Laut Frage bist du hier, weil du fandest bzw fragtest, dass oder ob dein PC mit Ubuntu nicht kompatibel wäre. Der Tip mit alternativen Linux probieren, um zu bestätigen, dass der PC damit läuft, hast du ja jetzt hinbekommen, und sogar eine Installation damit von der Festplatte tut's. Also Frage im Prinzip beantwortet: PC ist mit Linux kompatibel.
Warum du den jetzt mit Ubuntu oder mit Mint nicht booten kannst, wäre dann vermutlich eine andere Frage.
Versuch mal Debian Testing, Manjaro oder Fedora. Die nutzen jeweils den neuesten Linux Kernel. Vielleicht hilft das.
Du könntest erst nochmal versuchen über das Bios Menü (Herunterfahren und Einschaltknopf laaaange drücken, bis es 3x Piept) Dein Bios wieder herzustellen oder ein weiteres update durchzuführen.
Ansonsten stimmt vielleicht etwas nicht mit Deinem Ubuntu LiveDVD. Lade es noch mal neu herunter und erstell Dir einen USB Bootstick, vorzugsweise ohne Hilfsprogramme wie Unetbootin etc. ;)
Wenn du zwei ram riegel drin hast, würde ich mal einen rausnehmen, wenn es dann nicht geht, den anderen versuchen. Beide werden nicht kaput sein.
Das könnte ich mal ausprobieren... allerdings werden ja auch beide im bios angezeigt. und wie wahrscheinlich ist es, dass ein ram ausgerechnet nach einem bios update stirbt
Das sie angezeigt werde, muss nichts heißen.
wie wahrscheinlich ist es, dass ein ram ausgerechnet nach einem bios update stirbt
Tatsächlich ziemlich wahrscheinlich. die bios version beeinflusst die kompitabilität mit ram.
an einen live usb stick hab ich auch schon gedacht. ich hab einfach die sd card reingesteckt, wo noch das ubuntu image drauf ist, das ich eine woche zuvor installiert hab. aber leider bootet das system immer in grub, wo ich dann die wahl zwischen ubuntu, advanced options for ubuntu und uefi firmware settings hab. deaktivieren von secure boot hat leider auch nicht geholfen