Leseprobe. »BootvorgangPaketmanagement« Inhalt. Index. Die Autoren. Wissen, wie s geht.

Transkript

1 Wissen, wie s geht. Leseprobe Dieses Buch ist wie ein Schweizer Taschenmesser für den Linux-Admin: Für jede Herausforderung hat es eine Lösung. In dieser Leseprobe finden Sie alles Wichtige zum Bootloader GRUP, und Sie machen sich mit dem Paketmanagement vertraut. Außerdem können Sie einen Blick in das vollständige Inhalts- und Stichwortverzeichnis des Buches werfen.»bootvorgangpaketmanagement«inhalt Index Die Autoren Dirk Deimeke, Stefan Kania, Charly Kühnast, Daniel van Soest, Peer Heinlein Linux-Server Das umfassende Handbuch PDF-Format, Seiten*, in Farbe, 3. Auflage ,90 uro, ISBN *auch erhältlich als gebundenes Buch: 49,90 uro, ISBN

2 Kapitel 2 2 Bootvorgang Der Startvorgang eines Linux-Systems ist die Basis dafür, überhaupt etwas mit dem System anfangen zu können. Wir geben einen inblick in den Bootloader, die initiale Ramdisk und den Start mittels init-skripten. in kurzer Blick auf»eventgesteuertes Starten«mittels»upstart«und»systemd«rundet dieses Kapitel ab. 2.1 inführung Mit dem Bootloader wird das Betriebssystem gestartet. Nachdem das BIOS den mehr oder weniger ausführlichen Systemcheck durchgeführt hat, werden die Bootmedien in der Reihenfolge der Präferenzen abgearbeitet. Wenn es zur Festplatte kommt, werden die ersten 512 Byte der Festplatte ausgewertet; in diesen ist der Master Boot Record (MBR) zu finden. Von den 512 Byte sind die ersten 446 für den Bootloader reserviert. In diesem begrenzten Bereich lassen sich keine großen Programme unterbringen, daher wird der Bereich dafür genutzt, Code von anderer Stelle nachzuladen. Der frühere Linux Loader (LILO) ist heute kaum nach verbreitet, daher beschränken wir uns im Weiteren auf den Grand Unified Bootloader (GRUB) und die Weiterentwicklung GRUB Der Bootloader GRUB Man unterscheidet bei GRUB drei Stages. Die Hauptaufgabe der ersten Stufe Stage 1 liegt darin, die zweite Stufe Stage 1.5 zu laden. In dieser Stufe liegen die notwendigen Treiber zum Ansprechen des Dateisystems. Stage 1.5 fällt unterschiedlich aus, je nachdem welches Dateisystem verwendet wird. Zu finden ist diese ebenfalls sehr kleine Stufe zwischen dem Master Boot Record (MBR) und der ersten Partition. Bei der Installation von GRUB werden die benötigten Treiber festgestellt und entsprechend installiert. Sobald der Dateisystemtreiber verfügbar ist, kann mit dem»eigentlichen«bootloader begonnen werden. Nach Laden dieser dritten Stufe Stage 2 wird von allen verwendeten Distributionen ein Menü angezeigt, mit dem sie das zu startende Betriebssystem oder spezielle Optionen starten können, häufig ist eine Option zum Speichertesten oder ein failsafe-modus auswählbar. Wenn Sie keine Option auswählen, wird das Standardbetriebssystem gestartet. 63

3 2 Bootvorgang 2.2 Der Bootloader GRUB Installation Die Installationsroutinen der Betriebssysteme installieren den Bootloader GRUB automatisch vor Abschluss aller Installationsarbeiten. Im Normalfall müssen Sie keine Hand anlegen, es sei denn, Sie wollen spezielle Optionen setzen, einen Bootloader reparieren oder eine (defekte) Festplatte ersetzen. Der Standardweg, den Bootloader zu installieren, ist, grub-install zu verwenden. Dieses Skript fasst die Befehle, die notwendig sind, einen Bootloader zu installieren, auf einfache Art und Weise zusammen. Die Befehle müssten ansonsten manuell in der GRUB-Shell ausgeführt werden. Die Konfigurationsparameter werden in der Datei /etc/grub.conf gesucht. Je nach Distribution werden leicht unterschiedliche Werkzeuge verwendet. Listing 2.1 zeigt die Installation in SUS Linux nterprise Server (SLS) 11, opensus setzt in aktuellen Versionen auf GRUB 2. sles:~ # grub-install GNU GRUB version 0.97 (640K lower / 3072K upper memory) [ Minimal BASH-like line editing is supported. For the first word, TAB lists possible command completions. Anywhere else TAB lists the possible completions of a device/filename. ] grub> setup --stage2=/boot/grub/stage2 --force-lba (hd0,0) (hd0,0) Checking if "/boot/grub/stage1" exists... yes Checking if "/boot/grub/stage2" exists... yes Checking if "/boot/grub/e2fs_stage1_5" exists... yes Running "embed /boot/grub/e2fs_stage1_5 (hd0,0)"... failed (this is not fatal) Running "embed /boot/grub/e2fs_stage1_5 (hd0,0)"... failed (this is not fatal) Running "install --force-lba --stage2=/boot/grub/stage2 /boot/grub/stage1 (hd0,0) \ /boot/grub/stage2 p /boot/grub/menu.lst "... succeeded Done. grub> quit Listing 2.1 Installation des»grub«in SLS11 s müssen keine weiteren ingaben vorgenommen werden, mit grub-install läuft der Rest automatisch. Bei älteren Linux-Distributionen benötigt grub-install das Device (die Festplatte), auf die der GRUB geschrieben werden soll, als Parameter, beispielsweise wie in Listing 2.2 gezeigt: root@debian:~# grub-install /dev/sda Searching for GRUB installation directory... found: /boot/grub Installation finished. No error reported. This is the contents of the device map /boot/grub/device.map. Check if this is correct or not. If any of the lines is incorrect, fix it and re-run the script 'grub-install'. (hd0) /dev/sda Listing 2.2 Installation des»grub«auf älteren Systemen Statt des Skripts grub-install lässtsichdiearbeit auchdirekt mit dergrub-shell ausführen. Sie wird mit grub aufgerufen und bietet eine große Anzahl an Kommandos, um GRUB auf vielfältige Weise zu konfigurieren. Wie Sie in Listing 2.1 gesehen haben, ließe sich der Befehl setup mit den notwendigen Parametern auch von Hand ausführen. Alternativ dazu besteht aber auch die Möglichkeit, die Schritte kleiner zu wählen und mit root festzulegen, auf welcher Partition des Verzeichnis boot liegt. Der Befehl setup schließlich schreibt die Informationen in den MBR. Um es dem Administrator nicht zu leicht zu machen, unterscheidet sich die zu verwendende Schreibweise von der sonst in Linux üblichen, was aber kein böser Wille ist. Zum Zeitpunkt des Systemstarts gibt es noch keine Verbindung zu den unter /dev beschriebenen Geräten und zu denen, die beim Starten des Systems gefunden wurden. So wird aus /dev/sda der Parameter (hd0), der die erste Festplatte im System meint. Weiterhin wird die erste Partition der ersten Festplatte nicht mit /dev/sda1 beschrieben, sondern mit (hd0,0). In Listing 2.3 finden Sie ein Beispiel für die Arbeit mit der GRUB-Shell. Bitte beachten Sie, dass die Zählung bei 0 beginnt und nicht bei 1, ebenfalls muss /boot sich nicht zwangsläufig auf der gleichen Partition wie das root-dateisystem unter / befinden. Viele Distributionen legen /boot auf eine eigene Partition mit dem Dateisystem ext2. sles:~ # grub GNU GRUB version 0.97 (640K lower / 3072K upper memory) [ Minimal BASH-like line editing is supported. For the first word, TAB lists possible command completions. Anywhere else TAB lists the possible completions of a device/filename. ] grub> root (hd0,0) Filesystem type is ext2fs, partition type 0x83 grub> setup (hd0) Checking if "/boot/grub/stage1" exists... yes Checking if "/boot/grub/stage2" exists... yes Checking if "/boot/grub/e2fs_stage1_5" exists... yes Running "embed /boot/grub/e2fs_stage1_5 (hd0)" sectors are embedded

4 2 Bootvorgang 2.2 Der Bootloader GRUB succeeded Running "install /boot/grub/stage1 (hd0) (hd0)1+17 p (hd0,0)/boot/grub/stage2 \ /boot/grub/menu.lst"... succeeded Done. grub> quit Listing 2.3»GRUB-Shell«auf SLS11 In der Datei /boot/grub/device.map finden sich die Informationen über Devices, auf die der GRUB geschrieben werden kann, sie sieht wie in Listing 2.4 gezeigt aus. Sollten die Informationen veraltet oder falsch sein, können Sie die Datei bearbeiten oder löschen. Falls sie nicht verfügbar ist, wird sie neu angelegt. (fd0) /dev/fd0 (hd0) /dev/disk/by-id/ata-qmu_harddisk_qm00001 Listing 2.4 /boot/grub/device.map Alternativ zu /dev/disk/by-id/ata-qmu_harddisk_qm00001 kann auch die Schreibweise /dev/sda verwendet werden Konfiguration Wie Sie sicher bemerkt haben, haben wir bis jetzt bis auf den Ort, an dem der Bootloader installiert werden soll,noch gar nichts konfiguriert. Die eigentliche Konfiguration des Bootloaderserfolgt in derdatei /etc/grub/menu.lst, die in Listing 2.5 gezeigt wird: # Modified by YaST2. Last modification on Thu May 15 07:24:35 CST 2014 default 0 timeout 8 ##YaST - generic_mbr gfxmenu (hd0,0)/message ##YaST - activate ###Don't change this comment - YaST2 identifier: Original name: linux### title SUS Linux nterprise Server 11 SP root (hd0,0) kernel /vmlinuz default root=/dev/system/root resume=/dev/system/swap \ splash=silent showopts initrd /initrd default ###Don't change this comment - YaST2 identifier: Original name: failsafe### title Failsafe -- SUS Linux nterprise Server 11 SP root (hd0,0) kernel /vmlinuz default root=/dev/system/root showopts ide=nodma \ apm=off noresume edd=off powersaved=off nohz=off highres=off \ processor.max_cstate=1 nomodeset x11failsafe initrd /initrd default ###Don't change this comment - YaST2 identifier: Original name: floppy### title Floppy rootnoverify (fd0) chainloader +1 Listing 2.5 Die Datei»/etc/grub/menu.lst«Ohne Auswahl des Benutzers innerhalb der durch timeout konfigurierten Sekunden beim Starten des Systems wird der Menüpunkt gewählt, der mit default konfiguriert wird, auch hier wird bei»0«mit dem Zählen begonnen. Die einzelnen Menüpunkte werden durch title beschrieben, die weiteren Parameter werden durch die folgenden Abschnitte erklärt.»root«der Parameter root gibt das Device bzw. die Partition an, von der gestartet werden soll, hier wird wie schon bei der Installation benutzt die besondere Schreibweise mit hd0,0 verwendet. In der Regel ist das die Partition, in der /boot zu finden ist, dort liegen auch der Betriebssystemkern und die Initial Ramdisk (initrd).»kernel«der Parameter kernel nimmt den Betriebssystemkern und seine Parameter auf. Da es beispielsweise bei SLS11 dafür eine eigene Partition /boot gibt, braucht der Pfadname nicht explizit angegeben werden. Besonders wichtig ist der Parameter root=, ohne dendas Linux-System gar nicht erstgestartet werden kann. Weitere Parameter werden einfach durch Leerzeichen getrennt an diese Zeile angehängt.»initrd«letztlich verweist initrd auf den Pfad der Initial Ramdisk, dies wird in Abschnitt 2.5,»Der Kernel und die initrd «, genauer beschrieben. Sie enthält alle Treiber, die notwendig sind, um das System zu starten, insbesondere (aber nicht nur) die Dateisystemtreiber, die nötig sind, um die unterschiedlichen für das System notwendigen Partitionen einzubinden

5 2 Bootvorgang 2.3 GRUB 2 ditieren beim Starten des Systems Bei Starten des Systems und Anzeigen des Bootmenüs können alle Parameter durch Druck auf die Taste () verändert werden. Diese Änderungen gelten nur für den neuen Start und werden nicht auf die Festplatte geschrieben. Auf manchen Systemen wird die Veränderungsmöglichkeit mit einem Standardpasswort geschützt, dieses lautet changeme, wenn es nicht verändert wurde. 2.3 GRUB 2 Mit GRUB 2 wurde GRUB von Grund auf neu entwickelt, die ntwickler haben sich sehr viel Zeit gelassen und sich mit kleinen Versionssprüngen der 2 genähert. So ist in Debian Wheezy die Version 1.99 Patchlevel 27 enthalten, die faktisch GRUB 2 entspricht, aber noch nicht die Versionsnummer 2 trägt. Nebenbei bemerkt hat GRUB nie die Version 1.0 erreicht, die aktuellste Version trägt die Nummer Booten von einem Software-RAID-1 Wenn Sie von einem Software-RAID-1 starten möchten, müssen Sie beachten, dass zum Zeitpunkt des Systemstarts der Kernel noch nicht aktiv ist und so auf den Spiegel als Ganzes die md-devices noch nicht zugegriffen werden kann. rst nach Aktivierung des Kernels wird wieder gespiegelt. Das ist insofern verschmerzbar, als dass der Bootloader beim Starten nur lesenden Zugriff benötigt. Als Vorarbeitmüssen Sie den Bootloader in denmaster Boot Record beider Festplatten schreiben und in das Bootmenü unter /boot/grub/menu.lst zwei inträge, einen für jede Festplatte, aufnehmen. In Listing 2.6 sehen Sie neben den inträgen für die beiden Festplatten den Parameter fallback, er sorgt dafür, dass der zweite Menüeintrag ausgeführt wird, falls der unter default angegebene nicht verfügbar ist: default 0 fallback 1 timeout 10 title root kernel initrd Debian GNU/Linux, kernel amd64 (hd0,1) /vmlinuz amd64 root=/dev/md2 ro /initrd.img amd64 title Debian GNU/Linux, kernel amd64 root (hd1,1) kernel /vmlinuz amd64 root=/dev/md2 ro initrd /initrd.img amd64 Listing 2.6»menu.lst«für ein Software-RAID-1 Falls die Spiegelung vor dem Start des Computers in Ordnung war, starten beide inträge dasselbe System. Inkompatibilität Die Konfigurationsdateien von GRUB und GRUB 2 sind nicht kompatibel zueinander! Funktionsweise Der große Unterschied von GRUB 2 im Vergleich zu GRUB ist, dass die Stages 1.5 und 2 zu einem einzigen Stage 2 zusammengelegt wurden. Dabei nutzt GRUB 2 einen minimalistischen und sehr kleinen Kern und viele Module, die je nach Bedarf nachgeladen werden können, um auf die Konfigurationsdatei zugreifen zu können. Auf diese Weise unterstützt GRUB 2 auch das Starten von LVM oder Software-RAIDs mit md Installation Um festzustellen, welche Version von GRUB auf Ihrem System verwendet wird, lohnt sich ein Blick auf dpkg -l grep grub bei Ubuntu und Debian bzw. rpm -qa grep grub bei open- SUS und SLS11. Ansonsten kann man GRUB 2 genauso wie GRUB mit grub-install (bei opensus mit grub2-install) installieren, allerdings müssen Sie bei GRUB 2 angeben, wo der Bootloader installiert werden soll. Dabei zeigt GRUB 2 deutlich weniger Ausgaben bei der Installation, siehe Listing 2.7: root@debian:~# grub-install /dev/sda Installation finished. No error reported. root@ubuntu:~# grub-install /dev/sda Installing for i386-pc platform. Installation finished. No error reported. opensuse:~# grub2-install /dev/sda Installation finished. No error reported. Listing 2.7 Installation»GRUB 2«68 69

6 2 Bootvorgang 2.3 GRUB Konfiguration Die Konfigurationsdatei von GRUB 2 finden Sie unter /boot/grub/grub.cfg. Bitte ändern Sie diese nicht von Hand, sie wird von den Skripten unter /etc/grub.d erstellt. In diesem Verzeichnis wird den Skripten eine Nummer vorangestellt, um die Reihenfolge festzulegen. Das Verfahren, die Konfiguration aus einzelnen Bausteinen (Skripten) zusammenstellen zu lassen, macht GRUB 2 deutlich flexibler und besser automatisierbar so werden installierte Kernel automatisch erkannt und in das Bootmenü aufgenommen: als GRUB. Die hohe Flexibilität wird allerdings durch eine komplexere Konfiguration erkauft. Ohne gutes Shell-Skripting-Know-How kommt man da nicht viel weiter. infachere Konfigurationen wie das Bootmenü sind relativ leicht machbar. instellungen, die das komplette Bootverhalten beeinflussen, wie beispielsweise Timeouts oder der Kernel, der standardmäßig gestartet werden soll, werden in der Datei /etc/default/grub vorgenommen. In der aktuellen Ubuntu-Version sind die folgenden Dateien im Verzeichnis /etc/grub.d zu finden: 00_header Mit diesem Skript werden die Standardeinstellungen aus der Datei /etc/default/grub gesetzt. 05_debian_theme DieseDateisorgtfür das Aussehendes Bootmenüs, hier werden Farben und Hintergrundbild definiert. 10_linux Dieses Skript nimmt alle installierten Kernel in das Bootmenü auf. 20_linux_xen Hier werden besondere instellungen und besondere Kernel für Xen-Virtualisierung getroffen. 20_memtest86+ Das Programmmemtest wird mit diesem Skript in das Bootmenü aufgenommen, es führt automatisierte Speichertests aus. 30_os-prober Dieses Skript sucht nach installierten (anderen) Betriebssystemen und nimmt sie in das Bootmenü auf. 30_uefi-firmware Besondere instellungen für UFI-Systeme werden mit diesem Skript getroffen. 40_custom Diese Datei ist für eigene Booteinträge vorhanden. 41_custom Hiermit wird die /boot/grub/custom.cfg eingebunden, sofern sie existiert. RADM Diese Datei enthält Hintergrundinformationen für die Skripte in diesem Verzeichnis. Die Skriptnummern, die mit 00, 10 oder 20 beginnen, sind reserviert. Alle Nummern dazwischen können Sie für eigene Skripte verwenden. Je nachdem, welche Nummer Sie Ihrem Skript geben, wird es früher oder später im Prozess ausgeführt. Apropos ausgeführt, die Skripte unterhalb von /etc/grub.d müssen alleausführbar sein. Wir legen jetzt einen neuen intrag im Bootmenü an. Dazu werden am nde der Datei 40_custom die Zeilen aus Listing 2.8 neu eingefügt: #!/bin/sh exec tail -n +3 $0 # This file provides an easy way to add custom menu entries. Simply type the # menu entries you want to add after this comment. Be careful not to change # the 'exec tail' line above. menuentry "Ubuntu Kernel " { set root='(hd0,1)' linux /boot/vmlinuz generic \ root=uuid=97152e6d-aef0-4b21-be4d-6bfbd1171e01 initrd /boot/initrd.img generic } Listing 2.8 igener intrag in der Datei»40_custom«Das Skript sorgt nur dafür, dass die Zeilen ab der dritten Zeile ausgegeben werden. Die eigentliche Konfiguration findet sich in der geschweiften Klammer nach dem menuentry, der den Text des intrags im Bootmenü enthält. Wie gewohnt kennzeichnet set root die Partition, in der sich das Verzeichnis /boot befindet. Natürlich bietet GRUB 2 eine Besonderheit: Die Festplattennummerierung beginnt bei 0, und die Nummerierung der Partition beginnt bei 1. So wird aus der Partition /dev/sdb3 unter GRUB hd1,2 und unter GRUB 2 hd1,3. Nachlinux (früher kernel) folgt der zu startende Betriebssystemkern. Und initrd istso, wie bereits beschrieben, die Initial Ramdisk. Mittels update-grub wird ein neuer Bootloader geschrieben, und beim nächsten Start finden wir unseren neuen intrag im Bootmenü

7 2 Bootvorgang 2.3 GRUB 2 Wie bereits beschrieben ist GRUB 2 modular aufgebaut und bringt keine Treiber mit, daher muss man eventuell noch Module mit dem Kommando insmod hinzuladen, um aus einem einfachen Menüeintrag ein startfähiges System zu machen. Beispiele dafür sind LVM, besondere Dateisysteme oder auch RAID. Alle verfügbaren Module Ihrer GRUB-2-Installation finden sich im Verzeichnis /boot/grub und enden auf.mod. In Listing 2.9 finden Sie die Module eines Debian-Wheezy-Systems: root@debian:/boot/grub# ls *.mod 915resolution.mod gcry_whirlpool.mod play.mod acpi.mod gettext.mod png.mod adler32.mod gfxmenu.mod probe.mod affs.mod gfxterm.mod pxecmd.mod afs_be.mod gptsync.mod pxe.mod afs.mod gzio.mod raid5rec.mod aout.mod halt.mod raid6rec.mod ata.mod hashsum.mod raid.mod ata_pthru.mod hdparm.mod read.mod at_keyboard.mod hello.mod reboot.mod befs_be.mod help.mod regexp.mod befs.mod hexdump.mod reiserfs.mod biosdisk.mod hfs.mod relocator.mod bitmap.mod hfsplus.mod scsi.mod bitmap_scale.mod iorw.mod search_fs_file.mod blocklist.mod iso9660.mod search_fs_uuid.mod boot.mod jfs.mod search_label.mod bsd.mod jpeg.mod search.mod btrfs.mod keylayouts.mod sendkey.mod bufio.mod keystatus.mod serial.mod cat.mod legacycfg.mod setjmp.mod chain.mod linux16.mod setpci.mod cmostest.mod linux.mod sfs.mod cmp.mod loadenv.mod sleep.mod configfile.mod loopback.mod squash4.mod cpio.mod lsacpi.mod tar.mod cpuid.mod lsapm.mod terminal.mod crypto.mod lsmmap.mod terminfo.mod cs5536.mod ls.mod test_blockarg.mod datehook.mod lspci.mod testload.mod date.mod lvm.mod test.mod datetime.mod lzopio.mod tga.mod dm_nv.mod mdraid09.mod trig.mod drivemap.mod mdraid1x.mod true.mod echo.mod memdisk.mod udf.mod efiemu.mod memrw.mod ufs1.mod elf.mod minicmd.mod ufs2.mod example_functional_test.mod minix2.mod uhci.mod ext2.mod minix.mod usb_keyboard.mod extcmd.mod mmap.mod usb.mod fat.mod msdospart.mod usbms.mod font.mod multiboot2.mod usbserial_common.mod fshelp.mod multiboot.mod usbserial_ftdi.mod functional_test.mod nilfs2.mod usbserial_pl2303.mod gcry_arcfour.mod normal.mod usbtest.mod gcry_blowfish.mod ntfscomp.mod vbe.mod gcry_camellia.mod ntfs.mod vga.mod gcry_cast5.mod ntldr.mod vga_text.mod gcry_crc.mod ohci.mod video_bochs.mod gcry_des.mod part_acorn.mod video_cirrus.mod gcry_md4.mod part_amiga.mod video_fb.mod gcry_md5.mod part_apple.mod videoinfo.mod gcry_rfc2268.mod part_bsd.mod video.mod gcry_rijndael.mod part_gpt.mod videotest.mod gcry_rmd160.mod part_msdos.mod xfs.mod gcry_seed.mod part_sun.mod xnu.mod gcry_serpent.mod part_sunpc.mod xnu_uuid.mod gcry_sha1.mod parttool.mod xzio.mod gcry_sha256.mod password.mod zfsinfo.mod gcry_sha512.mod password_pbkdf2.mod zfs.mod gcry_tiger.mod pbkdf2.mod gcry_twofish.mod pci.mod Listing 2.9 GRUB-2-Module eines Debian-Wheezy-Systems Auf dem gleichen System findet sich in der /boot/grub/grub.cfg ein Beispiel dafür, wie ein Teil dieser Module eingesetzt wird (siehe Listing 2.10):... ### BGIN /etc/grub.d/10_linux ### menuentry 'Debian GNU/Linux, with Linux amd64' \ --class debian --class gnu-linux --class gnu --class os { load_video insmod gzio insmod part_msdos insmod ext2 set root='(hd0,msdos1)' search --no-floppy --fs-uuid --set=root a7cbb b-4d43-a10b-40e0d34466c4 echo 'Loading Linux amd64...'

8 2 Bootvorgang 2.4 Bootloader Recovery linux /vmlinuz amd64 root=/dev/mapper/debian-root ro quiet echo 'Loading initial ramdisk...' initrd /initrd.img amd64 }... Listing 2.10 Die Optionen des Standardkernels aus der»/boot/grub/grub.cfg«änderungen in der Datei /boot/grub/grub.cfg werden nicht automatisch übernommen. Mit dem Kommando update-grub wird GRUB 2 aktualisiert, wiein Listing 2.11zu sehen ist: root@debian:~# update-grub Generating grub.cfg... Found linux image: /boot/vmlinuz amd64 Found initrd image: /boot/initrd.img amd64 done Listing 2.11»update-grub«Interessant ist, dass die Konfigurationsdatei /etc/default/grub ein Shell-Skript ist. Allerdings werden dort nur Variablen gesetzt, die nach Aufruf von update-grub durch /etc/grub.d/ 00_header ausgewertet werden. In der folgenden Auflistung finden Sie die wichtigsten Variablen: GRUB_DFAULT=0 Hiermit wird der Standardeintrag gesetzt. 2.4 Bootloader Recovery s passiert selten, aber wenn Sie Ihr System aufgrund einer Fehlkonfiguration des Bootloaders nicht mehr starten können, sollten Sie den Bootloader reparieren. Dazu können Sie den Rechner von einer beliebigen Live-CD 1 oder DVD oder von einem USB-Stick neu starten. Der einfachste Weg, eine Reparatur durchzuführen, ist, die Live-CD des Systems zu verwenden, mit der Sie den Rechner installiert haben. Beachten Sie jedoch, dass Sie in jedem Fall bei Benutzung einer anderen Rettungs-CD die gleiche Architektur verwenden wie das installierte System. Nach dem Start des Rettungssystems wird die Festplatte Ihres defekten Systems eingebunden. Das bedeutet, dass Sie alle Partitionen mounten. Im Regelfall werden die Partitionen unter /mnt eingebunden. Sie können natürlich auch eigene Verzeichnisse verwenden, wenn Sie dabei keines der vom Live-System benutzten Verzeichnisse nutzen. Das Kommando fdisk -l zeigt Ihnen alle gefundenen Festplatten an. Falls Software-RAIDs oder LVM benutzt werden, müssen diese vor der Benutzung aktiviert werden. Wie das geht, finden Sie in Kapitel 3,»Festplatten und andere Devices«. Device Boot Start nd Blocks Id System /dev/sda1 * Linux /dev/sda xtended /dev/sda e Linux LVM Listing 2.12 Ausgabe»fdisk -l«auf einem Testsystem 2 GRUB_TIMOUT=5 Nach Ablauf der durch TIMOUT gesetzten Zeit wird der Standardeintrag gestartet. GRUB_HIDDN_TIMOUT=0 Wenn nur ein Betriebssystem existiert, wird dieser Wert als Wartezeit benutzt. Sobald ein weiterer intrag hinzukommt, ist der Wert bedeutungslos. GRUB_HIDDN_TIMOUT_QUIT=true Mit true wird kein Countdown angezeigt, bei false wird er entsprechend angezeigt. GRUB_CMDLIN_LINUX= Hiermit werden Standardoptionen für jede linux-zeile gesetzt. In Listing 2.12 finden Sie den seltenen Fall eines Systems ohne eigene swap-partition. Vermutlich findet sich in der ersten Partition das boot-verzeichnis, was wir durch Mounten verifizieren können (siehe Listing 2.13): Rescue:~# mount /dev/sda1 /mnt Rescue:~# ls /mnt config amd64 initrd.img amd64 System.map amd64 grub lost+found vmlinuz amd64 Rescue:~# umount /mnt Listing 2.13 Mounten des vermeintlichen»boot«-filesystems Die Variablen werden erst nach einem erneuten Aufruf von update-grub gültig. Die fünfte Partition wird vom Logical Volume Manager (LVM) verwaltet. Mit dem Kommando lvs können wir uns die gefundenen Logical Volumes anzeigen lassen. Der Parameter -o +lv_path sorgt dafür, dass uns auch gleich der Pfad für das Mounten gezeigt wird (siehe Listing 2.14): 1 Zum Beispiel die»system Rescue CD«,

9 2 Bootvorgang 2.5 Der Kernel und die»initrd«rescue:~# lvs -o +lv_path LV VG Attr LSize Pool Origin Data% Move Log Copy% Convert \ Path root debian -wi-ao g \ /dev/debian/root swap_1 debian -wi-ao m \ /dev/debian/swap_1 Listing 2.14 Gefundene Partition im LVM An dieser Stelle haben wir alle Informationen zusammen, um die Dateisysteme benutzen zu können (siehe Listing 2.15): Rescue:~ # mount /dev/debian/root /mnt Rescue:~ # mount /dev/sda1 /mnt/boot/ Listing 2.15 Mounten der Dateisysteme Um das Linux-System komplett zu machen, müssen wir die dynamischen Pseudo-Dateisysteme (/dev, /proc und /sys) aus der Live-CD in die Verzeichnisse unterhalb von /mnt einbinden. Das funktioniert über Bind-Mounts. Wenn das nicht passieren würde, erhielten wir nach Wechsel der root-umgebung mittels chroot (»change root environment«) keine Informationen über verbundene Geräte und Kernelparameter (siehe Listing 2.16): Rescue:~ # mount --bind /dev /mnt/dev Rescue:~ # mount --bind /proc /mnt/proc Rescue:~ # mount --bind /sys /mnt/sys Listing 2.16 Bind-Mount der Pseudodateisysteme Damit sind jetzt alle Vorarbeiten abgeschlossen, um via chroot auf das System zu wechseln und den Bootloader zu reparieren (siehe Listing 2.17): Rescue:~ # chroot /mnt Rescue:/ # grub-install Rescue:/ # exit Listing 2.17 Neuinstallation des Bootloaders Sobald Sie fertig sind, müssen alle Dateisysteme ausgehängt werden. Sie müssen anschließend das System neu starten. 2.5 Der Kernel und die»initrd«beim Laden des Kernels gibt es ein klassisches Henne-i-Problem: Der Kernel probiert nämlich zunächst, alle notwendigen Module zu laden, die für den Zugriff auf die Hardware notwendig sind. Das sind insbesondere die Treiber zum Ansprechen der Festplatte und des Dateisystems. Die dafür notwendigen Module liegen aber auf dem noch nicht lesbaren Dateisystem. Um dieses Dilemma zu lösen, lädt der Bootloader nicht nur den Kernel direkt in den Speicher, sondern auch die Initial Ramdisk (initrd). Die initrd besteht aus einem komprimierten cpio-archiv und enthält ein absolut minimales Linux mit allen für den Start notwendigen Modulen. Der Kernel benutzt die initrd als root-filesystem. Sobald alle nötigen Treiber geladen sind, bindet der Kernel das eigentliche root-filesystem ein und startet den init-prozess »initrd«erstellen und modifizieren Bei der Installation eines Systems wird auch eine Initial Ramdisk (initrd) erstellt, die Treiber enthält, die für den Start des Rechners benötigt werden, bevor die Dateisysteme verfügbar sind. Diese Ramdisk wird bei jedem Kernelupdate neu erstellt und mit neuen Versionen der Treiber versehen. Wenn Sie allerdings Hardware benutzen, die Treiber benötigt, die nicht im Kernel vorhanden sind, wie beispielsweise besondere RAID-Controller oder Netzwerkkarten, so müssen Sie wenn Sie Ihr System von den Geräten aus starten wollen selbst Hand anlegen, wenn das nicht die Installationsroutine des Herstellers für Sie übernimmt. Die verschiedenen Distributionen nutzen unterschiedliche Tools für die rstellung. In den folgenden Abschnitten finden Sie die Beschreibungen für die im Buch unterstützten Distributionen, gefolgt von einem Abschnitt über die komplett manuelle rstellung der Initial Ramdisk. Debian und Ubuntu Debian und Ubuntu benutzen mkinitramfs und update-initramfs. Wenn Sie nicht besondere Gründe haben, sollte immer update-initramfs verwendet werden, da dieses Kommando unter anderem auch mkinitramfs auf Basis der bereits bestehenden Konfiguration aufruft. Die rstellung der initrd wird über die Konfigurationsdatei /etc/initramfs-tools/initramfs.conf und weitere Dateien innerhalb des Verzeichnisses /etc/initramfs-tools gesteuert. Aufgrund der vielen Kommentare in den Dateien werden Sie schnell zum Ziel kommen. inen besonderen Blick verdient die wichtigste Variable, MODULS. Sie kann verschiedene Werte annehmen, wie folgende Auflistung zeigt:

10 2 Bootvorgang 2.5 Der Kernel und die»initrd«most Das ist die Standardeinstellung bei Ubuntu und Debian. Damit werden fast alle Dateisystem- und Hardwaretreiber übernommen. Die daraus resultierende sehr große Initial Ramdisk kann dafür aber auch fast jedes System starten. dep Das laufende System wird analysiert, um festzustellen, welche Module wichtig sind. Diese instellung verkleinert die Initial Ramdisk auf ein Minimum. netboot Wie der Name es beschreibt, werden mit dieser instellung nur Treiber verwendet, die für das Starten vom Netz nötig sind. list Ausschließlich Module aus /etc/initramfs-tools/modules werden zum Bau der Initial Ramdisk verwendet, dies erlaubt die größtmögliche Kontrolle. (excluding hid-*ff.ko hid-a4tech.ko hid-cypress.ko hid-dr.ko hid-elecom.ko \ hid-gyration.ko hid-icade.ko hid-kensington.ko hid-kye.ko hid-lcpower.ko \ hid-magicmouse.ko hid-multitouch.ko hid-ntrig.ko hid-petalynx.ko \ hid-picolcd.ko hid-pl.ko hid-ps3remote.ko hid-quanta.ko hid-roccat-ko*.ko \ hid-roccat-pyra.ko hid-saitek.ko hid-sensor-hub.ko hid-sony.ko \ hid-speedlink.ko hid-tivo.ko hid-twinhan.ko hid-uclogic.ko hid-wacom.ko \ hid-waltop.ko hid-wiimote.ko hid-zydacron.ko) Adding module /lib/modules/ amd64/kernel/drivers/hid/hid.ko... Adding library /lib/x86_64-linux-gnu/libuuid.so.1 Calling hook dmsetup Building cpio /boot/initrd.img amd64.new initramfs Listing 2.18 Neuerstellen einer»initrd«2 Auch ohne weitere Konfiguration werden die Module aus /etc/initramfs-tools/modules bei den Parametern most, dep und netboot zur Initial Ramdisk hinzugefügt. Die Konfigurationen in den Dateien unterhalb von /etc/initramfs-tools/conf.d können die Werte aus /etc/initramfs-tools/initramfs.conf überschreiben. Um eine neue initrd zu erstellen bzw. die bestehende aktualisieren zu lassen, können Sie mit update-initramfs den Neubau starten. Die unten stehenden Parameter helfen bei der rstellung: update-initramfs -u Hiermit werden alle vorhandenen initrds aktualisiert. update-initramfs -k KRNL Dieser Paremeter wird benötigt, wenn nur die initrds einer bestimmten Kernelversion aktualisiert werden sollen. update-initramfs -c Dieser Parameter erstellt komplett neue Initial Ramdisks. Der Name der initrd ergibt sich aus dem Namen des Kernels. ine vorhandene Ramdisk wird somit bei jedem Aufruf von update-initramfs überschrieben. Wenn Sie dieses Verhalten nicht wünschen, sollten Sie den Parameter backup_initramfs=yes in der Datei /etc/initramfs-tools/update-initramfs.conf setzen oder manuelle Backups erstellen (siehe Listing 2.18): root@debian:~# update-initramfs -v -k amd64 -c update-initramfs: Generating /boot/initrd.img amd64 Copying module directory kernel/drivers/hid Wenn der Name der initrd bereits existierte, ist nichts weiter zu tun. Sollten Sie aber einen neuen Namen verwenden, muss im Bootloader der entsprechende Name eingetragen werden, sonst können Sie das System nicht mehr starten. SLS11 und opensus Anders als bei Ubuntu und Debian nutzen SLS11 und opensus das Skript mkinitrd,umeine Initial Ramdisk zu erstellen. Das Skript ermittelt die Treiber, die aufgenommen werden müssen, und nutzt die Informationen aus /etc/sysconfig/kernel, in der eine Liste von Modulen zu finden ist, die zusätzlich hinzugefügt werdensollen (siehe Listing2.19):... Kernel image: /boot/vmlinuz default Initrd image: /boot/initrd default Root device: /dev/system/root (mounted on / as ext4) Resume device: /dev/system/swap Kernel Modules: thermal_sys thermal processor fan dm-mod dm-log dm-region-hash \ dm-mirror dm-snapshot scsi_dh scsi_dh_rdac scsi_dh_emc scsi_dh_hp_sw \ scsi_dh_alua ata_piix linear Features: acpi dm block lvm2... Listing 2.19 Beispiel»mkinitrd«auf opensus Die Installation des Systems setzt automatisch die Variable INITRD_MODULS. Wenn diese Liste um eigene inträge ergänzt wird, muss anschließend mkinitrd aufgerufen werden. Analog zu update-initramfs bei Ubuntu und Debian bietet auch mkinitrd einige Optionen an, die Ihnen helfen, die initrd anzupassen: 78 79

11 2 Bootvorgang 2.6»Upstart«-k KRNL Angabe des Kernels, für das die initrd gebaut werden soll. Ohne Angabe des Parameters wird vmlinuz benutzt. -i INITRD setzt den Namen der initrd. Ohne diese Angabe wird /boot/initrd genommen. -m MODULS nimmt eine Liste von Modulen auf der Kommandozeile, ansonsten wird der Inhalt der Variablen INITRD_MODULS aus /etc/sysconfig/kernel ausgelesen. -f FATURS setzt Funktionalitäten für den Kernel, abhängig davon werden weitere Module und Skripte eingebunden. Als Beispiel seien hier Software-RAID (Parameterdm)undLogical Volume Manager (Parameter lvm2) genannt. In Listing 2.20 sehen Sie einen Beispielaufruf von mkinitrd: opensuse:~ # mkinitrd -k vmlinuz default -i initrdtest -m ext4 -f \ "lvm2 dm block" Kernel image: /boot/vmlinuz default Initrd image: /boot/initrdtest Root device: /dev/system/root (mounted on / as ext4) Resume device: /dev/system/swap Kernel Modules: thermal_sys thermal processor fan dm-mod dm-log dm-region-hash \ dm-mirror dm-snapshot scsi_dh scsi_dh_rdac scsi_dh_emc scsi_dh_hp_sw \ scsi_dh_alua ata_piix linear Features: acpi dm block lvm2 Listing 2.20 Beispielaufruf von»mkinitrd«2.5.2»initrd«manuell modifizieren Zusätzlich zu den vorgestellten Methoden, die zugegebenermaßen relativ beschränkt sind, lässt sich die initrd auch manuell verändern. Als Basis für Ihre Arbeiten nehmen Sie sich bitte eine vorhandene initrd und packen diese aus. Listing 2.21 zeigt Ihnen, dass es sich bei der initrd um ein minimales root-filesystem handelt: root@debian:~# mkdir /var/tmp/initrd root@debian:~# cd /var/tmp/initrd/ root@debian:/var/tmp/initrd# gzip -dc /boot/initrd.img amd64 \ cpio --extract --make-directories blocks root@debian:/tmp/initrd# ls -l total 40 drwxr-xr-x 2 root root 4096 Aug 10 16:14 bin drwxr-xr-x 3 root root 4096 Aug 10 16:14 conf drwxr-xr-x 6 root root 4096 Aug 10 16:14 etc -rwxr-xr-x 1 root root 6797 Aug 10 16:14 init drwxr-xr-x 6 root root 4096 Aug 10 16:14 lib drwxr-xr-x 2 root root 4096 Aug 10 16:14 lib64 drwxr-xr-x 2 root root 4096 Aug 10 16:14 run drwxr-xr-x 2 root root 4096 Aug 10 16:14 sbin drwxr-xr-x 6 root root 4096 Aug 10 16:14 scripts Listing 2.21»initrd«entpacken In dem resultierenden Verzeichnis /var/tmp/initrd können Sie nun Ihre Änderungen einpflegen und danach alles wieder einpacken (siehe Listing 2.22): root@debian:/var/tmp/initrd# find. \ cpio --create --format=newc \ gzip > /boot/initrd.adminbuch blocks Listing 2.22»initrd«einpacken In der Datei /boot/initrd.adminbuch findet sich nun die initrd, die alle Ihre Änderungen enthält. 2.6»Upstart«Nach dem Bootvorgang, in dem der Kernel das root-filesystem eingebunden und alle notwendigen Module geladen hat, übernimmt der init-daemon den weiteren Ablauf. Der klassische init-prozess folgt dem in System V 2 vorgestellten Verfahren und wird nach diesem auch SysVinit genannt. r ist verantwortlich für das Starten der Dienste in der richtigen Reihenfolge, das Folgen und auch den Wechsel von Runleveln sowie für das Stoppen von Prozessen. Dieses Verfahren ist sehr robust, aber leider auch sehr statisch. Upstart ist ein potenzieller Nachfolger, der vom statischen Starten von Skripten übergeht zum eventbasierten Starten. So können Bedingungen definiert werden, die erfüllt sein müssen, um Dienste starten zu können (beispielsweise wird der Webserver erst dann gestartet, wenn das Netzwerk verfügbar ist, oder ein Virenscanner, wenn ein USB-Stick eingesteckt wird). Der Start von Diensten mit Upstart ist hoch parallelisierbar. Als besonderes Feature ist Upstart auch in der Lage, abgestürzte Dienste neu zu starten

12 2 Bootvorgang 2.6»Upstart«Ursprünglich von Canonical entwickelt, ist Upstart seit Ubuntu 6.10 (»dgy ft«) Bestandteil der Distribution. In der Übergangsphase wurden Dienste trotzdem mit SysVinit-Skripten gestartet, und alle neueren ntwicklungen wurden mit Upstart-Skripten versehen. opensus wird voraussichtlich auf die Alternative zu Upstart, nämlich systemd,setzen,daher wirddas vermutlichauchdas Ziel für SUS Linux nterprise Server sein. Momentan setzt eine Konsolidierung der init-systeme ein, Red Hat nterprise Linux 7 und ebenfalls CentOS 7setzenaufsystemd, Debian wird ebenfalls auf systemd setzen, wird aber noch den SysVinit als Alternative anbieten. Canonical rückt aus diesem Grund auch von Upstart ab und will in weiteren Versionen vermutlich auch auf systemd umsteigen. Wir beschränken uns hier auf Upstart, weil der Wandel in allen Distributionen noch nicht vollzogen ist Funktionsweise Da bei Upstart alle Dienste durch einen init-daemon, verwaltet werden, ist ein Wechsel von SysVinit sehr leicht möglich. Allerdings verwendet Upstart nicht den SysVinit-Daemon, sondern bringt einen eigenen mit. Prozesse, die mit Upstart verwaltet werden, nennt man Jobs. Sie werden definiert durch eine Konfigurationsdatei (JOBNAM.conf in /etc/init.d), die beschreibt, welche Bedingungen für das Starten und Stoppen erfüllt sein müssen. Skripte des originalen SysVinit bleiben weiterhin unterhalb von /etc/init.d. Der Dienst rsyslog ist ein einfaches Beispiel, das mit sehr wenigen Abhängigkeiten auskommt, wie Listing 2.23 zeigt: # rsyslog - system logging daemon # # rsyslog is an enhanced multi-threaded replacement for the traditional # syslog daemon, logging messages from applications description start on filesystem stop on runlevel [06] expect fork respawn "system logging daemon" pre-start script /lib/init/apparmor-profile-load usr.sbin.rsyslogd end script script. /etc/default/rsyslog exec rsyslogd $RSYSLOGD_OPTIONS end script Listing 2.23»rsyslog.conf«in Upstart-Skript kann minimal aus einer Zeile bestehen, die mittels exec einen Dienst startet. Dieser Dienst würde allerdings nie automatisch gestartet werden, da Upstart die reignisse nicht kennt, die für den Start oder Stopp notwendig wären. Die Bedingungen kann man im Skript sehen, zum einen ist da start on filesystem, sobald also das vent filesystem eingetreten ist, kann der rsyslogd starten. Das vent filesystem wird vom Befehl mountall ausgelöst. Der Dienst rsyslogd soll gestoppt werden (stop on runlevel [06]), wenn entweder Runlevel 0 oder 6 erreicht wurde. Diese igenschaft ist aus Gründen der Kompatibilität zum SysVinit vorhanden. Wichtig ist noch die Direktive expect fork. Sie bedeutet, dass der Hauptprozess wenigstens einen Kindprozess bekommt und sich selbst beendet. Würde diese Direktive fehlen, wüsste Upstart nicht, dass der Dienst sauber gestartet wurde. Die Direktive respawn startet den Dienst neu, sobald er abgestürzt ist vents im Detail Die wichtigsten reignisse von Upstart sehen Sie hier in der Übersicht: startup wird ausgelöst, sobald der init-daemon seine Startphase beendet hat. Dienste ohne weitere Voraussetzungen können direkt danach starten. starting/stopping Wenn ein Dienst dabei ist, hochzufahren, wird das starting-vent ausgelöst;analog dazu stopping, wenn ein Job dabei ist, herunterzufahren. started/stopped Bei diesen vents ist der Dienst gestartet oder gestoppt. In Listing 2.24 finden Sie die Ausgabe des Kommandos apropos event signalling, das alle vents enthält: root@ubuntu:/etc/init# apropos event signalling acpi_listen (8) - ACPI event listener acpid (8) - Advanced Configuration and Power Interface event daemon all-swaps (7) - event signalling that all swap partitions have been ac... control-alt-delete (7) - event signalling console press of Control-Alt-Delete dbus-event (7) - event signalling that a dbus signal has been emitted

13 2 Bootvorgang 2.6»Upstart«epoll (7) - I/O event notification facility file-event (7) - event signalling that a file has changed filesystem (7) - event signalling that filesystems have been mounted inotify (7) - monitoring filesystem events iwevent (8) - Display Wireless vents generated by drivers and setti... keyboard-request (7) - event signalling console press of Alt-UpArrow local-filesystems (7) - event signalling that local filesystems have been mou... mounted (7) - event signalling that a filesystem has been mounted mounting (7) - event signalling that a filesystem is mounting nologin (5) - prevent unprivileged users from logging into the system pam_nologin (8) - Prevent non-root users from login power-status-changed (7) - event signalling change of power status remote-filesystems (7) - event signalling that remote filesystems have been m... runlevel (7) - event signalling change of system runlevel session-end (7) - event signalling session shutdown sigevent (7) - structure for notification from asynchronous routines socket-event (7) - event signalling that a socket connection has been made started (7) - event signalling that a job is running starting (7) - event signalling that a job is starting startup (7) - event signalling system startup stopped (7) - event signalling that a job has stopped stopping (7) - event signalling that a job is stopping systemd-udevd (8) - Device event managing daemon systemd-udevd-control.socket (8) - Device event managing daemon systemd-udevd-kernel.socket (8) - Device event managing daemon systemd-udevd.service (8) - Device event managing daemon udevd (8) - Device event managing daemon upstart-event-bridge (8) - Bridge between system Upstart and session Upstart upstart-events (7) - Well-known Upstart events summary virtual-filesystems (7) - event signalling that virtual filesystems have been... Listing 2.24 Liste der vents igene vents erzeugen Sie mit initctl, so erstelltinitctl emit yippieh das reignis yippieh. Das vent alleine macht allerdings noch gar nichts. Im Folgenden erklären wir, was sich mit einem vent durchführen lässt: start on started cron Wenn cron gestartet wurde, soll der Job starten. start on starting networking Dieser Job startet gleichzeitig mit networking. stop on runlevel [!5] Dieser Job wird bei Übergang in alle Runlevel außer 5 gestoppt. start on started aaa and (started bbb or started ccc) Verknüpfungen sind auch möglich, dazu gibt es and und or und Klammern. start on started abc until starting xyz Wenn abc gestartet wurde und xyz noch nicht, wird der Job ausgeführt. Achtung: Der Job wird nicht gestoppt, wenn xyz im späteren Verlauf gestartet wird Prozessdefinitionen Wie Sie bereits in Listing 2.23 gesehen haben, gibt es weitere Programmierelemente, die verwendet werden können. So werden Blöcke zwischen script und end script als Shell-Skripte interpretiert. Zusätzlich dazu können mit pre-start, post-start, pre-stop und post-stop noch Bedingungen definiert werden, die für das nachfolgende exec oder einen folgenden script/end script-block gelten. Klassischerweise kann man im pre-start prüfen, ob die Bedingungen für einen Start gegeben sind (existieren die Dateien, die benötigt werden, überhaupt?). Und in einem poststop-teil können temporäre Dateien weggeräumt werden Anzeige aller»upstart«-jobs Alle bekannten Jobs, inklusive Status, zeigt der Befehl initctl list an (siehe Listing 2.25): root@ubuntu:~# initctl list mountall-net stop/waiting mountnfs-bootclean.sh start/running passwd stop/waiting rc stop/waiting rsyslog start/running, process 397 startpar-bridge stop/waiting tty4 start/running, process 776 udev start/running, process 293 upstart-udev-bridge start/running, process 287 ureadahead-other stop/waiting apport start/running console-setup stop/waiting hwclock-save stop/waiting irqbalance stop/waiting plymouth-log stop/waiting systemd-logind start/running, process 398 tty5 start/running, process 781 failsafe stop/waiting

14 2 Bootvorgang 2.6»Upstart«mountall.sh start/running atd start/running, process 863 dbus start/running, process 380 mounted-var stop/waiting plymouth-shutdown stop/waiting plymouth stop/waiting resolvconf start/running ssh start/running, process 838 udev-fallback-graphics stop/waiting checkroot.sh start/running control-alt-delete stop/waiting hwclock stop/waiting mounted-proc stop/waiting setvtrgb stop/waiting shutdown stop/waiting cron start/running, process 862 mountall stop/waiting mounted-debugfs stop/waiting mountkernfs.sh start/running console stop/waiting mounted-run stop/waiting acpid start/running, process 858 checkfs.sh start/running checkroot-bootclean.sh start/running kmod stop/waiting mountnfs.sh start/running plymouth-stop stop/waiting rcs stop/waiting ufw start/running wait-for-state stop/waiting bootmisc.sh start/running flush-early-job-log stop/waiting friendly-recovery stop/waiting rc-sysinit stop/waiting upstart-socket-bridge start/running, process 558 mountdevsubfs.sh start/running tty2 start/running, process 786 udevtrigger stop/waiting upstart-file-bridge start/running, process 426 container-detect stop/waiting mounted-dev stop/waiting mtab.sh start/running tty3 start/running, process 787 udev-finish stop/waiting hostname stop/waiting mountall-reboot stop/waiting mountall-shell stop/waiting mounted-tmp stop/waiting network-interface (lo) start/running network-interface (eth0) start/running plymouth-ready stop/waiting plymouth-splash stop/waiting plymouth-upstart-bridge stop/waiting tty1 start/running, process 955 udevmonitor stop/waiting dmesg stop/waiting mountall-bootclean.sh start/running network-interface-security (network-interface/eth0) start/running network-interface-security (network-interface/lo) start/running network-interface-security (networking) start/running networking start/running procps stop/waiting tty6 start/running, process 789 console-font stop/waiting network-interface-container stop/waiting ureadahead stop/waiting Listing 2.25 Jobs eines minimalen Ubuntu LTS Die Informationen, die Sie in Listing 2.25 finden können, sind zum Teil leicht irreführend. in Status stop/waiting kann bedeuten, dass der Dienst gestoppt oder noch nicht ausgeführt wurde. Insbesondere das waiting sehen Sie auch, wenn keine Bedingung hinterlegt wurde. Sicher können Sie nur sein, dass es eine entsprechende Konfigurationsdatei gibt. Der erste Teil der Informationen in Listing 2.25 beinhaltet den Status, der erreicht werden soll: start oder stop. Der Wert hinter dem Schrägstrich zeigt, wo sich der Prozess auf dem Weg zum Ziel befindet. ine aktive Prozess-ID wird ebenfalls angezeigt. Sollte der Status pre-start oder post-stop sein, sehen Sie die ID des Pre- oder Post-Prozesses Anzeige und Überprüfung der Job-Konfigurationen Mit initctl show-config können Sie sich die Job-Konfigurationen anzeigen lassen. Wenn Sie einen Parameter mitgeben, wird nur der Job angezeigt, den Sie als Parameter übergeben haben, ansonsten sehen Sie alle Job-Konfigurationen (siehe Listing 2.26):

15 2 Bootvorgang 2.6»Upstart«mysql start on runlevel [2345] stop on starting rc RUNLVL=[016] initctl show-config mountall mountall emits virtual-filesystems emits local-filesystems emits remote-filesystems emits all-swaps emits filesystem emits mounting emits mounted start on startup stop on starting rcs initctl show-config shutdown shutdown start on power-status-changed Listing 2.26 Beispiele für»show-config«2.6.6 Starten, Stoppen und Neustarten von Diensten Wie bereits erläutert ist Upstart abwärtskompatibel mit SysVinit. Sie können noch immer die Dienste mittels der Skripte in /etc/init.d starten oder stoppen. Allerdings weist Sie das System darauf hin, wenn ein Dienst bereits direkt zu Upstart migriert wurde. Betrachten Sie dazu Listing 2.28: /etc/init.d/cron restart Rather than invoking init scripts through /etc/init.d, use the service(8) utility, e.g. service cron restart Since the script you are attempting to invoke has been converted to an Upstart job, you may also use the stop(8) and then start(8) utilities, e.g. stop cron ; start cron. The restart(8) utility is also available. cron stop/waiting cron start/running, process 2782 root@ubuntu:~# ls -l /etc/init.d/cron lrwxrwxrwx 1 root root 21 Mar 9 12:56 /etc/init.d/cron -> /lib/init/upstart-job Listing 2.28 Klassisches Neustarten von»cron«2 Die Datenbank mysql ist ein gutes Beispiel dafür, dass es kein echtes Upstart-Skript gibt, sondern nur das SysVinit-Skript übernommen wurde. Das Skript mountall hingegen definiert eine ganze Reihe an vents, die durch emits charakterisiert werden. Wie auf»externe«veränderungen reagiert wird, zeigt shutdown. Konfigurationen können mittels initctl check-config überprüft werden, das Kommando gibt die Jobs aus, die entweder nicht gestartet oder gestoppt werden können. Häufig sind nicht installierte Zusatztools der Grund, vergleichen Sie dazu Listing root@ubuntu:~# initctl check-config plymouth-shutdown start on: unknown job uxlaunch start on: unknown job xdm plymouth-stop start on: unknown job oem-config start on: unknown job ubiquity start on: unknown job uxlaunch start on: unknown job lightdm start on: unknown job lxdm start on: unknown job xdm start on: unknown job kdm start on: unknown job gdm Listing 2.27»initctl check-config«wie Sie in Listing 2.28 sehen können, ist das Skript in /etc/init.d ein Verweis auf /lib/init/ upstart-job. Letzteres sorgt dafür, dass die Upstart-Kommandos für den Neustart verwendet werden. Der richtige neue Weg wäre allerdings root@ubuntu:~# service cron restart cron stop/waiting cron start/running, process 2809 Listing 2.29 Neustarten von»cron«mit»upstart«2.6.7 Abschlussbemerkung Die hier vorgestellten Befehle und Direktiven bilden nur einen Ausschnitt der Möglichkeiten von Upstart ab. Dieser Ausschnitt ist jedoch eine gute Basis für weitere Schritte mit Upstart, eigene Skripte und Job-Definitionen können Sie damit bereits jetzt erstellen. Über die Manpage von init (man 5 init) können Sie noch einige andere Direktiven finden. Nachdem sich auch Canonical aus der Upstart-ntwicklung zurückgezogen hat, lohnt es sich nicht, die eigenen Skripte auf dieses init-system umzustellen, da systemd vermutlich die Nachfolge antreten wird. In Ihren bestehenden Installationen werden Sie aber noch mit Upstart konfrontiert

16 Kapitel 6 Paketmanagement Der Umgang mit Software Quellcode, Paket und Paketmanagementlösungen steht im Vordergrund dieses Kapitels. rfahren Sie, wie Sie Ihre selbst entwickelte Software in Pakete schnüren, Update-Pakete erstellen und das Paketmanagement Ihrer Distribution richtig einsetzen. Zu den Aufgaben einer Paketverwaltung (engl. packet management) gehören das Installieren, das Aktualisieren und das Deinstallieren von Software. Schon in den Anfangsjahren von Linux wurde solch ein System erforderlich. Durch die wachsende Anzahl von Programmen der GNU-Sammlung konnten Linux-Systeme fast alle Aufgaben bewältigen. Lediglich das Installieren der Software sorgte für Unmut, da das Übersetzen des Quellcodes (Kompilieren) auf dem eigenen System oft beschwerlich war. Vorausgesetzte Software (dependencies1) mussten von Hand nachinstalliert werden, Updates sorgten für Konflikte mit anderer installierter Software, und die Deinstallation musste ebenfalls von Hand durchgeführt werden. 6.1 Paketverwaltung Hier setzt die Paketverwaltung an. Sie löst Abhängigkeiten auf und versucht, notwendige Software selbstständig nachzuinstallieren. Sie entfernt Programme sauber aus dem System und prüft bei Updates, ob Überschneidungen existieren und wie diese gelöst werden können. Dafür musste die Software aber in eine entsprechende Form gebracht werden: in Pakete. ine Paketverwaltung besteht aus zwei Teilen. Der erste Teil ist für das Laden der Programme aus einem Repository2 sowie für das Auflösen von Abhängigkeiten und Konflikten verantwortlich. Der zweite Teil, zum Beispiel dpkg (Debian Packet Management) oder rpm (RPM Packet Management), sorgt für die eigentliche Installation. In diesem Kapitel erfahren Sie alles zu den zwei größten Paketverwaltungen, dpkg und rpm. Sie erfahren, wie Pakete zu diesen Paketverwaltungen konvertiert werden, welche weiteren Programme es gibt und wie Sie selbst Pakete aktualisieren, erstellen und patchen können. 1 dependencies, engl. für Abhängigkeiten. Damit meint man in der Paketverwaltung Software, die für den Betrieb anderer Software benötigt wird. 2 Repository, engl. für Lager, Depot

17 6 Paketmanagement 6.1 Paketverwaltung 6.1.1»rpm«oder»deb«? Trotz aller Vorteile, die eine Paketverwaltung bietet, besitzen Paketverwaltungen auch Nachteile. Zum einen verfügen Paketverwaltungen zum Großteil lediglich über Binärpakete. Diese Pakete sind für eine Architektur übersetzt und nur auf dieser lauffähig. Dies führt zu statischen Paketen, die nicht voll an das System, auf dem sie laufen, angepasst sind. Zum anderen kommt es bei Paketverwaltungen auch zu Konflikten. Wenn in den Paketen Alpha und Beta teilweise die gleichen Dateien enthalten sind, können Sie nicht beide Pakete gleichzeitig installieren. Falls die Aktualisierung des Pakets Gamma auch die Aktualisierung des Pakets Delta fordert, das Paket psilon aber die»alte Version«des Pakets Delta benötigt, ist eine Aktualisierung von Alpha nicht möglich. ine gute Paketverwaltung zeichnet sich dadurch aus, dass sie diese Konflikte effektiv löst. In der heutigen Zeit haben sich drei Konzepte durchgesetzt: die rpm-paketverwaltung die dpkg-paketverwaltung quellenbasierte Distributionen Die ersten beiden Paketverwaltungen haben die Linux-Welt quasi in zwei Lager gespalten. Die letzte Variante findet eher selten Anwendung, aber Distributionen wie zum Beispiel Gentoo Linux verzichten ganz auf Binärpakete und stellen lediglich den Quellcode zur Verfügung, sodass jede Installation voll an das System angepasst wird. Jede Distribution verfügt über ihre eigene Implementierung einer Paketverwaltung. Das hat zur Folge, dass zum Beispiel zwei auf rpm basierende Distributionen nicht zwingend miteinander kompatibel sein müssen.»rpm«die Paketverwaltung rpm wurde ursprünglich als Red Hat Packet Management bezeichnet, da sie von Red Hat entwickelt wurde. Da rpm aber ein Teil der Linux Standard Base werden wollte, wurde das Projekt einfach in ein rekursives Akronym umbenannt: RPM Packet Management. Das Ziel vom rpm bestand darin, Softwarepakete sowohl für ntwickler als auch für den Anwender einfacher zu gestalten. Abhängigkeiten sollten berücksichtigt und automatisch aufgelöst werden, Redundanzen sollten vermieden, und das saubere ntfernen von Software sollte möglich gemacht werden. benso sollte das inspielen von Updates einfacher gestaltet werden, ebenso wie das sichere Verwalten von Konfigurationen kam es zur Zweiteilung von rpm, da der Hauptentwickler Jeff Johnson Red Hat verließ und einen Fork des Projekts startete. Jetzt gibt es zwei rpm-versionen: zum einen das in SUS, Red Hat, Fedora und vielen anderen Distributionen verwendete rpm von rpm.org,zum anderen den Fork von Johnson, rpm5, der zum Beispiel in Alt Linux, ArkLinux und Unity Linux Anwendung findet. Bei rpm-paketen handelt es sich um komprimierte Dateien, denen ein binärer Header vorangestellt ist. Dieser Header ist nicht komprimiert, sodass dieser leicht durchsucht werden kann. Die zentrale Datei eines Pakets im rpm-formatistdie SPC-Datei. Sie enthält alle Metainformationen des Pakets, also Informationen darüber, was in dem Paket enthalten ist, wohin es installiert wird, wie es installiert wird, sowie Informationen zum Paket selbst. Diese Datei ist in folgende acht Sektionen unterteilt: Präambel Informationen über das Paket, die mittels rpm dem Benutzer angezeigt werden Prep ein Skript, das den Quellcode-Dateibaum erzeugt Build ein Kompilierungsskript Install Installationsanweisung für die Binaries in den meisten Fällen»make install«files eine Auflistung aller Dateien, die im Paket enthalten sind Install/Uninstall Skripte für die Installation und Deinstallation. Diese Sektion besteht wiederum aus vier Unterabschnitten: pre, post, prerun und postrun. Das sind Befehle, die vor/nach der Installation/Deinstallation ausgeführt werden. Verify Skript zur Prüfung der Installation Clean Befehle, die auf dem ntwicklerrechner ausgeführt werden sollen Die Dateinamen der rpm-pakete haben folgende Konvention: <Bezeichnung>-<Versionsnummer>-<Revisionsnummer>.<Architektur>.rpm Listing 6.1 Schema der»rpm«-paketdateinamen»deb«die Paketverwaltung deb wurde von Ian Murdock entwickelt. Die Bezeichnung deb bezieht sich hierbei auf die ersten drei Buchstaben der Linux-Distribution Debian. DieZielsetzung von deb entspricht der von rpm, allerdings sind beide nicht miteinander kompatibel. Hierfür

18 6 Paketmanagement 6.1 Paketverwaltung gibt es aber Konvertierungstools, die es erlauben, Pakete für die jeweils andere Paketverwaltung nutzbar zu machen. in deb-paket setzt sich aus folgenden Abschnitten zusammen: debian-binary Textdatei mit Angabe der Versionsnummer des verwendeten Paketformats control enthält alle relevanten Informationen des Pakets, die in eigenen Dateien verwaltet werden. Die folgenden Dateien sind immer vorhanden: control Kurzbeschreibung des Pakets und Auflistung der Abhängigkeiten md5sums Prüfsummen der enthaltenen Dateien conffiles Auflistung der Konfigurationsdateien im Paket preinst, postinst, prerm, postrm Skripte, die vor oder nach der Installation/Deinstallation ausgeführt werden Ubuntu- und Debian-Pakete sind zum Teil binärkompatibel, sodass Debian-Pakete auch unter einigen Ubuntu-Versionen lauffähig sind. benso gilt dies für Red Hat und SUS. Die Bedienung der einzelnen Tools unterscheidet sich erheblich voneinander. Die Debianbasierte Variante apt ist eine Suite mit mehreren Anwendungen, die jeweils eine Anwendung für spezielle Aufgaben zur Verfügung stellt. Die Red-Hat-Variante yum kommt hingegen mit nur einem Programm aus, und die SUS-Variante yast kann sowohl als Kommandozeilentool als auch im ASCII-Menü gesteuert werden, wobei ab opensus 10.2 das zusätzliche Tool zypperparallelzu yast eingesetzt werden kann. Neben den von den Distributionen ausgelieferten Programmen können auch unabhängige eingesetzt werden.hier ist vor allem das Toolsmart erwähnenswert, das sich selbst als»der Paketmanager«bezeichnet. Auf der Projektseite erhalten Sie weitere Informationen zum insatz des von Gustavo Niemeyer entwickelten Tools. inen Auszug der Befehle zur Bedienung der einzelnen Tools auf der Kommandozeile entnehmen Sie Tabelle 6.1 für die Paketverwaltung und Tabelle 6.2 für lokalen Pakete. Aktion RHL SLS Debian/Ubuntu 6 config ein debconf-skript, das Metainformationen für die debconf-datenbank enthält Paket installieren yum install yast -i zypper install apt-get install shlibs Auflistung der Programmbibliotheken data Archiv der enthaltenen Programmdaten Auch hier gibt es eine zentrale Datei, die für das Paket verantwortlich ist: control.inihrsind sowohl alle Metainformationen zum Paket enthalten als auchdie Installationsanweisungen. Dateinamen von deb-paketen folgen einer definierten Syntax: <Bezeichnung>_<Versionsnummer>-<Revisionsnummer>_<Architektur>.deb Paket deinstallieren yum remove yast --remove zypper remove apt-get remove Paketinformationen abfragen yum info zypper info apt-cache showpkg Paket zur Datei suchen yum provides apt-file search Alle installierten Pakete anzeigen yum list * Tabelle 6.1 Auszug: Kommandozeilenbefehle für Repositorys Listing 6.2 Schema der»deb«-paketdateinamen 6.1.2»yum«,»yast«oder»apt«? Wie bereits erläutert besteht eine Paketverwaltung nicht allein aus einem Programm. Zu ihr gehört immer (mindestens) ein Tool, das sich um das Laden der Software, das Auflösen von Abhängigkeiten und die Beseitigung von Konflikten kümmert. Jede Distribution besitzt eine eigene Umsetzung. So findet yum auf Red-Hat-basierten Systemen Anwendung, yast auf SUS-basierten und apt auf Debian-basierten. Wenn Distributionen binärkompatibel miteinander sind, können Sie auch Pakete aus der jeweils anderen Distribution installieren. Aktion RHL SLS Debian/Ubuntu Paket installieren yum install rpm -i dpkg -i Paket deinstallieren yum remove rpm -e dpkg -r Paketinformationen abfragen yum info rpm -qi dpkg -p Tabelle 6.2 Auszug: Kommandozeilenbefehle für lokale Pakete

19 6 Paketmanagement 6.2 Pakete im igenbau Aktion RHL SLS Debian/Ubuntu Paket zur Datei suchen yum provides rpm -qf Alle installierten Pakete anzeigen yum list * rpm -qa dpkg -l Tabelle 6.2 Auszug: Kommandozeilenbefehle für lokale Pakete (Forts.) Außerirdische an Bord»alien«s gibt Software, die nur in einer Paketform angeboten wird und nicht als Quellcode zur Verfügung steht. Um diese Software auf dem eigenen System betreiben zu können, muss das Paket umgewandelt werden. Hier eilt Ihnen alien zur Hilfe. Das ursprünglich von Debian- ntwickler Christoph Lameter geschriebene Tool konvertiert Pakete in die Formate rpm, deb, slp (Stampedes), tgz (Slackwares)und pkg (Solaris). Die Installation von alien setzt viele weitere Pakete voraus, unter anderem auch die Kompilierungsprogramme (gcc, make etc.). Auf Systemen, die auf Debian basieren, können Sie alien aus den Paketquellen installieren. Leider ist alien in SLS11 nicht enthalten. LadenSiedenaktuellenQuellcodeunterhttp://packages.debian.org/unstable/source/alien herunter, und führen Sie nach dem ntpacken wie in der enthaltenen Datei INSTALL beschrieben die folgenden Befehle aus: daniel@example:/usr/local/alien# perl MakeFiles.pl root@example:/usr/local/alien# make root@example:/usr/local/alien# make install Listing 6.3»alien«aus dem Quellcode installieren Oder erzeugen Sie auf einem Debian-basierten System einfach ein rpm-paket mittels alien. Laden Sie dafür die entsprechende deb-datei herunter. Falls Sie ein Paket konvertieren wollen, das bereits installiert ist, finden Sie die deb-dateiunter /var/cache/apt/archives.wenden Sie alien nun mit dem Schalter -r (oder -to-rpm) an: root@example:/var/cache/apt-/archives# alien -r alien_8.79ubuntu0.1_all.deb alien-8.79ubuntu0.1-2.noarch.rpm generated Listing 6.4 Umwandeln von»deb«zu»rpm«alien erzeugt nun die Datei alien-8.79ubuntu0.1-2.noarch.rpm. Wie Sie dem neuen Dateinamen entnehmen können, wurde auch die Versionsnummer angepasst. Falls Sie die eigentliche Versionsnummer des Pakets behalten wollen, verwenden Sie den Schalter -k beim Aufruf von alien. 194 Speicherort installierter Pakete Installierte Pakete auf Systemen mit deb-paketverwaltung finden Sie im Verzeichnis /var/cache/apt/archives/. Bei SLS11 finden Sie die installierten Pakete unter /var/cache/zypp/ packages/<repository>:<reponame>/rpm/. FallsSieeinPaketaufdemSystemkonvertieren,aufdemdieSoftwareinstalliertwerdensoll, können Sie diese mit dem Schalter -i auchdirekt vonalien installieren lassen. root@example:/# alien -i <fremdpaket> Listing 6.5 Direkte Installation 6.2 Pakete im igenbau Neben der Vielzahl an Software, die über die Repositorys bezogen werden kann, gibt es auch Software, die lediglich als Quellcode zur Verfügung steht. Um solche Programme auf Ihrem System betreiben zu können, müssen sie kompiliert werden. Hierfür verwenden Sie den Ihnen vermutlich bereits bekannten Dreisprung: daniel@example:/usr/local/packet#./configure daniel@example:/usr/local/packet# make daniel@example:/usr/local/packet# sudo make install Listing 6.6 Kompilierung im Dreisprung Dies ist natürlich eine adäquate Möglichkeit, Software auf»einem«system zu verwenden. Wenn Sie aber mehrere Systeme der gleichen Architektur mit dem gleichen Betriebssystem verwenden,könnensiedenquellcodeauchineinpaketschnüren,umsodiesoftwareeinfach zu verteilen, eine Update-Sicherheit zu erzeugen oder auch Patches effektiv zu verteilen. In diesem Abschnitt erfahren Sie alles zu Paketen: wie Sie diese aus einem tarball 3 erzeugen, wie Sie Patches einspielen und wie Sie Update-Pakete erstellen Am Anfang war das Makefile Software, die nicht in den Repositorys zur Verfügung steht, wird in der Regel von den ntwicklern als tgz oder auch tar.gz-datei zur Verfügung gestellt. Aus dieser entpacken Sie den Quellcode und kompilieren dann das Programm. Um selbst geschriebene Software so zur Verfügung zu stellen, muss diese erst mal in die richtige Form gebracht werden. Dazu dient das Makefile, aufdasdasconfigure-skript zugreift, das das Programm entsprechend Ihrem 3 tarball (tape archive ball) Archivformat, in dem oft Quellcode ausgeliefert wird

20 6 Paketmanagement 6.2 Pakete im igenbau System verarbeitet. Im Grunde genommen sind Makefiles nichts weiter als Textdateien, in denen der Übersetzungsprozess von Programmen formalisiert enthalten ist. Darüber hinaus stellt das Makefile eine Intelligenz zur Verfügung, die bereits vorhandene und kompilierte Abhängigkeiten, oder bei Updates auch eigenen Code, erkennt und diese nicht erneut kompiliert. Das rstellen eines solchenmakefiles von Hand kann bei größeren Projekten mit vielen Abhängigkeiten schnell in unüberschaubare Arbeit ausarten. Um effizient Makefiles zu erstellen, gibt es die»gnu autotools«, die Ihnen die Arbeit zu einem Großteil abnehmen. Folgende Arbeitsschritte müssen Sie durchlaufen, um ein eigenes tgz zu erstellen: 1. Quellcode erstellen 2. Makefile.am erstellen 3. autoscan configure.scan nach configure.in 4. aclocal Anpassung für die Sprachumgebung 5. autoconf Verarbeitung von Konfigurationsdateien 6. autoheader Verarbeitung von zusätzlichem Quellcode 7. automake rzeugen des Makefiles In diesem Abschnitt zeigen wir Ihnen, wie Sie das allseits beliebte Programm»helloworld«von seinem C-Code-Dasein befreien und als tgz-datei zur Verfügung stellen. rstellen Sie zunächst ein Verzeichnis hello-1.0 in Ihrem Homeverzeichnis. In diesem Verzeichnis erstellen Sie das helloworld.c-programm mit folgendem Quellcode: /* Simple "Hello World!" program in C */ #include <stdio.h> main() { printf("hello world! Once again... \n"); } Listing 6.7»helloworld.c«rstellung als Benutzer Die rstellung von Paketen (tgz, rpm oder deb) sollte immer als normaler Benutzer ausgeführt werden. Da»root«Vollzugriff auf alle Dateien hat, könnten während der Installation eines von ihm erstellten Pakets Dateien überschrieben oder gelöscht werden, die auf dem System benötigt werden. Die Installation des gepackten Programms selbst muss hingegen von»root«durchgeführt werden, da Benutzern die entsprechenden Rechte fehlen. Das soeben erstellte Programm dient als zu verpackende Basis. rstellen Sie nun die Datei Makefile.am mit folgendem Inhalt: bin_programs = helloworld helloworld_sourcs = helloworld.c Listing 6.8»Makefile.am«Die Datei Makefile.am wird von den autotools ausgewertet. In ihr wird der Name des Programms (bin _PROGRAMS) und dessen Quellcode (helloworld_sourcs) deklariert. Bei größeren Projekten werden hier alle programmrelevanten Dateien aufgeführt und auch alle Bibliotheken. Führen Sie nun autoscan aus. Dieses Programm analysiert die Makefile.am und ihren Quellcode. s erstellt die Datei configure.scan, die als Basis zur rstellung der configure.in dient: # -*- Autoconf -*- # Process this file with autoconf to produce a configure script. AC_PRRQ([2.65]) AC_INIT([FULL-PACKAG-NAM], [VRSION], [BUG-RPORT-ADDRSS]) AC_CONFIG_SRCDIR([hello.c]) AC_CONFIG_HADRS([config.h]) # Checks for programs. AC_PROG_CC # Checks for libraries. # Checks for header files. # Checks for typedefs, structures, and compiler characteristics. # Checks for library functions. AC_CONFIG_FILS([Makefile]) AC_OUTPUT Listing 6.9»configure.scan«Benennen Sie die Datei entsprechend um, und passen Sie die Parameter dem helloworld.c-programm an: AC_PRRQ(2.59) AC_INIT([helloworld], [1.0], [bugs@example.net]) AM_INIT_AUTOMAK([1.9 foreign]) AC_PROG_CC