Mit der neuen Kernelserie 4.9 wird es einige grundlegende Änderungen und weitergehende Möglichkeiten geben.
Die Bootdateien des neuen Kernels nutzen schon udev und bringen außerdem alle möglichen Module für Festplatten-Controller mit. Dadurch kann eine Installation ohne Änderung der initrd auf eine neue Hardware übertragen werden und sollte dort problemlos booten.
Dadurch werden allerdings die Bootdateien viel größer als bisher, wodurch der Platz in /boot eng werden kann. Gegebenenfalls muss mittels entsprechender Tools die boot-Partition vergrößert werden.
Es werden prinzipiell nur zwei Varianten der initrd erzeugt, je nachdem, ob das spätere Bootmedium eine interne Platte oder ein USB-Stick ist:
Im ersten Fall werden die Module usb-storage und uas blacklisted, damit sich Devices eventuell angeschlossener USB-Sticks/Platten nicht zwischen die Devices der internen Platten schieben können; insbesondere könnte es sonst passieren, dass sich ein USB-Device zwischen die Platten eines RAIDs drängelt. Die Module usb-storage und uas werden in diesem Fall erst nach der Durchlaufen der initrd im Init-Prozess geladen.
Im zweiten Fall werden die Module usb-storage und uas nicht blacklisted, da sie beim Booten für den Zugriff auf das auf USB installierte System benötigt werden.
Mit dem Base-Update 2.8.18 wurde die fstab derart angepasst, dass die Partitionen der Boot-Platte (boot, swap und root) mittels UUID gemountet werden, so dass der Boot nicht davon abhängt, wie udev die sdX-Devices auf die physikalischen Platten verteilt. Eine entsprechende Konvertierung auf eindeutige Platten- und Partitions-UUIDs der /etc/lilo.conf nehmen die aktuellen Kernelpakete beim Update vor.
Mit dem Kernel 4.9 entfällt das alte fest in den Kernel integrierte IDE-Modul und somit nun auch die hdX-Devices. IDE-Devices werden nun auch von den libata basierten Modulen behandelt, womit diese zu sdX-Devices werden. Dies kann auf Systemen, die bislang hdX- und sdX-Devices hatten, zu Verschiebungen führen.
Verfügbare Modulpakete für passive ISDN-Geräte/Karten von AVM
Für den 4.9er-Kernel werden folgende AVM-Modulpakete zur Verfügung stehen:
- avm_fritz-1_pci
- avm_fritz_usb2x
Vergrößerung der boot-Partition
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 etwa 43 MB, wäre bei Nutzung auch 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 auch für die Fallback-Bootoption vorläufig genügend Platz vorhanden. Es bestände also derzeit kein dringender Handlungsbedarf, die Boot-Partition zu vergrößern. Die Platzverhältnisse lassen sich mit folgenden Befehlen feststellen:
# df -h Filesystem Size Used Avail Use% Mounted on /dev/md3 16G 2.6G 13G 18% / tmpfs 4.0G 440K 4.0G 1% /run devtmpfs 4.0G 4.0K 4.0G 1% /dev /dev/md1 49M 32M 14M 71% /boot /dev/md4 442G 25G 395G 6% /data tmpfs 4.0G 0 4.0G 0% /run/shm
In diesem Beispiel wären in /boot von 49 MB nun 32 MB belegt, wobei dies in diesem Beispiel zwei 4.9er-Kernel (eis und oldeis) und ein Fallback auf den vorigen stable Kernel 3.16.74 sind:
# ls -l /boot total 31010 -rw-r--r-- 1 root root 512 May 26 2004 boot.0300 -rw-r--r-- 1 root root 512 Nov 7 2012 boot.0800 -rw-r--r-- 1 root root 512 Nov 7 2012 boot.0810 -rw-r--r-- 1 root root 512 Oct 6 09:28 boot.0820 -rw-r--r-- 1 root root 512 Nov 7 2012 boot.0901 -rw-r--r-- 1 root root 4368 May 26 2004 boot.b -rw-r--r-- 1 root root 3693026 Oct 15 18:34 initrd-3.16.74-PAE.gz -rw-r--r-- 1 root root 8735951 Nov 26 06:39 initrd.gz -rw-r--r-- 1 root root 3583712 Nov 26 06:39 kernel -rw-r--r-- 1 root root 3055072 Oct 15 18:34 kernel-3.16.74-PAE drwx------ 2 root root 12288 Nov 7 2012 lost+found -rw------- 1 root root 328704 Nov 26 06:40 map -rw-r--r-- 1 root root 8747036 Nov 6 06:59 old-initrd.gz -rw-r--r-- 1 root root 3583712 Nov 6 06:59 old-kernel
Mittels gparted (https://gparted.org/livecd.php) kann boot auf Kosten der anderen Partitionen vergrößert werden. Auf einer Standard eisfair-Installation mit boot (1. Partition), swap (2. Partition) und root (3. Partition) könnte man mittels gparted die swap-Partition am Anfang um einige MB verkleinern und diese dann der boot-Partition zuschlagen. Ohne swap-Partition muss man den notwendigen Platz durch Verkleinern der root-Partition freiräumen. Eine Kurzanleitung zu gparted hat Heise/c't als Tipp und Trick https://www.heise.de/tipps-tricks/Linux-Partition-vergroessern-4164154.html veröffentlicht.
Auch wenn gparted selbst bei richtiger Anwendung perfekt funktioniert, ist ein Image der Platte Pflicht, denn Bedienfehler, Rechnerabstürze oder Stromausfälle kann auch gparted nicht ungeschehen machen!
Diese Anleitung gilt nur für normale und nicht für RAID-Systeme, bei denen die Systempartitionen von eisfair auf einem RAID liegen! Thomas Zweifel hat in der Newsgroup eine Anleitung zur Vergrößerung für diesen Fall geschrieben: https://web.nettworks.org/forum/index.php?t=msg&th=10264&goto=75599&#msg_75599
Liegen die Systempartitionen jedoch auf einer einzelnen Platte und das RAID ist zusätzlich z. B. als Datenablage vorhanden, kann diese Anleitung verwendet werden.
Den eventuell hinter der letzten Partition befindliche Freiraum ist Absicht, insbesondere wenn er etwa 10 MB groß ist. Diesen niemals der vorhergehenden Partition zuschlagen! Am besten verändert man den rechten Rand der letzten Partition nicht.
Jede zu bearbeitende Partition (außer swap) vorher überprüfen (fsck), was in der gparted-Oberfläche als Aktion gemacht werden kann.
Auch wenn inzwischen manche Operationen sogar im gemounteten Zustand möglich sind, rate ich dringend dazu, alle Aktionen nur bei ungemounteten Partitionen durchzuführen.
Im folgenden eine Schritt für Schritt Anleitung zur Vergrößerung der boot-Partition (/dev/sdX1) auf Kosten der swap-Partition (/dev/sdX2), natürlich ohne jede Gewähr; sdX bezeichnet hier und im folgenden das Device der Platte, wie es in gparted erscheint:
- Booten des gparted-Livesystem von CD-Rom oder USB-Stick. Nach Aufbau des Desktop startet gparted mit root-Rechten automatisch.
- Wähle aus der Schaltfläche am rechten oberen Bildschirmrand die richtige Platte aus.
- Mit Rechtsklick auf die Partition /dev/sdX1 das Kontextmenü aufrufen, "Überprüfen" auswählen und mit dem "Anwenden"-Button durchführen.
- Mit Rechtsklick auf die Partition /dev/sdX2 das Kontextmenü aufrufen, "Größe ändern/Verschieben" auswählen.
- Nun wenden wir uns zunächst der swap-Partition zu und verkleinern diese, so dass vor ihr freier Platz entsteht.
- Im "Größe ändern/Verschieben"-Fenster zunächst die Option "Ausrichten an:" auf MiB stellen.
- Nun mit der Maus das schwarze Dreieck an der linken Seite anfassen (Rechts-Links-Pfeil erscheint) und wie gewünscht nach rechts verschieben; die Eingabeboxen zeigen die gewählten Werte numerisch an.
- Durch Klick auf "Größe ändern/Verschieben" wird die eingestellte Operation vorgemerkt.
- Nun wenden wir uns der boot-Partition zu und vergrößern diese bis zum Beginn der swap-Partition.
- Mit Rechtsklick auf die Partition /dev/sdX1 das Kontextmenü aufrufen, "Größe ändern/Verschieben" auswählen.
- Im "Größe ändern/Verschieben"-Fenster zunächst die Option "Ausrichten an:" auf MiB stellen.
- Nun mit der Maus das schwarze Dreieck an der rechten Seite anfassen (Rechts-Links-Pfeil erscheint) und bis an den rechten Rand verschieben; die Eingabeboxen zeigen die gewählten Werte numerisch an.
- Durch Klick auf "Größe ändern/Verschieben" wird die eingestellte Operation vorgemerkt.
Nun sind die gewünschten Operationen vorgemerkt, sie werden im unteren Abschnitt des gparted-Fensters aufgelistet, aber bis auf den Dateisystemcheck der boot-Partition ist noch nichts passiert. Man kann durch Rechtsklick in diesem Operationen-Abschnitt auch "alle Operationen löschen", mit "letzte Operation rückgängig machen" der Reihe nach Operationen wieder entfernen oder gparted beenden.
- Zur Durchführung der vorgemerkten Operationen, klickt man nun auf den "Anwenden"-Button. Nun werden alle Operationen in der festgelegten Reihenfolge abgearbeitet. Danach kann gparted beendet, der PC heruntergefahren und eisfair wieder gebootet werden.
Hat man keine swap-Partition, muss man obige Schritte ebenfalls für /dev/sdX2 durchführen, nur das dies dann eben die root-Partition ist. Diese sollte, wie oben für die boot-Partition geschehen, vorher überprüft werden.
Ist es nicht gewollt, eine vorhandene swap-Partition (/dev/sdX2) zu verkleinern, muss der für boot zusätzlich benötigte Platz durch Verkleinern der root-Partition (/dev/sdX3) bereitgestellt werden:
- Nach Überprüfung verkleinern der root-Partition (/dev/sdXa3), so dass vor ihr Freiraum entsteht.
- Verschieben der swap-Partition (/dev/sdX2) bis zum Beginn der root-Partition; im "Größe ändern/Verschieben"-Fenster mit Partition mit der Maus innerhalb des Partitions-Rechtecks anfassen und ganz nach rechts schieben,wodurch nun Freiraum vor der swap-Partition entsteht.
- Wie oben beschrieben nun die boot-Partition (/dev/sdX1) vergrößern.
Befindet sich auf der eisfair-Systemplatte neben den drei Standardpartitionen auch eine vierte Partition (/dev/sdX4), die sogenannte data-Partition, kann auch diese den für die boot-Partition zusätzlich benötigten Platz bereitstellen:
- Nach Überprüfung verkleinern der data-Partition (/dev/sdX4), so dass vor ihr Freiraum entsteht
- Nach Überprüfung verschieben der root-Partition (/dev/sdX3) bis zum Beginn der data-Partition; im "Größe ändern/Verschieben"-Fenster mit Partition mit der Maus innerhalb des Partitions-Rechtecks anfassen und ganz nach rechts schieben, wodurch nun Freiraum vor der root-Partition entsteht.
- Verschieben der swap-Partition (/dev/sdX2) bis zum Beginn der root-Partition; im "Größe ändern/Verschieben"-Fenster mit Partition mit der Maus innerhalb des Partitions-Rechtecks anfassen und ganz nach rechts schieben, wodurch nun Freiraum vor der swap-Partition entsteht.
- Wie oben beschrieben nun die boot-Partition (/dev/sdX1) vergrößern
Empfehlenswert ist es, mit dem gparted-Programm vorher mal an einem in Partitionen unterteilten Stick zu üben.
Benennung von Platten- und Partitions-Devices durch udev und daraus folgende Konsequenzen
Jedem Platten- oder Partitions-Device werden durch udev in /dev/disk/by-id und /dev/disk/by-uuid eindeutige Devicenamen zugeordnet:
# ls -l /dev/disk/by-id total 0 lrwxrwxrwx 1 root root 9 Oct 15 18:38 ata-ATAPI_DVD-ROM_16XMax -> ../../sr0 lrwxrwxrwx 1 root root 9 Oct 15 18:38 ata-WDC_WD10EFRX-68PJCN0_WD-WCC4J0123456 -> ../../sdb lrwxrwxrwx 1 root root 10 Oct 15 18:38 ata-WDC_WD10EFRX-68PJCN0_WD-WCC4J0123456-part1 -> ../../sdb1 lrwxrwxrwx 1 root root 10 Oct 15 18:38 ata-WDC_WD10EFRX-68PJCN0_WD-WCC4J0123456-part2 -> ../../sdb2 lrwxrwxrwx 1 root root 10 Oct 15 18:38 ata-WDC_WD10EFRX-68PJCN0_WD-WCC4J0123456-part3 -> ../../sdb3 lrwxrwxrwx 1 root root 10 Oct 15 18:38 ata-WDC_WD10EFRX-68PJCN0_WD-WCC4J0123456-part4 -> ../../sdb4 lrwxrwxrwx 1 root root 9 Oct 15 18:38 ata-WDC_WD10EFRX-68PJCN0_WD-WCC4J6543210 -> ../../sda lrwxrwxrwx 1 root root 10 Oct 15 18:38 ata-WDC_WD10EFRX-68PJCN0_WD-WCC4J6543210-part1 -> ../../sda1 lrwxrwxrwx 1 root root 10 Oct 15 18:38 ata-WDC_WD10EFRX-68PJCN0_WD-WCC4J6543210-part2 -> ../../sda2 lrwxrwxrwx 1 root root 10 Oct 15 18:38 ata-WDC_WD10EFRX-68PJCN0_WD-WCC4J6543210-part3 -> ../../sda3 lrwxrwxrwx 1 root root 10 Oct 15 18:38 ata-WDC_WD10EFRX-68PJCN0_WD-WCC4J6543210-part4 -> ../../sda4 lrwxrwxrwx 1 root root 9 Oct 15 18:38 ata-WDC_WD5002AALX-00J37A0_WD-WCAYUX987654 -> ../../sdc lrwxrwxrwx 1 root root 10 Oct 15 18:38 ata-WDC_WD5002AALX-00J37A0_WD-WCAYUX987654-part1 -> ../../sdc1 lrwxrwxrwx 1 root root 9 Oct 15 18:38 md-uuid-135afd76:948553dc:948eeef1:172592f9 -> ../../md2 lrwxrwxrwx 1 root root 9 Oct 15 18:38 md-uuid-203badca:8a80e9c7:8dc76d1d:46951125 -> ../../md1 lrwxrwxrwx 1 root root 9 Oct 15 18:38 md-uuid-36bc0c98:73b1d447:1ed7b829:58d71fd0 -> ../../md4 lrwxrwxrwx 1 root root 9 Oct 15 18:38 md-uuid-40fd76c9:661c73fe:a10f393a:eaf0a8dd -> ../../md3 lrwxrwxrwx 1 root root 9 Oct 15 18:38 wwn-0x50014ee1da2a4aa0 -> ../../sdc lrwxrwxrwx 1 root root 10 Oct 15 18:38 wwn-0x50014ee1da2a4aa0-part1 -> ../../sdc1 lrwxrwxrwx 1 root root 9 Oct 15 18:38 wwn-0x50014ee2093d24c2 -> ../../sdb lrwxrwxrwx 1 root root 10 Oct 15 18:38 wwn-0x50014ee2093d24c2-part1 -> ../../sdb1 lrwxrwxrwx 1 root root 10 Oct 15 18:38 wwn-0x50014ee2093d24c2-part2 -> ../../sdb2 lrwxrwxrwx 1 root root 10 Oct 15 18:38 wwn-0x50014ee2093d24c2-part3 -> ../../sdb3 lrwxrwxrwx 1 root root 10 Oct 15 18:38 wwn-0x50014ee2093d24c2-part4 -> ../../sdb4 lrwxrwxrwx 1 root root 9 Oct 15 18:38 wwn-0x50014ee2095c32c1 -> ../../sda lrwxrwxrwx 1 root root 10 Oct 15 18:38 wwn-0x50014ee2095c32c1-part1 -> ../../sda1 lrwxrwxrwx 1 root root 10 Oct 15 18:38 wwn-0x50014ee2095c32c1-part2 -> ../../sda2 lrwxrwxrwx 1 root root 10 Oct 15 18:38 wwn-0x50014ee2095c32c1-part3 -> ../../sda3 lrwxrwxrwx 1 root root 10 Oct 15 18:38 wwn-0x50014ee2095c32c1-part4 -> ../../sda4 # ls -l /dev/disk/by-uuid total 0 lrwxrwxrwx 1 root root 10 Oct 15 18:38 12834961-5ffc-4893-b0d6-06290813633d -> ../../sdc1 lrwxrwxrwx 1 root root 9 Oct 15 18:38 d1e22432-f054-4de6-b96b-a6fc4a48ff1d -> ../../md4 lrwxrwxrwx 1 root root 9 Oct 15 18:38 ae8c6c23-60b2-4db6-9b8f-34558604c9d4 -> ../../md3 lrwxrwxrwx 1 root root 9 Oct 15 18:38 bfb57216-0e4f-4ba8-b2da-d4c34530cb27 -> ../../md1 lrwxrwxrwx 1 root root 9 Oct 15 18:38 f11c5f08-8f4d-49bb-aa19-f90918329887 -> ../../md2
Wie zu erkennen ist, handelt es sich bei diesen eindeutigen Devicenamen in /dev/disk/by-id und /dev/disk/by-uuid um Links auf die aktuell den Platten und Partitionen zugeordneten /dev/sdXn-Devices, wobei /dev/sdX-Namen die Platte und /dev/sdXn-Namen Partitionen bezeichnen. Für physikalische Platten und Partitionen werden in /dev/disk/by-id sogar deren zwei angelegt, nämlich einmal von Plattenname und Seriennummer abgeleitet und einmal mit dem Prefix wwn (World Wide Number). Die Partitionslinks in /dev/disk/by-id leiten sich von den Links für die ganze Platte und einem angehängten Suffix "-partN" für die jeweilige Partition ab, die Links in /dev/disk/by-uuid werden aus der UUID des Dateisystems gebildet.
Durch die Verwendung von udev im Bootprozess und/oder das Entfallen des alten kernelintegrierten IDE-Moduls kann es zu Umbennung der Platten- und Partitions-Devices kommen. Deshalb wird zukünftig in der /etc/lilo.conf und auch in der fstab für die Systemplatte mit von by-id und by-uuid abgeleiteten Devicenamen gearbeitet, die eindeutig und fix sind. Jedoch können an anderer Stelle in der Konfiguration diverser Pakete oder eigener Skripte noch hdX- oder sdX-Devices genutzt worden sein, die gegebenenfalls angepasst werden müssen.
Soweit möglich, ist die Verwendung eindeutiger Devicenamen vorzuziehen, für Partitionen vorzugsweise aus /dev/disk/by-uuid, da diese z. B. beim Klonen auf eine neue Platte erhalten bleiben.
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, ...
Im Folgenden sollen verschieden Fälle behandelt werden:
Bisher eine SATA- oder SCSI-Platte als sda-Device
Es sind keine Korrekturen erforderlich.
Bisher eine IDE-Platte als hda-Device
Diese wird nun zu sda; in allen Paketen oder eigenen Skripte ist also eine Referenz von /dev/hda auf /dev/sda bzw. bei Partitionsverweisen von /dev/hdaX auf /dev/sdaX zu ändern oder man benutzt die eindeutigen Devicenamen.
Bisher eine IDE-Platte als hda-Device und eine oder mehrere interne SATA- und/oder SCSI-Platten (sdX-Devices)
Die IDE-Platte wird nun zu einem sdX-Device, wobei vorab nicht vorhersehbar ist, in welcher Reihenfolge den Platten durch udev die fortlaufenden Devicenamen sda, sdb, ... zugeordnet werden. Für eine stabile Zuordnung sollten in Paketkonfigurationen, eigenen Skripten oder der /etc/fstab die eindeutigen Devicenamen benutzt werden.
Bisher eine IDE-Platte als hda-Device und eine oder mehrere externe USB-Platten (sdX-Devices)
Die IDE-Platte wird nun zu einem sdX-Device. Die Devicenamen der USB-Platten verschieben sich dadurch um eine Position (sda→sdb; sdb→sdc, ...). Für eine stabile Zuordnung sollten in Paketkonfigurationen, eigenen Skripten oder der /etc/fstab die eindeutigen Devicenamen benutzt werden.
Bisher eine IDE-Platte als hda-Device, eine oder mehrere interne SATA- und/oder SCSI-Platten (sdX-Devices) und eine oder mehrere externe USB-Platten (sdX-Devices)
Die IDE-Platte wird nun zu einem sdX-Device, wobei vorab nicht vorhersehbar ist, in welcher Reihenfolge den Platten durch udev die fortlaufenden Devicenamen sda, sdb, ... zugeordnet werden. Für eine stabile Zuordnung sollten in Paketkonfigurationen, eigenen Skripten oder der /etc/fstab die eindeutigen Devicenamen benutzt werden. Die USB-Platten reihen sich hinter den internen Platten ein, wobei man hier auch die UUID basierten Devicenamen in Paketkonfigurationen, eigenen Skripten oder der /etc/fstab nutzen kann.
Bisher zwei oder mehr interne SATA- und/oder SCSI-Platten (sdX-Devices)
Es ist vorab nicht vorhersehbar, in welcher Reihenfolge den Platten durch udev die fortlaufenden Devicenamen sda, sdb, ... zugeordnet werden. Für eine stabile Zuordnung sollten in Paketkonfigurationen, eigenen Skripten oder der /etc/fstab die eindeutigen Devicenamen benutzt werden.
Bisher zwei oder mehr interne SATA- und/oder SCSI-Platten (sdX-Devices) und eine oder mehrere externe USB-Platten (sdX-Devices)
Es ist vorab nicht vorhersehbar, in welcher Reihenfolge den Platten durch udev die fortlaufenden Devicenamen sda, sdb, ... zugeordnet werden. Für eine stabile Zuordnung sollten in Paketkonfigurationen, eigenen Skripten oder der /etc/fstab die eindeutigen Devicenamen benutzt werden. Die USB-Platten reihen sich hinter den internen Platten ein, wobei man hier auch die UUID basierten Devicenamen in Paketkonfigurationen, eigenen Skripten oder der /etc/fstab nutzen kann.
Bisher RAID mit 2 oder 3 Platten
RAIDs werden schon bislang über die UUIDs assembliert. Für Überwachungsaufgaben/Monitoring wird man aber auch auf die einzelnen Member des RAIDs zugreifen wollen; für eine fixe Zuordnung empfiehlt sich daher die Nutzung der eindeutigen Devicenamen für die einzelnen Member des RAIDs.
Bisher RAID mit 2 oder 3 Platten und eine oder mehrere weitere SATA- oder SCSI-Platten
RAIDs werden schon bislang über die UUIDs assembliert, die sdX-Devices können sich aber zwischen 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.
Bisher RAID mit 2 oder 3 Platten und eine oder mehrere externe USB-Platten
RAIDs werden schon bislang über die UUIDs assembliert. Für Überwachungsaufgaben/Monitoring wird man aber auch auf die einzelnen Member des RAIDs zugreifen wollen; 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.
Bisher RAID mit 2 oder 3 Platten, eine oder mehrere weitere SATA- oder SCSI-Platten und eine oder mehrere externe USB-Platten
RAIDs werden schon bislang über die UUIDs assembliert, die sdX-Devices können sich aber zwischen 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.
Angabe von Devicenamen in eigenen Skripten
Eine eindeutige fixe Zuordnung erhält man durch Verwendung von eindeutigen Devicenamen. Im Falle von wechselnden externen USB-Platten z. B. für Backupzwecke kann es jedoch sinnvoll sein, wie bisher mit einem sdX-Device bzw. sdXn-Device zu arbeiten. Aufgrund des Wegfalls der hdX-Devices werden hdX-Devices zu sdX-Devices und es kommt zu Verschiebungen, die in eigenen Skripten zu berücksichtigen sind.
Angabe von Devicenamen in der Konfiguration von Paketen
Eine eindeutige fixe Zuordnung erhält man durch Verwendung von eindeutigen Devicenamen, sofern der Konfigurationscheck eines Paketes dies zuläßt . Aufgrund des Wegfalls der hdX-Devices werden hdX-Devices zu sdX-Devices und es kommt zu Verschiebungen, die in den Paketkonfigurationen zu berücksichtigen sind.
hddtemp: Änderung von hdX-Devices in sdX-Devices, Berücksichtigung von Vertauschungen und Verschiebungen oder Verwendung eindeutiger Devicenamen aus /dev/disk/by-id. Es ist zu beachten, dass andere Pakete neu zu konfigurieren sind, wenn sie Werte des hddtemp-Daemons auslesen.
monitoring: Änderung von hdX-Devices in sdX-Devices, Berücksichtigung von Vertauschungen und Verschiebungen oder Verwendung eindeutiger Devicenamen aus /dev/disk/by-id (Platten) und /dev/disk/by-uuid (Partitionen).
smartmon: Änderung von hdX-Devices in sdX-Devices, Berücksichtigung von Vertauschungen und Verschiebungen oder Verwendung eindeutiger Devicenamen aus /dev/disk/by-id.
backup-zip, rsnapshot: Änderung von hdXn-Devices in sdXn-Devices, Berücksichtigung von Vertauschungen und Verschiebungen oder Verwendung eindeutiger Devicenamen aus /dev/disk/by-uuid.
Kernel 4.9 und das haveged-Paket
Der Kernel 4.9 erfordert einen größeren Entropiepool (Pool für Zufallszahlen) als unsere bisherigen Kernelserien. Auf einem System ohne Benutzerinteraktion stehen nicht genügend Quellen für zufällige Ereignisse zur Verfügung, so dass dieser Entropiepool oftmals nicht genügend Daten enthält und dieses dann zu stark verzögerter Ausführung bestimmter Vorgänge wie z. B. dem Aufbau von ssh-Verbindungen führt. Daher wird das haveged-Paket zwangsweise installiert und aktiviert, welches dem Entropiepool ausreichend zufällige Daten zuführt. Das haveged-Paket sollte daher weder deaktiviert noch deinstalliert werden.
Ausführung von Programmen mit festgelegtem Speicherlimit
Startet eine Anwendung unter dem neuen Kernel mit Verweis auf Speichermangel nicht mehr, sollte überprüft werden, ob für diese Anwendung eine Speicherlimit z. B. mittel "ulimit -u 100000 (entspricht 100000 KB) in der Startdatei dieser Anwendung in /etc/init.d festgelegt wurde. Setzt man dieses höher, sollte auch diese Anwendung wieder starten. So startet der Datenbankserver firebird mit vorgenannten ulimit von 100000 unter dem Kernel 3.16 neue Threads auf eine Connectanfrage, mit dem Kernel 4.9 ist das Limit jedoch auf mindestens 130000 zu setzen.