Fedora22 wird von einem nicht aktiven USB-Laufwerk gebootet

373
Kendrick

Ich versuche, Fedora auf einem Flash-Laufwerk zu installieren und dann von einem PC aus zu booten, der nicht besonders zugänglich ist. Ich habe versucht, alles auf Label zu setzen, um an der UUID-Ausgabe vorbeizukommen. Ich bekam es zur Fehlermeldung no / dev / disk / by-label / ... sah und Dracut hatte keine / dev / disk / by-label oder die Raw-Disk-Knoten / dev / sda1 Irgendwelche Vorschläge, wie das geht Bringe die Label-Option zurück, um herauszuschneiden, wäre zu begrüßen. Ich vermute, das Hinzufügen / Erzwingen eines Moduls oder etwas für die durchgeführte Umgestaltung, aber ich habe noch keine hilfreichen Informationen in diesem Bereich gefunden.

Die Möglichkeit, von einem internen Flash-Laufwerk statt eines kostspieligeren SSD-Laufwerks zu booten, ist, was ich für Geschwindigkeit erhoffe, nicht so sehr ein Interesse wie keine beweglichen Teile ...

0

1 Antwort auf die Frage

1
Tom Yan

Sie müssen die USB-Speichertreiber in das initramfs (dracut) aufnehmen. Das hängt vom Typ Ihres Controllers ab. Für moderne Computer möchten Sie wahrscheinlich xhci-pci, ehci-pci, uas und ihre Abhängigkeiten (z. B. xhci-hcd, ehci-hcd, usb-storage ... was ich vermute, dass dracut automatisch ziehen würde?)

Übrigens bin ich mir nicht sicher, über welches "Problem" Sie sprechen. Aber FWIW, es ist nichts falsch daran, UUID zu verwenden, um ein Laufwerk zu finden. Ich hoffe, Sie sprechen nicht über die falsche Idee, die ein dummer Kerl auf Youtube angesprochen hat, dass UUID in Linux oder überhaupt nicht wirklich unterstützt wird. LABEL kann auch verwendet werden, wenn Sie LABEL als Root-Dateisystem eingestellt haben. Verwechseln Sie UUID / PARTUUID und LABEL / PARTLABEL jedoch nicht. Tom Yan vor 8 Jahren 0
fedora22 erkennt Flash-Laufwerke, ist jedoch für die Installation um die UUID von Partitionen herum eingerichtet. Diese UUIDs sind "sicher", dh portieren Sie nicht auf einen anderen Computer, wodurch ein tragbares Flash-Laufwerk unbrauchbar wird. Ich brauche / dev / sda1 wieder in den Boot-Optionen, aber ich konnte nicht herausfinden, wie Label oder Partitionen wieder zu Dracut-basierten Boot-Images hinzugefügt werden. Ich habe versucht zu spiegeln, was in centos7 gemacht wurde, da es standardmäßig portabel ist und standardmäßig / dev / sda1 verwendet. Kendrick vor 8 Jahren 0
"sichern"? Worüber redest du? fs uuid bleibt solange bestehen, wie das Dateisystem intakt ist (dh, wenn Sie die Partition nicht mit mkfs. * neu formatieren). Im Gegenteil, / dev / sdX ist nicht persistent. Ihr USB-Laufwerk könnte beispielsweise als Sda auf Maschine A und als SSB auf Maschine B erscheinen (tatsächlich kann es zwischen Booten auf derselben Maschine wechseln). es hat auch nicht viel mit dracut zu tun, aber der root = Kernel-Parameter Ihres Bootloader-Eintrags. Tom Yan vor 8 Jahren 1
konsequent auf diesem PC allein. Es verwendet Informationen aus den Quellen bios / pci / etc ... im PC, von denen Sie booten, um die UUID zu generieren. Es ist wie ein Fingerabdruck. Auch wenn Sie einen Finger auf den Finger einer anderen Person kleben, ist der Fingerabdruck auf jeder Hand der einzelnen Personen immer noch derselbe. Ich kann Screenshots machen, um zu beweisen, dass das Erstellen eines fc22-Images in einer virtuellen Maschine auf einem Flash-Laufwerk nicht funktioniert, da uuid zwischen Systemen wechselt. Es scheint, als würden sie es benutzen, wie Microsoft das sichere Boot-Zeug macht. Kendrick vor 8 Jahren 0
Sie haben einfach eine falsche Vorstellung von UUID. Es wird einfach zufällig auf mkfs generiert und im Header des Dateisystems gespeichert. Tom Yan vor 8 Jahren 1
Beispielsweise: http://git.kernel.org/cgit/fs/ext2/e2fsprogs.git/tree/misc/mke2fs.c?h=v1.42.13#n2646; Bei FWIW können Sie stattdessen auch eine UUID angeben. Tom Yan vor 8 Jahren 1
nach dem generieren des bootfähigen linux-flash-laufwerks in der vm war die uuid der partition 54 ... beim booten einer live-cd auf dem physischen pc nach dem booten fehlgeschlagen, weil root @ 54 nicht gefunden wurde ... live-cd würde die uuid lesen auf der partition und es wäre 67 .... nicht 54 wie auf der vm. Kendrick vor 8 Jahren 0
mit "54 ..." und "67 ..." meinen Sie lange Zeichenfolgen wie folgt: `de305d54-75b4-431b-adb2-eb6b9e546014", richtig? Wie genau haben Sie die UUID des FILESYSTEM (nicht die Partition, es sei denn, Sie meinen PARTUUID) in BEIDEN CASE geprüft? `blkid` /` lsblk -f`? Haben Sie sichergestellt, dass Sie dasselbe Laufwerk überprüfen (z. B. `lsusb.py '; sda in der VM bedeutet nicht, dass es sda in der physischen Maschine ist). Bedenken Sie nur, dass UUID nicht so funktioniert, wie Sie es bereits erwähnt haben. UUID ist sinnlos. Die "Veränderung", die Sie bemerkt haben, ist höchstwahrscheinlich auf ein paar Pebkac zurückzuführen. Tom Yan vor 8 Jahren 0
Wenn ein Dateisystem nicht über die UUID gefunden wird, bedeutet dies nicht notwendigerweise, dass die UUID geändert wird. Wie bereits erwähnt, benötigen Sie in den initramfs die erforderlichen Treiber (die aufgrund von virtuellen oder physischen Änderungen der Maschine eine Variable sein können), damit das Laufwerk richtig erkannt und geprüft werden kann Finde das Dateisystem. Tom Yan vor 8 Jahren 0

Verwandte Probleme