Windows 10 update changes partition table and breaks GRUB

It’s holiday season and so I got a hold of playing some games longly missed on Windows. Booting Windows 10 certainly unveiled several pending updates (Antivirus, Geforce, Windows updates). Since Windows 10 does not explicitly tell about big updates anymore I just did let it reboot several times, waiting for manual grub selection then.

Though this time the update essentially broke GRUB. “error: unknown filesystem. Entering rescue mode…” is certainly not what I expect from a Windows 10 update. After googling a bit I found this thread including an explanation as well as a solution for the problem: The Windows 10 update adds yet another hidden partition, but essentially rewrites the partition table which then breaks GRUB finding the correct /boot partition containing grub2/. Congrats Microsoft!

So, Windows 10 “Upgrade to Windows 10 Home, version 1511, 10586” breaks grub2 because boot block grub2 still thinks it should boot grub2 from (hd0,msdos2) when it now needs to boot from (hd0,msdos3).

The solution is simple but nasty without bash-completion and English keyboard layout on a German keyboard.

First find the boot partition containing the grub2/ directory.windows10_upgrade_dec2015_breaks_grub

grub rescue> ls (hd0,msdos1)/grub2
error: unknown filesystem.
grub rescue> ls (hd0,msdos2)/grub2
error: unknown filesystem.
grub rescue> ls (hd0,msdos3)/grub2
./ ../ themes/ i386-pc/ locale/ fonts/ grubenv grub.cfg

Next set the changed boot prefix and root attributes:

grub rescue> set prefix=(hd0,msdos3)/grub2
grub rescue> set root=(hd0,msdos3)
grub rescue> set
grub rescue> insmod normal
grub rescue> normal

Change from “rescue” to “normal” GRUB mode, and quickly select Fedora from the boot menu. In order to fix GRUB log into Fedora, open a terminal and become root. Now generate a new grub configuration.

sudo -i
grub2-mkconfig -o /boot/grub2/grub.cfg
grub2-install /dev/sda

Reboot and the GRUB menu should be fixed. Now safely choose to continue the Windows 10 upgrade.

Upgrade to Windows 10 on dual-boot systems

Upgrading Windows 10 on a dual-boot system is not that easy. After fetching KB3035583 and KB2952664 and reserving my upgrade copy on Windows 7 Professional x64 the setup still said “Something happened. We can’t tell if your PC is ready to continue installing Windows 10. Try restarting setup.”

The reason for this seems to be dual-boot installations only. First off, change the default boot entry to Windows.

windows7_mark_partition_as_activeAfterwards I did not want to override Grub with my Fedora 22 installation, but was looking into alternative solutions for error 800703ed. This tip about marking the C: partition as active partition did the trick – the Windows Update is now downloading Windows 10.





Getting ready for installing my Icinga 2 development environment 🙂

Change default boot entry in Grub2 on Fedora 22

Upgrading Windows 7 to 10 does not like dual-boot systems where Windows is not the default (likely due to automated reboots during upgrade). In order to fix this problem, we’ll need to change the boot order (or, the default entry).


# grep "submenu\|^\menuentry" /boot/grub2/grub.cfg | cut -d "'" -f2
Fedora (4.1.6-200.fc22.x86_64) 22 (Twenty Two)
Fedora (4.1.3-201.fc22.x86_64) 22 (Twenty Two)
Fedora (4.1.3-200.fc22.x86_64) 22 (Twenty Two)
Fedora, with Linux 0-rescue-46724b4128e8471db41e1e7efe9c8aeb
Windows 7 (loader) (on /dev/sda1)
Windows 7 (loader) (on /dev/sde1)

# grub2-editenv list
saved_entry=Fedora (4.1.6-200.fc22.x86_64) 22 (Twenty Two)

# grub2-set-default "Windows 7 (loader) (on /dev/sda1)"
# grub2-editenv list
saved_entry=Windows 7 (loader) (on /dev/sda1)

Logitech K800 wireless not working on dm-crypt passphrase

This bug did bite me in the past with Kernel 3.2 and Debian testing too, and I consider the Logitech wireless keyboard drivers in a similar tested fashion such as NVIDIA proprietary drivers – pretty much exotic and hard to maintain all the changes.

It’s not fun once you’ve chosen the grub entry and are prompted to enter your password for the encrypted LVM in order to boot your entire system – and nothing happens on the Logitech K800 wireless keyboard. But before it did work on selecting the correct grub entry.

Some googling for the error unveiled several threads providing insights and workaround fixes. This one told me that dracut is the root cause being responsible for loading the logitech kernel module before cryptsetup would prompt for the password. Which totally makes sense.

So how to convince dracut to load the logitech driver? It actually tries to do so already. So the initial workaround below did not work.


# vim /etc/dracut.conf

add_drivers+=" hid-logitech-dj "

# dracut -f

In a different manner, it came up that the kernel module had been renamed recently from “hid-logitech-dj” to “hid-logitech-hidpp”. Renaming something normally breaks all other dependencies, but looking at this fix – well, hardcoding everything somewhere in a shell script, oh my.

While waiting for an updated dracut, either patch the – which might break on dracut package update again.


imagine ~ # yum install dracut
imagine ~ # cp /usr/lib/dracut/modules.d/90kernel-modules/ /usr/lib/dracut/modules.d/90kernel-modules/
imagine ~ # vim /usr/lib/dracut/modules.d/90kernel-modules/
imagine ~ # diff -ur /usr/lib/dracut/modules.d/90kernel-modules/ /usr/lib/dracut/modules.d/90kernel-modules/
--- /usr/lib/dracut/modules.d/90kernel-modules/	2015-04-03 12:45:32.779223333 +0200
+++ /usr/lib/dracut/modules.d/90kernel-modules/	2015-04-03 12:45:45.843129483 +0200
@@ -45,7 +45,7 @@
         instmods yenta_socket scsi_dh_rdac scsi_dh_emc \
             atkbd i8042 usbhid hid-apple hid-sunplus hid-cherry hid-logitech \
-            hid-logitech-dj hid-microsoft firewire-ohci \
+            hid-logitech-dj hid-logitech-hidpp hid-microsoft firewire-ohci \
             pcmcia usb_storage nvme hid-hyperv hv-vmbus \

Or fix the dracut configuration for loading the correct additional driver. Note: Only rebuild the image for 3.19.x – the renamed driver does not exist in 3.18.x and below. (I did boot the old kernel allowing me to drecrypt the system).


# vim /etc/dracut.conf

add_drivers+=" hid-logitech-hidpp "

# dracut -f /boot/initramfs-3.19.1-201.fc21.x86_64.img 3.19.1-201.fc21.x86_64

Resize encrypted LVM on Fedora 21

It’s not about resizing the actual logical volume’s partition, but the mapped /dev/dm-XX device mounted inside /etc/fstab as /home.

Failed attempts:

# lvextend -L100G /dev/luksvg/home

# resize2fs /dev/luksvg/home
resize2fs 1.42.11 (09-Jul-2014)
resize2fs: Das Gerät oder die Ressource ist belegt beim Versuch, /dev/luksvg/home zu öffnen
Es kann kein gültiger Dateisystem-Superblock gefunden werden.

# lvresize --resizefs --size 100G /dev/luksvg/home 
fsck von util-linux 2.25.2
  Size of logical volume luksvg/home unchanged from 100,00 GiB (25600 extents).
  Logical volume home successfully resized
fsadm: Filesystem "crypto_LUKS" on device "/dev/mapper/luksvg-home" is not supported by this tool
  fsadm failed: 1


# lvextend -L100G /dev/luksvg/home

# ls -la /dev/disk/by-label/home
lrwxrwxrwx. 1 root root 11  6. Feb 14:56 /dev/disk/by-label/home -> ../../dm-12

# resize2fs -p /dev/dm-12
resize2fs 1.42.11 (09-Jul-2014)
Dateisystem bei /dev/dm-12 ist auf /home eingehängt; Online-Größenänderung ist
old_desc_blocks = 5, new_desc_blocks = 7
Das Dateisystem auf /dev/dm-12 is nun 26213888 Blöcke lang.

Online resizing works in a similar fashion with the root filesystem.

Git sub modules push creates remote error

When using git submodules it’s sometimes necessary to push local changes directly to the upstream origin. In older git versions it was possible to just edit the main `.git/config` file and change the git submodule origin from ‘git://’ to ssh.

michi@imagine ~/coding/icinga/icinga-core/docbook (master) $ grep -A 1 docbook ../.git/config
[submodule "docbook"]
url =

michi@imagine ~/coding/icinga/icinga-core/docbook (master) $ git push origin master
fatal: remote error: access denied or repository not exported: /icinga-doc.git

But apparently this does not work anymore. So where’s the problem? Check the remote push origin:

michi@imagine ~/coding/icinga/icinga-core/docbook (master) $ git remote -v
origin git:// (fetch)
origin git:// (push)

Ok, nothing has changed. Googling leads to this thread.

Editing the git submodule config fixes the problem.

michi@imagine ~/coding/icinga/icinga-core/docbook (master) $ grep -B 1 icinga-doc ../.git/modules/docbook/config
[remote "origin"]
url =