Hard time upgrading to Fedora 19 with fedup + LUKS encrypted drive

Hard time upgrading to Fedora 19 with fedup

Seems that using crypto is still not smooth and easy with Fedora. I have both root and home residing on LUKS encrypted LVM volume.

This time I was prepared to have plenty of space in advance for the fedup upgrade (5+GB) and mentally prepared for some glithes, but still I spent some quality time in getting it up and running again.

First phase of Fedup went quite smooth this time (having plenty of free space). Download of dependencies ad preparation for the install was quite OK.
fedup-cli --network 19

After the reboot still everything was fine and all the packages were updated. There was just one moment where the installator was actually asking for the LUKS password on console, but the prompt was overwritten with some status message. It took me some time to figure out it is actually asking me for a password. So far so good.

The real problems came after the first reboot to F19 where the initrd ramdisk was apparently not expecting to have the root volume on a LUKS encrypted LVM drive.
#Open the LUKS device cryptsetup luksOpen /dev/sda5 luks-sda5 #Activate the LVM volumes on the fresh opened LUKS device lvm vgscan lvm vgchange -a y mount /dev/vgsystem/fc19 /sysroot chroot /sysroot

Even tried to mount the standard filesystems to be able to operate the yum database and other stuff: #!/bin/bash mount -t proc proc /proc mount -t sysfs sysfs /sys mount -t devtmpfs devtmpfs /dev mount -t tmpfs tmpfs /run mount -t securityfs securityfs /sys/kernel/security mount -t selinuxfs selinuxfs /sys/fs/selinux mount -t tmpfs tmpfs /dev/shm mount -t devpts devpts /dev/pts mount -t tmpfs tmpfs /sys/fs/cgroup mount -t cgroup cgroup /sys/fs/cgroup/systemd mount -t pstore pstore /sys/fs/pstore mount -t cgroup cgroup /sys/fs/cgroup/cpuset mount -t cgroup cgroup /sys/fs/cgroup/cpu,cpuacct mount -t cgroup cgroup /sys/fs/cgroup/memory mount -t cgroup cgroup /sys/fs/cgroup/devices mount -t cgroup cgroup /sys/fs/cgroup/freezer mount -t cgroup cgroup /sys/fs/cgroup/net_cls mount -t cgroup cgroup /sys/fs/cgroup/blkio mount -t cgroup cgroup /sys/fs/cgroup/perf_event

Putting the system half-way up this way was usefull to be able to move around and read and change what was necessary, but actually didn't lead me to solution. I have tried to regenerate the ramdisk, but it didn't help: mkinitrd /boot/initramfs-3.11.2-201.fc19.x86_64.img 3.11.2-201.fc19.x86_64

Also I have tried to run the commands from the kernel post installation scripts, but it didn't helped. rpm -q --scripts kernel-3.11.3-201.fc19.x86_64 /sbin/new-kernel-pkg --package kernel --install 3.11.3-201.fc19.x86_64 /sbin/new-kernel-pkg --package kernel --mkinitrd --dracut --depmod --update 3.11.3-201.fc19.x86_64 /sbin/new-kernel-pkg --package kernel --rpmposttrans 3.11.3-201.fc19.x86_64

Last resort, which actually worked for me was to use the old Fedora 18 kernel to boot into Fedora 19 system. Fedora 18 kernel luckily remained in the grub menu after the Fedup upgrade. I was able to boot it and fix the FC19 kernel resp. the init ramdisk. yum remove kernel-3.11.2-201.fc19.x86_64 yum install kernel-3.11.2-201.fc19.x86_64

After doing this I was finally able to boot into Fedora 19 kernel + Fedora 19 system (+ some manual changes to /etc/grub2.cfg related to my dualboot setup with Windows7+bitkeeper encryption)

Acoording to this article it might have been enough running the dracut to regenerate the init ramdisk: dracut --force or the fix mentioned in the bugzilla 980587: dracut --regenerate-all --force

For completeness here is also link for the Dracut toubleshooting instructions from FedoraProject.