Fix Fedora UEFI Boot with encrypted partitions

I recently upgraded my laptop, a Lenovo X1 Carbon 4th gen, to Fedora 32, which is still in Beta, but with just two weeks until its scheduled release, I deemed it stable enough for my purposes.

The upgrade process went smoothly and everything worked fine. I really like the new lockscreen, it looks really clean.

As usual with the beta releases, there are quite many updates and I usually run a sudo dnf upgrade once a day. I also do not really pay attention to what is actually upgraded, it is simply too much.

One of these upgrades seems to have broken my startup system. After a restart, the Grub selection did not appear at all and instead Windows started immediately. This seemed odd, so I started investigating.

First thing I did was to open the Boot selection menu of the laptop. It lists all the available boot options and still contains the Fedora entry. Selecting it resulted in nothing, instead the very same selection screen reappeared immediately. Windows could be selected and booted up without issues, so I guess that the system automatically tries all entries in order until it finds one that actually works.

My task now was to fix the issue. As this turned out to be a bit trickier due to UEFI and the fact that my Linux partitions are encrypted. Most forum entries and manual pages are considering simpler cases, where either it is not an UEFI system or where everything is unencrypted. Hence, I will list all steps to help anyone and to have a reference in case this happens again.

I started off by downloading the Fedora Media Writer and the Fedora 32 DVD ISO from the Fedora download page. It might have worked with the stable Fedora 31 release as well, but I didn’t want to take any chances. I then created a Live CD on a USB stick.

Next, I booted from the USB stick, started the Live version of Fedora, opened a terminal, made myself a superuser with the

su
command and listed all my disk partitions:

# fdisk -l
Festplatte /dev/nvme0n1: 476,96 GiB, 512110190592 Bytes, 1000215216 Sektoren
Festplattenmodell: SAMSUNG MZVKV512HAJH-000L1              
Einheiten: Sektoren von 1 * 512 = 512 Bytes
Sektorgröße (logisch/physikalisch): 512 Bytes / 512 Bytes
E/A-Größe (minimal/optimal): 512 Bytes / 512 Bytes
Festplattenbezeichnungstyp: gpt
Festplattenbezeichner: 2C4E590F-0E6F-4950-9740-F8C04BCDCC5E

Gerät             Anfang       Ende  Sektoren  Größe Typ
/dev/nvme0n1p1      2048     534527    532480   260M EFI-System
/dev/nvme0n1p2    534528     567295     32768    16M Microsoft reserviert
/dev/nvme0n1p3    567296  362516479 361949184 172,6G Microsoft Basisdaten
/dev/nvme0n1p4 998166528 1000214527   2048000  1000M Windows-Wiederherstellungsumgebung
/dev/nvme0n1p5 362516480  364613631   2097152     1G Linux-Dateisystem
/dev/nvme0n1p6 364613632  998166527 633552896 302,1G Linux-Dateisystem

We can see that the EFI partition is

/dev/nvme0n1p1
the Linux
/boot
partition can be determined by its size of 1 GB and is
/dev/nvme0n1p5
and finally the main Linux partition with all encrypted partitions is
/dev/nvme0n1p6

Next, we need to unlock the encrypted partition:

# udiskctl unlock -b /dev/nvme0n1p6

This prompts us to enter our password for decryting the partition and it provides all the logical volumes under
/dev/mapper
. In my case, the actual partitions can be accessed at
/dev/mapper/fedora-root
,
/dev/mapper/fedora-home
and
/dev/mapper/fedora-swap
, respectively.

Now we can start to mount our real Fedora installation into some directory in order to repair it. First, we need some main directory under which to mount everything:

# mkdir /mnt/root

and now we can mount all directories:
# mount /dev/mapper/fedora-root /mnt/root

# mount /dev/nvme0n1p5 /mnt/root/boot

# mount /dev/nvme0n1p1 /mnt/root/boot/efi

# mount -t proc proc /mnt/root/proc

Although this could already be sufficient, I needed to make the Wireless network from my live instance available in the environment which will be used for chroot:

# mv /mnt/root/etc/resolv.conf \

/mnt/root/etc/resolv.conf.backup<br># cp /etc/resolv.conf /mnt/root/etc/resolv.conf

Finally I could change into my prepared environment

# chroot /mnt/root /bin/bash

… and actually repair the UEFI setup:

# dnf install grub2-efi shim

# dnf reinstall grub2-efi shim

After all of this, the system should be ready to be rebooted.

I hope these steps are helpful to someone else than just me 🙂

Why 2018 won’t be the year of Linux on the desktop – again

The „Year of Linux on the desktop“ seems to be kind of a running gag. For years now, people have predicted that „this is going to be the year where Linux will win the desktop“. I (and others) think, this is not gonna happen in 2018. And I also assume that it won’t happen in 2019.

Before I start my rant about the reasons, let me state a few things. When I say „Linux„, I mean any Linux distribution out there. Fedora, Ubuntu, Arch – you name it. Also: I am a big fan of Linux myself. I’ve been using it since the days of Debian 2.something around 1998, and RedHat/Fedora has been my main desktop (and laptop) operating system for more than 15 years now. By all means I am a huge fan of the whole idea of Linus’s work and everything around it. Nevertheless, I don’t see it going anywhere further on the desktop.

Secondly, the reason for me writing about it now is the continuing dissatifaction around Apple and macOS (aka OS X). At work, I use a MacBook Pro with Retina display and I like the combination of hard- and software! But I hear many colleagues complaining about the ever-increasing price tag on the hardware. For their private hardware, quite a few are switching back to non-Apple choices. I for myself bought a Lenovo X1 Carbon instead of a MacBook Pro, only because of the price. And the experiences with Linux on this machine made me realize, why Linux is not working for the masses.

Here is an unsorted list of reasons which I think are at least part of the reason, why not even 2018 will be the year of Linux on the desktop. „Why 2018 won’t be the year of Linux on the desktop – again“ weiterlesen

Java, Maven, JBoss AS, Windows – eine unheilvolle Kombination

So … wie vielleicht schon aus einigen meiner letzten Beiträge erkennbar geworden ist, bin ich eigentlich kein großer Fan des Betriebssystems „Windows“. Während es für viele Nutzer vielleicht eine gute Wahl sein mag, ist es für Softwareentwickler (die nicht unbedingt Windows-Anwendungen entwickeln) schon nicht mehr optimal. Aber was gar nicht geht: Windows als Server.

Mit genau einem solchen Server hatte ich nämlich heute einige Stunden lang Spaß. Man nehme ein Maven-Projekt, in dem es einen Sourcepfad /src/main/java/de/test/meinProjekt/ gibt. Darunter hat man Klassen, alles ist gut, alles funktioniert.

Jetzt nehme man an, es werden Dateien in das Package/Verzeichnis /src/main/resources/java/de/test/meinprojekt/ gepackt. Sieht nach harmlos aus, ist aber katastrophal! Wer findet den Fehler?

Genau: das große „P“ im ersten Pfad funktioniert gut, solange man keinen gleichlautenden Pfad mit anderer Groß-/Kleinschreibung im Parallelverzeichnis hat. Durch diese kleine Unaufmerksamkeit ist die gesamte Applikation beim Starten im JBoss nämlich mit einer total zusammenhangslosen Fehlermeldung gar nicht erst gestartet. Es scheint, als beachte der Classloader des JBoss‘ das Casing der Pfade/Packages, was ja auch richtig ist. Im entstandenen Archiv, welches von Maven unter Windows zusammengebaut wurde, stehen die Sachen aber alle im gleichen Ordner mit kleinem „p“. Deswegen werden sie vom Classloader nicht gefunden.

Fiese Sache!

Zu meiner Verteidigung: der Package-Namen mit dem großen P stammte nicht von mir. Ich würde sowas doch niemals tun … *hüst*

Fortschritt, der sich selber überholt

Ich mag mein Fedora-System. Linux im Allgemeinen sowieso. Aber beim Lesen dieses Blogeintrags, auf den ich über Planet Fedora gestoßen bin, ist mir eines mal wieder bewusst geworden und unangenehm aufgefallen:

So sehr ich dafür bin, dass ständig neue Programme entwickelt werden, so unpraktisch ist es, dass es ständig neue Programme gibt. In obigem Blogeintrag werden die Programme Shotwell und Gnote erwähnt. Shotwell ist ein Foto-Managementprogramm und tritt die „Nachfolge“ von F-Spot an, da es das standardmäßig installierte Programm zur Fotoverwaltung in Fedora 13 sein wird. Gleiches gilt für Gnote, das Tomboy als Programm für Notizen ersetzt.

Auch wenn ich den Vorteil der neuen Programme sehe, so ist der Aufwand, der durch die ständige Neuorganisation aufgrund der neuen Programme entsteht doch erheblich. Ich beneide ein wenig die Leute, die seit Jahren Programme wie iTunes für ihre Musik einsetzen oder Picasa für ihre Fotos. Sie haben wenigstens nicht das Problem, dass aufwändig und in stundenlanger Kleinarbeit erstellte Bibliotheken mit dem nächsten Release neu erstellt werden müssen. Gerade bei den Sachen, die sich über einen langen Zeitraum ansammeln, also hauptsächlich Fotos und Musik ist dieser ständige Wechsel einfach nervig!

Daher, liebe Softwareentwickler: Bitte stellt sicher, dass wenn schon ein Wechsel der Programme forciert wird, wenigstens alle Daten sauber übernommen werden können!

Nokia E-Serie – Schein oder Sein?

Ich habe mir zum Vergleich ein Nokia E71 und ein Nokia E75 geholt.
Das E75 kam zuerst an – Tastaturbeleuchtung defekt, direkt wieder eingeschickt. Der große Gewinner hierbei: DHL. Ansonsten fühlte es sich aber ganz gut an, zumindest soweit ich das in 10 Minuten beurteilen konnte.

Dann bekam ich mein E71. Weil es ja schon was älter ist, habe ich es erstmal an den Nokia Software Updater angeschlossen. Eine neue Firmware war tatsächlich verfügbar, also runtergeladen, installiert. Daten gehen dabei verloren, macht aber ja nix, ist ja noch nichts drauf. (Wieso braucht man für ein Firmware-Update eigentlich eine SIM-Karte?) Update wird laut Anzeige erfolgreich abgeschlossen, das Telefon startet neu – und verlangt die Eingabe des Sperrcodes. Hm, Handbuch angeschaut – 12345. „Fehlerhafter Code“. WTF? Nochmal – wieder falsch. Google angeschmissen – ich bin nicht allein: http://discussions.europe.nokia.com/discussions/board/message?board.id=swupdate&thread.id=48243

[UPDATE]

Der korrekte Sperrcode lautet 0000

Die Eingabe ist nur nicht ganz so einfach, da nach Eingabe der vierten Null im Display nur noch 000 angezeigt wird, denn das scheint in einigen Ländern eine Notrufnummer zu sein. Zur Lösung muss man einmal die Löschen-Taste drücken, dann kann man die vierte Null normal eingeben, das wird dann vom Handy akzeptiert.

Trotz gefundener Lösung ein inakzeptables Verhalten!

[UPDATE ENDE]

Bilanz: Zweimal Nokia E-Serie, zweimal keine 30 Minuten Funktionalität genießen können. Mein Sony Ericsson K800i läuft übrigens seit über drei Jahren problemlos …