Unfortunately I was not able to find this piece of information on any public materials:
You need "#13" gola key on at least 17cm extension to be able to replace the car battery in Skoda Octavia II.
I was able to by me such long standalone key in OBI :D
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.
