Kernel 6.1 bekommt Anpassung der Hintergrundbeleuchtung

Wie Hans De Goede in seinem neuesten Blogeintrag mitteilt, arbeitet er an einer Überarbeitung des Hintergrundbeleuchtungssubsystems ( Backlight ). Das könnte auf einigen Geräten zum Problem werden.

Kernel 6.1 bekommt Anpassung der Hintergrundbeleuchtung

Durch die Neuordnung der Erkennung der Hintergrundbeleuchtung in der Hardware, kann es zu Fehldiagnosen kommen, die die bisher funktionierende Hintergrundbeleuchtung nicht länger funktional lassen. Dies soll primär bei alten und sehr spezialen ( ich tippe auf Dell und M$ ) auftreten, da die vielen Spezialroutinen weggefallen sind.

Da mein ACER Laptop auch nicht das neueste ist, habe ich da mal ein paar Tests gemacht. Ich scheine nicht betroffen zu sein, da ich zwei Geräte in der Hintergrundbeleuchtungserkennung gefunden habe. Dafür konnte Ich aber für eine Euch eine wichtige Erkenntnis gewinnen: Traue nie einem Grubeintrag 😉

Falls man unter /sys/class/backlight nur einen einzigen Eintrag findet, sollte man den Kernel mal mit der Option „acpi_backlight=video“ booten. Taucht dann kein zweites Device auf, ist man sehr wahrscheinlich betroffen und sollte Hans mit den technischen Daten ( siehe Blogeintrag ) versorgen.

Mit der Zusatzoption für die Hintergrundbeleuchtung booten

Auf meinem Laptop ist in Grub der BLS Modus aktiviert. Das wurde von Fedora vor einigen Jahren eingeführt. Sinn ist es die Grubconfig aufzuräumen, was meiner bescheidenen Meinung nach, komplett in die Hose gegangen ist, weil man jetzt nicht mehr weiß, was da eigentlich booten will.

Früher(TM) hat man einfach alle Menueinträge der Kernel mit der neuen Option versorgt und konnte sicher sein, daß die beim Boot benutzt wird. Heute reicht es nicht, die eigentlich zur Vereinfachung gedachte Default-Kernelline in der Grub.cfg anzupassen, damit alle Bootloadereinträge das gleiche machen, nein, man muß es doch wieder in jedes File eintragen oder per GrubEdit beim Booten die Kernelzeile vervollständigen. Leider.

Falls Ihr also damit die Hintergrundbeleuchtung Eures Laptops oder Tablets testen wollt, macht Euch gleich die Mühe es per Grub-Editfunktion beim Booten dem aufgewählten Kernel mitzugeben. Spart viel Arbeit auf Dauer 😉

Wenn sich Grub und Grubby uneins sind

Ihr erinnert Euch noch an den Artikel Fedora 30&31 Bootumstellung führt zu Startproblem? Davon habe ich eine neue Version für Euch 🙂

Wenn sich Grub und Grubby uneins sind

Allen Anfängern rate ich jetzt mal zunächst ein bisschen zu Lesen: Grubby: wie man wieder einen Default Kernel setzen kann damit dürfte klar sein, was Grubby macht. Grub ist der verbreiteste Bootloader für Linux und der liest normalerweise das ein, was Grubby so von sich geschrieben hat. Wenn ich das schon so flapsig schreibe, dann kann das ja eigentlich schon nicht stimmen, tut es auch nicht immer 🙂

Fangen wir mit der Geschichte von vorn an …ää ähm .. ä ..hm… es war mal im Jahr 2019 ein Fedora Releasewechsel von Fedora 29 auf 30, und ein Linux Tablet. Ok,ok, mein Tablet war zwar an der Geschichte beteiligt, aber das hätte jedem PC passieren können, ehrlich 😉 Mit Fedora 30 wurde ja BLS eingeführt und dabei muß jemand an Grub geschraubt und was falsch gemacht haben, denn bis zu dem Upgrade lief das mit dem Setzen des Default Kernels über Grubby noch.

„Ihr wagt es mir zu trotzen, wer seid Ihr Ritter Rosthülle!“

Seit dem Update konnte ich machen was ich wollte, es wurde immer der erste Kernel in Menü als Bootkernel ausgewählt, egal was ich mit Grubby angestellt habe. Zu beachten ist hier, daß immer alle aktuell installierten Kernels im Menü aufgetaucht sind. Nun habe ich ja für den Beitrag zum neuen Surfacekernel Repo einen, wer würde es erraten, neuen Kernel installiert \o/ und prompt bootete der nicht automatisch. Da ich aber sicher gehen wollte, daß der immer startet, habe ich da nochmal alles überprüft.

Die Dateien in /boot/grub2/ waren alle OK. Wenn Grubby gehustet hat, änderten sich die grubenv und die grub.cfg untertänigst und trotzdem blieb es beim ersten Kernel im Menü. Unglaublich. Jetzt kann man glücklicherweise im Grubmenü auf „c“ drücken und kommt in die GrubShell. Wenn man da „set“ aufruft, zeigt er einem die Grubvariablen an, das sind die, die man mit dem Eintrag in der grubenv überschreiben kann. Wenn man sich die grub.cfg ansieht:

if [ -f ${config_directory}/grubenv ]; then
    load_env -f ${config_directory}/grubenv
elif [ -s $prefix/grubenv ]; then
    load_env
fi

erkennt man auch als Uneingeweihter, daß hier die grubenv geladen werden soll. d.b. Schritt Eins vom Bootloader, bevor das Menü überhaupt zusammenbaut wird, ist also die grubenv laden und die passenden Variablen setzen oder überschreiben.

Die GrubShell

Wie bereits erwähnt kann man sich das Ergebnis in der GrubShell ansehen, wenn man „set“ eingibt. Solltet Ihr beim nächsten Boot einfach mal machen und reinsehen. „boot“ oder „reboot“ bringen Euch da wieder raus. Als ich heute (für Euch vor 2 Wochen) in die Variablenliste von „set“ sah, wäre ich fast vom Stuhl gefallen. Da stand allen ernstes ein Kernel 5.2.7 (Fedora 29) als Defaultkernel drin! Den gab es unter /boot/ aber gar nicht mehr und das System hat nur eine Bootplatte. Ich habe ja erwähnt, daß alle Kernel, die hätten im Menü sein sollen, auch im Menü drin waren. Ein Kernel 5.2.7 wäre da aufgefallen.

Jetzt sucht mal auf der Platte nach einem Kernel, den es seit 5 Monaten nicht mehr gibt, viel Spaß dabei! Das muß ja irgendwo drin stehen, also /etc/ durchsucht, /boot/grub2 durchsucht, /usr/ durchsucht, nichts! Kein Kernel, kein Eintrag.. wo zum Geier kommt das her? Grubby schreibt doch jede Änderung des Kernels direkt in die Files, da KANN DOCH GAR KEIN ALTER KERNEL DRINSTEHEN!

Wenn A und B nicht das Gleiche sind!

Stands auch nicht. Die Lösung für das Problem war dann weniger spannend als die Suche danach 🙂 Grubby änderte die Dateien in /boot/grub2, aber Grub lud nicht /boot/grub2 sondern /boot/EFI/efi/fedora/ und da standen uralte Fedora 29 Sachen in den Dateien. Das ist so eine „Links weiß nicht was Rechts tun“ Geschichte. Die Lösung für das Problem ist dann ganz einfach, man nimmt einfach zwei Symbolische Links und verknüpft die beiden Orte, so daß es nur noch eine Datei mit dem Inhalt gibt, und nicht mehr zwei verschiedene.

Da Grubby alle aktuellen Anpassungen nach /boot/grub2/ schreibt, aber Grub aus /boot/EFI/efi/fedora/ liest und zu allem Überfluß /boot/ zu „/“ wird, wenn man der Bootloader ist, muß man ein klein bisschen kreativ werden, um den korrekt Pfad für den Link abzuleiten. Folgende Anweisungen können das für Euch direkt lösen:

mv /boot/grub2/grubenv /boot/EFI/efi/fedora/grubenv
mv /boot/grub2/grub.cfg /boot/EFI/efi/fedora/grub.cfg
cd /boot/grub2
ln -s ../EFI/efi/fedora/grubenv
ln -s ../EFI/efi/fedora/grub.cfg

Kurz erklärt

„mv“ steht für „move“ und verschiebt Dateien von A nach B. Wenn B vorhanden, wird es überschrieben, man muß B also nicht vorher löschen.
„ln -s {Pfad/Dateiname}“  legt den symbolischen (-s) Link von {Pfad/Dateiname} als „Dateiname“ im Filesystem an. Sollen Ziel und Quelle des Links gleich heißen muß man da nichts weiter angeben. Üblich wäre aber z.B. „ln -s pfad1/datei1 pfad2/datei2“ . In den Anweisungen oben haben wir einen relativen Pfad ../EFI/efi/fedora benutzt, weil /boot/EFI/efi/fedora nicht geht, da es /boot/ in der Bootparition nicht gibt, denn die wird während des Bootens erst später unter /boot/ eingehängt. Der Bootloader hantiert also direkt im /boot/ rum, weswegen in seinem Kontext „/boot/“ = „/“ ist. Das Root = / ist hätte man riskieren können, aber da Grub nicht von /boot/grub2 lädt, könnte da ja noch viel mehr anders sein, als mir jetzt bekannt ist. Daher war der relative Link hier sicherer als „ln -s /EFI/efi/fedora/grubenv“ zu benutzen.

Für Anfänger: Ein symbolischer Link ist eigentlich nur eine kleine Textdatei, wo das Ziel ( hier ../EFI/efi/fedora/grubenv ) drinsteht. Das Filesystem merkt das, und folgt dann dem Pfad zum eigentlichen Ziel. Symbolische Links kann man quer über alle eingehängten Partitionen benutzen. „Hardlinks“, die sich hier auch angeboten hätten, kann man nur innerhalb einer Partition benutzen, dafür haben die andere Vorteile.

Bugreport ist raus, mal sehen wann die Beule am Kopf der GrubDevs vom gegen die Wand schlagen wieder abgeschwollen ist 🙂

Der GAU – Festplattenausfall und wie man Ihn behebt

„Wenn die Hardware versagt,und das Filesystem mit in den Abgrund zieht.“

Es war ein lauer Sonntagmittag, der Stream des Chaosradios ergoß sich von Radio Fritz, der Frachter in EVE flog seine Route, als plötzlich …  „can’t create tempfile in /tmp/gluster-x34234.tmp“ auf der Konsole  erschien. Das Ende vom Lied, die Festplatte hatte versagt:

 

 

 

 

 

 

Beim Rebooten startete das System nicht mehr mit dem Hinweis, daß die Superblöcke der Partionen/Filesysteme beschädigt wären.

/var/log/messages-20170402:Apr  2 15:05:32 eve kernel: EXT4-fs (sdc1): filesystem has both journal and inode journals!
/var/log/messages-20170402:Apr  2 15:08:10 eve kernel: EXT4-fs (sdc1): filesystem has both journal and inode journals!
/var/log/messages-20170402:Apr  2 15:08:29 eve kernel: EXT4-fs (sdc1): filesystem has both journal and inode journals!
/var/log/messages-20170402:Apr  2 15:08:30 eve kernel: EXT4-fs (sdc1): filesystem has both journal and inode journals!
/var/log/messages-20170402:Apr  2 15:08:34 eve kernel: EXT4-fs (sdc1): filesystem has both journal and inode journals!
/var/log/messages-20170402:Apr  2 15:08:44 eve kernel: EXT4-fs (sdc1): filesystem has both journal and inode journals!
/var/log/messages-20170402:Apr  2 15:08:47 eve kernel: EXT4-fs (sdc1): filesystem has both journal and inode journals!
/var/log/messages-20170402:Apr  2 15:08:49 eve kernel: EXT4-fs (sdc1): filesystem has both journal and inode journals!
/var/log/messages-20170402:Apr  2 15:08:49 eve kernel: EXT4-fs (sdc1): filesystem has both journal and inode journals!
/var/log/messages-20170402:Apr  2 15:09:46 eve kernel: EXT4-fs (sdc1): filesystem has both journal and inode journals!
/var/log/messages-20170402:Apr  2 15:09:58 eve kernel: EXT4-fs (sdc1): filesystem has both journal and inode journals!
/var/log/messages-20170402:Apr  2 15:11:34 eve kernel: EXT4-fs (sdc1): filesystem has both journal and inode journals!
/var/log/messages-20170402:Apr  2 15:21:39 eve kernel: EXT4-fs (sdc1): filesystem has both journal and inode journals!
/var/log/messages-20170402:Apr  2 15:25:56 eve kernel: EXT4-fs (sdc1): filesystem has both journal and inode journals!

Ein Mounten der Bootpartition war nicht mehr möglich, weil der Superblock defekt war. Im Endergebnis waren zwei Filesysteme der SSD defekt.

Wie konnte das passieren ?

Wenn man Google nach den im Screenshot gezeigten Fehlern befragt, zeichnet sich sehr schnell ab, daß die meisten auf ein Versagen der Stromzufuhr tippen. Das kann man aber wohl ausschliessen, da dabei als erstes die Grafikkarte ausgegangen wäre.

Da ich einige Tage vorher von Fedora 24 auf Fedora 25 umgestiegen bin, und damit auch ein neuer 4.10er Kernel zum Einsatz kam, ist es viel wahrscheinlicher, daß eine Treiber-HW-Kernel-Inkompatibilität vorlag. Das gabs bei Kernel 3.11 und 3.18 schon einmal.

Wie komme ich jetzt darauf ?

Das kommt daher, daß ich an dem besagten 2. April  das Stromversagen akzeptiert habe und daher die Stromverbindungen erneuert hatte. Einige Tage später, knallte die gleiche Platte wieder weg, ohne das jemand auch nur in  die Nähe der Stecker gekommen wäre. Seit Kernel 4.10.8-200 tritt das Problem nicht mehr auf. Es lag also vermutlich nicht am Strom, sondern an der Kernel-Treiber-HW Kombination.

Filesystem läßt sich nicht mounten

Es waren also zwei Filesysteme defekt. Dummerweise System-Root und die Bootpartition, wobei es die Bootpartition besonders schwer getroffen hatte:

kernel: EXT4-fs (sdc1): filesystem has both journal and inode journals!

Der den Fehler sieht, spart sich am besten gleich den Reperaturversuch und mountet die Platte mit der NOCHECK Option im Readonlymodus und kopiert die noch vorhandenen Files auf ein Backupmedium. Danach dann die Platte frisch formatieren und Daten wieder drauf spielen. Alles andere dürfte Zeitverschwendung sein. (siehe PDF)

Die Systempartition ließ sich im Gegensatz zur Bootplatte recht einfach mit fsck.ext4 reparieren. Daher liegt das Augenmerk des Beitrags auch auf dem Thema: Wie man eine neue Bootpartition aufbaut.

Da ich aus dem Problem und seiner Lösung gleich einen Vortrag für unsere LUG gemacht habe, könnt Ihr Euch jetzt alle nötigen Schritte in einem PDF herunterladen. Ich werde daher auch nur grob auf die einzelnen Lösungswege eingehen. Im PDF sind auch Reparaturanweisungen mit fsck, dumpefs, mke2fs  enthalten. Ich empfehle dringend das PDF an einem zugänglichen Ort aufzubewahren, ggf. auch als Offlinekopie 😉

Wie man eine Bootpartition neu aufbaut

Wir nehmen einfach mal an, daß die Bootpartition komplett hinüber ist, was bei dem oben aufgeführten Bug wohl auch der Fall ist. Mein Rettungsversuch mit fsck führte zum totalen Datenverlust, weil einige Inodes doppelt und dreifach belegt waren( vermute ich mal).

Deswegen ist oftmals nur eine neue Partition bzw. ein Reformatieren der Partition der letzte Ausweg.

Da das Formatieren die UUIDs einer Partition ändert, stimmen die Daten auf der Systemplatte nicht mehr.

Um der Sache jetzt folgen zu können, müßt Ihr zwei Dinge wissen:

  1. Was UUIDs und BLKIDs  sind
  2. Wie die im System benutzt werden um Partition zu referenzieren.

zu 1)

UUIDs werden von LUKS verschlüsselten Festplatten benutzt und sind ziemlich lange, aber eindeutige IDs.

$ lsblk
NAME                                          MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
sr0                                            11:0    1  1024M  0 rom   
sdc                                             8:32   0 111,8G  0 disk  
├─sdc2                                          8:34   0 103,7G  0 part  
│ └─luks-ffbd61f2-4c1e-4dc8-b12b-c89e9f69c9fa 253:0    0 103,7G  0 crypt /
├─sdc3                                          8:35   0   7,6G  0 part  
│ └─luks-ca1f019d-39ce-4cf8-b522-f6d3e63ebe2a 253:1    0   7,6G  0 crypt [SWAP]
└─sdc1                                          8:33   0 525,5M  0 part  /boot
sda                                             8:0    0   1,8T  0 disk  
├─sda4                                          8:4    0     1K  0 part  
├─sda2                                          8:2    0  78,1G  0 part  
│ └─luks-6d45b281-c56c-40f0-acf7-c3058d4d6913 253:3    0  78,1G  0 crypt 
├─sda5                                          8:5    0   1,8T  0 part  
│ └─luks-7881f602-9462-497d-810a-7d6111ad6085 253:2    0   1,8T  0 crypt /sata_home
├─sda3                                          8:3    0   7,8G  0 part  
│ └─luks-384d6b27-6263-4d53-bfce-e7e5bcd221b9 253:4    0   7,8G  0 crypt 
└─sda1

BLKid sind die IDs der Filesystem selbst, also von / , von /home oder /boot . Ein Ext3/4, BTRS usw. Filesystem erzeugt beim Formatieren eine BLKID für sich dieses Filesystem. Jedesmal, wenn die Partition neu formatiert wird, gibt es eine neue Nummer.

$ blkid
/dev/sda1: UUID="aee1b027-ebd7-4ad9-a0ea-0fc881193708" TYPE="ext4" PARTUUID="000c4469-01"
/dev/sda2: UUID="6d45b281-c56c-40f0-acf7-c3058d4d6913" TYPE="crypto_LUKS" PARTUUID="000c4469-02"
/dev/sda3: UUID="384d6b27-6263-4d53-bfce-e7e5bcd221b9" TYPE="crypto_LUKS" PARTUUID="000c4469-03"
/dev/sda5: UUID="7881f602-9462-497d-810a-7d6111ad6085" TYPE="crypto_LUKS" PARTUUID="000c4469-05"
/dev/sdc1: LABEL="Boot" UUID="221608f2-5914-4619-9ef7-6dfddf233fd4" TYPE="ext4" PARTUUID="0000a3dd-01"
/dev/sdc2: UUID="ffbd61f2-4c1e-4dc8-b12b-c89e9f69c9fa" TYPE="crypto_LUKS" PARTUUID="0000a3dd-02"
/dev/sdc3: UUID="ca1f019d-39ce-4cf8-b522-f6d3e63ebe2a" TYPE="crypto_LUKS" PARTUUID="0000a3dd-03"
/dev/mapper/luks-ffbd61f2-4c1e-4dc8-b12b-c89e9f69c9fa: UUID="e62edbbe-a1ae-4242-bca5-1249d6f2df67" TYPE="ext4"
/dev/mapper/luks-ca1f019d-39ce-4cf8-b522-f6d3e63ebe2a: UUID="46da0d80-21fb-45b7-8567-ba047de66cb6" TYPE="swap"
/dev/mapper/luks-7881f602-9462-497d-810a-7d6111ad6085: UUID="196a4455-7ccb-40e4-bc71-7b2929f29225" TYPE="ext4"
/dev/mapper/luks-6d45b281-c56c-40f0-acf7-c3058d4d6913: UUID="0fd1b33c-5a2e-421a-a872-7bfc784ea2cf" TYPE="ext4"
/dev/mapper/luks-384d6b27-6263-4d53-bfce-e7e5bcd221b9: UUID="0bb5a502-f854-4e40-a3bd-08c3a2e6bf22" TYPE="swap"

zu 2)
Jetzt schauen wir uns mal /etc/fstab und den Bootentry im Grub an :

$ cat /etc/fstab 

/dev/mapper/luks-ffbd61f2-4c1e-4dc8-b12b-c89e9f69c9fa /           ext4    defaults,x-systemd.device-timeout=0 1 1
UUID=221608f2-5914-4619-9ef7-6dfddf233fd4 /boot                   ext4    defaults        1 2
/dev/mapper/luks-7881f602-9462-497d-810a-7d6111ad6085 /sata_home  ext4    defaults,x-systemd.device-timeout=0 1 2
/dev/mapper/luks-ca1f019d-39ce-4cf8-b522-f6d3e63ebe2a swap        swap    defaults,x-systemd.device-timeout=0 0 0

Wie man in der FSTAB sehen kann, soll /boot über die BLKID eingebunden werden.

Warum macht man das ?

Ganz einfach, weil die BLKID ( BlockID ) eindeutig ist, egal an welchem Port eines Controllers die Platte angebunden ist. Selbst wenn die per USB ins System eingehängt ist, kann man diese Partition referenzieren. Das alt bekannte Problem von früher, wenn sich die Plattenreihenfolge geändert hat, daß dann eine andere Platte das Bootdevice war, entfällt damit.

Wieso ist /boot über BLK referenziert und / mit einer LUKS ID ?

Weil Boot nicht verschlüsselt ist. Das geht zwar auch, aber dann wird es haarig 😉

Da in der FSTAB die BLKID enthalten ist und sich nach erneuten Anlegen des Filesystems eine neue BLKID ergibt, muß man also vor dem ersten Boot die /etc/fstab anpassen, sonst bootet der Rechner nicht mehr.

Der Grub-Booteintrag:

menuentry 'Fedora (4.10.6-200.fc25.x86_64) 25 (Twenty Five)' --class fedora --class gnu-linux --class gnu --class os --unrestricted $menuentry_id_option 'gnulinux-4.10.6-200.fc25.x86_64-advanced-e62edbbe-a1ae-4242-bca5-1249d6f2df67' {
        load_video
        set gfxpayload=keep
        insmod gzio
        insmod part_msdos
        insmod ext2
        set root='hd2,msdos1'
        if [ x$feature_platform_search_hint = xy ]; then
          search --no-floppy --fs-uuid --set=root --hint-bios=hd2,msdos1 --hint-efi=hd2,msdos1 --hint-baremetal=ahci2,msdos1  221608f2-5914-4619-9ef7-6dfddf233fd4
        else
          search --no-floppy --fs-uuid --set=root 221608f2-5914-4619-9ef7-6dfddf233fd4
        fi
        linux /vmlinuz-4.10.6-200.fc25.x86_64 root=UUID=e62edbbe-a1ae-4242-bca5-1249d6f2df67 ro vconsole.font=latarcyrheb-sun16 rd.luks.uuid=luks-ca1f019d-39ce-4cf8-b522-f6d3e63ebe2a rd.luks.uuid=luks-ffbd61f2-4c1e-4dc8-b12b-c89e9f69c9fa  rhgb quiet splash audit=0 rd.driver.blacklist=nouveau nouveau.modeset=0 
        initrd /initramfs-4.10.6-200.fc25.x86_64.img
}

Wie man hier unschwer erkennen kann, kommt die BLKID auch im Bootentry vom Bootloader vor, was verständlich ist, weil der sonst nicht weiß welche Platte er booten sollte 😉

Zudem sind hier die zum Systemstart zu entschlüsselnden  LUKS Partitionen enthalten. Zudem ist die ROOT Partition mit angegeben, die auch über die BLKID referenziert wird.

Wie stellen wir jetzt aber die Bootpartition wieder her ?

Am einfachsten mit einer LiveCD vom gleichen Distributor . Dann formatieren wir die Bootpartition, so daß diese leer ist und legen uns die BLKID bereit. Folgende Schritte führen dann zum Ziel:

  1. Systempartition mounten
  2. DEV und PROC in die Systempartition mounten
  3. BOOT in die Systemplatte mounten
  4. CHROOT in die Systemplatte machen
  5. Bisherige Kernel finden
  6. Kernel neu installieren

Das sieht dann so aus ( natürlich haben Sie andere Partitionen als ich: SDC2 ist Root, SDC1 ist Boot ). Vorher zum Rootuser werden ( su root ) :

mount /dev/sdc2 /media
mount -t devtempfs devtempfs   /media/dev
mount -t procfs procfs /media/proc
mount -t ext4 /dev/sdc1 /media/boot
chroot /media/

Jetzt befinden wir uns im System des normalen Rechners, so daß wir alles so tun können, als wenn er normal gebootet hätte ( ohne Desktop natürlich ) . Wir bekommen die Kernel raus die drauf waren :

rpm -qa | grep kernel-core

und installieren die neu:

dnf reinstall kernel-core-*

Das sind natürlich Anweisungen für Fedora/RedHat Systeme, hier bitte die passenden für Eure Distribution wählen. Natürlich kann man das Raussuchen der Kernels auch weglassen, da ist ja nur eine Info für Euch, damit Ihr seht, ob es stimmt. Nun noch die GRUB Boot Konfiguration neu erzeugen und der Rechner sollte wieder starten:

grub2-install /dev/sdc
grub2-mkconfig -o /boot/grub2/grub.cfg

Das Anpassen von /etc/fstab sollte man natürlich jetzt auch machen, sonst gehts nicht 😉

Wer unerfindliche Probleme mit seinem GRUB Bootentry hat, dem könnte der Beitrag helfen. Ich mußte auch Linux16 durch Linux ersetzen, damit es wieder funktioniert.

Ich kann allen nur nochmal nahe legen, das PDF unten auf einem USB Stick zu sichern, damit Ihr das im Notfall parat habt. Außerdem sind in dem PDF noch viele andere Infos zum Thema aufgeführt und einige intensiver heraus gearbeitet.

PDF zum Download: LUGBS-Filesystemmeltdown