Reboot nach cgdisk auf "aktiver" Disk erforderlich ?!?

Baut man öfter mal ein neues System oder hängt die Platten mal grad um, kann das zu Boot-Problemen führen.

Da ich liebend gerne eine Variante hätte, die es ermöglicht, quasi aus einem tarball heraus eine Installation vorzunehmen, die dann auch sauber mit ihrem /root bootet, sind Varianten mit UUID nicht so sinnig, weil ich die nicht wirklich beeinflussen kann.

Die Variante PARTLABEL in Verbindung mit der internen Kernel-Commandline (und dem geeigneten fstab Eintrag versteht sich) scheint mir die sinnigste Variante zu sein.

Dummerweise scheint cgdisk ein syncing-Problem zu haben, falls man die Physische Disc anpackt, auf der das aktuelle root liegt - oder isses der Kernel.

Nee - eher nicht der Kernel, mit cfdisk klappt dat.

Beispielsweise: 2 Platten im System sda und nvme0n1, gebootet von nvme0n1.

cgdisk auf sda losgelassen gibt mit ne gelabelte Part auf sda, die sofort verfügbar ist ( kein reboot)

cgdisk auf nvme0n1 losgelassen fordert reboot, cfdisk nicht, es sei denn vorher war cgdisk auf der Platte, dann kann das cfdisk auch nicht mehr syncen.

Das Gleiche gilt selbstverfreilich auch beim Boot von sda für sda.

Muss ich wirklich für alle eventülitöten erst die Partition mit cfdisk anlegen und mit [c]gdisk nur das PARTLABEL setzen oder ist das Probem zwischen meinen Ohren?

Oder überseh ich nur ne Option im Kernel, wobei sich dann die Frage stellt, wieso braucht [c]fdisk diese Option im Kernel nicht?

HJS

Quote from SHF

Die UUID kann auch einfach ändern.

zB. mit tune2fs oder swaplable einfach ändern.

Bei einem anderen Partitionstypen wird es mit dem entsprechenden Tools auch irgendwie gehen, denke ich.

Man sollte nie eine Partitionstabelle bearbeiten, solange eine der Partitionen noch gemountet ist.

Was ändert sich für eine gemountete Partition, wenn dahinter noch eine oder mehrere neue Partitionen angelegt wurden ?

cfdisk kennt das Problem nicht.

However, bei meiner Suche habe ich auch nach der Beeinflussung von UUID gesucht, dummerweise die Option datumsabhängig oder zufällig zu setzen gefunden, aber nicht den Hinweis, dass ich die UUID kurzerhand setzen kann - wo auch immer mich die Suche hinführte

Das erfüllt den Zweck natürlich genauso - Danke

HJS

Quote from SHF

Eigentlich würde auch ich, zumindest auf einigen Rechnern, gerne wieder auf /dev/sd... zurück zu gehen. Wenn man weiss, was man macht, hat das im handling auch einige Vorteile.

Der Nachteil ist die "feste Verdrahtung".

Installiere ich auf Sata vom Stick, ist bei der Installation der Stick sda, ist der Stick weg (was ja nach der Installation typisch ist), liegt root auf /sda.

Verweist mein fstab Eintrag auf sdb (die Sata Platte während der Installation, wars das schon, kleine Kernel Panic.

Oder bei Installation von CD:

Ich vergesse meinen Stick zu entfernen, der ist jetzt sda, statt der Sata Platte, das wars, kleine Kernel Panic

Ich mühe mich, meine Kernel so zu bauen, dass sie zumindest das rootfs ohne "fremde Hilfe" mounten können, also ohne initrd/initramfs.

Das führt zu Extrarunden, um auch von beliebigen Datenträgern (USB, Sata, Nvme) booten zu können, aber wenn mans ersma geblickt hat

HJS

Quote from SHF

Das Umstellen auf PARTLABEL habe ich vor einer Weile mal mit dem damals aktuellen Debian probiert.

So wirklich geklappt hat es aber nicht, da einige Skripte da nicht mit gemacht haben.

Ob es nach der Umstellung auf systemd besser geht müsste man mal probieren.

Glücklicherweise bevorzuge ich HJSLFS

PARTLABEL ist halt so lang oder so kurz wie gewünscht, nicht diese elend langen Zeichenketten in der fstab

HJS

Quote from SHF

Neben der Optik in der fstab lässt sich ein selbstausgesuchtes PARTLABEL auch geringfügig besser merken .

Abba nur geringfügig

Sodele, nach Exkurs über setzen der UUID schon beim formatieren der Platte, dem Anpassen der PARTUUID (da der Kernel numal nix mit der FSUUID anfangen kann), sich auch PARTLABEL mittels sfdisk auf einer Partition auf der aktuellen Root-Pladde setzen lässt, dem Vorteil der sich halt so ergibt, wenn FS Label und PARTLABEL identisch sind (refind zeigt FS Label) und der Feststellung das auch in der fstab "PARTLABEL=" zum gewünschten Erfolg führt, bin ich nu wieder beim Partlabel angekommen.

mit "root=PARTLABEL=<MyLabel> [rootwait]" als Kernelcommandline und "PARTLABEL=<MyLabel> ext4 default 1 1" in der fstab, isses schnurz wie oft ich welche pladde wohin schieb, entferne, dazusteck, von USB boote ... ES KLAPPT!

HJS