[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Effekte, die nicht gefallen



Sascha Reißner wrote:
Am Sonntag, den 31.03.2013, 23:44 +0200 schrieb Thomas Schmidt:
Ulf Volmer wrote:
On Sun, Mar 31, 2013 at 07:36:52PM +0200, Thomas Schmidt wrote:
Zweites Debian zu Bestehendem installiert:
Die Partitionen bekommen neue UUIDe.
Alte Installation hängt rettungslos.
Kann ich so nicht bestätigen.
Freut mich.
Sollte dich eigentlich verwundern, nachdem es bei dir anscheinend anders
ist.
Zur Information: Die UUID steht im Filesystem.

Soweit klar.

Wenn du ein FS verkleinerst oder vergrösserst bleibt die UUID erhalten.

Auch klar.

Auch wenn du die Festplatte/SSD an einen anderen Port oder gar Controler
hängst, bleibt die UUID die selbe.

Wenn die Teil des FS ist, klar.

Wenn du ein FS mit dd auf eine andere Partition kopierst, bleibt die
UUID ebenfalls gleich.

Sehr gut.

Die UUID ändert sich nur, wenn du ein neues FS erzeugst (formatieren)
oder absichtlich eine andere UUID zuweist (tune2fs).

Und da ist der Wurm begraben. Ein tune2fs geschah nicht, aber da der Rechner völlig perfekt hängenblieb, wurde eine andere partition wohl oder übel von der CD her formatiert. Aber nur die eine, selbstverständlich blieben andere unberührt, aber nicht deren UUID.
Wurden beim Formatieren einfach alle UUID neu zugewiesen,  a l l e ?
Jedenfalls, UUID auf der jeweiligen partition, Teil des filesystems
dort, wurden also nicht versucht, herauszufinden.

Wenn Du wirklich paralell installierst,
also alte Installation auf sda1, neue auf sda2, wird die alte Installation
_nicht_ angefasst, auch die UUIDs bleiben erhalten.
So ist es, genau so. Nur hat sich die neue Installation in
/dev/disk/by-uuid was Neues einfallen lassen und damit ging die alte
aber nicht mehr.
In /dev/disk/by-uuid lässt sich keine Installation etwas einfallen.
Genau genommen gibt es dieses Verzeichnis garnicht, da es virtuell ist.

Also miserable Ausdrucksweise meinerseits.

Als Beweis:
# mount -o bind / /mnt
# ls -l /mnt/dev

Soweit auch klar.

Nichtmal das Verzeichnis disk existiert wirklich.

Auch hier nicht :-)

Der Daemon udev sammelt die Informationen beim Start und blendet diese
an dieser Stelle nur ein. Sehen kannst du das mit mount.
Es sollte eine Zeile wie diese dabei sein:
$ mount
udev on /dev type tmpfs (rw,mode=0755)

Ist natürlich auch da. (Ich kümmere mich noch einmal um udev)

Erster Eintrag bei der alten Installation:
8fed55b4-998c-49b9-80e1-7420c50dcb17  da war noch zu erkennen, daß sda1
gemeint war, laut fstab alt
Erster Eintrag bei der neuen Installation in dev/disk/by-uuid
0cbcfd2f-f3b4-4c77-9c40-1198f47f9705
435822d7-43a2-47fd-a811-44b13eced188 bei fstab neu für sda1, aber
da steht das an vierter Stelle. Aber immerhin etwas, wenn auch
sehr unlogisch an vierter Stelle. Dieser Eintrag fehlt in
fstab alt. Deswegen kein Start.
Die Reihenfolge wie du sie siehst (ich vermute mal du schaust mit ls
nach) ist aufsteigend sortiert. Welche Partition mit welcher UUID
gemeint ist, siehst du mit ls -l /dev/disk/by-uuid.
Dann siehst du auch, daß die Einträge nur symbolische Links sind, die
auf die entsprechenden Partitionen zeigen.

Uh, das bringt's!
Das ist der Hinweis!
Hervorragend, danke.
Kaum macht man's richtig, schon funktioniert's.
Aber da kommt schon noch was:
Ich habe mit der alten Installation zu starten versucht und die stoppte mit busybox. Von grub gab es zwar die richtige partition, aber da weitere einzubinden waren, blieb eben nur busybox, fsck stoppte.
Und da ging mit ls -l herzlich wenig. Es blieb nur chroot von der
neuen Installation und da kamen die verschiedenen UUIDe zum Vorschein.
Mit gitfm. Die Hinweise seitens ls -l gingen da nicht hervor.
Schande, über mein Bequemlichkeit.

Ich möchte nicht irgendwelche UUIDe irgendwo einhängen!
Du sollst auch nicht irgendwelche UUIDs irgendwo einhängen, sondern die
richtigen UUIDs an den richtigen Stellen.

:-) Mach ich sicher nicht .-)

Noch besteht ein Problem bei /etc/network/interfaces,
Zuordnen von zwei Netzwerkkarten schlägt unerbittlich
fehl.
Kann ich ebenfalls nicht bestätigen.
Freut nch auch für dich .-)
Zeig doch bitte mal die Datei und bitte
auch die dazugehörigen Fehlermeldungen (ifup $DEVICE)
# ifup eth0
ifup: interface eth0 already configured
# ifup eth1
ifup: interface eth1 already configured
na das ist ja nicht so faszinierend, das weiß ich ja, das ist ja von der
alten Installation.
Natürlich bringt da "ifconfig" oder "ip addr show"
auch nichts, weil das ja bestens werkt, da wird ja auch
/etc/network/interfaces ordentlich berücksichtigt.
Ich vermute du meinst deine Netzwerkkarten haben andere Bezeichnungen.

Exakt.

Das lässt sich leicht anpassen. Auch die Netzwerkbezeichnungen vergibt
udev und legt diese, beim Erkennen eines neuen Interfaces, in der
Datei /etc/udev/rules.d/70-persistent-net.rules ab.

Jetzt reichts, als erstes sofort udev anschaun, Aber gründlich :-)
Und das ärgert mich jetzt auch, weil ich mich glaube erinnern zu können, daß das Thema schon einmal hier über die Bühne ging. Eine Entschuldigung finde ich jetzt wirklich angebracht, was ich hiemit mache.

Durch diese Datei wird sichergestellt, daß bei jedem Systemstart die
Interfaces immer die selbe Bezeichnung erhalten.

Drum war das /etc/network/interfaces derart dürftig, ja erbärmlich.

Da du ein neues System installiert hast, waren die Interfaces für udev
neu und er vergab die Bezeichnungen der Reihe nach.

udev hätte aber schon fragen können :-) Wenigstens.

Damit im neuen System die Interfaces die selben Bezeichnungen wie im
alten System haben, übertrage die Information aus dem alten in das neue
System. Es ist recht einfach.

Stimmt!

In dieser Datei findest du in jeder Zeile
die MAC-Adresse und die zugewiesene Bezeichnung. Du musst nur darauf
achten, daß das Interface mit einer MAC-Adresse wieder die selbe
Bezeichnung zugewiesen bekommt wie im alten System.

Wirklich eine Kleinigkeit.

Sollten deine Probleme doch anders liegen, bitte ich um mehr Information
damit wir besser feststellen können wo der Hund begraben liegt.

Ich muß nur noch die hektische Konfiguration mittels DHCP von dem nächsten DHCP-server abstellen, der nicht wirklich fest zuweisen kann.

PS: grub2 hat Probleme mit 2 root-Partitionen, genaugenommen die Scripte
hinter update-grub.
Habe selber zuhause ein 32bit-root (squeeze) und ein 64bit-root
(wheezy). grub2 verwende ich aus wheezy. Im squeeze ist kein grub
installiert.
Bei update-grub (im wheezy) trägt er zwar beide im Menü ein (Menüeintrag
ist korrekt), aber die UUID der 32bit-root-Partition stimmt nicht. Dort
trägt er ebenfalls die UUID der 64bit-root-Partition ein.
Ich ändere das dann immer händisch, damit ich mit dem 32bit-System
wieder booten kann.

Handwerk hat *** auch hier geholfen :-)
Nicht rasend elegant, einfach mit
/dev/sda1   /  und gut war's.
Nur, das kann es ja wohl nicht sein, oder?

Jedenfalls bedanke ich mich ganz herzlich zuallererst für den freundlichen Umgangston, dann natürlich für die Geduld beim Lesen und last bur not least für die hervorragende und leicht verständlichen Erklärungen.

--
Herzliche Grüße

Schmidt Thomas


Reply to: