...
Da die Boot-Dateien, insbesondere die initrd, die nun alle möglichen Festplattenkontroller-Module mitbringt, deutlich größer sind (Kernel 3.16 ca. 7-8 MB, Kernel 4.9 12-14 MB), wird für die Bootvarianten eis, oldeis und gegebenenfalls auch die Fallback-Option mehr Platz in der Boot-Partition benötigt, als es ältere Installer eingerichtet haben. Zukünftige Installer werden für die Boot-Partition 96 MB vorsehen, wenn das Installationsmedium größer als 1 GB ist.
Ist die Bootpartition derzeit größer als zwischen etwa 43 MB und 50 MB groß, wäre ist bei Nutzung auch Installation von testing-Kernels eventuell kein Platz zum Anlegen einer Fallback-Bootoption auf den letzten stable Kernel vorhanden, für die beiden Boot-Optionen eis und oldeis als 4.9er-Kernel würde der Platz jedoch ausreichen. Ab etwa 50 MB Größe wäre ist auch für die Fallback-Bootoption vorläufig genügend Platz vorhanden. Es bestände also , es bestünde also in diesem Fall derzeit kein dringender Handlungsbedarf, die Boot-Partition zu vergrößern. Die Platzverhältnisse lassen sich mit folgenden Befehlen feststellen:
...
Empfehlenswert ist es, mit dem gparted-Programm vorher mal an einem in Partitionen unterteilten Stick zu üben.
Aktivierung der Festplatten-UUID
...
unter VMWare
Um Probleme beim Updaten es Kernels unter VMWare zu vermeiden, ist es notwendig dass der Parameter disk.EnableUUID = "TRUE" in der .vmx Datei eingetragen wird, bzw auf "TRUE" gesetzt wird. Hierzu sind folgende Schritte zu unternehmen:
To enable disk UUID on a virtual machine
Die auf 4.9.x basierenden eisfair-Kernel erfordern es, dass Platten und Partitionen eine eindeutige UUID erhalten. Das ist bei Virtualisierern von VMWare nicht immer gegeben. Bei einem Updates eines 3.x basierenden eisfair-Kernels auf einen 4.x basierenden eisfair-Kernel könnte deshalb folgende Fehlermeldung beim Update erscheinen:
Cannot convert boot device /dev/sda to /dev/disk/by-id/!
Um das Problem zu lösen, muss der .vmx-Datei des eisfair-Gastes folgende Option hinzugefügt bzw. diese auf "TRUE" gesetzt werden: disk.EnableUUID = "TRUE".
Hierzu sind für VMWare ESXi folgende Schritte zu unternehmen (Quelle: https://sort.veritas.com/public/documents/sfha/6.2/vmwareesx/productguides/html/sfhas_virtualization/ch10s05s01.htm):
- Gast herunterfahren.
- Gast auswählen und "Edit Settings" wählen.
- "Options" Tab selektieren.
- Wähle "General" unter "Advanced section".
- "Configuration Parameters" auf rechter Seite auswählen.
- Prüfe, ob der Parameter "disk.EnableUUID" vorhanden und auf "TRUE" gesetzt ist. Ist der Parameter nicht sichtbar, wähle "Add Row", füge ihn hinzu und setze in auf und setze in auf "TRUE".
Bei VMWare Workstation und sicherlich auch bei VMWare Player ist die .vmx-Datei nach Herunterfahren des Gastes und Erzeugen eines Schnappschusses von Hand zu editieren. Wenn die virtuelle Maschine eisfair heisst, existiert im Home-Verzeichnis des Users oder unter %userprofile%\documents\My Virtual Machines ein Verzeichnis eisfair und darin eine Datei eisfair.vmx, die zu editieren ist (Quelle: https://kb.vmware.com/s/article/2057902):
- Gast herunterfahren.
- In der Verzeichnis mit den Dateien der virtuellen Maschine wechseln.
- Öffnen der Konfigurationsdatei (.vmx) in einem Texteditor.
- Hinzufügen oder editieren der Zeile disk.EnableUUID = "TRUE".
- Abspeichern der Konfiguration und Texteditor beenden.
Benennung von Platten- und Partitions-Devices durch udev und daraus folgende Konsequenzen
...
Besitzt ein Rechner mehrere verschiedene Festplatten-Controller mit jeweils einer oder mehreren angeschlossenen Festplatten, können die Devicenamen sogar ineinander verwoben sein, z. B.: Controller 1 Platte 1 → /dev/sda, Controller 2 Platte 1 → /dev/sdb, Controller 1 Platte 2 → /dev/sdc, ..Controller 1 Platte 1 → /dev/sda, Controller 2 Platte 1 → /dev/sdb, Controller 1 Platte 2 → /dev/sdc, ...
Achtung: Skripte und Programme, die zukünftig weiterhin auf die Nutzung von sdX/sdXn-Devices konfiguriert sind, können hierdurch plötzlich auf eine ganz andere Platte schreiben, als dies beabsichtigt ist. Da sich die Device-Zuordnungen sogar zwischen Boots verändern können (Race Conditions bei der Device-Zuordnung durch udev) ist nicht kontrollierbar, welche Platte/Partition durch ein sdX/sdXn-Device angesprochen wird. Dis kann zum Totalverlust der Daten führen.
Im Folgenden sollen verschieden Fälle behandelt werden:
...
RAIDs werden schon bislang über die UUIDs assembliert, die sdX-Devices können sich aber zwischen/vor die Devices des RAIDs schieben. Für Überwachungsaufgaben/Monitoring wird man aber auch auf die einzelnen Member des RAIDs zugreifen wollen bzw. auf die weiteren Platten in Paketkonfigurationen, eigenen Skripten oder der /etc/fstab; für eine fixe Zuordnung empfiehlt sich daher die Nutzung der eindeutigen Devicenamen.
...
RAIDs werden schon bislang über die UUIDs assembliert, die sdX-Devices können sich aber zwischen/vor die Devices des RAIDs schieben. Für Überwachungsaufgaben/Monitoring wird man aber auch auf die einzelnen Member des RAIDs zugreifen wollen bzw. auf die weiteren Platten in Paketkonfigurationen, eigenen Skripten oder der /etc/fstab; für eine fixe Zuordnung empfiehlt sich daher die Nutzung der eindeutigen Devicenamen. Die USB-Platten reihen sich hinter den internen Platten ein, wobei man hier auch die eindeutigen Devicenamen in Paketkonfiguration, eigenen Skripten oder der /etc/fstab nutzen kann.
...