Just as a warning:
If you use LVM-snapshots better stop it for the root filesystem. If your root-filesystem is on an LVM and you have a snapshot on it, dracut will be unable to boot the system.
Instead you will fall into the dracut emergency console, which sadly misses vi (or any editor). Because to repair the system you need to delete the snapshot and to be able to delete it you need to edit lvm.conf.
This post started as a question, but during writing a colleague managed to bring up a small workaround to get the system bootable again:
sed -i -e ‘s/locking_type = 4/locking_type =1/’ /etc/lvm/lvm.conf
then you are able to delete the snapshot.
then you can reboot the system and should have a working system again.
But why does the system fail to boot just because of a snapshot?
are you in a position to open a service request for this issue? It looks well worth it…
Regards,
Jens[/QUOTE]
Hi Jens,
i’m not sure if this is worth burning one of our few SRs.
but I found a fix that prevents this. It’s actually a bug in dracut: It forgets to add the dm-snapshot module to the initramfs. This means volumes with snapshots cannot be mounted on boot.
The funny thing is: If you do “mkinitrd” while having a snapshot active then dracut will produce a working initramfs.
Permanent solution is adding “dm-snapshot” to add_drivers in /etc/dracut.conf or drop a similar snippet into /etc/dracut.conf.d. You probably need more modules added if you use different lvm-features (thin-provisioning comes to my mind).
If I find the time I post a followup to the bug i filed via the bugreport form.