3.2 Der erste Kontakt mit dem System
In diesem Abschnitt beschäftigen wir uns mit dem ersten Kontakt mit einem Linux-System. Dieser »erste Kontakt« kann natürlich nicht jeden Aspekt der Kontaktaufnahme mit dem System umfassend behandeln, daher werden wir später noch ausführlich auf einzelne Punkte eingehen.
3.2.1 Booten
Beginnen wir mit dem Start des Systems. Egal, ob bei einer Installation auf Festplatte oder beim Laden einer Livedistribution – das Geschehen ist eigentlich immer gleich. Im BIOS wird festgelegt, auf welchen Medien in welcher Reihenfolge nach einem zu bootenden Betriebssystem gesucht werden soll. In diese Bootreihenfolge können nahezu alle Speichermedien wie USB-Sticks, CD-ROMs/DVDs oder auch Festplatten einbezogen werden.
Wird nun auf einem der im BIOS angegebenen Bootlaufwerke ein zu startendes Betriebssystem gefunden, wird dieses auch geladen. Auf allen bootfähigen Medien wird nämlich nach einem gültigen MBR (Master Boot Record) gesucht. Dies ist zum Beispiel bei einer Festplatte immer der erste Sektor (entspricht den ersten 512 Bytes) der Festplatte. Er enthält dabei folgende Informationen:
-
Bootloader
Der Bootloader besteht aus Code zum Laden eines Betriebssystems oder aus weiteren Bootloader-Codes. Damit von einem Medium gebootet werden kann, muss dieser Code gültig sein und ein Betriebssystem laden können. -
Partitionstabelle
Die Partitionstabelle gibt an, welche Partitionen wo auf dem Medium vorhanden sind. Die Partitionstabelle besteht aus vier Einträgen zu je 16 Byte und ist damit insgesamt 64 Byte groß. Sie liegt relativ nah am Ende des Bootsektors bei Byte 446. -
Magic Number
Die fehlenden 2 Byte[ 17 ] bis zum Ende des Sektors werden nun mit einem Wert gefüllt, anhand dessen das BIOS entscheiden kann, ob es sich um ein bootbares Medium handelt oder nicht: Ist der Wert 0x55aa, so kann der Code am Anfang des MBR geladen werden. Ändert man diesen Wert, wird das Medium nicht als bootfähig erkannt.
Sehen wir uns den Bootvorgang weiter an: Hat man Linux auf seinem System installiert, so wird mit ziemlicher Sicherheit ein Bootloader wie GRUB geladen. Mit diesem kann man zwischen allen auf diesem Medium installierten Betriebssystemen das zu startende auswählen – normalerweise wird jedoch bei keiner Eingabe nach wenigen Sekunden automatisch ein vordefiniertes System gestartet.
Als Nächstes wird der Kernel geladen, der das System schließlich allm"ahlich initialisiert und mit dem Init-Prozess (erkennbar an der PID 1) auch den ersten Prozess des Userlands explizit startet. Dieser Prozess – in den meisten Distributionen ist das heutzutage systemd – übernimmt dann das eigentliche Starten des Systems, indem dafür vorgesehene Konfigurationsdateien ausgelesen und entsprechende Dienste im Hintergrund gestartet werden.
Dabei werden von init verschiedene Systemkonfigurationen, sogenannte Targets, unterschieden. Je nach Target werden unterschiedliche Dienste gestartet. So gibt es zum Beispiel bei den meisten Systemen ein Target mit grafischer Oberfläche und eines ohne. Auch gibt es bestimmte Targets zum Herunterfahren bzw. Neustarten des Systems, wobei zuerst alle Dienste sauber gestoppt werden, bevor das System schließlich angehalten bzw. neu gestartet wird.
3.2.2 Login
Auch die Login-Dienste der Textoberfläche – realisiert durch das Programm (m)getty – werden durch den Init-Prozess gestartet. Je nach Target kann aber auch ein grafischer Login-Dienst wie GDM oder KDM gestartet sein. In jedem Fall werden die Nutzerinnen und Nutzer aufgefordert, sich mit einem Usernamen und einem Passwort einzuloggen, damit sie am System arbeiten können.
Das Login ist dabei wieder ein typisches Beispiel für die Netzwerktransparenz: Normalerweise wird bei der Anmeldung einer Benutzerin bzw. eines Benutzer überprüft, ob der Benutzername in der lokalen Datei /etc/passwd verzeichnet ist und mit dem Passwort in der Datei /etc/shadow übereinstimmt. Setzt man im Netzwerk jedoch Dienste wie LDAP ein, kann man ein Unix-System überreden, die Benutzerinformationen von einem solchen zentralen Server zu laden – die Anwenderin bzw. der Anwender selbst merkt davon nichts. Verbindet man dieses Feature noch geschickt mit dem Einsatz von NFS, kann so auf jedem System der Firma die gleiche Arbeitsumgebung zur Verfügung gestellt werden.
3.2.3 Arbeiten am System
Nach dem Einloggen kann man am System arbeiten. Je nach Aufgabenspektrum oder Präferenz kann dies in verschiedenen Umgebungen erfolgen. Auch die verwendeten Programme werden stark variieren. Eines ist jedoch für alle Benutzerinnen und Benutzer gleich: Der Ort ihrer Arbeit und der Platz zum Speichern wichtiger Daten ist jeweils das Heimatverzeichnis (engl. home directory, im Deutschen oft auch Homeverzeichnis genannt).
Unter Linux besitzt jeder Benutzer sein eigenes Verzeichnis in /home, wohingegen dieses Verzeichnis unter anderen Unix-Systemen zum Beispiel auch unterhalb von /usr liegen kann. Im Normalfall hat der Benutzer nur in seinem eigenen Verzeichnis das Recht, Dateien anzulegen, zu ändern und zu löschen – von Spezialfällen wie dem Verzeichnis für temporäre Dateien /tmp einmal abgesehen. Dafür besitzt er dort dann auch Narren- und Gestaltungsfreiheit. Wie man die eigenen Daten organisiert, ist jedem Benutzer und jeder Benutzerin selbst überlassen.
Alle Programme können Dateien im jeweiligen Verzeichnis des Benutzers ablegen. Im Regelfall sind diese jedoch »versteckt«, werden also bei einem normalen Betrachten des Verzeichnisses nicht angezeigt. Die Namen versteckter Dateien beginnen alle mit einem Punkt; solche Dateien können natürlich unter Angabe spezieller Optionen dennoch angezeigt werden. In diesem Sinne sind sie also nicht versteckt, sondern werden im Normalfall schlicht ausgeblendet, um den Benutzerinnen und Benutzern einen besseren Überblick über die von ihnen selbst angelegten und bearbeiteten Dateien zu geben.
3.2.4 Die Linux-Verzeichnisstruktur
Wie Sie bereits wissen, besitzt Linux ein virtuelles Dateisystem, das von physischen Speichermedien auf eine Verzeichnisstruktur abstrahiert. Doch auch diese Verzeichnisstruktur selbst ist interessant, da sich das zugrunde liegende Konzept von anderen, nicht Unix-artigen Betriebssystemen wie Windows unterscheidet.
Im Folgenden wollen wir die wichtigsten Verzeichnisse und ihre Bedeutung kurz erläutern. Dazu müssen vorher noch einige Begriffe geklärt werden, mit denen die Daten später klassifiziert werden:
-
shareable
Dateien sind shareable, wenn sie auf einem Rechner im Netzwerk gespeichert und auf anderen Rechnern genutzt werden können; es wird also das Prinzip der Netzwerktransparenz unterstützt. Beispielsweise ist ein Homeverzeichnis eines Benutzers shareable, da es theoretisch auf einem zentralen Server im Netzwerk gespeichert sein und auf dem PC, auf dem sich der betreffende Benutzer gerade angemeldet hat, genutzt werden kann. (Dateien, die den Zugriff auf lokale Systemressourcen wie Bildschirm oder Tastatur regeln, sind eher nicht im Netzwerk teilbar und damit unshareable.) -
static
Dateien sind statisch (engl. static), wenn sie nicht ohne die Intervention des Administrators bzw. der Administratorin geändert werden können. Typische Beispiele für statische, also im Normalfall nicht schreibbare Daten sind Programm-Binaries, Dokumentationen oder Systembibliotheken. -
variable
Im Gegensatz zu static-Dateien stehen variable, also zur Laufzeit veränderbare Daten. Solche veränderbaren Dateien sind zum Beispiel Logfiles, temporäre Dateien oder Datenbanken.
Diese Kategorien finden sich in der Verzeichnisstruktur unter Linux wieder. Beginnen wir deswegen mit den wichtigsten Verzeichnissen und ihrer Bedeutung:
-
/bin
Dieses Verzeichnis enthält essenzielle (Shell-)Programme. Diese sind statisch und durchaus shareable. -
/boot
Das /boot-Verzeichnis beinhaltet alle wichtigen Dateien zum Hochfahren des Systems, wozu vor allem der Kernel gehört. Diese Dateien sind im Allgemeinen statisch und nicht shareable, da sie durch verschiedene Treiber und die Konfiguration sehr systemspezifisch sind und direkt beim Systemstart verfügbar sein müssen. -
/etc
Alle systemweiten Konfigurationsdateien eines Rechners sollten im /etc-Verzeichnis abgelegt sein. Da sich eine Konfiguration selten selbst ändert, sind auch diese Daten statisch und aufgrund des personalisierenden Charakters einer Konfiguration eher als unshareable einzustufen.[ 18 ] -
/home
Das Homeverzeichnis eines Users unter /home/username haben wir Ihnen bereits vorgestellt. Hier werden die eingeloggten Benutzerinnen und Benutzer in der Regel arbeiten. Auch benutzerspezifische, also nicht systemweite Einstellungen finden sich in diesem Verzeichnis. -
/lib
In diesem Verzeichnis liegen alle essenziellen Bibliotheken. In dem Verzeichnis /lib/modules/<kernelversion> finden sich somit auch die Module, die zur Laufzeit dynamisch in den Kernel geladen werden können. -
/mnt
In /mnt sollten Wechseldatenträger wie DVDs oder USB-Sticks gemountet werden. -
/opt
Damit Softwarepakete auch von Drittanbietern ins System integriert werden können, gibt es das /opt-Verzeichnis. Dort können entsprechend dem Firmen- oder Softwarenamen Unterverzeichnisse angelegt werden, in denen dann die jeweilige Software installiert werden kann. -
/proc
Im /proc-Verzeichnis findet sich ein gemountetes virtuelles Dateisystem, in dem sich Informationen über alle Prozesse und über das System abrufen lassen. -
/root
Dies ist das Homeverzeichnis von root. Da man als root nicht direkt am System arbeiten sollte, wird dieses Verzeichnis recht selten genutzt werden. -
/sbin
In diesem Verzeichnis finden sich essenzielle System-Binaries. -
/tmp
Dies ist das Verzeichnis für temporäre Daten. Im Regelfall werden während des Bootens alte, von der letzten Sitzung zurückgebliebene Dateien gelöscht. -
/usr
Die /usr-Hierarchie ist die größte und wichtigste Ansammlung statischer, sharebarer Daten. Die wichtigsten Unterverzeichnisse finden Sie hier:
-
/usr/bin/
Benutzerprogramme (Binaries) -
/usr/lib/
Bibliotheken für Benutzerprogramme -
/usr/local/
Extra-Hierarchie für selbstkompilierte Software, in sich wieder genauso gegliedert wie /usr -
/usr/sbin/
nicht essenzielle Systemprogramme -
/usr/share/
architekturunabhängige Daten[ 19 ] -
/usr/src/
Verzeichnis für Quellcode (optional)
Aus den Charakteristika dieser Daten ergibt sich die Möglichkeit, das Verzeichnis /usr auf eine eigene Partition zu legen, es read-only zu mounten und es gegebenenfalls im Netzwerk freizugeben und auf anderen Systemen zu mounten. Beim Aktualisieren des Systems muss dann natürlich ein Remount mit möglichem Schreibzugriff erfolgen, da sonst zum Beispiel keine Binaries ersetzt werden können.
-
-
/var
Das /var-Verzeichnis umfasst ähnlich wie /usr eine ganze Hierarchie von Unterverzeichnissen mit speziellen Aufgaben. Im Gegensatz zu diesem sind die Daten in /var jedoch variabel und im Allgemeinen nicht shareable.-
/var/cache/
anwendungsspezifische Cachedaten -
/var/lib/
variable Statusinformationen -
/var/local/
variable Daten für /usr/local -
/var/lock/
Lockdateien: Diese Dateien stellen den exklusiven Zugriff auf bestimmte Ressourcen sicher: Ist eine bestimmte Datei vorhanden, so ist die zugehörige Ressource belegt. Erst nach dem Löschen der Datei kann wieder versucht werden, die Ressource anzufordern. -
/var/log/
Logdateien: Diese Dateien dienen der Protokollierung des Nutzer- und Systemverhaltens inklusive aufgetretener Hardware-Ereignisse. -
/var/opt/
variable Daten für /opt -
/var/run/
für laufende Prozesse relevante Daten: Soll zum Beispiel ein Programm wie ein bestimmter Serverdienst nur einmal gestartet werden können, kann in /var/run eine Datei mit der Prozess-ID abgelegt werden. Bei einem versuchten zweiten Start des Programms kann dieses anhand der Datei nun feststellen, dass es schon läuft, und daher den Start verweigern. -
/var/spool/
Spooling-Daten wie beispielsweise noch zu druckende Dateien oder noch nicht abgeholte Mails -
/var/tmp/
temporäre Dateien, die nicht bei einem Reboot gelöscht werden sollten
Auch bei /var kann sich die Speicherung der Daten auf einer eigenen Partition oder Platte anbieten, um bei knapper werdendem Plattenplatz immer noch etwas Platz auf der Root-Partition freihalten und damit ein funktionierendes System gewährleisten zu können.
-
Mit Ausnahme des Homeverzeichnisses wird man mit diesen Verzeichnissen in aller Regel jedoch nur als Administrator bzw. Administratorin zu tun haben. Das liegt vor allem am Rechtesystem: Bis auf die temporären Verzeichnisse wie /tmp/ oder /var/tmp/ dürfen normale Benutzerinnen und Benutzer in der Regel nur in ihr Homeverzeichnis schreiben.
3.2.5 Das Rechtesystem
Diese restriktive Handhabung des Schreibzugriffs ist sinnvoll, da so kein normaler Benutzer das System manipulieren oder umkonfigurieren kann. Wir wollen im Zusammenhang mit dem Rechtesystem als Erstes natürlich die Rechte etwas näher betrachten, die einem Benutzer bzw. einer Benutzerin gewährt oder nicht gewährt werden können.
-
Write (w)
Das Schreibrecht: Hat ein Benutzer dieses Recht (man spricht auch von einem Rechte-Flag oder Rechte-Bit) auf eine Datei, so kann er sie zum Schreiben öffnen oder sie auch löschen. In Verzeichnissen, auf das ein Benutzer ein Schreibrecht hat, können durch diesen Dateien oder weitere Unterverzeichnisse angelegt werden. -
Read (r)
Das Leserecht: Dieses Recht erlaubt es einem Benutzer bzw. einer Benutzerin, lesend auf entsprechende Dateien oder Verzeichnisse zuzugreifen. -
Execute (x)
Dateien mit diesem Rechte-Flag können ausgeführt werden. Entweder handelt es sich bei diesen Dateien um binäre Formate wie ELF oder um Skriptdateien bestimmter Sprachen wie Bash oder Perl. Bei Letzteren muss jedoch in der ersten Zeile des Skripts der Interpreter genannt werden, mit dem die Datei ausgeführt werden kann. Dieses Rechte-Flag wird in erster Linie verwendet, um zwischen Programmen und Daten zu differenzieren, und seltener, um festzulegen, wer ein bestimmtes Programm ausführen darf und wer nicht.
Bei Verzeichnissen hat dieses Flag eine etwas andere Semantik: Dort wird nämlich durch das x-Flag der Zugriff auf ein Verzeichnis gesteuert. Wem dieses Recht nicht gewährt wird, dem bleibt das Wechseln in den entsprechenden Ordner verwehrt.
Werden Rechte auf Dateien beziehungsweise Verzeichnisse vergeben, so müssen sich von einer bestimmten Rechtemaske auf einer Datei die Berechtigungen für jeden möglichen Benutzer ableiten lassen. Jedem Benutzer und jeder Benutzerin ist im System daher eine Benutzer-ID (UID, User ID) und mindestens eine Gruppen-ID (GID, Group ID) zugeordnet. Eine Datei wird nun auch einem Benutzer – nämlich dem Eigentümer beziehungsweise dem Ersteller der Datei – sowie einer Gruppe zugeordnet.
Für den Rechtekontext bedeutet dies, dass man eine Rechtemaske setzen kann, die aus je einem Bit für Read, Write und Execute für den Eigentümer bzw. die Eigentümerin, die Gruppe und schließlich noch für den Rest der Welt besteht. Möchte eine Benutzerin auf eine Datei zugreifen, so wird zuerst geprüft, ob sie die Eigentümerin dieser Datei ist. Ist dies der Fall, so wird die entsprechende Rechtemaske zur Prüfung der Gültigkeit des geforderten Zugriffs herangezogen. Ist die Benutzerin nicht die Eigentümerin, so wird geprüft, ob sie in der Gruppe der Datei ist, um eventuell die Rechtemaske dieser Gruppe heranzuziehen. Ist auch dies nicht der Fall, werden automatisch die Rechte für den Rest der Welt angewendet.
$ ls -l .bashrc -rw-r----- 1 admin users 1379 10. Jun 2024 .bashrc
Listing 3.1 Die eine beispielhafte Rechtemaske
Im oben genannten Beispiel sehen Sie, dass die Datei /etc/passwd dem Benutzer admin und der Gruppe users gehört. Greift der Eigentümer admin selbst auf die Datei zu, kommt die erste Rechtemaske rw- zum Einsatz: Er darf die Datei lesen und schreiben, aber nicht ausführen. Ist der zugreifende Benutzer nicht admin, aber Mitglied der Gruppe users, kommt die zweite Rechtemaske r-- zum Einsatz. Ein Benutzer der Gruppe könnte die Datei nur lesen, aber nicht schreiben oder ausführen. Ist der zugreifende Benutzer auch nicht in der Gruppe, kommt die dritte Rechtemaske --- zum Einsatz, und der Zugriff würde komplett verweigert.
root
Eine Ausnahme in diesem Rechtekontext bildet der Benutzer root (UID 0), der immer auf alle Dateien Zugriff hat. Er ist, vom Eigentümer einer Datei abgesehen, auch der Einzige, der die Rechte auf eine Datei ändern kann. Dieser Superuser ist in der Regel der Administrator bzw. die Administratorin des Systems und verfügt sozusagen über absolute Macht durch den unbeschränkten Zugriff auf alle Dateien.
Rechte und Hardware
Rechte werden nur auf Dateien oder Verzeichnisse vergeben. Da jedoch zum Beispiel Geräte und bestimmte Ressourcen als Dateien im System repräsentiert sind und Unix an sich generell sehr dateiorientiert ist, ergibt sich so wieder ein konsistentes Gesamtbild.
Auch sollte erwähnt werden, dass es problemlos möglich ist, mit mehreren Benutzerinnen und Benutzern zur selben Zeit an einem System zu arbeiten. Natürlich ist ein PC in der Regel mit nur einem Bildschirm und nur einer Grafikkarte ausgestattet, jedoch kann zum Beispiel über den SSH-Dienst das Remote-Arbeiten, also ausgehend von anderen Rechnern im Netzwerk, ermöglicht werden.
3.2.6 Herunterfahren
Ein weiterer wichtiger Schritt im ersten Kontakt mit dem System ist das Herunterfahren. Wie heutzutage bei fast allen komplexeren Systemen üblich, kann man ein System nicht einfach beliebig von seiner Stromquelle trennen. Damit man es in einem konsistenten Zustand halten kann, müssen alle Programme
-
ihre temporären Daten speichern,
-
alle verwendeten Ressourcen freigeben und
-
das Dateisystem in einem konsistenten Zustand hinterlassen.
Vor allem die Problematik des Dateisystems ist offensichtlich, wenn man sich an das letzte Kapitel und die Tatsache erinnert, dass viele Daten zwischengespeichert und gepuffert werden, um die Performance des Systems zu erhöhen. Werden diese gepufferten Daten nicht zurückgeschrieben oder wird die Festplatte vielleicht sogar inmitten eines Schreibvorgangs unterbrochen, tritt ein Datenverlust auf oder es kommt zu inkonsistenten (Meta-)Daten auf der Festplatte.
Ein System herunterfahren und solche Probleme vermeiden können Sie mit dem Befehl shutdown:
-
shutdown -h now
Mit diesem Befehl hält man das System an (engl. halt). Dazu wird das System in den shutdown-Target überführt, wobei alle gestarteten Dienste über ihre Stopskripte beendet werden. Schließlich werden alle verbleibenden Prozesse über ein SIGTERM aufgefordert, sich zu beenden, um sie dann nach kurzer Zeit mit einem SIGKILL auf die »harte Tour« durch den Kernel zu beenden. Die Prozesse werden gesondert beendet, damit alle offenen Dateien noch geschlossen werden können. Ignorierte man diese im Prozesskontrollblock vermerkten Daten, würden eventuell bisher nur gepufferte Schreibzugriffe nicht ausgeführt und gingen somit verloren. -
shutdown -r now
Mit diesem Befehl wird das System neu gestartet (engl. reboot). Die dazu notwendigen Aktionen, vom Herunterfahren der beim Systemstart von Init-Prozess bzw. systemd aktivierten Dienste bis zum Senden der Signale an alle Prozesse, entsprechen dem Vorgehen beim Systemhalt.
Natürlich muss man diese Befehle nicht auf der Shell eingeben, sondern kann auch von einer grafischen Oberfläche wie Gnome aus ein System herunterfahren. Allerdings hat man auf der Shell die Möglichkeit, anstelle von now einen genauen Zeitpunkt anzugeben, zu dem das System heruntergefahren oder neu gestartet wird. Auch kann man hier eine Nachricht eingeben, die vor der shutdown-Aktion an alle eingeloggten Nutzer gesendet wird.
3.2.7 Wie Laufwerke bezeichnet werden
Wenn Sie eine Windows-Anwenderin bzw. ein Windows-Anwender sind, dann kennen Sie Laufwerksbezeichnungen als Buchstaben (etwa C: oder D:). Unter Linux ist das Prinzip ähnlich, Laufwerke werden hier allerdings als Gerätedateien repräsentiert und heißen daher anders. Wie für Gerätedateien üblich sind Dateien, die Laufwerksgeräte repräsentieren, im Verzeichnis /dev zu finden.
Laufwerke werden (im Falle von CD-/DVD-, (S)ATA- und SCSI-Laufwerken) mit sdX bezeichnet, wobei anstelle des X ein Kleinbuchstabe eingesetzt wird. /dev/sda ist etwa eine typische Festplattenbezeichnung, genauso wie /dev/nvme. Es kann sich bei den jeweiligen Geräten aber auch um CD-Laufwerke und Ähnliches handeln.
Auch einzelne Partitionen sind unter Linux als Dateien vorhanden. So ist die erste Partition der Festplatte /dev/sda als /dev/sda1 ansprechbar, die zweite Partition als /dev/sda2 und so fort.
Die genannten Bezeichner für Festplatten sind für die Systemkonfiguration von großer Bedeutung. Sie werden etwa verwendet, um anzugeben, wo eine Platte im Dateisystem eingehängt werden soll. Es kann allerdings sein, dass eine Festplatte umkonfiguriert und dadurch ihr Bezeichner verändert wird, was wiederum die Systemkonfiguration empfindlich treffen kann. Aus diesem Grund sind viele Distributionen dazu übergegangen, sogenannte UUIDs (Universally Unique Identifiers) zu verwenden. Dabei handelt es sich um eindeutige Bezeichner für Laufwerke, die auch nach einer Umkonfiguration erhalten bleiben können. Sollten Sie also einmal eine Festplatte umstecken, so müssen Sie die Systemkonfiguration nicht ändern. Eine UUID ist eine eindeutige und zudem recht lange Hex-Zahl. Über das Programm blkid können Sie sich die UUIDs Ihrer Partitionen anzeigen lassen.
$ blkid /dev/sda1: UUID="7b898fa6-391e-4b81-888c-48ef10d7a95f" SEC_TYPE="ext2" TYPE="ext3" /dev/sdb1: UUID="7b76eae9-1d58-43b2-856e-f4c6b7a914f9" SEC_TYPE="ext2" TYPE="ext3" /dev/sdb2: UUID="c646f84c-2c4c-446b-ac09-9d398099867e" TYPE="swap" /dev/sdb3: UUID="018ad305-97b0-40a6-b8c0-54734cf6e6b3" SEC_TYPE="ext2" TYPE="ext3"
Listing 3.2 Das Programm blkid zeigt die UUIDs des Systems an.
Die erste Spalte enthält die Partitionsbezeichnung. Darauf folgen die eigentliche UUID und zwei Dateisystemtyp-Angaben. Die Angabe TYPE steht für den eigentlichen Dateisystemtyp (hier also ext3). Kann ein Dateisystem auch als ein anderes Dateisystem gemountet werden (das Dateisystem ext3 kann auch als ext2-Dateisystem eingehängt werden, ist also rückwärtskompatibel), so gibt SEC_TYPE (secondary filesystem type) diesen alternativen Typ an.
Möchten Sie nur die UUID einer bestimmten Partition angezeigt bekommen, können Sie deren Dateinamen auch an blkid übergeben:
$ blkid /dev/sdb3 /dev/sdb3: UUID="018ad305-97b0-40a6-b8c0-54734cf6e6b3" SEC_TYPE="ext2" TYPE="ext3"
Listing 3.3 Die UUID von /dev/sdb3 anzeigen
Die UUIDs sind als Links im Dateisystem präsent, können also auch durch das ls-Programm angezeigt werden.
$ ls -l /dev/disk/by-uuid insgesamt 0 lrwxrwxrwx 1 root root 10 2023-09-12 10:12 018ad305-97b0-40a6-b8c0-54734cf6e6b3 -> ../../sdb3 lrwxrwxrwx 1 root root 10 2023-09-12 10:12 7b76eae9-1d58-43b2-856e-f4c6b7a914f9 -> ../../sdb1 lrwxrwxrwx 1 root root 10 2023-09-12 10:12 7b898fa6-391e-4b81-888c-48ef10d7a95f -> ../../sda1 lrwxrwxrwx 1 root root 10 2023-09-12 10:12 c646f84c-2c4c-446b-ac09-9d398099867e -> ../../sdb2
Listing 3.4 UUIDs mit ls anzeigen