Moin. Folgendes Problem tut sich hier auf: Mir ist hier auf einem Dualbooter eine Festplatte gestorben. Also nur beginnend. Hab also eine neue gekauft, und das Ding geklont. Die Systeme sind auf separaten Datenträgern. Die kaputte Platte enthielt diverse Daten für W10 und auf einer separaten Partitition das Home-Verzeichnis von einer Mint19 Installation. Win10 läuft so halbwegs wieder, aber Linux ziert sich noch etwas. Mit anderen Worten: Linux startet nicht mehr. Bleibt im Startvorgang hängen. Wie kann ich die neue Partition als /home wieder einhängen? MfG Micha
MO schrieb: > Mit anderen Worten: Linux > startet nicht mehr. Besser als eine weitere Umschreibung wäre die konkrete Fehlermeldung und/oder -beschreibung gewesen. Daran könnte man sehen, woran es liegt, und wie es zu beheben wäre.
MO schrieb: > Wie kann ich die neue Partition als /home wieder einhängen? In dem du deine home-Partition in der fstab einträgst, die anscheinend beim Bootvorgang gemountet wird.
You are in emergency mode. After loggin in, type "journalctl -xb" to view system logs, "systemctl reboot" to reboot, "systemctl default" or "exit" to boot into default mode. Im Log steht :Timed out waiting for device dev-disc by\x2duuid.....device. Etwas abgekürzt. Subject ... has failed. Und dann wars das. MfG Micha
Du sohltest die uuid anpassen in der /etc/fstab die bekommst mit blkid raus das Rescue System scheint ja noch zu gehen mit dem du das machen kannst.
Sandfrog schrieb: > Du sohltest die uuid anpassen in der /etc/fstab die bekommst mit blkid > raus das Rescue System scheint ja noch zu gehen mit dem du das machen > kannst. Genau, das kann das Problem sein. Du schreibst ja (TO), dass du die Platte geklont hast, damit passt die UUID in der fstab nicht mehr. Sandfrog hat die Lösung bereits beschrieben.
Moin. Hab jetzt von USB nochmal gestartet und die fstab bearbeitet. Läuft. Hing nur an der UUID. Muss wohl am Druck liegen, das Lernsax laufen muss, wegen Halbjahreszensuren für die Absenker :-). Gut Nacht.
... schrieb: > Du schreibst ja (TO), dass du die > Platte geklont hast, damit passt die UUID in der fstab nicht mehr Das kommt drauf an. Ich habe eine Ubutu-Platte mit Acronis geklont und die UUID stimmte (war also mit übertragen worden). Also habe ich 2 Platten mit identischer UUID, aber ich benutze ja nur noch den Klon. Georg
Moin. Ja, Acronis hab ich ja auch genommen. Nur das sich die UUID halt geändert hat. Irgendwie hab ich angenommen, die würde mitgeklont. Aussetzer am Abend halt. Das Log hats ja auch schön rot markiert angezeigt. Nu geht wieder alles, hab den halben Vormittag Arbeitsblätter gescannt und PDFs gebaut. MfG Micha
Georg schrieb: > Das kommt drauf an. Ich habe eine Ubutu-Platte mit Acronis geklont und > die UUID stimmte (war also mit übertragen worden). Also habe ich 2 > Platten mit identischer UUID, aber ich benutze ja nur noch den Klon. Ernsthaft? Also, in UUID steckt ja eigentlich schon unique und so sollte das auch sein. Gleiche UUID kann zu unschönen Effekten führen, wenn man mit Klonen hantiert.
Beitrag #6557772 wurde vom Autor gelöscht.
Beitrag #6557787 wurde von einem Moderator gelöscht.
M.M.M schrieb: > Gleiche UUID kann zu unschönen Effekten führen, wenn man > mit Klonen hantiert Ich mache das ja nicht zum Spass, sondern um einen defekten Server zu ersetzen. Danke dass du mich als Idioten darstellst. Genauere Details dürften sinnlos sein, das würdest du sowieso nicht verstehen. Georg
Es geht übrigens auch klassisch ohne UUID. Dann muss man aber die Reihenfolge der Platten beachten, die kriegen ohne UUID dann nämlich ihre /dev/sdX Bezeichner der Reihenfolge nach zugewiesen. Die UUID wurde wegen den ganzen Wechselmedien, wie bspw. USB Sticks, Wechselplatten, Festplatten die man per eSATA oder USB anschließen kann usw. nötig. Damit das OS weiß, welchen /dev/sdX Bezeichner es einer bestimmten Platte zuweisen soll. Hat man nur stationäre Platten, dann könnte man auf die UUID somit eigentlich verzichten. Aufpassen muss man dann nur, wenn man ne Platte dazu steckt und die Reihenfolge wieder durcheinanderbringt.
Nano schrieb: > Hat man nur stationäre Platten, dann könnte man auf die UUID somit > eigentlich verzichten. Nein. Die Reihenfolge ist ausdrücklich nicht garantiert, und kann sich jederzeit ändern. Etwa bei ’nem Kernelupdate, bei einem BIOS-Update, bei Änderungen an der Hardware, die gar nichts mit den Datenträgern zu tun haben, und bei einigen Hardwarekonfigurationen auch ganz ohne erkennbare äußere Ursache. Es gibt im Grunde nur ein Szenario, bei dem man sicher auf UUIDs oder Labels verzichten kann: man hat nur genau ein festverbautes Laufwerk und kann sicherstellen, dass zum Bootzeitpunkt auch niemals andere Datenträger angeschlossen sind.
:
Bearbeitet durch User
Jack V. schrieb: > Nano schrieb: >> Hat man nur stationäre Platten, dann könnte man auf die UUID somit >> eigentlich verzichten. > > Nein. Die Reihenfolge ist ausdrücklich nicht garantiert, und kann sich > jederzeit ändern. Nochmal, hat man stationäre Platten.... Nach jedem Neustart bleibt bei einem unveränderten System die Reihenfolge gleich. > Etwa bei ’nem Kernelupdate, bei einem BIOS-Update, bei > Änderungen an der Hardware, Ein Kernelupdate macht da gar nichts. Ein BIOS Update normalerweise auch nicht, die Bootreihenfolge musst du dann natürlich wieder richtig wie vorher einstellen. Weitere Hardware ja, aber das sagte ich ja schon in meinem letzten Posting, dass man da dann aufpassen muss.
M.M.M schrieb: > Georg schrieb: >> Das kommt drauf an. Ich habe eine Ubutu-Platte mit Acronis geklont und >> die UUID stimmte (war also mit übertragen worden). Also habe ich 2 >> Platten mit identischer UUID, aber ich benutze ja nur noch den Klon. > > Ernsthaft? Also, in UUID steckt ja eigentlich schon unique und so sollte > das auch sein. Gleiche UUID kann zu unschönen Effekten führen, wenn man > mit Klonen hantiert. Aber Klon beinhaltet ja eigentlich auch, dass alles gleich ist, inklusive UUID. Ich finde das auch praktisch, gerade wenn man eine Platte ersetzt und die neue dann einfach funktioniert, weil die UUID die selbe ist. Natürlich könnte das Programm, mit dem man das Image erzeugt hat, auf die Idee kommen, die UUID durch eine neue zu ersetzen, aber dann würde auch ein Image, das man auf die selbe Platte zurückspielt, nicht mehr out of the box, was ärgerlich ist. Nano schrieb: > Nochmal, hat man stationäre Platten.... > Nach jedem Neustart bleibt bei einem unveränderten System die > Reihenfolge gleich. Meistens, ja. Aber eben nicht garaniert. > Ein Kernelupdate macht da gar nichts. > Ein BIOS Update normalerweise auch nicht, die Bootreihenfolge musst du > dann natürlich wieder richtig wie vorher einstellen. Die im BIOS eingestellte Bootreihenfolge hat nichts mit der Zuordnung der Laufwerke in /dev zu tun.
geht schon; mount-filesystem-in-certain-order-systemd https://www.golinuxcloud.com/mount-filesystem-in-certain-order-systemd/ (ist konkret zwar centos aber anderswo lauft es ähnlich) --- fstab geht immer, noch :/ ;) .... :) systemd (mint19?!) alike ist das weiter oben aber eher nicht. schätze mal die Meldung zu Beginn wird gelautet haben auf -- Unit dev-xxxxx.device has failed. dev-xxxx.device: Job dev-xxxx.device/start failed with result xy in der Art, die unitfiles zu systemd mount-points gammeln unter [/etc,...]/systemd/system eine fstab braucht das systemd ja eigentlich nicht. Wenn da nur ein vorhandener Eintrag angepasst wurde braucht man nicht weiter gucken, falls neu angelegt wird das systemd immer noch meckern. Funktionieren tut es nat.
M.M.M schrieb: > Georg schrieb: >> Das kommt drauf an. Ich habe eine Ubutu-Platte mit Acronis geklont und >> die UUID stimmte (war also mit übertragen worden). Also habe ich 2 >> Platten mit identischer UUID, aber ich benutze ja nur noch den Klon. > > Ernsthaft? Also, in UUID steckt ja eigentlich schon unique und so sollte > das auch sein. Gleiche UUID kann zu unschönen Effekten führen, wenn man > mit Klonen hantiert. Geänderte UUID kann ebenfalls zu unschönen Effekten führen, wenn man mit Klonen hantiert. Siehe Ursprungsposting... Um Probleme zu vermeiden sollte man generell einfach wissen was man tut, anstatt z.B. zu sagen "UUID muss immer unique sein"...
Nano schrieb: > Nochmal, hat man stationäre Platten.... > Nach jedem Neustart bleibt bei einem unveränderten System die > Reihenfolge gleich. Nochmal: nein, darauf kann man sich ausdrücklich nicht verlassen. Nano schrieb: > Ein Kernelupdate macht da gar nichts. Wie seltstam, dass genau der Fall vor zwei Wochen das letzte Mal in ’nem einschlägigen Distributionsforum aufgeschlagen ist – darf ja gar nicht sein, wenn’s nach dir ginge? Geht’s aber offensichtlich nicht …
:
Bearbeitet durch User
Man muss als Identifier nicht unbedingt die UUID nehmen, es geht auf die Partitionsbezeichnung, Beispiel einer fstab:
1 | # <file system> <mount point> <type> <options> <dump> <pass> |
2 | /swapfile none swap sw 0 0 |
3 | LABEL=sys017 / ext4 errors=remount-ro 0 1 |
4 | LABEL=dat017 /home ext4 defaults 0 2 |
sys017 und dat017 sind die jeweiligen Partitionsnamen.
Jack V. schrieb: > Nano schrieb: >> Nochmal, hat man stationäre Platten.... >> Nach jedem Neustart bleibt bei einem unveränderten System die >> Reihenfolge gleich. > > Nochmal: nein, darauf kann man sich ausdrücklich nicht verlassen. Ich habe einen Server mit 5 SATA HDDs an 2 Controllern. Wo sich die Bootplatte am Einzelcontroller einreiht, ist bei jedem Boot anders. Schön abwechselnd.
bingo schrieb: > Man muss als Identifier nicht unbedingt die UUID nehmen > ... > sys017 und dat017 sind die jeweiligen Partitionsnamen. Nenn' sie ruhig Label, soviel denglisch muss sein. Bei Partitionsnamen denke ich, dass da immer noch irgendetwas dahinter steckt. Das gute an Label ist ja gerade, dass ich selbst lesbare und merkbare Namen vergeben kann -- ganz ohne Automatik. Und beim Booten und in der fstab funktioniert label genauso wie uuid.
:
Bearbeitet durch User
Rolf M. schrieb: > Nano schrieb: >> Nochmal, hat man stationäre Platten.... >> Nach jedem Neustart bleibt bei einem unveränderten System die >> Reihenfolge gleich. > > Meistens, ja. Aber eben nicht garaniert. Doch, solange das System unverändert bleibt, bleibt die Zuweisung immer gleich. Wenn es anders ist, dann hast du was verändert. Z.B. USB Stick beim letzten mal reingesteckt und vergessen wieder rauszuziehen. Wäre es anders, dann hätte man so etwas wie eine UUID schon vor 30 Jahren einführen müssen. > >> Ein Kernelupdate macht da gar nichts. >> Ein BIOS Update normalerweise auch nicht, die Bootreihenfolge musst du >> dann natürlich wieder richtig wie vorher einstellen. > > Die im BIOS eingestellte Bootreihenfolge hat nichts mit der Zuordnung > der Laufwerke in /dev zu tun. Das hängt ganz davon ab wie die Geräten angebunden sind. Sowie ob UEFI oder BIOS.
Jack V. schrieb: > Nano schrieb: >> Nochmal, hat man stationäre Platten.... >> Nach jedem Neustart bleibt bei einem unveränderten System die >> Reihenfolge gleich. > > Nochmal: nein, darauf kann man sich ausdrücklich nicht verlassen. Es hat früher in den 90ern bei statischen Systemen funktioniert. Da gab's keine UUID, also rede keinen Unsinn. > Nano schrieb: >> Ein Kernelupdate macht da gar nichts. > > Wie seltstam, dass genau der Fall vor zwei Wochen das letzte Mal in ’nem > einschlägigen Distributionsforum aufgeschlagen ist – darf ja gar nicht > sein, wenn’s nach dir ginge? Geht’s aber offensichtlich nicht … 1. Quelle angeben und 2. der Typ hat sicher mehr gemacht als nur ein Kernelupdate. Das Problem sitzt bekanntlich vor dem Bildschirm.
Nano schrieb: > Doch, solange das System unverändert bleibt, bleibt die Zuweisung immer > gleich. > […] > Wäre es anders, dann hätte man so etwas wie eine UUID schon vor 30 > Jahren einführen müssen. Es wurde nicht ganz zwanzig Jahren eingeführt, und die feste Devicezuordnung verschwand mit der Einführung von udev. Du solltest den Knopfler von anno 1995 mal durch etwas Aktuelleres ersetzen. Nano schrieb: > 1. Quelle angeben debianforum.de Nano schrieb: > 2. der Typ hat sicher mehr gemacht als nur ein Kernelupdate. Das Problem > sitzt bekanntlich vor dem Bildschirm. … und das behauptest du, obwohl du den betreffenden Thread nicht kanntest. Nun ja … :D (er hat aber tatsächlich mehr gemacht, nämlich sein System auf Testing gezogen. Dafür ist die Reihenfolge nun nicht mehr fix, sondern ändert sich wohl je nach Sonnenstand beim Booten – das Verhalten dürfte deiner antiquierten Informationslage nach ja auch nicht auftreten, oder?)
:
Bearbeitet durch User
Nano schrieb: >> Nochmal: nein, darauf kann man sich ausdrücklich nicht verlassen. > > Es hat früher in den 90ern bei statischen Systemen funktioniert. Da > gab's keine UUID, also rede keinen Unsinn. In meinem obigen Beispiel pendelnder Nummerierung handelt es sich um verschiedene SATA Modi. 1x IDE und 4x AHCI. Also sind es wohl auch verschiedene Treiber.
Nano schrieb: > Wäre es anders, dann hätte man so etwas wie eine UUID schon vor 30 > Jahren einführen müssen. Vor 30 Jahren lief manches streng sequentiell, was heute parallel stattfindet.
Nano schrieb: > Wenn es anders ist, dann hast du was verändert. Z.B. USB Stick beim > letzten mal reingesteckt und vergessen wieder rauszuziehen. Wobei ich es nervig finden würde, wenn mein System nicht mehr bootet, weil irgendwo noch ein USB-Stick drin steckt und die Laufwerksreihenfolge dadurch durcheinander kommt. > Wäre es anders, dann hätte man so etwas wie eine UUID schon vor 30 > Jahren einführen müssen. Nur dass es halt damals noch keine dynamische Adresszuweisungen gab. Der erste IDE-Controller war z.B. immer fix per Jumper auf I/O-Adresse 0x1F0 gestellt. Dehalb war /dev/hda immer der Master an dem Controller mit eben dieser Adresse. Da konnte sich keine Reihenfolge ändern.
(prx) A. K. schrieb: > Nano schrieb: >>> Nochmal: nein, darauf kann man sich ausdrücklich nicht verlassen. >> >> Es hat früher in den 90ern bei statischen Systemen funktioniert. Da >> gab's keine UUID, also rede keinen Unsinn. > > In meinem obigen Beispiel pendelnder Nummerierung handelt es sich um > verschiedene SATA Modi. 1x IDE und 4x AHCI. Also sind es wohl auch > verschiedene Treiber. Und da liegt dann wohl auch die Ursache begraben. Durch systemd, der asychronen Ausführung von verschiedenen Prozessen werden die wohl zu unterschiedlichen Zeiten geladen.
Nano schrieb: > Durch systemd, Das war bei der Kiste allerdings von Anfang an so. HP Microserver N36L. In Debian vor bald einem Jahrzehnt. Also nicht systemd anzulasten. > der asychronen Ausführung von verschiedenen Prozessen Ist auch meine Vermutung.
:
Bearbeitet durch User
(prx) A. K. schrieb: > Nano schrieb: >> Durch systemd, > > Das war bei der Kiste allerdings von Anfang an so. HP Microserver N36L. > In Debian vor bald einem Jahrzehnt. Also nicht systemd anzulasten. > >> der asychronen Ausführung von verschiedenen Prozessen > > Ist auch meine Vermutung. Meine auch. Ich hatte das Problem mit sich ändernden Devicenamen bei Linux erstmals bei Netzwerkkarten gehabt. Das muss ca 2005 herum gewesen sein. Meiner Erinnerung nach änderte es sich zwar nicht bei jedem booten, aber bei Kernel-Updates, auch wenn es nur kleine Updates waren. Von da hatte ich in Erinnerung behalten, dass der Kernel die Zuordnungen von Gerät zu Name explizit nicht garantiert, sondern sie bei jedem Booten anders sein können. Eine persistente Zuordnung von Geräten zu Namen ist dagegen Aufgabe von udev. Wie ja andere schon geschrieben war das früher mal anders, aber wie gesagt, seit mindestens etwa 2005 herum garantiert der Kernel selbst die Zuordnung nicht mehr.
Nee nicht durch systemD das kann dafür nichts IDE vs. SCSI IDE zwei Lw/bus, mehr ging halt auch nicht hda ist der Master des ersten hdc des zweiten, hde des dritten, ... Wenn zb. IDE 1 nicht belegt aber ein LW an pos2 von IDE2 -> hdd fix auch wenn eines oder zwei an IDE1 da zukomen klassisch SCSI 0-7 o. wide 0-15 enum scsi in der Reihenfolge des Anschluss Gerät mit SCSI ID 0, 3, u. 5. -> sda, sdb, und sdc jetzt eines vor 3 dazugeklemmt dann wird das neue als sdb eingereiht und aus Gerät ID3 wird sdc und aus dem mit der ID5 sdd .... und heute noch verwende IDE interfaces werden durch über den scsi Treiber bedient.
1 | bspw. 4 Lw | jetzt noch eines dazu |
2 | |
|
3 | 0 | stick,whatever -> sda |
4 | 1 lw1 -> sda | -> sdb |
5 | 2 | |
6 | 3 lw2 -> sdb | -> sdc |
7 | 4 lw3 -> sdc | -> sdd |
8 | 5 | |
9 | 6 | |
10 | 7 lw5 -> sdd | |
11 | 8 | |
12 | 9 | |
weshalb und warum ... Die Namen und wie man das ansprechen kann ist nochmals was anderes falls udisk, mal ggf. udislkkctl dump da findet man u.A. zu jedem LW und. Partition die Namen /dev/disk/by-id/... /dev/disk/by-partuuid/... /dev/disk/by-path/... /dev/disk/by-uuid/... und das wiederum erlaubt einem Reihenfolge zu erzwingen.
Beitrag #6560172 wurde von einem Moderator gelöscht.
Beitrag #6560175 wurde von einem Moderator gelöscht.
Klaus schrieb im Beitrag #6560172:
>1 | C-Code |
schrieb: >> zu hastig, udisksctl dump > > Was bedeutet das Dump? #man udisksctl dump Prints the current state of the daemon. ---- hist. ~ sysvinit|hal| ..... -> udev -> udisks http://storaged.org/doc/udisks2-api/latest/udisks.8.html
1 | C-Code |
schrieb: > Nee nicht durch systemD das kann dafür nichts Das ist erstmal vollkommen korrekt. >
1 | >
|
2 | > bspw. 4 Lw | jetzt noch eines dazu |
3 | > | |
4 | > 0 | stick,whatever -> sda |
5 | > 1 lw1 -> sda | -> sdb |
6 | > 2 | |
7 | > 3 lw2 -> sdb | -> sdc |
8 | > 4 lw3 -> sdc | -> sdd |
9 | > 5 | |
10 | > 6 | |
11 | > 7 lw5 -> sdd | |
12 | > 8 | |
13 | > 9 | |
14 | >
|
15 | >
|
Genau das ist der springende Punkt, Das Bootlaufwerk hat immer das Potential, alles andere durcheinander zu bringen.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.