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
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.
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.
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 …
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.
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?)
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.
(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.4Lw|jetztnocheinesdazu
2
|
3
0|stick,whatever->sda
4
1lw1->sda|->sdb
5
2|
6
3lw2->sdb|->sdc
7
4lw3->sdc|->sdd
8
5|
9
6|
10
7lw5->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.
